我为什么选择多边形架构做为工程的基础思想

软件工程师罗小东，多年平台架构设计和落地经验，从单体工程到服务化工程，从整合再到拆分再整合实践过程中，对多边型架构的一些落地心得。

背景

这里以开源项目 alinesno-cloud 微服务架构的建设拆分再到整合成产品型结构的进行阐述，从原来的几十个工程基线(近百个服务模块)，再到后来的 20 个左右产品模块的组合，进行服务能力的输出。过程工程由微服务、六边型、再到多边型工程结构的实践经验，这里偏向于工程结构以适应平台产品化发展的变更。

需要达到的效果是把工程结构多组合的结构以适应项目的需求变化。多边形架构是一个泛指的概念，指的是由多个组件或模块组成的系统架构。这些组件或模块可以以不同的形状和大小组合在一起，形成各种不同形态的系统架构。多边形架构中的每个组件或模块都可以担任不同的角色和功能，并通过定义清晰的接口和协议，实现彼此之间的通信和交互。

概述

软件架构也在不断地演化。从单体应用到 RPC 服务再到微服务，这些技术的出现和应用都是为了解决不同阶段的问题。而六边形架构是在微服务架构基础上的一种新型架构，它强调领域驱动设计（DDD）和面向接口的编程，旨在更好地支持业务复杂度的增长和应对变化。

这里以时间维度阐述自己从 MVC 架构到六边型架构，再到多边型架构的产品线整合尝试，这里以过程以时间维度（18 年到 21 年）和成熟度进行阐述过程。

• 初版定义：单体到 Dubbo 服务工程的尝试建设

• 技术升级：从 Dubbo 服务工程到 Cloud 工程结构的改造

• 产品改造：从 Cloud 工程到自定义工程结构的改造

• 模型成熟：从六边型概念到多边型工程结构的改造

对于这块的模型的定义有很多不一致的理解层面，这里针对的是问题和解决两个角度进行阐述，经验不一，我有我思。

过程

在产品型建设过程中，软件架构也在不断地演变和升级。从单体应用到分布式系统、再到微服务和六边形架构，每一种架构都有其独特的优势和适用场景。本文将会介绍从单体工程到 RPC 服务、再到微服务、再到六边形架构以及多边形架构的技术发展。

初版定义：单体到 Dubbo 服务工程的尝试建设

这个过程的改造适合国情化的发展

在单体应用时代，由于业务需求相对简单且交互较为单一，使用单体架构是比较合适的选择。但是，随着业务的不断扩大和功能的不断增加，单体架构也开始暴露一些问题，如代码耦合度高、代码可维护性差等。为了解决这些问题，在 RPC 服务时代，我们将原本单体应用中的模块拆分成了独立的服务，同时采用远程过程调用方式进行通信，使得不同服务之间的耦合度降低，系统的可扩展性得到了提升。

工程结构开始是 MVC 型，后面改成 Dubbo 型，将 Service 层抽取出来，提供出 api 实体和接口工程给第三方依赖，这个过程的改造会将庞大的业务系统架构进行拆分，形成多个模块化，将单体应用改造为 Dubbo 服务，可以将原本臃肿而难以维护的单体应用拆分成多个独立的服务，使得系统变得更加模块化和清晰。这样做的好处包括：

• 提高可伸缩性：将单体应用改造成 Dubbo 服务后，每个服务可以独立部署和扩展，可以根据实际负载情况进行动态伸缩，提高了系统的可伸缩性。

• 提高可靠性：Dubbo 提供了多种服务治理功能，比如容错机制、路由策略等，可以有效保证服务的可靠性和稳定性，相对于单体应用更加可靠。

• 提高可维护性：将单体应用拆分成多个服务后，每个服务的代码规模变小了，易于维护和升级。同时，模块化的设计也使得开发人员更加关注自己的业务领域，提高了团队的开发效率。

• 提高代码复用率：Dubbo 服务通过接口进行解耦，将相同或类似的功能封装到独立的服务中，提高了代码复用率，减少了重复开发的工作量。通过将单体应用改造成基于 Dubbo 的分布式服务架构，可以帮助企业构建基于微服务的架构体系，从而提高系统的可伸缩性、可靠性、可维护性和代码复用率。

这是一个不错的工程结构，而且确实也解决了原始大型工程的问题，这个过程的建设相对于传统项目来说，有可能会形成微服务，也可能会形成大型的分布式工程（也就是伪微服务），不过总的来说，会解决单体陷阱的问题。

技术升级：从 Dubbo 服务工程到 Cloud 工程结构的改造

新型的分布式服务，也会带来新的问题，需要让这个服务就做这个事情

Dubbo 服务之间有很强的依赖性，在不小心或者不轻易间，会产生强依赖性和不断传递问题，这个形成的影响又是另一方面，特别是在公用网络或者外部网络的情况下，服务之间的关联还有调用不稳定性常常发生，还包括操作系统的因素等，另一个更为明显的，Dubbo 只是一个 RPC 架构，针对微服务和分布式来说，外围生态和组件成熟度不高，基本上都是东拼西凑起来。

另一个更加夸张的是原阿里团队的不维护，导致出来了很多不一致的版本，生态体系有可能无法发展的情况，这个时候，不得来说，会转向 SpringCloud 体系，一个是协议的通用性，另一个是社区生态。虽然来说，不管从工程结构和代码量来说，Dubbo 服务会少于 Cloud 体系，而且工程资源还有开发的习惯、有高性能、低延迟、易扩展等特点，但是无法在很多场景下，会带来很多限制。

另一个致命的是，由于工程结构的特点，它对外提供的是 RPC 接口是直接面向 Service 层服务，在很多情况下会影响项目开发人员，设计人员的设计思维，很多情况下我们只写到 Service 层服务，这个会让人有一种误区就是逻辑只到 Service 层，那这样的话，Rest 层接口这个自然就不会存在，这样的设计，很多时候会无形的影响设计人员在处理服务模块的时候，会自然而然的将工程设计只到 Service 层。

这个容易产生大量的工程服务组件，在领域设计上，容易（这里只是说容易，但并不绝对）无形中拆分了这个模块，这个跟高内聚、低耦合的思想有一定偏离，在后期的使用过程中，总会感觉需要有一层进行聚合，而这个聚合的服务其实最好的体现在 Rest 层上面，而 dubbo 面向 service 的设计，让很多工程结构下无形的把这个思维在潜意识里面隐藏了。

开始尝试会在前面加一层聚合服务进行整合，但是这个链路并不是很乐观，因为从实际结果上，还是拆分了。

以上种种，将 Dubbo 服务工程结构转成 SpringCloud 工程结构，增加了一些层级和工程代码量，但是效果上会把上面潜意识的问题消除掉，达到的效果就是：这个服务就做这个事情，由原来的 RPC 服务减少，转成模块形的设计，进一步减少复杂度和提高服务的内聚。

产品改造：从 Cloud 工程到自定义工程结构的改造

在一些架构不满足的情况下，需要自定义工程结构

前期在使用 Cloud 过程中，过多的复杂组件和概念，还有 starter 工程结构的增加，无形中加剧和工程变重，这个过程容易影响业务的开发，另一个问题是，在服务组件不断的成熟下，这些组件会开始进一步的平台化（直白的说增加一个管理界面）。

它包含多个工程和组件，使得开发人员可以快速构建复杂的微服务应用程序。然而，使用大量的工程组件也有一些弊端：

• 复杂性：Spring Cloud 包含众多的组件和工具，这使得整个应用程序变得非常复杂。开发人员需要学习和掌握各种组件的使用方法，这增加了开发难度和时间成本。

• 版本兼容性：由于 Spring Cloud 包含众多的组件和工具，每个组件都有自己的版本号。当一个组件更新版本时，它可能会影响其他组件的兼容性。这给开发人员带来了额外的负担，需要测试和修复版本兼容性问题。

• 性能问题：每个组件都需要运行在不同的进程中，这可能会导致性能问题。每个进程都需要消耗 CPU 和内存资源，这可能会降低整个应用程序的性能表现。

另外一个特别让人意外的是，Netflix 组件在不断的放弃维护，而又发展出 alibaba 版、tenant 版，还有 n 多的个人版本，这些基本上容易导致被牵着走。

在市场架构调整中，做了一些调整，以适配工程结构，同时抛弃掉 Cloud 思维结构：

• 去掉 Cloud 体系和大量的第三方组件，只保留基础的 springboot 工程结构，同时将第三方组件需要用到的核心能力进行自定义封装。

• 去掉所谓官方“好的”微服务插件，比如配置中心、注册中心、链路跟踪等，将这些独立出来，一般小的工程用不上，大的工程通过自定义封装包的形式加载（比如 nacos)

• 将工程结构进一步的独立化，适当的组件进行平台化，通过租户的形式提供服务，并提供出可视化的管理界面

• 将大量的工程进一步压缩消减，形成模块化，提供包的形式，需要的时候依赖，而不是都通过接口调用，通过插件的概念形式进行整合（类似于 wordpress 插件）

通过上面的调整，你会发现，工程结构会有点类似于云平台，每个服务组件都有单独的能力，这个时候，产品型的体现已经慢慢程现，但是还不够充分。

模型成熟：从六边型概念到多边型工程结构的改造

为了产品更好的迭代和发展，提取出领域的概念，进一步彻底的产品化

架构也开始出现一些问题，如服务之间的依赖关系复杂、服务治理难度大等。为了解决这些问题，领域模型的思维进一步的切入到服务建设中。将微服务合并拆分出领域服务，并以领域模型为中心进行设计和开发，强调了面向 API 接口编程的思想，通过定义清晰的接口，使得不同服务之间的交互更加规范化、灵活化。

在这个过程中，特别需要关注的是业务本身的特点和复杂性，导致软件难以维护、扩展和适应业务变化，做了一些调整方向，主要是：

• 明确业务领域模型，提高业务分析和设计的准确性和效率，可以自由地进行修改、测试和演化，而不会对其他系统产生影响。

• 将业务逻辑与外部依赖分离开来，使得业务逻辑在不同的环境中都能够独立运行。

• 多个模块间内部核心和外部适配器之间通过接口来进行通信，使得它们可以相互独立地演化和变化。

• 多种不同类型的适配器，使得系统可以更加灵活地适应不同的业务场景和需求变化，从而提高了系统的可扩展性。

这个原来在调整工程结构过程时，发现六边型概念是跟我想要的基本上吻合的，而且融合度非常高，但是过多的代码编码概念，开发人员来说可能会有一定的技术门槛，特别是在领域建模、聚合、限界上下文等方面，在某个程度会让我们感觉到这个是否是我们需要的，最终我们把工程结构进一步拆分和根据内部的习惯定义，重新设计和工程结构，以下是调整的结构图：

这个调整的结构使得服务产品间更稳定，组件或模块可以以不同的形状和大小组合在一起，形成各种不同形态的系统架构，每个组件或模块都可以担任不同的角色和功能，并通过定义清晰的接口和协议，实现彼此之间的通信和交互，以适应不同的业务场景。

总结

以上为在过程工程由微服务、六边型、再到多边型工程结构的实践经验，这里偏向于工程结构以适应平台产品化发展的变更，最终发展形成产品化的工程结构调整过程。工程结构的调整是解决的是应用程序的可测试性、可维护性和可扩展性问题，同时针对于自己所面对的场景不断的适配调整过程，这个过程的调整差不多有 4 年左右，不断的进行优化调整而形成的结果，这里也是输出一些经验，供参考。