Spring Cloud Alibaba 系列之微服务架构的演变_微服务架构演进-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_72133062/article/details/131019370

文章讲述了软件架构从单体应用到微服务架构的演进过程，包括单体架构的紧密耦合、垂直应用架构的高内聚、分布式架构的分布特性和SOA架构的松耦合服务。微服务架构强调服务的单一职责、面向服务、自治和松耦合，带来了更好的可扩展性和维护性，但也带来了分布式系统的复杂性挑战。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一.微服务架构的演变

1.单体应用架构

既然说到了单体架构，大家可能多少都有所了解，单体架构是一种传统的软件架构风格，将整个应用程序作为一个单一、紧密耦合的单体应用来构建。在单体架构中，应用程序的各个功能模块和组件共享同一个代码库和数据库。通常，单体应用程序采用单一的技术栈和部署单元，所有的功能和服务都运行在同一个进程中。

单体架构的特征：

单一代码库：整个应用程序的代码被组织在一个单一的代码库中，所有的功能模块和组件都在同一个代码库中进行开发、构建和版本控制。
共享数据库：所有的功能模块和组件共享同一个数据库。数据的访问和操作在数据库层面进行，并且通常使用数据库事务来保持数据的一致性。
紧密耦合：在单体架构中，各个模块和组件之间通常具有紧密的耦合关系。函数调用和内部方法调用是常见的通信方式，模块之间的依赖性较高。
单一部署单元：整个单体应用程序作为一个整体进行部署。通常将应用程序打包成一个可执行的部署单元（如WAR或JAR文件），然后部署到服务器上。
技术栈一致性：单体应用程序通常使用相同的技术栈和编程语言进行开发和运行。这简化了开发和维护的复杂性，并提供了一致的开发环境。

单体架构的优点：

1.架构图简单易懂；

2.对于一些小型项目来讲,开发维护简单；

3.部署一个单点tomcat上,后期维护方便；

单体架构的缺点：

1.对大型项目来讲,维护困难

2.模块之间紧密糕合,单点容错率低

3.无法针对某一个模块进行水平扩展或优化

为了解决模块之间紧密耦合，和提高单点容错率，推出了垂直应用架构

2.垂直应用架构

垂直应用架构（Vertical Application Architecture），也被称为垂直切分架构，是一种将应用程序按照业务领域或功能划分为多个垂直的模块或组件的架构风格。在垂直应用架构中，每个垂直模块专注于处理特定的业务领域或功能，例如订单管理、用户管理、支付处理等。每个模块通常都有自己的数据库、服务和用户界面，它们之间通过明确定义的接口进行通信。

垂直应用架构的特征：

高内聚：每个垂直模块具有高内聚性，即模块内的组件和功能高度相关联，处理特定的业务领域或功能。这种高内聚性可以提高模块的可维护性和开发效率。
业务驱动：垂直应用架构将应用程序的组织方式与业务领域相匹配。每个垂直模块专注于解决某个特定的业务问题，使得开发团队可以更好地理解和管理业务逻辑。
独立部署和伸缩：由于每个垂直模块都是独立的，可以独立进行部署和伸缩。这样可以实现按需伸缩，只对需要扩展的模块进行扩展，而无需整体扩展整个应用程序。
技术多样性：不同的垂直模块可以使用不同的技术栈和工具，以满足其特定需求。这样可以根据每个模块的特性选择最合适的技术，提高开发效率和灵活性。
通信机制：垂直模块之间通过明确定义的接口进行通信，常见的通信方式包括API调用、消息队列、事件驱动等。这种松耦合的通信机制使得模块之间的集成和协作更加灵活和可扩展。

垂直应用架构的优点：

系统之分之后,就可以进行水平扩展和优们提高了单点容错性；

垂直应用架构的缺点：

系统之间无法相互调用，会有一部分代码重复；

为了解决垂直应用架构带来的系统服务无法调用，解决公用代码的冗余，分布式架构就产生了。

3.分布式架构

分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。

分布式架构的特征：

1.分布性:分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。

2.对等性:分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的。副本（Replica）是分布式系统最常见的概念之一，指的是分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。数据副本是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取该数据，这是解决分布式系统数据丢失问题最为有效的手段。另一类副本是服务副本，指多个节点提供同样的服务，当每个节点都有能力接收来自外部的请求并进行相应的处理。

3.并发性:在“问题的提出”部分，我们已经提到的与“更新的并发行”相关的内容。在一个计算机网络中，程序运行过程中的并发性操作，是非常常见的行为，例如同一个分布式系统中的多个节点，可能会并发地操作一些共享的资源，诸如数据库或分布式存储等，如何准确并高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一。

4.缺乏全局时钟:在上面的讲解中，我们已经了解到，一个典型的分布式系统是由一系列在空间上随意分布的多个进程组成的，具有明显的分布性，这些进程之间通过交换消息来进行相互通信。因此，在分布式系统中，很难定义两个事件究竟谁先谁后，原因就是因为分布式系统缺乏一个全局的时钟序列控制。关于分布式系统的时钟和事件顺序，在Leslie Lamport的经典论文 Time，Clocks，and the Ordering of Events in a Distributed System中已经做了非常深刻的讲解。

5.故障总是会发生:组成分布式系统的所有计算机，都有可能发生任何形式的故障。一个被大量工程实践所检验过的黄金定理是：任何在设计阶段考虑到的异常情况，一定会在系统实际运行时发生，并且，在系统实际运行过程中还会遇到很多在设计时未能考虑到的异常故障。所以，除非需求指标允许，在系统设计时不能放过任何异常情况.

分布式架构的优点：

1.降低服务耦合:每个功能模块，都成为了单独的项目，大家各写各的项目，没有过多的牵扯耦合度就会大大的降低，两外像打包速度，代码量都会减少。

2.有利于服务升级和拓展：像以后功能模块项目/服务进行升级维护也影响不了别的功能模块项目的正常进行。

分布式架构的缺点：

调用关系如上图所示肥肠复杂,后期维护困难；

但是分布式架构带来的系统服务调用肥肠复杂，SOA架构就推出了解决方案

4.SOA架构

SOA（Service-Oriented Architecture，面向服务的架构）是一种在计算机环境中设计、开发、部署和管理离散模型的方法。SOA不是一种新鲜事物，它是在企业内部IT系统重复构建以及效率低下的背景下提出的。在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统，当然，由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)，因此，其本身也会引入更多的复杂性。

SOA架构的特征：
        1.服务的封装（encapsulation）：将服务封装成用于业务流程的可重用组件的应用程序
函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐
藏了复杂性。服务的 API 保持不变，使得用户远离具体实施上的变更。
        2.服务的重用（reuse）：服务的可重用性设计显著地降低了成本。为了实现可重用性，
服务只工作在特定处理过程的上下文（context）中，独立于底层实现和客户需求的变更。
        3.服务的互操作(interoperability)：互操作并不是一个新概念。在 CORBA、DCOM、
web service 中就已经采用互操作技术。在 SOA 中，通过服务之间既定的通信协议进行互操
作。主要有同步和异步两种通信机制。SOA 提供服务的互操作特性更有利于其在多种场合被
重用。
        4.服务是自治的（Autonomous）功能实体：服务是由组件组成的组合模块，是自包含
和模块化的。
SOA 非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，
如.NET Remoting、EJB、COM 或者 CORBA，都需要有一个宿主(Host 或者 Server)来存放和
管理这些功能实体；当这些宿主运行结束时，这些组件的寿命也随之结束。这样当宿主本身
或者其他功能部分出现问题的时候，在该宿主上运行的其他应用服务就会受到影响。
SOA 架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如
事务处理(Transaction)、消息队列(Message Queue)冗余部署(Redundant Deployment)和集群系
统(Cluster)在 SOA 中都起到至关重要的作用。
        5.服务之间的松耦合度(Loosly Coupled）：服务请求者到服务提供者的绑定与服务之间
应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语
言、部署平台，等等。服务请求者往往通过消息调用操作，请求消息和响应，而不是通过使
用 API 和文件格式。
这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式
保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码（如 COBOL）的实
现完全用基于 Java 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真
实的，只要新代码支持相同的通信协议。
        6.服务是位置透明的(location transparency）：服务是针对业务需求设计的。需要反映
需求的变化，即所谓敏捷（agility）设计。要想真正实现业务与服务的分离，就必须使得服
务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服
务的位置，甚至不必知道具体是哪个服务参与了响应。

SOA架构的优点：

使用服务治理中心帮我们维护复杂的调用关系

SOA架构的缺点：

服务有依赖性,可能会因为一个服务的问题,导致多个系统不可用(拆分的不够彻底)

SOA出现了什么问题？

服务越来越多，需要管理每个服务的地址
调用关系错综复杂，难以理清依赖关系
服务过多，服务状态难以管理，无法根据服务情况动态管理

服务治理要做什么？

服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
动态监控服务状态监控报告，人为控制服务状态

5.微服务架构(服务的原子化拆分)

前面说的SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非常容易混淆，但其实缺有一些差别：

微服务架构图：

微服务的特点：
1.单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
2.微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
3.面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
4.自治：自治是说服务间互相独立，互不干扰
        团队独立：每个服务都是一个独立的开发团队，人数不能过多。
        技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
        前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
        数据库分离：每个服务都使用自己的数据源
        部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护