1、系统架构演变过程

随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。 从互联网早起到现在，系统架构大体经历了下面几个过程: 单体应用架构 → 垂直应用架构 → 分布式架构 → SOA架构 → 微服务架构，当然还有悄然兴起的Service Mesh（服务网格化）。

系统架构演变

接下来我们就来了解一下每种系统架构是什么样子的， 以及各有什么优缺点。

1.1、单体应用架构

互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。 如：一个电商系统，里面会包含很多用户管理、商品管理、订单管理、物流管理等多个模块， 我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。

单体应用架构

所谓“单体应用架构（all in one）”是指：我们将一个应用中的所有应用服务都封装在一个应用中。无论是ERP、CRM或其它系统，我们都把数据库访问、Web访问等功能放在一个war包内。all in one的架构方式，我们把所有的功能单元放在一个应用里面，然后把整个应用部署到服务器上。

  • 优点：
    • 项目架构简单，易于开发和测试（适合小型项目）；
    • 方便部署，项目部署在一个Tomcat上；
    • 当需要扩展时，只需将war包复制多份，然后放到多个服务器上，再做个负载均衡就可以了。
  • 缺点：
    • 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护；
    • 项目模块之间紧密耦合，单点容错率低（即：一个模块出问题，可能导致整个应用不能正常使用）；
    • 无法针对不同模块进行针对性优化和水平扩展。如果负载能力不行，我们需要将整个应用进行水平复制，进行扩展，然后再负载均衡。哪怕要修改一个非常小的地方，我们都要停掉整个服务，重新打包、部署整个应用的war包。

1.2、垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。

还是以上面的电商为例，用户访问量的增加可能影响的只是用户和订单模块，但是对消息模块的影响就比较小。那么此时我们希望只多增加几个订单模块，而不增加消息模块。此时单体应用架构就做不到了，垂直应用架构就应运而生了。

所谓的垂直应用架构：就是将原来的一个项目拆成互独立的几个项目，并将各项目分开部署在不同的Tomcat上。比如我们可以将上面电商的单体应用拆分成：

  • 电商系统（主要负责：用户管理、商品管理、订单管理）
  • 后台系统（主要负责：用户管理、订单管理、客户管理）
  • CMS系统（主要负责：广告管理、营销管理）

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。

**注：**垂直应用架构中的各个项目常采用MVC三层架构设计。

垂直应用架构

优点：

  • 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展；
  • 一个系统的问题不会影响到其他系统，提高了单点容错率。

缺点：

  • 系统之间相互独立，无法进行相互调用；
  • 系统之间相互独立，会有重复的开发工作。

1.3、分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就将重复的代码抽取出来，做成独立的服务，组成服务层，然后通过前端的控制层去调用服务层不同的服务来实现各种业务逻辑。

这就产生了新的分布式系统架构。它将把各个项目拆分成控制层和服务层两个部分。其中：控制层负责处理和页面的交互（类似于Controller层）；服务层负责提供具体的服务（类似于Service层）。

**注：**常用的分布式框架有：RPC（Remote Procedure Call，远程过程调用）框架等。

分布式架构

**优点：**抽取各个项目公共的功能为服务层，提高了代码的复用性。

**缺点：**各个系统之间的耦合度变高，调用关系错综复杂，用户难以维护。

1.4、SOA架构

在分布式架构下，当服务越来越多，容量的评估、小服务资源的浪费等问题逐渐显现，此时需增加一个服务调度中心对集群进行实时管理。此时，用于资源调度和服务治理的中心SOA（Service Oriented Architecture，面向服务的架构）才是关键。

SOA架构

**注：**阿里巴巴的Dubbo目前比较流行的服务治理中心。

优点： 使用服务注册中心解决了服务间调用关系的自动调节。

**缺点：**由于服务拆分的不够彻底，服务间会有依赖关系，一旦某个服务出错可能会导致多个系统崩溃（即：服务雪崩）。

1.5、微服务架构

在某种程度上，微服务架构是在面向服务的SOA架构的基础上发展来的，它更加强调服务的**“彻底拆分”**。

微服务架构

优点：

  • 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展；
  • 微服务之间采用Restful风格等轻量级的http协议相互调用。

**缺点：**分布式系统开发的技术成本高（容错、分布式事务等）。

2、什么是微服务架构

**微服务架构也是一种分布式架构风格。**它要求我们在开发一个应用的时候，这个应用必须构建成一系列小服务的组合。

  • 每个微服务都围绕着具体的业务进行构建，并且能够独立地部署；
  • 对于具体的一个微服务而言，应根据业务实际，选择合适的语言和工具对其进行构建，可以使用不同的语言来编写服务；
  • 每一个服务能够单独启动和销毁，可以拥有自己独立的数据库；
  • 每个服务运行在自己独立的进程中；
  • 服务之间可以通过http/RPC等方式进行通信；
  • 微服务架构的根本目的是为了解耦。

注：IDEA中的每一个SpringBoot项目或模块（Module）就是一个微服务。

所谓“微服务架构”，就是打破之前“all in one”的架构方式，把每一个功能元素独立出来。把独立出来的功能元素动态组合，需要的功能元素才拿来组合，需要多一些时可以整合多个功能元素。所以，微服务架构是对功能元素进行复制，而没有对整个应用进行复制。

SpringCloud架构

这样做的好处是：

  • 节省了调度资源。
  • 每个功能元素的服务都是一个可替换的、可独立升级的软件代码。
单体应用与微服务

注：Martin Fowler于2014年3月25日写的《Microservice》，详细阐述了什么是微服务。

3、如何构建微服务

SpringCloud的微服务弹性

一个大型系统的微服务架构，就像一个复杂交织的神经网络，每一个神经元就是一个功能元素，它们各自完成自己的功能，然后通过http互相请求调用。比如一个电商系统，查缓存、连接数据库、浏览页面、结账、支付等服务都是一个个独立的功能服务，它们都被微服务化了，它们作为一个个微服务共同构建了一个庞大的系统。如果修改其中的一个功能，只需更新升级其中的一个功能服务单元即可。

但是这种庞大的系统架构给部署和运维带来了很大的难度。于是，Spring为我们带来了构建大型分布式微服务的全套产品，主要包括：

  • 构建一个个功能独立的微服务应用单元，可以使用Spring Boot，它可以帮助我们快速构建一个应用（微服务）。
  • 大型分布式网络服务的调用，这部分由Spring Cloud来完成，实现分布式。
  • 在分布式中间，进行流式数据计算、批处理，我们有Spring cloud data flow。
  • Spring为我们想清楚了整个从开始构建应用到大型分布式应用的全流程方案。

SpringBoot与SpringCloud

4、★微服务架构的常见问题

微服务架构主要解决分布式系统中存在的以下5个问题：

  • 这么多服务，如何对所有的服务进行统一管理？（即：服务注册与发现问题）
  • 这么多服务，服务与服务之间如何进行通信（HTTP或RPC）？（即：服务调用问题）
  • 这么多服务，客户端该如何访问？（即：API网关问题）
  • 这么多服务，如果服务出现问题了，系统应该如何自处理？（即：服务容错问题）
  • 这么多服务，如果服务出现问题了，程序员应该如何排错? （即：链路追踪问题）

对于上述5个问题，是任何一个微服务架构都不能绕过去的。因此，针对上述5个问题，采用不同的技术栈解决它们，便得到不同的微服务架构。虽然不同微服务架构的技术栈不同，但它们的本质都是解决上述5个问题。

5、微服务架构的常见概念

微服务架构的以下5个概念，依次为微服务架构上述5个问题的解决方案。

5.1、服务治理

服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。

  • **服务注册：**服务实例将自身服务信息注册到注册中心。
  • **服务发现：**服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
  • **服务剔除：**服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

5.2、服务调用

在微服务架构中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。

  • REST（Representational State Transfer）

    • 这是一种HTTP调用的格式（风格），更标准、更通用；
    • 无论哪种语言都支持http协议。

  • RPC（Remote Promote Call，远程过程调用）

    • RPC协议是一种进程间通信方式，它允许像调用本地服务一样调用远程服务；
    • RPC框架的主要目标就是让远程服务调用更简单、透明；
    • RPC框架负责屏蔽底层的传输方式、序列化、反序列化和通信等细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

RESTful与RPC对比如下：

比较项 RESTful RPC
通讯协议 HTTP 一般使用TCP
性能 略低 较高
灵活度 高 低
应用 一般用于微服务架构 一般用于SOA架构

5.3、服务网关

不同的微服务一般会有不同的网络地址。随着微服务的不断增多，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：

  • 客户端需要调用不同的url地址，增加难度；
  • 在一定的场景下，存在跨域请求的问题；
  • 每个微服务都需要进行单独的身份认证；

针对这些问题，API网关顺势而生。

API网关字面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。

一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

服务网关

5.4、服务容错

在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。

服务容错

我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是：

  • 不被外界环境影响
  • 不被上游请求压垮
  • 不被下游响应拖垮

5.5、链路追踪

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能是使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪。

6、★主流的微服务框架

针对分布式系统存在的上述5个问题，目前常见的解决方案主要有以下4套（即4种主流的微服务框架）：

微服务架构 特点 服务注册与发现解决方案 服务之间通信解决方案 API网关解决方案 服务熔断机制解决方案
SpringCloud Netflix 一站式解决方案、2018年12月宣布无限期停止维护 Eureka Feign（基于HTTP） zuul组件 Hystrix
Apache Dubbo + zookeeper 半自动解决方案、没有API网关和服务熔断机制解决方案，需要找第三方组件或自己实现 zookeeper Dubbo（RPC通信框架） 没有 没有
SpringCloud Alibaba 新的一站式解决方案 Nacos Discovery Dubbo（RPC通信框架） Dubbo+Servlet Sentinel
Server Mesh（服务网格） 下一代微服务架构（新概念） – – – –

注：

  • 分布式微服务架构之所以要解决上述5个问题，本质上是解决网络传输不可靠的问题。
  • Spring Cloud不是一种具体的技术，而是一种生态（技术栈）。
  • 一般我们谁说的SpringCloud指的就是Netflix公司的SpringCloud Netflix。
  • SpringCloud Alibaba是目前比较主流的微服务框架。

7、SpringCloudAlibaba简介

SpringCloudAlibaba微服务架构原理及技术栈（组件）如下图所示：

SpringCloudAlibaba

**注：**服务调用我们这里推荐使用的技术栈（组件）是SpringCloud官方的OpenFeign，而不是SpringCloudAlibaba自带的Dubbo。

SpringCloudAlibaba致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过SpringCloud编程模型轻松使用这些组件来开发分布式应用服务。

依托SpringCloudAlibaba，您只需要添加一些注解和少量配置，就可以将SpringCloud应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

（本讲完，系列博文持续更新中…… ）

阿汤笔迹微信公众平台

关注**“阿汤笔迹”** 微信公众号，获取更多学习笔记。
原文地址：http://www.atangbiji.com/2023/08/27/SpringCloudOverview
博主最新文章在个人博客 http://www.atangbiji.com/ 发布。