微服务设计的十个步骤

近年来，「微服务」是非常热门的技术主题。微服务的好处是：1 可适应业务变化（例如：快速调整业务功能） 2 可适应业务「量」变化（例如：举办促销，业务量大增）。

而微服务的缺点也很明显：1 设计难度高 2维运难度高。关于「维运难度高」这一点，可以通过各种技术框架和工具来缓解。但第一点「设计难度高」就比较麻烦，因为设计微服务需要对技术和业务都有深度了解，也非常仰赖架构师的经验和建模方法论。

许多企业都号称使用微服务，但在我看来往往是假的微服务，主要的问题有三个：1 边界设计错误或太大 2 微服务之间耦合度高 3 介面品质低。

目前看来，似乎大家都是用DDD（领域驱动设计）的方法来设计微服务，但我非常怀疑DDD在此的实际效果（以后有机会再撰文讨论）。现在给大家介绍我自己的一个轻量级的方法，其中融合了我的三维技术架构，和运行/分析/控制三位一体思维，我把微服务的设计划分为十个步骤。

第一步是「场景分解」。我先把整体环境分解为用户、前端、后端、外部共四层，每一层还分为操作和资料，共有八个象限。把使用场景分解到这八个象限。

第二步是「资料建模」。在所有的场景分解完后，对已经出现在四个资料象限内的资料进行建模，重点在找出资料和资料之间的关係。

第三步是「强一致性的资料聚合」。把第二步里面的资料模型做聚合体设计，用的是DDD的Aggregate 原则：聚合体内的资料必须有强一致性。把出现在四个操作象限内的操作各自归类到适合的聚合体内。这一步骤是微服务设计的关键任务。

第四步是「X轴（业务）分解」。把第一步四层中的「前端」再分解为UI和App两层。把第一步四层中的「后端」再分解为API、服务、SPI三层。现在，前端和后端共有五层，分别为：UI、App、API、服务、SPI。

第五步是「Y轴（技术）分解」。把前一步骤的五层，各自独立分解为业务逻辑层、技术API层、技术服务层、技术SPI层。

第六步是「处理一致性失败」。当微服务之间的资料一致性出问题时，通常可以先利用「沖正」的方式来处理，如果「沖正」失败，再人为介入处理。这时候要同时考虑这些后续处理的比例和成本是否过高。如果成本太高，可能甚至需要调整微服务的边界来把最终一致性变为强一致性。

第七步是「设计讯息瀑布」。彻底解耦的微服务之间是透过讯息沟通的，讯息量可能非常大，甚至冲击系统稳定。我设计了所谓的讯息瀑布机制，来消除这个问题。在我的讯息瀑布机制中，讯息不会逆流。

第八步是「设计业务大数据」。对于这些系统运作过程中产生的业务资料（数据），在设计微服务的时候，可以同步设想要如何运用这些数据，找出其中的业务价值。

第九步是「Z轴（维运）分解」。把我们的在第五步中分解出来的 20 个象限（5x4）中的微服务，各自分解为程式、容器平台、作业系统、电脑、网路。

第十步是「设计维运大数据」。对于这些系统运行过程中产生的技术资料（数据），在设计微服务的时候，可以同步设想要如何运用这些数据，找出其中的维运价值。

对于微服务，我们必须先认识微服务的优缺点，评估是否需要这些优点，是否可以克服这些缺点，然后再思考是否要用微服务。这篇文章提出十步骤的方法，试图理出设计思路。通过我的三维架构参考模型，可以帮助你控制微服务的複杂度，不管是在设计上还是在运维上。且第八步和第十步希望做到运行、分析、控制，三位一体，可以让我们对微服务有更多掌控权。由于文章篇幅关係，我在此只能极度简单地说明这十个步骤。有需要这方面指导的企业，可以联繫我。