服务拆分准则

有很多个准则，这里拿两个罕用的介绍

1. 繁多职责 (SRP)

   • 扭转一个类应该只有一个理由。
     如果一个类承载了多个职责，那么，这个类就会非常不稳固。
     微服务架构下，应设计小、内聚、繁多职责的服务，那么会大大提高服务的稳定性。

2. 闭包准则 (CCP)

   • 包中所有类，应该是同类变动的一个汇合。
   • 也就是说，如果须要对包做调整，须要调整的类、变量等，都应在这个包之内。
     需要变更，改变须要两个耦合的包做调整，这是很大的危险。
     如果业务变更，只需调整同一个包下的类，那么就能够极大的改善，我的项目可维护性。
     微服务架构下，雷同起因须要扭转的服务，放在一个组件内。
     需要变动的变更、部署，代价升高；能够管制服务的数量。
     现实的状况下，一个变更只会影响一个团队。

失常开发中，在评估阶段，有很多因素导致，不能齐全的遵循原则。
为了保障日后的可维护性，尽量的依照准则，若不能齐全遵循，则提前准备分段，给日后保护应用。

• 代码是首先是给人读，而不是机器。
• 性能要求不高时，尽可能进步可读性。

拆分服务难点

1. 网络延时
   大量的接口调用。
   例如，http 接口的调用
   解决办法：
   apigateway，内网中先对某项性能 http、rpc 接口进行聚合
   合并相干性能的服务，应用函数调用，取代接口调用
2. 同步过程通信，可用性问题
   解决过程通信可用性问题。
   例如，创立订单，调用户服务验证，用户服务不可拜访
   解决办法：
   应用异步事件机制
   针对例子，应用异步事件，批改流程，创立订单分为：提交订单，验证用户等校验阶段，创立胜利，分阶段进步服务可用性
3. 服务间数据一致性
   某些操作，可能更改多个服务的数据。
   例子：
   餐馆承受订单，需更改 kitchen service 状态、delivery service 状态
   解决办法：
   TCC(Try Confirm Cancle)、
   SAGA、
   等
   https://zhuanlan.zhihu.com/p/…
4. 获取统一的数据视图
5. 上帝类
   上帝类是整个应用程序中，应用的全局类。
   例子：
   订单，蕴含，restaurant、delivery 等信息
   而 order 数据表蕴含了所有信息，拆分为 kitchen service、delivery service 就存在问题
   解决办法：
   应用 DDD
   对于例子，对 kitchen service、delivery service 别离实现本人服务外部的订单