软件工程师罗小东，多年渠道架构规划和落地经历，从单体工程到服务化工程，从整合再到拆分再整合实践进程中，对多边型架构的一些落地心得。

布景

这儿以开源项目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年左右，不断的进行优化调整而构成的成果，这儿也是输出一些经历，供参考。