作者：汪照辉 王作敬
汪照辉个人页面

在微服务设计实现过程中，可能会遇到一些问题做不下去，用已实现的微服务难以解决或者不知道怎么解决，这就需要停下来认真考虑和评估当前的微服务内部设计架构和已实现的微服务，可能是时候进行必要的调整和改进了。
我们说过微服务的设计实现不可能一蹴而就，需要不断的调整和改进。随着时间的推移和环境的变化，曾经运行良好的微服务也可能需要改进和调整，比如随着数据量的增多，或者并发访问量的变化，都可能需要调整微服务，不管是调整部署架构，或者直接更新微服务内部设计和实现等，都需要随着各因素变化而变化。当然在更新之前，需要根据实际情况对已实现的微服务进行评估，以选择合适的更新和实现方案。因此在某个时间点或定时进行微服务设计评估也是在微服务开发过程中的一项重要工作。很多时候不是出了问题再回过头来评估改进，而是要未雨绸缪，尽可能的减少资金和时间成本的浪费。

一、 设计评估基于实际业务流程

不管什么样的系统或架构，最终我们是希望帮助解决生产生活中遇到的实际问题，因此采用微服务架构的目的也是为了满足业务系统分布式架构敏捷、弹性等需求。微服务的评估和调整也是为了更好的满足业务需求，更快的实现业务流程，更便利的支撑业务扩展和调整。
微服务评估主要考虑其是否能够胜任支撑业务流程这一工作进行评估，选择合适的架构，以及在合适的时间内完成评估和调整。通常微服务设计实现过程中会涉及到技术问题和组织问题。技术问题是微服务的分拆设计以及微服务之间的通信协作等；组织问题是微服务的设计实现可能会涉及多个部门、多个团队之间的合作，如果都愿意配合则是最好结果，如果不愿意配合可能无法完成微服务评估和调整。因此采用微服务架构需要考虑顶层设计问题，包括技术方案和组织架构两个方面。

二、 微服务顶层设计

顶层设计主要是识别微服务的主要组件和关键服务，识别组件和服务之间的关系及通信，组件和服务的部署方式，服务之间的协作方式，以及服务更新及网络环境等，而组件和服务分别由不同的团队提供和运维。比如客户微服务、产品微服务，两个微服务分别由客户中心团队和产品中心团队提供，而这两个微服务（实际业务可能需要分拆为多个微服务）几乎应用于每一项业务。微服务的部署和协作通信、网络带宽、地理位置、业务请求量、响应时间要求、数据量大小等都可能有所差别。一种方式可能无法满足所有需求，因此需要从顶层、从整体上考虑这些微服务的设计和实现，需要从实际业务考虑适时对这些微服务进行评估改进，协调组织间的工作及配合。因此我们认为采用微服务不仅仅是某个团队的事情，而是所有团队的事情，需要有顶层架构和设计团队把控微服务的设计和技术架构，协调团队之间的合作和任务安排。收集分析微服务实施过程中的问题，评估微服务设计和架构，并适时协调更新。

三、 微服务设计评估事项

微服务评估除了顶层设计，还需要考虑微服务的数据、微服务通信、微服务协同方式、微服务的高可用性、容错性、负载均衡、部署方式、微服务安全、微服务的监控、微服务测试等事项。

（一） 数据

微服务设计数据的问题我们也讨论了很多，在评估微服务的时候同样需要考虑数据问题。数据量、数据来源、数据存储、请求数、负载压力、响应时间、响应数据量等等都密切相关。某种因素的量变都可能会引起其他因素的质变从而需要评估更新微服务实现设计。
随着接入业务的增多，数据的复杂性可能成倍增加，数据语义的二义性、数据的一致性、数据事务处理、数据定义的标准化等等是不得不面对的重要问题，其实这也是我们一再强调良好数据治理的原因。采用微服务不像原来单体集成那样，只考虑服务层数据转换集成，而是要从数据存储、数据模型来重新构建，消除数据的不一致、数据的二义性、数据的不准确等问题，提供唯一可信数据源，具有很重要的价值，也是将来快速构建新业务的基础。
提到数据模型我们还得再说下通用数据模型CDM。CDM也可以作为企业数据治理的一部分工作，通常基于行业CDM来定义企业自身的CDM，也就是企业内部标准化的数据模型。这是定义微服务、分拆微服务的基础。很多时候一个数据模型实体就是一个良好的微服务定义基础。在评估微服务的时候，首先评估CMD的设计也是一项重要任务。
还有重要的一点是实体间事务关联，前面的文章中我们也讨论过事务处理，在评估实现微服务的时候这也是需要重点考虑的问题。

（二） 通信

通信协议的选择不仅决定了传输数据所用的技术，也决定了表示数据所用的技术，但不影响消息本身的语义（含义）和语法（结构）。比如HTTP、JMS、SOAP、TCP、UDP等。通信协议的选择通常要考虑能力限制、地理分布、交互方式、延迟要求等问题，然后选择合适的工具和实现方法。比如HTTP Restful、Kafka消息机制等。不同的业务场景通信方式可能是不一样的，我们也提到过主动和被动数据准备，就是为了适应实际不同的业务场景和流程。微服务设计切忌墨守成规，心中有剑胜却手中有剑。

（三） 协同

微服务协同我们也讨论过，我们觉得实现微服务不仅要考虑微服务之间的依赖交互，更要考虑微服务的自治和独立性，微服务之间是平等的，就像现实中我们人与人的关系。这也是微服务容错性等的要求。

（四） 容错性

一个微服务的异常不能导致依赖它的其他微服务的瘫痪。所以微服务设计时需要考虑依赖异常处理。评估可能存在的异常因素有哪些，在出现这些问题时的处理方案是否符合预期，是否满足微服务之间的协同关系要求等。

（五） 高可用性和负载均衡

我们希望微服务封装唯一可信数据源，那么其高可用性就至关重要。高可用通常可以通过负载均衡等机制来实现，这也微服务实现弹性扩展能力的一种方式。微服务评估也要考虑微服务是否具备高可用和弹性扩展能力、负载均衡机制、稳定性等能力。

（六） 安全

认证、鉴权、加密、审计等安全措施是必不可少的工作。不管是面对企业内部或是面向外部提供服务，安全机制都需要考虑实现。不同的业务可能需要的安全机制和实现方式会有差别，这在设计和评估时需要认真考虑。我们讨论过统一认证中心和权限中心的设计，是采用微服务架构，应用微服务思想实现安全机制的一个方面。微服务安全评估涉及的层面很多，不同业务安全级别要求也不一样，可以基于实际的业务来评估确定安全级别。

（七） 监控

微服务监控评估一方面评估已监控的内容是否真正的合理有效，检查是否遗漏的内容未能监控起来；另一方面也是检查微服务设计是否满足需求的手段。监控的内容不是越多越好，监控的目的是实现有效监控、重点监控，避免疲于奔命而导致重点问题被忽略。监控配合微服务的容错、高可用等能力提供服务。

（八） 测试

微服务测试评估主要考虑微服务的测试流程和测试案例是否合理，在实际运行过程中是否发现了一些未测试到的关键点，是否有重大缺陷遗漏等。
四、 定期评估微服务设计
微服务的评估不建议在做不下去的时候再回过头来考虑调整，那样往往会带来时间和资金成本的极大浪费。微服务评估可以在接入新业务时或者定期由顶层架构设计团队进行，及时调整不合理的设计，特别是微服务采用前期，微服务的调整和更新可能是很频繁的。随着接入业务的增多和微服务的逐步稳定，不再进行大规模的调整和更新。否则其成本和代价可能无法承受，所以在前期一定要充分考虑微服务的设计和实现方式，充分考虑其扩展性，特别是基础的微服务。

五、 优化改进设计

微服务评估是优化改进的基础。对于评估过程中发现的问题，需要进行优化和改进。微服务评估工作启动的越早，所面对的问题可能越小，调整和改进越容易，其时间和资金投入的代价越小。微服务设计和改进是持续的过程，随着业务的变化而调整，这也是我们构建DevOps持续改进闭环流程的一个方面。