微服务经验分享&杂谈

微服务架构

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

微服务核心要素

微服务架构实例

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

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

咱们一开始设计出以下图的服务架构：

对比的微服务的标准： 符合单独部署； 符合进程独立； 服务间通讯使用rpc，符合轻量级。

专一于一件事这一点，看起来是符合，可是咱们结合两个实际流程：

支付流程：

注册流程：

咱们能够看到，除了微服务自己的逻辑，在具体流程下，部分微服务还要考虑如何和别的服务串起来，也就是说，原有的逻辑层，并未消失，而是分散到了各个微服务，职责并不单一！

因而架构进化：

能够看到，多了一层聚合层。专门负责聚合领域层的数据，对外提供接口。而领域层的微服务，只用承担好本身领域的职责，提供出独立，通用的服务接口。但在业务扩展的过程当中，咱们发现聚合层业务愈来愈重，因而乎，咱们须要继续演进：

聚合层也作了拆分，因而，领域层是一组微服务，聚合层是一组微服务，职责清晰。聚合层划分一般能够考虑到实际业务的前端界面，页面为最小粒度来考虑聚合层微服务，不失为一个参考办法，即一个页面或者几个页面为一个微服务。

微服务的优点与劣势

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

微服务 优势:

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

缺点

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

经验总结

经验

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

总结

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