分布式/微服务理论知识
分布式系统和微服务架构越来越流行，特意卖了一本《SpringCloud微服务与分布式系统实战》来给自己充充电，也是掌握技术的必经之路。
一、分布式系统
大数据、高并发和快响应已经成为互联网系统的必然要求。
在之前的单机系统中，大量的数据会导致查找数据的响应时间边长。高并发会使系统因为繁忙而变慢，从而影响响应速度，单机故障也会是系统崩溃。
为了解决单机系统带来的问题，互联网系统就从单机系统演变位多台机器的系统。
1、分布式系统简介
分布式系统由一组为了完成共同任务而协调工作的计算机节点组成，它们通过网络进行通讯。
分布式系统在不同的硬件，不同的软件，不同的网络，不同的计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
分布式系统能满足互联网对大数据存储、高并发和快响应的要求，采用了分而治之的思想。
好处：
- 高性能：大量请求可以分摊到各个节点上，从而解决系统的大数据、高并发和快响应问题。
- 高可用：请求会避开存在故障的节点，使用其他节点，系统仍然可以继续工作。
- 可伸缩性：对于现有机器节点可以根据业务量灵活的进行增加或者减少。
- 可维护性：对出现故障的节点，进行处理之后可以重新上线。
- 灵活性：对于系统的更新迭代，可以在非高峰期，停止部分节点更新，然后交替去更新剩下的节点，从而更加灵活，不需要停止系统的工作。
2. 分布式的切分方法
在分布式系统中，会根据业务或者数据将系统合理切分给各个不同的节点的机器，从而让多个机器节点能够互相协作，完成业务的需求。
常见的切分方法如下：
- 水平切分：水平切分是指将同一个系统部署到多台机器上。
- 垂直切分：垂直切分是按照业务的维度进行拆分，将各个业务独立出来，单独开发和维护。
- 混合切分：混合切分是将水平切分和垂直切分结合起来的一种切分方法。
微服务架构中大部分都是采用混合切分方法。
3. 分布式系统面临的问题
对系统进行拆分之后会带来很多问题，有兴趣可以去了解下分布式计算的八大谬论。
- The network is reliable 网络是可靠的
- Latency is zero 网络是没有延迟的
- Bandwidth is infinite 带宽是无限的
- The network is secure 网络是安全的
- Topology doesn’t change 网络拓扑不会改变
- There is one administrator 肯定至少有一个（在值班的）管理员
- Transport cost is zero 传输开销为零
- 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、微服务的风格
微服务没有明确的概念和定义，但是微服务存在一定的风格，只要系统架构满足一定的风格，就可以被称为微服务架构。
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. 求知若饥，虚心若愚。