微服务经验分享&杂谈

1,148

微服务架构

一个应用,拆分为多个小服务,这样的架构方式,就是微服务架构

微服务核心要素

微服务架构实例

我们拿一个电商贷款场景(如京东白条)划分微服务举例,以便后面的描述。 购买场景主要有如下关键服务。

  • 账户服务:负责管理用户基本信息,如姓名,性别,身份证等
  • 额度服务:用户所能使用的额度。
  • 支付服务:负责完成支付操作。
  • 账单服务:指定时间生成账单给用户。
  • 风控服务:通过数据分析,管理用户操作权限。

我们一开始设计出如下图的服务架构:

对比的微服务的标准: 符合单独部署; 符合进程独立; 服务间通信使用rpc,符合轻量级。

专注于一件事这一点,看起来是符合,但是我们结合两个实际流程:

支付流程:

注册流程:

我们可以看到,除了微服务本身的逻辑,在具体流程下,部分微服务还要考虑如何和别的服务串起来,也就是说,原有的逻辑层,并未消失,而是分散到了各个微服务,职责并不单一!

于是架构进化:

可以看到,多了一层聚合层。专门负责聚合领域层的数据,对外提供接口。而领域层的微服务,只用承担好自己领域的职责,提供出独立,通用的服务接口。但在业务扩展的过程中,我们发现聚合层业务越来越重,于是乎,我们需要继续演进:

聚合层也做了拆分,于是,领域层是一组微服务,聚合层是一组微服务,职责清晰。聚合层划分通常可以考虑到实际业务的前端界面,页面为最小粒度来考虑聚合层微服务,不失为一个参考办法,即一个页面或者几个页面为一个微服务。

微服务的优势与劣势

五年前加入腾讯时还是使用典型的logic-server架构,后面微服务如燎原之火,成了新的主角。后续经历的上市外企,tmd中的一家,微服务也是大行其道。也时常思考微服务的必要性。

微服务 优点:

  1. 模块小而独立,方便新人上手;
  2. 发布时候,只发布对应的微服务,减少依赖和查错成本。
  3. 由于拆分得比较细,重构时不容易背太大的技术债务。
  4. 新的微服务中,可以大胆使用新技术,不受原有模块的制约。

缺点

  1. 容易只关注自己一亩三分地,对整体把握不足。
  2. 微服务真正的难点在于划分,如果划分不当,那么服务存在耦合,比如一些状态信息,是服务b管理,但是服务a又十分需要,此时无论是通知还是轮询,都是很麻烦的事。
  3. 一个完整数据,可能需要从多个服务反复获取,如果存在层级关系,可能一个请求就导致几十个rpc。
  4. 后台开发中每个其他服务都是不可信的,都需要做错误处理,那此时聚合层如果调用5个领域服务成功,一个领域失败,抛出错误还是降级服务,也是个让人得具体思考的问题。

经验总结

经验

  • 注册等数据初始场景,只能做同步调用,拿上面的贷款场景举例,如果账户额度初始化都没成功,那么支付的时候也会有问题。所以一步错,必须返回错误给前端。此时考虑回滚,但回滚成本太高,分布式事务是一个很难解决,并且很重的场景。而注册这种用户必须得重试的场景,可以依赖接口可重入解决。
  • 能异步的场景,尽量异步,比如支付完成,入帐账单,账单并不需要实时,此时就可以通过消息队列推送。
  • 不要过度划分,十多个服务打交道的成本,比想象中大很多。一开始粒度可以稍微大点,后面再划分。

总结

  1. 微服务最大的贡献,个人认为在人力调度上,一个新人可以很快地上手某个微服务而不需要其他业务背景。如果团队比较稳定,那么建议服务划分比较粗一点,人员流动很厉害,就可以稍微细些。
  2. 不要为用微服务而用,其不是银弹。小型公司创业阶段,就图短平快,没必要扯这些虚的。
  3. 微服务容易让人只管自己一亩三分地。而划分微服务也是个很考经验的事情。所以如果要使用微服务,需要有一个人来专门研究微服务,由他来整体划分和持续调整。
  4. 微服务因为调用服务间变得很多,如果是比较难发生的异常场景,去保证自动兼容或修复成本太高了。此时,可以考虑轻轻地打一条日志或一些其他后台监控手段,人工解决。