​微服务，是一种新型的应用架构术语，而最准确的定义来自于两位大神（James Lewis和Martin Fowler）。

原文翻译后，简单来说就是：将软件应用程序设计为可独立部署运行的一种方式。这些服务主要围绕业务能力进行构建，可以采用不同的编程语言和不同的数据存储技术，并且在组织架构上存在一些共同的特征。

当下，越来越多的组织在应用架构上逐步从单体架构再向微服务架构进行演进，殊不知，盲目的跟风，只会让软件开发及运维成本日益剧增，我们应该始终坚持以“拆是手段，合是目的”为原则，从而提升应用交付效能，实现可持续演进的架构体系。

(资料图)

今天就跟大家来讲一讲，我在日常工作中常用的一些微服务设计参考，但我想说，它并不是万能的，也不是绝对的，所以不要指望它，能解决你所有的微服务设计问题，而且，有时候还需要考虑一些客观因素的存在，特别是历史遗留系统。

微服务内部应确保为无状态，即：将有状态信息从微服务中进行剥离，从而单纯的成为一个无状态的计算节点，以便可快速实现动态伸缩的横向扩展能力，同时对应用系统不产生额外的成本投入或代码侵入。例如：将会话信息剥离出来，放入分布式缓存中托管。

传统的应用通常会将前端代码与后端代码融合在一起，导致前后端代码强耦合，不便于后续的管理维护，建议进行前后端分离，前端更强调的是交互体验和灵活性，而后端更强调的是能力抽象和稳定性，而微服务仅承接后端服务或者接口，不承接前端展现或渲染。

通常设计人员会站在技术视角，采用数据驱动这种自下而上的设计模式，强调的是数据结构，即：优先确定数据结构，然后再根据数据结构的关系进行微服务拆分，但微服务一般适用于解决业务复杂度较高的场景，建议从业务视角，采用领域驱动这种自上而下的设计模式，更强调的是业务能力，即：优先明确业务场景，然后再根据业务场景建立统一语言，并对业务概念进行边界定义。

根据业务场景流程需要识别微服务间的调用关系，并对其进一步进行合理性的验证，在通常情况下我们建议用例跨越的服务越少越好，一方面能够降低系统的响应延迟，另一方面能够减少服务之间的依赖程度，若依赖链路过长，那么依赖链条上的任何一个微服务发生变更，其链条后的任何微服务均可能需要改变。

在某些业务场景下，需要两个或多个微服务间针对某个实体信息进行单向或双向同步，即：某个实体由多个微服务来管理，从而降低微服务间的依赖程度，但可能会引发数据一致性的问题，建议相同的实体所跨越的微服务不能太多，实体参与同步的微服务越多，其数据一致性问题就越容易暴露。

微服务的内聚性越高，设计模型的可理解性就越强，根据业务流程和场景识别所有实体后，需对实体间进行关系分析，优先识别出生命周期一致的实体进行归类，然后根据实体与聚合根的区别，明确每个聚合根的边界，微服务的最小单元通常是一个聚合根，可根据技术成本来评估并确定一个微服务中包括几个聚合根，但不建议对一个聚合根进行割裂。

微服务的耦合性越低，设计模型就能更快适应系统需求的变化，若微服务间联系越紧密，其独立性就会变得越差，微服务的管控治理也会变得十分困难，例如：某个微服务契约发生变化后，那么依赖的微服务将都会受到影响，因此需要深度分析微服务间的调用关系强弱，并根据依赖的强弱梳理上下游关系，从而将此影响减少到最低。

以业务领域视角对服务进行垂直拆分，在屏蔽任何技术实现细节的情况下，先对业务能力进行服务分类，然后再根据服务间的关联程度将其划分到一个微服务中，其满足每个微服务仅承担一类业务能力，且后续仅因这类业务发生变化而变化，以及这些变化尽可能在一个微服务中闭环完成，不需要影响其他服务，最后再根据拆分后所引入的技术债务进行权衡决定是否合并。

以非功能性视角对微服务进行水平拆分，通常会从服务的隔离性、可靠性、扩展性等几个方面进行综合评估考虑。可根据迭代的变化速率进行拆分，避免敏态服务的改动升级影响稳态服务，根据业务的服务水平进行拆分，在出现故障时优先确保关键核心服务的正常运作，根据服务的性能要求进行拆分，避免因性能隔离性问题导致服务整体瘫痪，最后再根据拆分后所引入的技术债务进行权衡决定是否合并。

自组织能力是实施微服务的关键所在，每一个团队需要对微服务的整个生命周期负责，所有团队成员的工作能够在独立的微服务上下文中，即：微服务应用架构需要尽可能的适配团队间的组织架构，从而能够独立决策独立治理，而团队和团队之间也是以一种松耦合性的方式进行交互连接。

综上所列，是我常用的一些招数，希望它能够对你有所帮助，但请永远记住，「拆」永远不是目的，它是一种手段，通过「拆」，是让微服务间能够更好的协同工作，最终达到「合」的效果。​