Dubbo3技术一套通之架构演变

• 作者简介：☕️大家好，我是Aomsir，一个爱折腾的开发者！
• 个人主页：Aomsir_Spring5应用专栏,Netty应用专栏,RPC应用专栏-CSDN博客
• 当前专栏：Dubbo3应用专栏_Aomsir的博客-CSDN博客

参考文献

• 孙哥说分布式之Dubbo技术一套通
• Dubbo官方文档
• Apifox官方文档

引言

在深入探讨Dubbo之前，我们还需要花费一个章节的时间来追溯架构的历史脉络。从早期的单体架构到如今的微服务架构，它们之间的演变蕴含了哪些故事和转折？
在聊架构之前，还需要排除大家的一个误区。我们开发一个系统，比如说商城系统，都有前台门户系统与后台管理系统，前台门户系统用于给用户访问操作，后台管理系统用于给管理员以及运营人员进行操作。学习的时候不要将这个前后台与前后端混淆了嗷，是两个概念

单体架构

什么是单体架构？

在单体架构设计中，前台的门户系统和后台的管理系统被打包为一个整体。若是Java项目，它们会被共同部署在同一Tomcat服务器上。具体的结构可以参见下方所示的图示

存在的问题

扩展性差

当前台门户系统与后台管理系统被捆绑在同一包中（例如jar包），我们遇到一个局限性：无法为前台门户系统或后台管理系统单独进行精确的扩展或调整。若有任何扩展需求，就必须对代码进行修改，接着再经过重新编译、打包和部署的流程。这无疑增加了维护的复杂度和灵活性的损失

热点问题

前文中，我们讨论了前台门户系统与后台管理系统的不同之处。考虑一下，当双十一大促来临时，哪个系统会承受更大的访问流量？不言而喻，前台门户系统会面临巨大的访问压力，而后台管理系统相对较为清闲。在单体架构的设计中，这两个系统是紧密耦合的，意味着前台系统在高并发场景下的压力很可能对后台管理系统造成干扰或影响，这种设计远非理想

技术栈受限

在单体架构下，前台门户系统与后台管理系统被封装在同一个包内，例如一个jar文件中。这样的设计决定了两个系统必须共用相同的技术栈。换句话说，如果前台门户系统是基于Java构建的，那么后台管理系统也只能使用Java，而不能选择例如PHP这样的其他语言。这种限制对于技术选择和系统灵活性产生了很大的约束

模块耦合度高

由于前台门户系统和后台管理系统紧密地结合在一起，模块间的耦合度高，它们之间存在明显的相互影响。当修改某个系统的代码时，可能引发的问题会对另一系统造成影响，增加了整体的风险和维护难度

维护部署成本高

将前台门户和后台管理系统集成为一个包导致每当对其中任一系统进行修改，都需要重新编译、构建、测试、打包，再至部署。这种方式显著增加了维护和部署的复杂性及成本

水平架构

什么是水平架构？

水平架构，通常被称为水平扩展架构，是一种通过增加更多的服务器或节点来提高系统的性能和吞吐量的策略，而不是仅仅依赖于单一服务器的升级或增强。这种方法提供了更高的灵活性，使得系统能够更容易地适应不断增长的工作负载，如下图所示

存在的问题

水平扩展看似确实解决不少的问题，提升了系统的稳定性，有更多的硬件支撑，系统的并发能力也有很大的提升，但是并没有从根本上解决单体架构存在的问题，比如热点问题、拓展性问题、技术栈问题、维护成本问题、模块耦合等问题

垂直架构

什么是垂直架构？

垂直架构，也被称为垂直拆分架构，是指将一个单一的大型系统拆分为几个独立的、专门的子系统，每个子系统运行在自己的服务器或Tomcat实例上。例如，在双十一促销期间，由于前台门户的并发量巨大，我们可以通过增加更多的服务器来扩展前台门户系统，确保其性能和稳定性。如下图所示，这种拆分方法可以针对性地优化和扩展每个子系统，提高整体的系统效率和可靠性

存在的问题

垂直架构也确实继续解决了不少的问题，子系统级别的热点问题解决、子系统的耦合度没那么高，扩展性变好，维护部署的成本也有所好转，技术栈也不要求统一的语言，但是模块间的热点问题还是没能解决，没能继续优化，只能说是部分解决单体架构的问题

RPC架构

什么是RPC架构？

RPC（远程过程调用）架构可以视为垂直架构的自然延伸。当系统的模块不断地垂直拆分，逐渐独立运行在各自的服务上，就需要一种高效的方式来进行通讯和数据交换。RPC架构正是应运而生，提供了一种模块之间的快速、透明的通信机制，使得各个服务能够就如同本地方法调用一样简单地相互交互。这种模式大大提高了系统的扩展性和模块化，同时也促进了服务的复用和独立部署，如下图所示

SOA架构

什么是SOA架构？

SOA架构可以视为RPC架构的进阶形态，其中Dubbo是其代表性的框架。当RPC架构中的模块并发量增加，必须进行水平扩展，这时便引入了“服务治理”的概念。那么，何为服务治理？它涵盖了一系列的机制和策略，如注册中心、负载均衡、容错机制、配置中心管理及流量限制等功能。
SOA不仅仅是个学术名词或理论概念，它为企业级应用提供了实际的、综合性的解决策略。这确保了不同的模块能够在一个统一、高效且稳定的环境中无缝协作，如下图所示

企业服务总线

什么是企业服务总线？

企业服务总线（Enterprise Service Bus，简称ESB）被设计用来处理异构系统间的调用问题。它可以将调用请求转换成如ThriftIDL、Protobuf等中间态来实现系统之间的通信。 需要注意的是，对于同步调用，我们可以采用ESB; 而对于异步调用，则可以通过消息队列（MQ）来处理

微服务架构

什么是微服务架构？

微服务架构可以看作是SOA架构的进一步演化。在这种架构中，传统的大型子系统，如前台门户系统，被分解为一系列功能精细、独立的微服务。与传统的大型子系统不同，微服务架构将整个系统分解为众多独立的业务功能模块。代表性的技术实现有Spring Cloud和DNS。采用微服务架构后，许多单体应用所面临的问题都得到了有效的解决。如今，SOA和微服务架构在某些上下文中几乎可以互换使用，基本可以统一成一个概念