忽视业务与架构，微服务建设则如沙中建塔！

1 对架构的期待与现实

十几年前我参加了一场线下的架构沙龙，满心欢喜而去，但是听到的都是在讨论服务器解耦，微服务触发、微服务调用什么数据这类话题，然后又讲了讲网页怎么做，跟我对架构的理解和期待差距太大。

当时就感觉到，如果这么做架构总感觉少了很多东西，而且有一种对技术专家的不安，你想到了这个，但是有没有没想到的？甚至很多东西靠你自己的聪明才智的极限是根本就想不出来的？

这是技术人员跟业务人员在思维上的重要区别。技术人员相信技术实现的力量,yes !而业务人员相信客户say no的力量...就你技术再牛，不是他要的，那不还是nothing么？

正彷徨时，一善于拍马的某企业客户服务经理在沙龙上指着其同事说：“跟人家好好学学吧，看这多专业....”

中国几百年来在科学、商业、创新上的停滞不前跟这些见风使舵、媚上压下的马屁精们有相当大的关系。你看一个企业如果出现了大量的这种人，那么也就距离衰落乃至完蛋不远了，赶紧走哈。很简单，若决策者周围都是这种人，那么，他的耳朵和眼睛乃至大脑都将失灵。而专业主义者、技术主义者最不擅长的就是这些...

言归正传，但即便如此，还是要秉承专业主义、保有匠人精神。

技术专家很可贵，你要证明自己的价值就要多听听业务真实的声音。

2  微服务架构的兴起

微服务架构自Netflix和阿里巴巴的成功应用开始，迅速获得了广泛认可。其核心优势在于能够将复杂的应用拆分为多个独立的服务，每个服务围绕单一业务功能开发、部署和维护。

这种设计风格在支持大规模扩展、提高可维护性和灵活性方面表现出色，特别适合拥有多条业务线、并需要快速响应市场变化的公司。

如今你谈业务就很难脱离谈软件...通常软件项目被划分为项目型软件和产品型软件。

项目型软件是指具有明确的项目生命周期，通常存在清晰的甲方与乙方关系。甲方提出需求，乙方负责开发和交付。在项目交付后，维护需求有限，且通常没有持续的迭代更新。

产品型软件则没有固定的生命周期，它的开发与企业自身业务的演进密切相关。企业可以自行研发或委托外部研发，但不存在明确的外部需求方。其特征是随着业务需求的变化不断演化。这类软件的持续演进、功能扩展及技术更新是其核心需求。

我们以阿里云为例看其发展脉络：

1 阿里云最初是为了服务于阿里巴巴电商内部业务的扩展，处理海量交易数据和流量高峰。随着云计算技术的成熟，阿里云逐步转型为一个公共云平台，提供大数据分析、AI计算、存储服务等。

2 在发展过程中不断扩展新的功能和服务，从最初的简单存储和计算服务，发展到如今涵盖人工智能、大数据、IoT（物联网）等众多领域。比如MaxCompute（大数据计算平台）以及AI产品（如ET工业大脑），开始为适应不同企业客户的需求和应对市场竞争的压力而不断推出新东西。

3 随着阿里云的用户群体从小企业扩展到金融、政府和大型企业，系统的技术要求变得更加复杂。阿里云需要不断升级其架构以应对安全性、可扩展性和稳定性方面的挑战。例如，阿里云引入了微服务架构，以支持更复杂的业务需求和系统扩展。阿里云的容器服务、Serverless架构以及分布式数据库等技术更新，都是为了应对新业务场景。

在实践中，尤其是面对复杂的产品型软件，业务架构和技术架构的设计是关键环节，这两个阶段的设计质量直接影响个体微服务的拆分效果和系统的可扩展性。

业务架构总体设计要涵盖子系统划分、模块设计、处理流程设计、数据库设计、网络设计及接口设计等多个阶段；详细设计则聚焦于模块内部实现。

有些企业的朋友反复跟我说：我们是敏捷研发，不是传统瀑布研发，模式不同，对需求的理解不同，但我们陷入了方法困境，我们找不到新方法论了....

其实敏捷研发它不是横空跳出来的孙悟空，它是从瀑布研发继承并发挥出来的，如果你说敏捷研发就不要做总体设计和详细设计了，我想那你只是在重复历史的老路，直到掉坑里才会发现经典就是经典，它告诉了你全面考虑问题的办法，至于你选择性的考虑哪些点那是你的选择，若你跑得快了，但是该交的作业逃不了，你的业务越复杂越会发现必须要回头致敬经典。

国内很多企业之前蜂拥的学阿里，现在蜂拥的学华为...作为这个领域从业者来讲，其实都很担心他们学的到底对不对...阿里和华为本身也还有不少要进步的地方。

那些当年迷信所谓互联网运维开发服务的企业都销声匿迹了吧？

野蛮成长是有发展阶段性的，你不可能让整个社会都疯狂并为此付出代价。就拿现在中国大多数的传统制造企业的技术成熟度来说，它敢工业互联吗？很多MOM还没整明白呢（说到这里，如果真有在做MOM的企业可以联系我哈），马斯克的特斯拉那能叫单纯的制造企业么？马斯克做特斯拉是为了单纯卖车么？还是行走的数据收割机？不是一个阶段的企业。

3 容器与服务的演进

容器化技术（如Docker、Kubernetes）在微服务的落地中可以大幅提升部署与管理效率，但过早引入这些复杂的工具，可能会在没有必要的场景下增加企业的技术负担。

并且，若缺乏有效的业务架构设计，容器的管理和编排会变得复杂且难以维护。也即，演进式容器化部署应基于已有的业务规模、特征与未来扩展的需求开展技术栈的规划，以避免不必要的修改和重构，以实现系统模块的持续高内聚和低耦合，降低维护成本。

尽管微服务架构强调灵活性，但在实际业务环境中，它会对企业的开发团队带来一些挑战。很多架构师和开发团队在实施微服务时，容易陷入一个误区：过于关注技术实现上的独立性，而忽略了业务需求的优先级和整体架构的协调性。

这就导致开发团队的时间和精力大量耗费在非业务功能的工作上，如服务的拆分、数据的一致性处理、服务间通信的复杂性等问题，而业务需求的落地速度反而被延缓。

因此，在进行微服务拆分时，需要首先明确业务需求，并将其作为服务划分的首要标准。微服务的核心在于为业务功能服务，因此，应当优先分析哪些业务流程需要独立化，哪些业务领域需要更高的灵活性或独立性。例如：

• 利用领域驱动设计（DDD）方法、根据业务领域进行合理的服务拆分，避免因为过度的服务分裂导致开发复杂度增加。

  
  

• 业务流程与服务的松耦合是关键，确保每个服务单元能够独立开发和扩展，而不会引发大量跨服务的依赖。

  
  

• 关注业务边界的明确定义，避免服务之间过多的依赖和频繁通信，保持服务的清晰边界和职责范围。

微服务的核心目标之一是实现高内聚、低耦合。业务架构设计能够帮助识别系统中不同功能模块之间的关系，并据此进行合理拆分。

例如，在用户管理系统中，通过前后端分离设计和OAuth授权服务的引入，可以有效减少模块间的依赖，使得各个服务可以独立开发、测试和部署。这种结构不仅提升了系统的灵活性，还促进了团队的敏捷开发能力。

随着微服务数量的增加，企业的DevOps团队需要处理更多的部署、监控、日志管理等工作。为此，在设计微服务时，也需要从全局业务视角评估服务的规模和数量，以平衡开发、测试与运维之间的负载。

业务架构设计也能够帮助架构师定义清晰的测试用例和标准，确保每个微服务在拆分后依然能有效满足业务需求。

4 明确业务需求的重要性

很多团队在实施微服务时，容易陷入一个误区：过于关注技术实现上的独立性，而忽略了业务需求的优先级和整体架构的协调性。

这就导致开发团队的时间和精力大量耗费在非业务功能的工作上，如服务的拆分、数据的一致性处理、服务间通信的复杂性等问题，而业务需求的落地速度反而被延缓。

为了避免这种情况，架构师在进行微服务拆分时，需要首先明确业务需求，并将其作为服务划分的首要标准。微服务的核心在于为业务功能服务，应当优先分析哪些业务流程需要独立化，哪些业务领域需要更高的灵活性或独立性。

• 利用领域驱动设计方法帮助架构师根据业务领域进行合理的服务拆分，避免因为过度的服务分裂导致开发复杂度增加。

  
  

• 业务流程与服务的松耦合是关键，确保每个服务单元能够独立开发和扩展，而不会引发大量跨服务的依赖。

  
  

• 关注业务边界的明确定义，避免服务之间过多的依赖和频繁通信，保持服务的清晰边界和职责范围。

微服务的核心目标之一是实现高内聚、低耦合。业务架构设计能够帮助识别系统中不同功能模块之间的关系，并据此进行合理拆分。例如，在用户管理系统中，通过前后端分离设计和OAuth授权服务的引入，可以有效减少模块间的依赖，使得各个服务可以独立开发、测试和部署。这种结构不仅提升了系统的灵活性，还促进了团队的敏捷开发能力。

随着微服务数量的增加，企业的DevOps团队需要处理更多的部署、监控、日志管理等工作。为此，在设计微服务时，也需要从全局业务视角评估服务的规模和数量，以平衡开发、测试与运维之间的负载。

业务架构设计也能够帮助架构师定义清晰的测试用例和标准，确保每个微服务在拆分后依然能有效满足业务需求。

5 业务架构的重要作用

业务架构的设计集中于软件系统的业务流程和业务协作。这一阶段主要以逻辑模块为单位，定义系统内部的业务关系。

在业务架构阶段，通常会基于分层模型设计出基本的单体应用架构，并为后续的服务拆分提供基础。各个逻辑服务在部署时可以独立运行，为微服务的模块化提供了基础。

这种分层设计能够帮助企业根据复杂业务需求逐步过渡到微服务架构，使得业务功能模块的调整和扩展变得更加灵活。在业务架构阶段的模块划分直接影响后续微服务的拆分策略，合适的模块边界可以提升业务功能的灵活性和技术实现的扩展性。

技术架构基于业务架构，进一步加入更多的技术细节。此时，需要对软件系统的各类技术问题进行详细设计。例如，在处理大规模数据时，技术架构需要考虑到结构化数据库和非结构化数据库的适用场景。

在软件架构的演进过程中，从业务架构到技术架构的逐步演变，恰恰是解决微服务拆分问题的有效途径。这一演化不仅满足了软件项目的功能性需求，也兼顾了非功能性需求。

比如说电商平台信息系统类型繁多，涵盖了核心业务应用，如订单管理系统、用户管理系统、商品管理系统等。

如果未充分分析这些系统内部及之间的关系，微服务的拆分可能导致数据孤岛或接口调用复杂，最终影响系统的整体性能。

它的生态系统也在不断扩展，在线客服系统、会员管理系统、社交媒体营销工具等逐渐成为电商企业数字化服务的关键组件。许多传统电商系统仍为历史遗留的孤立应用，缺乏有效的集成，这就容易导致：

1. 数据共享难题：例如，订单管理系统发布订单状态后，用户可能需要通过不同的渠道（如APP、微信小程序等）查询相关信息，甚至登录多个账号才能获取完整的订单状态。

   
   

2. 多账号管理的困扰：每个系统都有独立的用户账号体系，导致用户需要管理多个账号和密码，影响用户体验。

   
   

A 公共服务分解

在电商平台中，多个系统（如订单管理、用户管理、商品管理等）存在大量的公共功能需求，例如与用户身份管理相关的功能。这些功能通常集中在用户管理系统中，但在其他系统中也可能重复出现。通过服务分解，可以将这些公共服务抽取为独立的服务模块。

如果缺乏整体业务架构设计，那么公共服务可能会被重复开发，造成资源浪费与维护成本增加。

B 用户管理系统的微服务化

在用户管理系统的演化过程中，首先通过前后端分离的设计方法进行业务架构设计。用户管理系统的前端负责呈现用户界面（UI），中间层服务负责处理用户的业务逻辑和数据交互。为了实现系统的统一身份验证和授权管理，采用OAuth授权服务，该服务不仅为用户管理系统提供身份验证支持，还为其他系统（如订单管理和商品管理）提供统一的权限管理功能。

这种架构设计确保了系统的业务逻辑高内聚、低耦合，并通过API接口为其他系统提供访问服务，实现了跨平台的功能共享。

随着更多系统接入用户管理系统，这种分层设计能够支持业务逻辑的逐步扩展，并为后续的服务拆分奠定基础。

C 重点服务集群化

在微服务架构中，一些核心服务由于访问量较大，需要进行集群化管理。例如，在电商平台中，OAuth授权服务由于被各个子系统（如订单管理、用户服务等）频繁调用，成为了系统性能的关键节点。因此，针对这类高并发的服务，集群化能够有效提高其可用性和系统稳定性。

通过微服务架构的演进，OAuth授权服务被集群化部署，以分散流量并提升系统的可扩展性。每次架构迭代时，对授权服务的增量拆分和优化能够有效应对用户增长和访问频次提升带来的压力。

D 测试的复杂性

由于系统模块数量众多，模块之间的集成测试成为了难题。传统的一次性大规模拆分可能带来测试困难和系统不稳定性。为此，采用演进式服务拆分方法，能够逐步解决这一问题。每次拆分仅专注于一个完整的服务模块，保留已有的测试用例，并将拆分后的服务视为一个整体进行测试。

大规模的服务拆分往往会带来容器编排和网络架构设计的复杂性。一次性完成所有服务的容器化部署，可能导致维护成本增加以及网络设计的难度加大。这都需要业务架构的整体排布与有控制的迭代调整。

综上，微服务的成功实施往往要依赖于业务架构的支撑，要深入理解业务需求和流程，才可能设计出符合企业战略目标的微服务架构，而非单纯的技术堆砌。脱离业务架构的微服务建设短期可能看到亮点，这要拜赐于个别聪明人，但长期来看，不仅难以满足企业的后续、持续发展需求，还可能导致后期成本迅速叠加、和大型项目失败，就各自为战、乱作一团、风险一堆...

而业务架构师在微服务的设计与实施中恰扮演着不可或缺的角色，要担当起推动技术与业务的有效、持续融合的重要责任。