分布式系统和微服务简介

怼烎@ 2022-12-26 13:26 235阅读 0赞

分布式系统和微服务架构越来越流行，在项目开发中使用也有一段时间了，也特意卖了一本《SpringCloud微服务与分布式系统实战》来给自己充实下，简单记录 SpringCloud学习过程。

# 一、分布式系统简介 #

大数据、高并发和快响应已经成为互联网系统的必然要求。  
在之前的单机系统中，大量的数据会导致查找数据的响应时间边长。高并发会使系统因为繁忙而变慢，从而影响响应速度，单机故障也会是系统崩溃。  
为了解决单机系统带来的问题，互联网系统就从单机系统演变位多台机器的系统。

## 1. 简介 ##

分布式系统有一组为了完成共同任务二协调工作的计算机节点组成，它们通过网络进行通讯。  
分布式系统能满足互联网对大数据存储、高并发和快响应的要求，采用了`分而治之`的思想。

**好处：**

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

## 2. 分布式的切分方法 ##

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

*  水平切分  
    水平切分是指将同一个系统部署到多台机器上。
 *  垂直切分  
    垂直切分是按照业务的维度进行拆分，将各个业务独立出来，单独开发和维护。
 *  混合切分  
    混合切分是将水平切分和垂直切分结合起来的一种切分方法。微服务架构中大部分都是采用这种。

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

对系统进行拆分之后会带来很多问题，有兴趣可以去了解下`分布式计算的八大谬论` – 参考文章：[分布式计算中的八大谬论][Link 1]

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 网络是均匀的（同质的）

总结为一句话就是：`如何保证多个节点之间保持一致性，服务于企业实际业务。`  
**所以，分布式系统的核心问题就在于：**

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

## 4. 分布式系统的设计原则 ##

最著名和最具影响力的是 CAP原则和 BASE理论。  
**1、CAP原则**  
分布式系统中主要的特点是一致性、可用性和分区容忍。

*  **一致性（consistency）**：保证所有节点在同一个时刻具有相同的、逻辑一致的数据。
 *  **可用性（availability）**：保证每个请求不管成功还是失败都有响应。
 *  **分区容忍（partition tolerance**）：系统中任何的信息丢失或者失败都不会影响系统的继续运作。  
    Eric Brewer教授针对这 3个特点在2000年提出了 CAP原则，也称为 CAP定理。

> CAP原则指出：任何分布式系统都不能同时满足这 3个特点。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNDAyODU0_size_16_color_FFFFFF_t_70]

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

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

微服务主要追求可用性和分区容忍性（AP），轻一致性（C）。在 CAP原则中的一致性是指强一致性。

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

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

> Base理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。  
> BASE理论的核心思想是：即分布式系统即使无法做到强一致性，也可以采用适当的方法来达到最终的一致性。即放弃强一致性，来保证系统的可用性，从而达到最终一致性。

BASE是几个英文单词的简写：

*  **BA(Basically Available，基本可用)**：指分布式系统在出现故障的时候，保证系统有响应返回，实现基本可用，允许损失部分可用性，即保证核心可用。比如：在高并发的场景下可以采用服务降级，提示“系统繁忙，待会再来”。
 *  **S(Soft Status，软状态)**：指允许系统存在中间状态。而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。
 *  **E(Eventual Consistency，最终一致性)**：是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，以保证数据的正确性。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

# 二、微服务架构 #

最受欢迎的分布式架构就是微服务架构了。  
**1、简介**  
微服务架构是将一个单体系统拆分为多个相对独立的服务，每一个服务拥有独立的进程和数据，每一个服务都是以轻量级的通信机制来进行交互的（比如：HTTP）。  
一般服务都是根据业务模块来进行的，可以是独立的产品。

**2、 微服务的风格**  
微服务没有明确的概念和定义，但是微服务存在一定的风格，只要系统架构满足一定的风格，就可以被称为微服务架构。  
Eric Brewer教授提出了微服务的九个风格。有兴趣自行了解。  
开发中，一般我们遵守REST原则的web服务，即`RESTful`。

**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将会作为新的熔断器。

**参考文章：**

*  [CAP 定理的含义][CAP]

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

[Link 1]: https://blog.csdn.net/peterwanghao/article/details/81293461
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNDAyODU0_size_16_color_FFFFFF_t_70]: /images/20221120/bcd072a2b1984a3989d2f2cb2fa2d95d.png
[CAP]: http://www.ruanyifeng.com/blog/2018/07/cap.html