工程师日记20181007

今天聊一聊后台工程师(java初级工程师)的工作日常,微服务还有API。

导语:哎日常工作不就是增删改查吗!

其实初级工程师的日常工作还真是增删改查。不过却也没那么简单。谈一下需要做好的工作吧

  1. 接口设计

  2. 代码设计

API设计其实不是一个简单的活,业界认可的就是restful 规范,其次,就是接口文档。要是你能够定义一套规范的restful 的api,那层次算特别高的了。
其次,要维护一套文档。
再者,api是对外的,对内的,就是你的代码结构,一个好的项目就是23种设计模式的有机结合。用好这写设计模式,也是需要时间沉淀的。
最后,就是微服务的划分。其实微服务的划分这个有点属于架构师的工作范畴了,常见是基于业务领域的服务划分,划分过细的话,分分钟一个保存操作,涉及三四个分布式事务。

本篇就讨论一下微服务API吧

一、微服务的API设计

1.1.思想

之前领导是一个特别牛逼的偏前端的全栈工程师,那时候,我刚毕业对于一些api的设计理解有点偏,就是有点像是乱开接口。参数类型等等,定义不规范。那时候,给我看了几家他就职过的大厂的接口的demo,引导我那种design在哪种场景更加合适。还有小接口,大接口。

总结起来就是:

不是为了一个功能方法而去开放一些需要的接口,而是为了一个功能模块,我们后台需要去开一套维度合适的接口。

有一个特别快的提升方式,跟一个前端工程师交朋友,每天问他,现在给的接口用起来会不会更爽一点。

1.2.服务提供者,和消费者

见过几个厂的微服务架构。其实大同小异。对于服务的提供者和消费者,都有自己的见解。但是在我看过的几个项目,也有跟其他大神讨论过,可以总结出来,大概有两种形式吧:

  1. 提供者既是消费者:
  2. 提供者与消费者分层:

在这里得讲两个概念,外部接口,内部接口。

外部接口其实没啥可解释的。

内部接口,就是提供给其他微服务的接口,可以理解为service层的远程实现,一般来说,是不对外开放。

服务提供者,就可以理解为是平时单机架构里面的service层,

而消费者,就是调用一或多个service,进行业务逻辑操作,在某厂称为business层。

消费者开的是外部接口,提供者开的是内部接口。

在下面的项目里面,其实就是提供者既是消费者,但是,我在zuul里面没有做控制而已。

1.3.微服务的API以及接口

对于服务的消费者,一般写的API,都是要遵循restful规范。

对于服务的提供者,我感觉,把他看成一个用http协议的远程接口就OK了,如果要用restful规范,会失去一定的灵活性(在做接口设计的时候是可以体会得到的)。
从两个维度说吧:

  1. 框架方面

比如说,阿里的dubbo,新浪的motan,的服务提供者都是RPC框架实现的。你说要基于restful 吗?

  1. 其他方面(分布式事务等)

先普及一下分布式事务:

一般来说,微服务架构,多数使用的是柔性事务(基于业务代码的事务,不是基于资源的事务)有三种:

  1. 基于消息的最终一致性事务
  2. TCC事务
  3. 最大努力通知型事务

比如说,一个提供者接受到一个请求,需要跨服务保存操作。这样就涉及到分布式事务,使用消息的最终一致性事务的话,是发一条消息过去,而用TCC的话,一个保存操作又有了一个取消接口,确认接口。一个服务提供者,写的接口也要遵循 restful design的话,******,所以说,不要太较真,物极必反。

接口校验

其实过滤器是公司统一的,其次就是一些接口校验了。其实也没啥好说的。一般@Vaild校验的都是格式,长度,大小之类的。判空的一般会在Controller里面的业务逻辑里面做。

异常处理

其实更准确的来说,是状态码。
状态码处理的话主要分两种,一种是消费者的,一种是提供者的。
消费者的状态码:
其实就是给前端的状态码,比如说,有时候,你点击一个按钮,显示,服务器繁忙请稍后再试,很多时候,前端显示的提示信息,都是根据后台给的状态码,还有信息显示的。
提供者的状态码:
在Spring Cloud中,可以理解为Feign Client调用服务失败,要怎么处理,比如说,你去调一另外一个服务查询,返回500,其实可能有时候,那个服务当掉了,这时候,你重试,再去调一次(基于负载均衡,调的是另外一台服务器)可能就OK了,但是,如果,返回个不存在,这时候你重试是没有意义的。

最后上代码

allen-api-demo用到了 SPRING MVC + SWAGGER + OAUTH

水平有限,只是写了一些API文档的维护,校验,异常处理,接口权限,返回视图的简要使用方式。

再来一个今年一月多写的

flexible-transaction-event-demo 基于消息的最终一致性事务

TCC的,看了挺多设计方法,也有再加一个事务的协调者的。后面再慢慢分享出来吧。

结语
自己的学习路程是先打好基础,然后分课题学习。我觉得大概我研究完这几个课题应该就有中级工程师水准了

  • 软件工程
  • API设计
  • 分布式事务
  • 消息中间件
  • 数据库
  • 设计模式

自己研究的比较好的课题是API设计,然后自己花的最多时间去吃的是分布式事务。再者,

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,951评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,606评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,601评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,478评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,565评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,587评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,590评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,337评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,785评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,096评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,273评论 1 344
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,935评论 5 339
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,578评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,199评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,440评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,163评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,133评论 2 352

推荐阅读更多精彩内容