分布式/微服务理论知识

分布式系统和微服务架构越来越流行，特意卖了一本《SpringCloud微服务与分布式系统实战》来给自己充充电，也是掌握技术的必经之路。

一、分布式系统

大数据、高并发和快响应已经成为互联网系统的必然要求。

在之前的单机系统中，大量的数据会导致查找数据的响应时间边长。高并发会使系统因为繁忙而变慢，从而影响响应速度，单机故障也会是系统崩溃。

为了解决单机系统带来的问题，互联网系统就从单机系统演变位多台机器的系统。

1、分布式系统简介

分布式系统由一组为了完成共同任务而协调工作的计算机节点组成，它们通过网络进行通讯。

分布式系统在不同的硬件，不同的软件，不同的网络，不同的计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

分布式系统能满足互联网对大数据存储、高并发和快响应的要求，采用了分而治之的思想。

好处：

• 高性能：大量请求可以分摊到各个节点上，从而解决系统的大数据、高并发和快响应问题。
• 高可用：请求会避开存在故障的节点，使用其他节点，系统仍然可以继续工作。
• 可伸缩性：对于现有机器节点可以根据业务量灵活的进行增加或者减少。
• 可维护性：对出现故障的节点，进行处理之后可以重新上线。
• 灵活性：对于系统的更新迭代，可以在非高峰期，停止部分节点更新，然后交替去更新剩下的节点，从而更加灵活，不需要停止系统的工作。

2. 分布式的切分方法

在分布式系统中，会根据业务或者数据将系统合理切分给各个不同的节点的机器，从而让多个机器节点能够互相协作，完成业务的需求。

常见的切分方法如下：

• 水平切分：水平切分是指将同一个系统部署到多台机器上。
• 垂直切分：垂直切分是按照业务的维度进行拆分，将各个业务独立出来，单独开发和维护。
• 混合切分：混合切分是将水平切分和垂直切分结合起来的一种切分方法。

微服务架构中大部分都是采用混合切分方法。

3. 分布式系统面临的问题

对系统进行拆分之后会带来很多问题，有兴趣可以去了解下分布式计算的八大谬论。

1. The network is reliable 网络是可靠的
2. Latency is zero 网络是没有延迟的
3. Bandwidth is infinite 带宽是无限的
4. The network is secure 网络是安全的
5. Topology doesn’t change 网络拓扑不会改变
6. There is one administrator 肯定至少有一个（在值班的）管理员
7. Transport cost is zero 传输开销为零
8. The network is homogeneous 网络是均匀的（同质的）

如上，分布式系统有很多需要攻克的问题，这里了解一下通讯异常，网络分区，三态，节点故障等。

1）通信异常

通讯异常其实就是网络异常，网络系统本身是不可靠的，由于分布式系统需要通过网络进行数据传输，网络光纤，路由器等硬件难免出现问题。

只要网络出现问题，也就会影响消息的发送与接受过程，因此数据消息的丢失或者延长就会变得非常普遍。

2）网络分区 网络分区，其实就是脑裂现象。

比如：本来有一个交通警察，来管理整个片区的交通情况，一切井然有序，突然出现了停电，或者出现地震等自然灾难，某些道路接受不到交通警察的指令，可能在这种情况下，会出现一个零时工，片警零时来指挥交通。

但注意，原来的交通警察其实还在，只是通讯系统中断了，这时候就会出现问题了，在同一 个片区的道路上有不同人在指挥，这样必然引擎交通的阻塞混乱。

这种由于种种问题导致同一个区域（分布式集群）有两个相互冲突的负责人的时候就会出现这种精神分裂的情况，在这里称为脑裂，也叫网络分区。

3）三态 三态是什么？

三态其实就是成功，与失败以外的第三种状态，当然，肯定不叫变态，而叫超时态。

在一个 JVM 中，应用程序调用一个方法函数后会得到一个明确的相应，要么成功，要么失败。 而在分布式系统中，虽然绝大多数情况下能够接受到成功或者失败的相应，但一旦网络出现异常，就非常有可能出现超时/延迟，当出现这样的超时现象，网络通讯的发起方，是无法确定请求是否成功处理的。

4）节点故障

节点故障在分布式系统下是比较常见的问题，指的是组成服务器集群的节点会出现的宕机或“僵死”的现象，这种现象经常会发生。

所以，分布式系统的核心问题就在于：

• 如何保持数据的一致性：它不想单点系统的事务回滚那么简单，需要通过分布式事务或者其他方法来提供保证。
• 保证系统的性能问题：再保证数据一致性的时候，系统性能会大幅下降，所以考虑性能也是核心问题。

总结为一句话就是：如何保证多个节点之间保持一致性，服务于企业实际业务。

二、分布式系统的设计原则

了解了分布系统的特点以及会碰到很多会让人头疼的问题，这些问题肯定会有一定的理论思想来解决问题的。

最著名和最具影响力的理论是 CAP原则和 BASE理论。它两也是最基础的理论思想。

1、CAP原则

分布式系统中主要的特点是一致性、可用性和分区容忍。

• 一致性（Consistency）：保证所有节点在同一个时刻具有相同的、逻辑一致的数据。
• 可用性（Availability）：保证每个请求不管成功还是失败都有响应。
• 分区容错性（Partition tolerance）：系统中任何的信息丢失或者失败都不会影响系统的继续运作。

Eric Brewer教授针对这 3个特点在 2000年提出了 CAP原则，也称为 CAP定理。

CAP 其实就是一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个词的缩写。

CAP原则指出：任何分布式系统都不能同时满足这 3个特点。

1.1 一致性

一致性（Consistency）：保证所有节点在同一个时刻具有相同的、逻辑一致的数据。

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。

如果能够在分布式系统中针对某一个数据项的变更成功执行后，所有用户都可以马上读取到最新的值，那么这样的系统就被认为具有【强一致性】。在 CAP原则中的一致性是指强一致性。

1.2 可用性

可用性（Availability）：保证每个请求不管成功还是失败都有响应。但是不保证获取的数据为最新数据。

可用性是指系统提供服务必须一直处于可用状态，对于用户的操作请求总是能够在有限的时间内返回结果。

重点理解【有限的时间】和【返回结果】：

• 为了做到有限的时间需要用到缓存，需要用到负载，这个时候服务器增加的节点是为性能考虑；
• 为了返回结果，需要考虑服务器主备，当主节点出现问题的时候需要备份的节点能最快的顶替上来，千万不能出现 OutOfMemory 或者其他 500，404 错误，否则这样的系统我们会认为是不可用的。

1.3 分区容错性

分区容错性（Partition tolerance）：系统中任何的信息丢失或者失败都不会影响系统的继续运作。

分布式系统在遇到任何网络分区故障的时候，仍然需要能够对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。不能出现脑裂的情况。

1.4 CAP原则选择

CAP原则指出：任何分布式系统都不能同时满足这 3个特点。 在 CAP原则中的一致性是指强一致性。

根据 CAP原则，分布式系统只能满足3种情况：

• CA：满足一致性和可行性的系统。在可扩展性上难有建树。
• CP：满足一致性和分区容忍性的系统。通常性能不是特别高。
• AP：满足可用性和分区容忍性的系统。通常对一致性要求比较低，但是性能会比较高。

一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个基本需求，最多只能同时满足这三项中的两项（P 是必须的，因此只能在 CP 和 AP中选择）。

所以，架构师应该从一致性（A）和可用性（C）之间寻求平衡，系统短时间完全不可用（C）肯定是不允许的，P 又是必须的。那么在分布式环境下必然也无法做到强一致性（A），从而针对强一致性（A）演化出了 BASE理论。

• Zookeeper 保证的是 CP。Zookeeper写入是强一致性，读取是顺序一致性。
• Spring Cloud 系统中的注册中心 eureka保证的是 AP。

2、BASE理论

BASE理论是对 CAP 原则中一致性（C）和可用性（A）权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 原则逐步演化而来的。

BASE理论的核心思想就是：即分布式系统即使无法做到强一致性，也可以采用适当的方法来达到最终的一致性。即放弃强一致性，来保证系统的可用性，从而达到最终一致性。

**通俗来理解 BASE理论：**即使我们无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性。

在 BASE理论中，一致性分为强一致性和弱一致性。

• 强一致性：当用户更新数据之后，必须保证后续线程或者节点都能马上访问到最新的值。
• 弱一致性：当用户更新数据之后，并不能保证后续线程或者节点都能马上访问到最新的值，它只能通过某种方法来保证最后的一致性。

BASE 是 Basically Available(基本可用)、Soft Sstate(软状态) 和 Eventually Consistent(最终一致性) 这三个短语的简写。

1.1 BA(Basically Available)

基本可用：指分布式系统在出现故障的时候，保证系统有响应返回，保障系统实现基本可用。

允许损失部分可用性（服务降级、页面降级），来保证核心可用，体现在“时间上的损失”和“功能上的损失”。 比如：在高并发的场景下，部分用户双十一高峰期淘宝页面卡顿或降级处理，提示“系统繁忙，待会再来”。

1.2 S(Soft Status)

其实就是前面讲到的三态，既允许系统中的数据存在中间状态，既系统的不同节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性。

软状态：指允许分布式系统出现中间状态（延时态）。而该中间状态不会影响系统整体可用性。

这里的中间状态是指不同的 Data Replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。 比如：分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。

1.3 E(Eventual Consistency)

最终一致性：指分布式系统中所有数据副本经过一段时间的数据同步后，最终能够达到一致的状态，以保证数据的正确性。

弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

强一致性：又称线性一致性(linearizability )

1. 任意时刻，所有节点中的数据是一样的,
2. 一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后，才能正常的对外提供服务。
3. 保证了强一致性，务必会损耗可用性

弱一致性:

1. 系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。
2. 即使过了不一致时间窗口，后续的读取也不一定能保证一致。

最终一致性:

1. 弱一致性的特殊形式,不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化
2. 存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值

顺序一致性:

1. 任何一次读都能读到某个数据的最近一次写的数据。
2. 对其他节点之前的修改是可见(已同步)且确定的，并且新的写入建立在已经达成同步的基础上。

三、微服务架构

最受欢迎的分布式系统架构就是微服务架构了。

1、微服务架构简介

微服务架构是将一个单体系统拆分为多个相对独立的服务，每一个服务拥有独立的进程和数据，每一个服务都是以轻量级的通信机制来进行交互的，从而达到协同的效果。

一般服务都是根据业务模块来进行的，可以是独立的产品。

2、微服务的风格

微服务没有明确的概念和定义，但是微服务存在一定的风格，只要系统架构满足一定的风格，就可以被称为微服务架构。

Eric Brewer教授提出了微服务的九个风格。有兴趣自行了解。

开发中，一般我们遵守 REST原则的 Web服务，即RESTful。

3、微服务和分布式的区别/关系

1）字面含义上

• 分布式的意思是多个模块共同完成一件事情（可以是一个模块分多个部署），每个节点可以单独完成任务（分开不同机器部署）。
• 微服务的意思也是多个模块共同完成一件事情（(不管应用部署在哪里)）。

2）拆分单体系统上

• 微服务和分布式都是拆分单体应用的产物，
• 微服务只是对服务拆分的形容词，分布式是对服务部署方面的考量

3）从两者关系上

• 微服务是可以包含分布式的，但是分布式不一定是微服务。
• 微服务是分布式系统设计和架构的理念之一。但是微服务并不能解决所有的分布式系统的问题。
• 微服务只是寻找一个平衡点，让架构师能够更简单、容易地构建分布式系统。

四、SpringCloud

分布式服务框架有很多，单独使用他们可能会比较上手。

SpringCloud的开发团队就把各家开源的分布式服务框架，进行了整合，就形成了现在的 SpringCloud的组件。

注意：SpringCloud没有重复造轮子，而是通过技术进行整合。

SpringCloud就是通过这种方式构建了一个较为完整的企业级实施微服务的方案。同时开发团队将分布式框架通过 SpringBoot进行了封装，屏蔽了难懂的细节，给开发者提供了一套简单易懂、易部署和易维护的分布式开发工具包。

1、SpringBoot与SpringCloud 的关系

SpringCloud 是一套目前较完整的微服务解决框架，功能非常强大。注册中心、客户端调用工具、服务治理等。

SpringBoot 是一个快速开发框架，能够帮助我们快速整合第三方常用框架（Maven 依赖继承关系），完全采用注解化，简化XML配置，内置嵌入Http服务器（Tomcat、Jetty、undertow），默认嵌入Tomcat服务器。最终以Java应用程序进行执行（java -jar xxx.jar）。

两者的关系：

• SpringBoot + SpringCloud 就是微服务开发，
• 微服务通讯技术是 http+json(restful) 轻量级

2、SpringCloud组件

常见的组件如下：

• Spring Cloud Config：配置管理
• Spring Cloud Bus：消息总线
• Netflix Eureka：服务治理中心
• Netflix Hystrix：熔断器
• Netflix Xuul：API网关
• Spring Cloud Security：为微服务提供安全控制
• Spring Cloud Sleuth：日志收集工具包
• Spring Cloud Stream：分布式数据流操作
• Netflix Rubbon：提供客户端的负载均衡
• OpenFeign：一个声明式的调用方案
• Spring Cloud Task：微服务的任务计划管理和任务调度方案

SpringCloud未来有去 Netflix组件的趋势，比如：Resilience4j将会作为新的熔断器。

参考文章：

• 分布式计算中的八大谬论：https://blog.csdn.net/peterwanghao/article/details/81293461
• CAP 定理的含义-阮一峰：http://www.ruanyifeng.com/blog/2018/07/cap.html
• 凤凰架构：https://icyfenix.cn/summary/

– Stay Hungry. Stay Foolish. 求知若饥，虚心若愚。