作者：汪照辉 王作敬

---

微服务规划、微服务构建、微服务协同、微服务测试、微服务治理、微服务下线等是企业采用微服务必须面对的微服务生命周期管理问题。我们讨论过微服务治理的问题，由于一些原因未能整理微服务拆分、微服务设计、微服务构建等相关内容。网上对微服务的讨论更多是微服务开发框架的使用，较少深入讨论微服务拆分、设计和构建。我们提出过采用主数据思想来构建微服务体系，目前也有采用DDD方式来设计微服务的，这里我们探讨下微服务构建的一些思路和方法，以期抛砖引玉，带来更多更深入的探讨。

一、 采用微服务的目的

采用微服务，首先要有明确的目的，有清晰的认知。微服务并不是放之四海而皆准的理论，有其适用范围和场景。如果用单体应用能轻松解决的问题就没必要用微服务架构。在遇到有分布式、弹性扩展等需求的情况，才需要考虑微服务架构。一个微服务我们可以认为其是一个小的单体应用。在有很多单体应用之间需要通信、协同的情况下，或者通过单体应用之间的集成无法满足业务性能要求，需要重构业务应用系统时，才需要考虑采用微服务架构。
我们也提到过，微服务意在重构！并且通常在大中型企业有众多的单体业务系统情况下，各单体业务应用集成可能成为一个问题的时候，需要考虑采用微服务架构重构业务应用。由于微服务架构体系需要众多的基础设施平台和基础组件支撑，才能发挥微服务架构的优势，所以一些小公司或者没有计划进行大规模改造的情况下，采用微服务可能无法展现其价值，并且管理任务有可能更多、更繁琐。
服务化的目的在于重用，微服务也是一样。其实无论函数化、模块化、组件化、服务化等重要目的在于共享、重用。技术经过若干年后总会以另外一种面貌重现，就像当前的Serverless 函数编程，原来单体应用的函数放到云端，加个Serverless的概念马上就高大上了。微服务还有重要一点在于其分布式弹性，微服务实例数弹性伸缩，可以和容器平台结合，利用容器弹性伸缩的特性，实现微服务的弹性，快速响应业务变化需求。
采用微服务往往也是因为其轻量，可以快速迭代，即时响应新业务需求，快速开发部署微服务应用，在抢占市场的同时可以持续的迭代和完善。所以通常采用微服务是以业务需求变化快的场景为起始，比如活动促销等，然后逐步推广到其他业务场景。

二、 构建思路，方法论

跟很多厂商交流微服务，基本上都在谈SpringCloud、Dubbo，谈到用什么理论或方法来指导微服务的设计和构建时，几乎没有厂商关注这些，感觉大部分人也就是用微服务开发框架去写代码，至于微服务设计和构建，则基本上还不具备相应的能力。没有理论指导，每个人理解的微服务可能都不一样，所以实现出来的微服务也就五法八门、千奇百怪了。
都知道微服务是一种架构方式，但怎么架构？什么是合适的微服务架构？可能就仁者见仁、智者见智了。如果仅知道SpringCloud，那也就是一个编码人员，不具备微服务设计和构建的能力。微服务设计和构建则需要相应的理论功底，比如比较流行的DDD领域驱动设计方法，但领域驱动设计侧重业务领域，而且整个体系复杂，业务领域专家所设计的领域模型并不一定适合技术实现，需要技术人员的二次建模，最重要的是数据的存储未充分考虑。微服务可能根据数据的量、请求负载的量、数据的类型、来源等采用不同的存储方法，可能需要考虑分库、分表、分区、物化视图等不同的方式，也可能随着业务数据的变化而更新微服务的存储和实现。我们认为这才是微服务设计和构建需要重点考虑的方面。至于用什么工具开发，那是次要的选择。

如果了解主数据管理（MDM）的话，我们建议采用主数据的思想来构建和设计微服务。主数据强调唯一数据来源。主数据管理是实现主数据集成和治理，主数据是数据的骨架，其他数据是血肉，它们共同构成一个完整的企业数据整体。主数据并不是不关注业务，恰恰是从业务流程梳理开始，只不过我们不是构建一套主数据管理系统，而是以主数据的思路来构建微服务数据模型和存储模型。谈主数据可能需要了解通用数据模型CDM，它非常有助于我们构建适合的微服务数据模型。
当然，我们觉得两种方法结合可能会更好一些。目前只是理论上的思路，具体还缺少实践，所以也希望能充分和有这方面考虑的团队或个人深入交流。

三、 重点在数据

微服务重点不在采用什么语言或什么开发工具，我们曾经讨论过SpringCloud/SpringBoot不是微服务，SpringCloud/SpringBoot开发的服务也不一定就是微服务。微服务是一个从业务层到数据层到存储层都是相对独立完成特定功能的一个单元，所以我们经常听到拆库、拆表的讨论，但缺指导性的一些原则和方法论。微服务重点在数据，因此采用微服务和数据治理能力密切相关。数据标准、数据安全、数据所属、数据模型、数据持久化等直接影响着微服务的质量和实施难度。什么时候数据存放数据库？选择什么数据库？什么时候需要分区表?什么时候分表？什么时候需要分库？非结构化数据如何处理？……这些不是选择一个开发框架就能解决的问题，这才是微服务设计和构建的重点。
通常情况下需要考虑由原子微服务来准备数据。不同的场景数据准备的方式可能是不一样的。不过在当前的大多数业务场景下，实时及准实时的需求越来越多，所以数据准备需要在原子微服务中以实时或准实时的方式准备好。可以是高效的主动获取，也可以是被动的实时更新，但要确保数据的正确、准确。而关于用业务微服务和应用微服务封装业务逻辑和应用组件协同逻辑，我们将在下一篇《微服务协同》中详细讨论。

四、 提取基础组件

采用微服务在梳理完业务应用流程之后，首先就需要考虑提取基础公共组件。这些组件是每个应用系统都可能需要用到的，所以这些组件需要首先提取出来。比如日志服务、监控服务、告警服务、统计服务、权限服务、认证服务等。采用微服务架构还会涉及微服务注册发现、微服务配置、微服务网关等。这些服务通常也有开源的组件，可以协助构建整个微服务体系基础组件服务。但开源的毕竟只是在技术上可行，应用于实际的业务环境还有不少的工作要做，后期技术支持也是个需要认真考虑的事项。

在提取完非业务性功能组件服务之后，可能需要考虑业务性功能组件，比如公共数据字典服务、数据标准转换服务、数据分发规则服务等等。这些服务和整个业务微服务设计架构紧密相关，是其他业务微服务需要共享使用的，提取这些微服务将有助于快速的构建其他业务微服务，快速敏捷的推进微服务建设。
五、 基础设施支撑
微服务不是开发几个所谓的微服务就ok了，它需要众多的基础设施支撑才能更好的体现微服务的价值。微服务的开发、测试、部署、治理、运维等整个生命周期过程都需要各种设施的支持。比如基础设施资源平台，可以提供虚拟机、存储等资源服务。数据治理平台在设计构建微服务时有相应的数据标准和数据安全等支持。服务管控平台则提供微服务的部署、运营管理。接口管理平台提供微服务对内对外的标准API服务等等。

微服务意在重构，并不是为了某一个应用系统，而是要考虑企业内的所有应用系统，这些应用系统的公共的服务，首先就是共享，这是重构的意义所在。

六、 量变到质变，持续的过程

我们想强调的是，微服务设计和构建不是一步到位的。它是一个持续构建、持续优化的迭代过程。就像前面我们提到的，随着数据量的变化，微服务的实现可能需要优化，这是一个迭代的过程。数据量小的情况下可以一个库一张表，但数据量巨大的情况可能需要考虑分表、分库，甚至分区域数据中心。数据物理存储模型的改变必然导致微服务实现的变化。还有就是数据来源的变化，微服务协同的变化等都会带来微服务实现的调整。
微服务初始实现的时候可能也就几个、十几个或几十个微服务。不过在重构第二个业务系统的时候就会简单些，公共的组件服务不需要再构建了，直接可以使用。关注的重点是业务逻辑在业务微服务中的实现，公共的能力比如日志、配置、权限等只需要按照标准的服务接口调用相应的服务就可以了。还有一些公共的业务微服务组件可以共享，比如数据字典服务、一些公共的服务比如客户服务、产品服务、账户服务等。所以随着微服务构建的增多，在重构一个应用系统时将会越来越容易，越来越便捷，越来越快速，越来越敏捷。
其实我们觉得微服务的构建过程也会符合二八规则，前期做80%的工作可能只实现了20%的业务需求，但随着量的增加，后期20%的工作就可以实现80%的业务需求。这就是服务共享的收益。
到后期，也许就没有原子微服务的构建需求，更多的是业务应用微服务的构建，在一个业务需求提出后，选择合适的原子微服务或业务微服务通过流程配置就可以快速的发布部署，真正实现对业务需求的敏捷响应。