1. 分布式架构演进

1.1 单体架构

Web应用程序发展的早期，大部分web工程(包含前端页面,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。

比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构。

优点：简单易构。
缺点：资源有限，不支持高可用，高性能，高并发。

1.2 垂直架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

优点：比单体稍复杂，任然简单易构。
缺点：资源有限，不支持高可用，高性能，高并发。

1.3 SOA架构

SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生。目的是把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

SOA实质就把各个重用的服务单独抽离出来对外提供服务。类似于中台架构。

SOA 特点：分布式、可重用、扩展灵活、松耦合
优点：降低了耦合性，提高了并发能力。
缺点：抽取服务粒度大。

1.4 微服务架构

各个模块拆分成独立的服务，每个独立的服务在通过分布式集群架构实现高可用，高性能，高并发。
优点：实现高可用，高性能，高并发。
缺点：服务过多，技术门槛高，维护成本高。

1.5 SOA与微服务关系

SOA（ Service Oriented Architecture ）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

2. 分布式架构理论

2.1 远程调用

REST，即Representational State Transfer的缩写，如果一个架构符合REST原则，就称它为RESTful架构。

RPC（Remote Procedure Call ） 一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式（TCP或者UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

在常见的企业架构中通常内部采用RPC调用，外部采用restful方式调用，也就是常说的对内rpc对外restful。

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

1.HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。
2.RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

2.2 CAP定理

分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。CAP理论由 Eric Brewer 在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。

Consistency（一致性）：数据一致更新，所有数据的变化都是同步的。
Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
Partition tolerance（分区容忍性）：某个节点的故障，并不影响整个系统的运行。

CAP理论就是任何分布式系统只可同时满足二点，没法三者兼顾，既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：

CAP组合	组合说明
CA	放弃分区容错性，加强一致性和可用性，其实就是传统的关系型数据库的选择
AP	放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此
CP	放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用

需要明确一点的是，在一个分布式系统当中，分区容忍性和可用性是最基本的需求，所以在分布是系统中，我们的系统最当关注的就是A（可用性）P（容忍性），通过补偿的机制寻求数据的一致性。

2.3 一致性分类

根据CAP理论可知CAP之间不同的组合方式具有不同的特点属性，而在具体的设计架构中也需要结合实际的业务场景进行选择取舍，根据CAP理论一致性可分为，强一致性，弱一致性，与最终一致性。

1.强一致性
强一致性保证的数据的一致性，当系统中某个数据被更新的时候，同时进行的所有操作都将等待前一个操作执行完成，再去获取最新的值，要永远保证获取到的都是最新的值，简言之，在任意时刻，所有节点中的数据是一样的。例如，对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。

强一致性特点
一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后，才能正常的对外提供服务。保证了强一致性，务必会损耗可用性。

2.弱一致性
弱一致性强调的是数据同步具有一定的延迟，是在业务可接受范围内的延迟，不会对具体的业务造成损失，当系统中某个数据更新时，同时读取该数据在极短的时间窗口期内读取到的不是最新数据，过了该窗口期数据同步完成，则才可读取到最新的数据。这里强调的是业务可接受的延迟。例如12306买火车票，虽然最后看到还剩下几张余票，但是只要选择购买就会提示没票了，这就是弱一致性。

3.最终一致性
最终一致性本质上也是一种弱一致性，也是一种延迟同步数据的方式，就是最终数据是一致的，至于最终的时间周期是多久就要根据业务及设计实现了。

最终一致性特点
不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。

2.4 BASE理论

BASE理论是建立在CAP定理的基础上的，是对一致性与可用性的扩充，在保证可用性的基础上，权衡数据一致性的业务可接受范围。所以base理论可分为以下三种状态。

基本可用：Basically Available（基本可用）
软状态：Soft state（软状态）
最终一致性：Eventually consistent（最终一致性）

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

3. SpringCloud分布式架构

3.1 SpringCloud架构分类

架构是个比较大的概念，目前市场上架构设计方案也百花齐放，任何一种架构都是演进的结果，都是特定时间，特定场景，特定问题的解决方案，不同时间，不同行业，不同业务场景都有自己独具特色的架构设计方案，没有什么是最好，也不是说使用什么架构就是厉害，只有适合自己的才是最好的。
springcloud官网提供方案参考：https://spring.io/projects/spring-cloud

目前市场上常见的三种微服务架构解决方案：
第一套微服务架构解决方案：Spring Boot + Spring Cloud Netflix
第二套微服务架构解决方案：Spring Boot + Spring Cloud Alibaba
第三套微服务架构解决方案：Spring Boot + Dubbo + Zookeeper

3.2 Spring Boot + Spring Cloud Netflix

第一套微服务架构解决方案：Spring Boot + Spring Cloud Netflix。Spring Cloud Netflix 提供了一整套 快速构建分布式系统中一些常见模式的工具，可以快速地支持实现这些模式的服务和应用程序。

Spring Cloud Netflix 的核心组件

Eureka：服务注册于发现。
Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。
Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。
Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。
Zuul：网关管理，由 Zuul 网关转发请求给对应的服务。
config: 分布式配置。

注意：
2018 年 12 月 12 日，Netflix 宣布 Spring Cloud Netflix 系列技术栈进入维护模式（不再添加新特性）将模块置于维护模式，
意味着 Spring Cloud 团队将不会再向模块添加新功能。我们将修复 block 级别的 bug 以及安全问题，我们也会考虑并审查社区的小型 pull request。

3.3 Spring Boot + Spring Cloud Alibaba

第二套微服务架构解决方案：Spring Boot + Spring Cloud Alibaba。Spring Cloud Alibaba 致力于提供 微服务开发的 一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

Spring Cloud Alibaba 核心组件

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载等多个维度保护服务的稳定性。
Nacos：  服务注册与发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于分布式集群技术，提供高可用、低延时的的消息发布与订阅服务。
Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。
Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

3.4 Spring Boot + Dubbo + Zookeeper

第三套微服务架构解决方案：Spring Boot + Dubbo + Zookeeper。Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架。ZooKeeper 是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。

高性能 Java RPC 框架 Dubbo
Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 分布式服务框架。

它提供了三大核心能力：
面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo 采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

Zookeeper 分布式协调服务框架。--具体参照zookeeper章节

4. SpringCloud架构详解

SpringCloud ，SpringCloud Netflix，SpringCloudAlibaba各个组件详解。

SpringCloud架构详解：https://blog.csdn.net/m0_37583655/article/details/121993606