微服务架构
一个应用,拆分为多个小服务,这样的架构方式,就是微服务架构
微服务核心要素
微服务架构实例
我们拿一个电商贷款场景(如京东白条)划分微服务举例,以便后面的描述。 购买场景主要有如下关键服务。
- 账户服务:负责管理用户基本信息,如姓名,性别,身份证等
- 额度服务:用户所能使用的额度。
- 支付服务:负责完成支付操作。
- 账单服务:指定时间生成账单给用户。
- 风控服务:通过数据分析,管理用户操作权限。
我们一开始设计出如下图的服务架构:
对比的微服务的标准: 符合单独部署; 符合进程独立; 服务间通信使用rpc,符合轻量级。
专注于一件事这一点,看起来是符合,但是我们结合两个实际流程:
支付流程:
注册流程:
我们可以看到,除了微服务本身的逻辑,在具体流程下,部分微服务还要考虑如何和别的服务串起来,也就是说,原有的逻辑层,并未消失,而是分散到了各个微服务,职责并不单一!
于是架构进化:
可以看到,多了一层聚合层。专门负责聚合领域层的数据,对外提供接口。而领域层的微服务,只用承担好自己领域的职责,提供出独立,通用的服务接口。但在业务扩展的过程中,我们发现聚合层业务越来越重,于是乎,我们需要继续演进: 聚合层也做了拆分,于是,领域层是一组微服务,聚合层是一组微服务,职责清晰。聚合层划分通常可以考虑到实际业务的前端界面,页面为最小粒度来考虑聚合层微服务,不失为一个参考办法,即一个页面或者几个页面为一个微服务。微服务的优势与劣势
五年前加入腾讯时还是使用典型的logic-server架构,后面微服务如燎原之火,成了新的主角。后续经历的上市外企,tmd中的一家,微服务也是大行其道。也时常思考微服务的必要性。
微服务 优点:
- 模块小而独立,方便新人上手;
- 发布时候,只发布对应的微服务,减少依赖和查错成本。
- 由于拆分得比较细,重构时不容易背太大的技术债务。
- 新的微服务中,可以大胆使用新技术,不受原有模块的制约。
缺点
- 容易只关注自己一亩三分地,对整体把握不足。
- 微服务真正的难点在于划分,如果划分不当,那么服务存在耦合,比如一些状态信息,是服务b管理,但是服务a又十分需要,此时无论是通知还是轮询,都是很麻烦的事。
- 一个完整数据,可能需要从多个服务反复获取,如果存在层级关系,可能一个请求就导致几十个rpc。
- 后台开发中每个其他服务都是不可信的,都需要做错误处理,那此时聚合层如果调用5个领域服务成功,一个领域失败,抛出错误还是降级服务,也是个让人得具体思考的问题。
经验总结
经验
- 注册等数据初始场景,只能做同步调用,拿上面的贷款场景举例,如果账户额度初始化都没成功,那么支付的时候也会有问题。所以一步错,必须返回错误给前端。此时考虑回滚,但回滚成本太高,分布式事务是一个很难解决,并且很重的场景。而注册这种用户必须得重试的场景,可以依赖接口可重入解决。
- 能异步的场景,尽量异步,比如支付完成,入帐账单,账单并不需要实时,此时就可以通过消息队列推送。
- 不要过度划分,十多个服务打交道的成本,比想象中大很多。一开始粒度可以稍微大点,后面再划分。
总结
- 微服务最大的贡献,个人认为在人力调度上,一个新人可以很快地上手某个微服务而不需要其他业务背景。如果团队比较稳定,那么建议服务划分比较粗一点,人员流动很厉害,就可以稍微细些。
- 不要为用微服务而用,其不是银弹。小型公司创业阶段,就图短平快,没必要扯这些虚的。
- 微服务容易让人只管自己一亩三分地。而划分微服务也是个很考经验的事情。所以如果要使用微服务,需要有一个人来专门研究微服务,由他来整体划分和持续调整。
- 微服务因为调用服务间变得很多,如果是比较难发生的异常场景,去保证自动兼容或修复成本太高了。此时,可以考虑轻轻地打一条日志或一些其他后台监控手段,人工解决。