微服务是一种新型的应用架构术语，最准确的定义来自于两位大神（JamesLewis和MartinFowler）。原文翻译后，简单来说就是：一种设计可独立部署和运行的软件应用程序的方法。这些服务主要围绕业务能力构建，可以使用不同的编程语言和不同的数据存储技术，在组织结构上具有一些共同的特点。目前，越来越多的组织在应用架构上逐渐从单体架构向微服务架构演进。殊不知，盲目跟风只会增加软件开发和运维的成本。始终坚持“拆是手段，融合是目的”为原则，提高应用交付效率，实现架构体系的可持续演进。今天给大家讲讲我日常工作中经常用到的一些微服务设计参考，但是我想说的是，它不是万能的，也不是绝对的，所以不要指望它能解决你所有的微服务设计问题，有时还需要考虑一些客观因素的存在，尤其是遗留系统。准则一：服务无状态微服务内部应该是无状态的，即将有状态的信息从微服务中剥离出来，简单地成为一个无状态的计算节点，从而快速实现动态伸缩的水平扩展能力。同时，不会对应用系统产生额外的成本投入或代码入侵。例如：剥离session信息，放到分布式缓存中托管。准则二：前后端分离传统应用通常将前端代码和后端代码集成在一起，导致前后端代码强耦合，不便于后续管理和维护。建议前后端分离。前端更强调交互体验和Flexibility，后端更强调能力抽象和稳定性，而微服务只承担后端服务或接口，不做前端展示或渲染。准则三：业务抽象通常，设计者会从技术角度采用数据驱动的自下而上的设计模式，强调数据结构，即先确定数据结构，再根据数据结构的关系进行微观结构。服务拆分，但微服务一般适用于解决业务复杂度高的场景。从业务角度，建议采用领域驱动的自上而下的设计模式，强调业务能力，即优先考虑业务场景，然后根据业务场景建立统一的语言，定义业务概念的边界。准则四：用例收敛根据业务场景流程的需要识别微服务之间的调用关系，并进一步验证其合理性。一般来说，我们建议用例跨越的服务越少越好。一方面，它可以减少系统负载。另一方面，响应延迟可以降低服务之间的依赖程度。如果依赖链接太长，依赖链上的任何微服务发生变化，链后面的任何微服务都可能需要改变。准则5：实体融合在一些业务场景中，一个实体信息需要在两个或多个微服务之间进行单向或双向同步，即一个实体由多个微服务管理，从而减少微服务的数量。服务之间的依赖程度可能会导致数据一致性问题。建议同一个实体不要跨越太多的微服务。实体参与同步的微服务越多，就越容易暴露其数据一致性问题。准则六：高内聚微服务的内聚性越高，设计模型的可理解性就越强。在根据业务流程和场景识别出所有实体后，需要分析实体之间的关系，优先识别一致的生命周期。对实体进行分类，然后根据实体与聚合根的区别，明确各个聚合根的边界。微服务的最小单位通常是聚合根，可以根据技术成本评估确定。一个微服务根包含多少个聚合，但不建议拆分一个聚合根。类型唯一标识符生命周期只读判断相等聚合根全局唯一独立生命周期无标识符聚合根对应实体内唯一从属聚合无标识符值对象无唯一标识符无生命周期是属性指南七：低耦合特性微服务耦合下层灵活性越大，设计模型就越能适应系统需求的变化。如果微服务之间的联系越紧密，独立性就会越差，微服务的管控就会变得非常困难。例如：某个微服务契约发生变化后，所有依赖的微服务都会受到影响。因此，需要深入分析微服务之间调用关系的强弱，根据依赖强弱梳理上下游关系，将这种影响降到最低。准则8：首先垂直划分。从业务领域的角度垂直拆分服务。在屏蔽任何技术实现细节的情况下，先对业务能力的服务进行分类，然后根据服务之间的关联程度划分为一个微服务，其中，满足每个微服务只承担一类业务能力，而后续的变化只是由于这一类业务的变化，而这些变化尽可能在一个闭环的微服务中完成，不影响其他服务。最后根据拆分后引入的技术债权衡决定是否合并。准则九：后水平划分从非功能角度对微服务进行水平划分，通常会从服务隔离性、可靠性、可扩展性等几个方面综合考虑评估。可以根据迭代的变化率进行拆分，避免敏感服务的变更升级影响稳态服务。根据业务的服务级别进行拆分。当发生故障时，优先保证关键核心业务的正常运行，并根据业务的性能要求。拆分是为了避免服务因为性能隔离问题而整体瘫痪，最后根据拆分后引入的技术债来决定是否合并。准则10：自组织能力自组织能力是实现微服务的关键。每个团队都需要负责微服务的整个生命周期。所有团队成员都可以在一个独立的微服务上下文中工作，即：微服务应用架构需要尽可能适配团队之间的组织结构，做到独立决策，独立治理，团队之间也是交互连接的以松耦合的方式。总结一下，这些是我经常使用的一些技巧。希望对你有所帮助，但请永远记住，“拆”永远不是目的，它是一种手段。通过“拆”，就是让微服务能够更好的协同工作，最终达到“合”的效果。
