一个应用，拆分为多个小服务，这样的方式，就是微服务架构
微服务核心要素
微服务架构实例
我们拿一个贷款场景（如京东白条）划分微服务举例，以便后面的描述。 购买场景主要有如下关键服务。
- 账户服务：负责管理用户基本信息，如姓名，性别，身份证等
- 额度服务：用户所能使用的额度。
- 支付服务：负责完成支付操作。
- 账单服务：指定时间生成账单给用户。
- 风控服务：通过数据分析，管理用户操作权限。
我们一开始出如下图的服务架构：
对比的微服务的标准： 符合单独部署； 符合进程独立； 服务间通信使用rpc，符合轻量级。
专注于一件事这一点，看起来是符合，但是我们结合两个实际流程：
支付流程：
注册流程：
我们可以看到，除了微服务本身的逻辑，在具体流程下，部分微服务还要考虑如何和别的服务串起来，也就是说，原有的逻辑层，并未消失，而是分散到了各个微服务，职责并不单一！
于是架构进化：
可以看到，多了一层聚合层。专门负责聚合领域层的数据，对外提供接口。而领域层的微服务，只用承担好自己领域的职责，提供出独立，通用的服务接口。但在业务扩展的过程中，我们发现聚合层业务越来越重，于是乎，我们需要继续演进：
聚合层也做了拆分，于是，领域层是一组微服务，聚合层是一组微服务，职责清晰。聚合层划分通常可以考虑到实际业务的前端界面，页面为最小粒度来考虑聚合层微服务，不失为一个参考办法，即一个页面或者几个页面为一个微服务。
微服务的优势与劣势
五年前加入腾讯时还是使用典型的logic-server架构，后面微服务如燎原之火，成了新的主角。后续经历的上市外企，tmd中的一家，微服务也是大行其道。也时常思考微服务的必要性。
微服务 优点:
- 模块小而独立，方便新人上手；
- 发布时候，只发布对应的微服务，减少依赖和查错成本。
- 由于拆分得比较细，重构时不容易背太大的技术债务。
- 新的微服务中，可以大胆使用新技术，不受原有模块的制约。
缺点
- 容易只关注自己一亩三分地，对整体把握不足。
- 微服务真正的难点在于划分，如果划分不当，那么服务存在耦合，比如一些状态信息，是服务b管理，但是服务a又十分需要，此时无论是通知还是轮询，都是很麻烦的事。
- 一个完整数据，可能需要从多个服务反复获取，如果存在层级关系，可能一个请求就导致几十个rpc。
- 后台开发中每个其他服务都是不可信的，都需要做错误处理，那此时聚合层如果调用5个领域服务成功，一个领域失败，抛出错误还是降级服务，也是个让人得具体思考的问题。
