（一）软件架构演进与微服务架构

一、软件架构演进

软件架构的发展经历了从单体结构、垂直架构、SOA架构到微服务架构的过程。

1、单体架构

1.1 特点：

• 所有的功能集成在一个项目工程中。

• 所有的功能打一个war包部署到服务器。

• 应用与数据库分开部署。

• 通过部署应用集群和数据库集群来提高系统的性能。

1.2 优点：

• 项目架构简单，前期开发成本低，周期短，小型项目的首选。

1.3 缺点：

• 1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

• 2、系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

• 3、技术栈受限。

2、垂直架构

2.1 特点：

• 1、以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。

• 2、项目与项目之间的存在数据冗余，耦合性较大，比如上图中三个项目都存在客户信息。

• 3、项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

2.2 优点：

• 1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

• 2、通过垂直拆分，原来的单体项目不至于无限扩大。

• 3、不同的项目可采用不同的技术。

2.3 缺点： 

• 1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

• 2、系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

3、SOA架构

3.1 特点：

• 1、基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务。

• 2、各各项目（系统）与服务之间采用webservice、rpc等方式进行通信。

• 3、ESB企业服务总线作为项目与服务之间通信的桥梁。

3.2 优点：

• 1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。

• 2、可以针对不同服务的特点制定集群及优化方案。

• 3、采用ESB减少系统中的接口耦合。

3.3 缺点：

• 1、系统与服务的界限模糊，不利于开发及维护。

• 2、虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

• 3、抽取的服务的粒度过大，系统与服务之间耦合性高。

4、微服务架构

4.1 特点：

• 1、将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。

• 2、微服务遵循单一原则。

• 3、微服务之间采用RESTful等轻量协议传输。

4.2 优点：

• 1、服务拆分粒度更细，有利于资源重复利用，提高开发效率。

• 2、可以更加精准的制定每个服务的优化方案，提高系统可维护性。

• 3、微服务架构采用去中心化思想，服务之间采用RESTful等轻量协议通信，相比ESB更轻量。

• 4、适用于互联网时代，产品迭代周期更短。

4.3 缺点：

• 1、微服务过多，服务治理成本高，不利于系统维护。

• 2、分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大。

二、微服务架构

1、什么是微服务

可以理解为：为适应企业的业务发展，提高软件研发的生产力，降低软件研发的成本，软件架构也作了升级和优化，将一个独立的系统拆分成若干小的服务，每个小服务运行在不同的进程中，服务与服务之间采用http 轻量协议（比如流行的RESTful）传输数据，每个服务所拥有的功能具有独立性强、高内聚的特点，这样的设计就实现了单个服务的高内聚，服务与服务之间的低耦合效果，这一个一个的小服务就是微服务，基于这种方法设计的系统架构即微服务架构。

2、微服务中的相关概念

2.1 服务注册与发现

• 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。
• 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

2.2 负载均衡

·负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。

2.3 熔断

熔断这一概念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。

2.4 链路追踪

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

2.5 API网关

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

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

针对这些问题，API网关顺势而生：API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

三、SpringCloud微服务框架

1、什么是SpringCloud

1.1 SpringCloud

Spring Cloud的本质是在 Spring Boot 的基础上，增加了一堆微服务相关的规范，并对应用上下文（Application Context）进行了功能增强。既然 Spring Cloud 是规范，那么就需要去实现，目前Spring Cloud 规范已有 Spring官方，Spring Cloud Netflix，Spring Cloud Alibaba等实现。通过组件化的方式，Spring Cloud将这些实现整合到一起构成全家桶式的微服务技术栈。如下图所示：

1.2 SpringCloud实现的组件

• Spring Cloud Netflix组件

组件名称	作用
Eureka	服务注册中心
Ribbon	客户端负载均衡
Feign	声明式服务调用
Hystrix	客户端容错保护
Zuul	API服务网关

• Spring Cloud Alibaba组件

组件名称	作用
Nacos	服务注册中心
Sentinel	客户端容错保护

• Spring Cloud原生及其他组件

组件	作用
Consul	服务注册中心
Config	分布式配置中心
Gateway	API服务网关
Sleuth/Zipkin	分布式链路追踪

1.3 为什么要使用SpringCloud

微服务架构的优点表明它可以提高我们的生产力，但是分布式系统本身的技术成本问题给互联网那些创业型公司不少的挑战，阿里、百度等巨头所提供的微服务技术只是解决其中某个问题，而整合封装这些优秀的技术恐怕是Spring最擅长的领域了，Spring Cloud也正因为此而诞生。

使用Spring Cloud来构建微服务架构可以省去你整合各家技术的成本，Spring Cloud为我们构建微服务架构提供了一站式的解决方案，就好比当初Spring诞生是为解决EJB企业应用开发的众多问题而提供的一站式轻量级企业应用开发解决方案一样，随着使用Spring Cloud公司数量的增加，相信微服务将被Spring Cloud一统江湖。

2、SpringCloud的体系结构

2.1 SpringCloud的技术体系结构

核心体系结构如下图所示：

从上图可以看出Spring Cloud各个组件相互配合、合作支持了一套完整的微服务架构。

• 注册中心负责服务的注册与发现，很好将各服务连接起来
• 断路器负责监控服务之间的调用情况，连续多次失败进行熔断保护。
• API网关负责转发所有对外的请求和服务
• 配置中心提供了统一的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息
• 链路追踪技术可以将所有的请求数据记录下来，方便我们进行后续分析
• 各个组件又提供了功能完善的dashboard监控平台,可以方便的监控各组件的运行状况