微服务架构转型-业务重构

Posted 2021-04-14 远见先行

从最早的微服务架构定义，微服务架构和SOA的区别我们就多次谈到了，微服务架构重点之一是将原来的单体应用变为多个更加细粒度的微服务模块组成的应用（从数据库到应用层完全独立），其次是微服务模块横向和纵向间都通过轻量的Http Rest接口进行协同和交互，以实现模块的解耦。

在微服务架构的技术实践中，我们又强调了微服务架构核心思想仍然是SOA的服务化思想是一致的，同时微服务架构要实现彻底的组件化和模块化，在技术平台或微服务支撑平台层面管理和集成复杂度都增加，这就需要考虑整个过程的自动化程度，也因此微服务架构往往都会涉及到和容器技术，DevOps等最佳实践的集成。

而在微服务架构的定义和实践里面，有一句重要的话就是微服务架构需要和业务能力匹配，或者类似我原来经常强调的一句话就是首先是业务能力组件化，其次才是组件能力服务化，最终业务组件变化为独立自治的微服务模块。如果业务组件本身就没有识别和拆分正确，导致的就是后续微服务接口API服务本身高度耦合并难以复用，那么即使你采用了各种微服务框架搭建微服务架构，但是这种微服务架构对业务的匹配能力，或者说对业务变化的敏捷响应和适配能力是相当弱的。

当我们谈微服务架构的时候，也应该一方面从业务层面规划，一方面从技术层面架构。而对于业务层面规划要考虑的重点就是我们的业务流程是如何的，业务架构是如何的？我们的业务在面对市场需求的时候可能会存在哪些常见的变化？这种业务架构下需要一个什么样的微服务架构进行匹配？搞清楚这些问题的原因就是我们才知道如何去拆分微服务模块，如何去暴露接口服务，如何保证模块间的松耦合，服务本身的粗粒度和可复用。

前博客前面我写过几篇文章，谈中台的构建，谈微服务模块和接口服务本身的识别方法，这些本身也都是我们在和客户交流过程中关心的问题，可以看到当前企业客户也意识到微服务架构的重点不在技术平台，不在微服务框架的选择，而在于微服务架构如何匹配业务？如何保证微服务架构能够快速敏捷响应业务的变化，如果这些最基本的述求都实现不了，我们做微服务架构就是存粹为了技术而技术，没有任何意义。

市场驱动研发，业务驱动IT，但是很多时候随着技术的演进往往间接推动了业务架构的演进和重构，技术反向推动业务成为可能。最早的微服务架构，DevOps和容器化技术往往都是在互联网企业大量使用，而原因本身也是互联网企业的业务需求需要有这种灵活扩扩展的架构支撑，在微服务架构本身思想和技术发展迅速后，本身又推动传统企业IT转型，而这种IT转型本身又反向推动了传统企业业务的重构和变化。

举一个例子来收，一个传统的企业原来推出一项新的业务，往往相对困难，但是随着业务和技术的双重变革，发现新业务的推进本身更加灵活，更加快速，并不需要太长的周期，太多的资源和成本投入，即使失败这种新业务的试错成本完全也可以忍受。传统企业本身就应该体现一定的灵活和敏捷性，能够勇于试错，能够小步快跑的短周期迭代，这才是真正不断创新和发展的基础。

对于企业传统IT架构，我们可以回顾下，往往企业的业务系统往往和部门匹配进行建立，有采购部门就有采购系统，有物流部门就有物流系统，有市场和销售部门就有对应的CRM系统，这种建设模式看似隔离了端到端的业务流程，但是实质企业IT进行分而治之建设的最佳方法。其核心原因就是由于有部门的划分，在业务上面部门之间的分工边界，协同模式和流程是相对成熟的，那么对应的业务系统之间本身的边界和接口也是相对成熟的。即如果我们在职能设计的时候部门本身就是松耦合和自治的，那么我们规划和建设的系统本身也是松耦合的。

如果把采购部门做为一个大的业务单元，那么采购部门内部就还有更细粒度的小单元，类似到部门科室的，比如招标，采购，洽谈，供应商管理可能都是不同的科室在做，那么这些小业务单元之间如果原来协同和边界本身就明确，我们按照这种小业务单元划分而拆分处理的微服务模块本身也应该是松耦合的。如果一个部门内部本身的小业务单元之间本身原来交互，分工就没有理清，那我们就无法划分出更好的微服务模块。

简单来说，就是微服务模块的划分首先是要识别更加细粒度的业务单元，这些业务单元之间本身应该有明确的分工边界和交互接口，确保这些业务单元之间本身是松耦合和自治的，如果没有做到这点，那么首先要做的是业务重构，或者说根据微服务架构咨询规划来推动业务的重构。否则我们最终的微服务架构就很难真正和业务能力匹配和适应。

企业内所有业务活动，包括核心价值链活动和支撑类活动都应该被分解到不同的业务单元进行支撑，这些业务单元之间通过分工和协同，完成完整业务的支撑能力。而我们首先要做的就是这些业务单元的能力应该组件化掉，组件间确保最基本的高内聚和松耦合原则。其次再来演绎（沙盘）这些业务单元如何协同起来就可以支撑完整的业务（实际技术层面的服务编排）。

再回来我们看到：

前台：业务单元如何协同起来支撑业务（服务编排和组合等），这是应用层面的事情。
中台：提供各种业务和数据能力的独立业务单元，将这些业务单元能力通过API接口开放出去。

所有从这里可以看到在微服务架构的实现过程中，中台规划相对重要，不仅仅是要考虑现有业务，还需要考虑后续业务的扩展，一个中台规划和建设的好，那么在后续有业务模式产生的时候，只需要变化前台服务组装，而不需要过多改动中台，自然响应变化的而速度就更快。

这里谈到的前台不是应用功能的前端界面，而更多的是指服务组装层，面向业务用户的最终接口层。前台本身并不存在具体业务规则和逻辑的实现，而是根据不同的业务来组装服务接口，因此更多的是编排和组装工作量，如果有各种灵活的可视化服务编排工具，即实现我们常说的灵活可配置编排能力。如阿里来说，原来只有淘宝，再推出天猫，聚划算，团购等各种新业务的时候往往中台层并不会太变化，就是类似的道理。