分布式与微服务 —— 初始

前言

        距今微服务的提出已经过去快十个春秋，网络上的博文讲微服务也是一抓一大把，但是荔枝仍然觉得还是有必要自己梳理一下整个知识体系。在这篇文章中，荔枝将会以一个初学者的角度来切入，从分布式系统和微服务架构引入，简单梳理微服务的架构体系和组件方案，为后续的学习确定方向，希望能够帮助到有需要的小伙伴~~~

文章目录

前言

一、分布式与微服务

1.1 分布式架构演进 

1.2 分布式架构下的原则

1.2.1 强一致性的ACID 

1.2.2 弱一致性：Base理论

1.2.3 一致性原理 

1.3 分布式事务

1.4 微服务架构 

二、微服务的基本架构以及组件构成

2.1 架构组件

2.2 特点

2.3 服务的注册中心、服务网关、API网关三者区别

2.4 微服务解决了什么问题？

2.5 微服务又存在着什么问题呢？

总结

一、分布式与微服务

1.1 分布式架构演进 

        分布式是一组通过网络进行通信，并且为了完成共同计算任务的计算机节点组成的系统。分布式的设计理念起因是由于在小型机或大型机中计算瓶颈的成本增加，在单一系统或者集合系统里面单纯地增加硬件地CPU和内存，但这很明显会带来更多地成本增加，在计算需求越发庞大的前提下，集群的架构已经不能满足了，这就产生了分布式计算和分布式存储。也就是说把一个计算任务分配给多个计算机节点进行计算，把用户的数据分片到不同的计算机节点中存储，但是这种计算方式对于用户是不可见的。

分布式的特点

• 分布性：服务部署空间具有多样性
• 并发性：程序运行过程中，并发性操作是很常见的。比如同一个分布式系统中的多个节点，同时访问一个共享资源。数据库、分布式存储
• 无序性：进程之间的消息通信，会出现顺序不一致问题

面临的问题

• 通信异常：分布式系统需要在各个节点之间进行网络通信，因此网络通信都会伴随着网络不可用的风险或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外，即使分布式系统各节点之间的网络通信能够正常进行，其延时也会远大于单机操作，会影响消息的收发的过程，因此消息丢失和消息延迟变得非常普遍。

• 网络分区：当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通信，而另一些节点则不能——我们将这个现象称为网络分区，就是俗称的“脑裂”。当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式才能完成的功能，这就对分布式一致性提出类非常大的挑战。

• 三态：分布式系统的每一次请求与响应，存在特有的“三态”概念，即成功、失败与超时。当出现超时现象时，网络通信的发起方是无法确定当前请求是否被成功处理的。

• 节点故障：节点故障则是分布式环境下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象。

分布式缺点

• 系统之间的调用关系变得复杂。
• 系统之间的依赖关系变得复杂。
• 系统维护成本高。

        由于分布式架构部署的服务越来越多时，重复的代码就会变得越来越多，不利于代码的复用和系统维护，原有的软件架构也需要不断进行调整，在原来的单体应用拆分前提下，不同的服务之间通过远程通信协议去实现计算结果的数据交互，最后对计算结果进行汇总返回给客户端，同时还需要增加一个统一的调度中心对集群进行实时管理，这就是SOA面向服务架构。但是SOA架构在面对更加庞大的项目时会显得力不从心， 它通过注册中心解决了各个服务之间服务依赖和调用关系的自动注册与发现，但却带来了一个系统中的服务间依赖耦合度高，单点故障容易带来系统崩溃的问题，所以软件架构还是需要继续演进，这就出现了微服务的架构，微服务是对SOA架构的更细粒度的拆分。

这里可以看一篇比较好的博文：

https://blog.csdn.net/hzbooks/article/details/120916132

分布式架构的经典场景：https://mikechen.cc/15795.html

服务网格的兴起 

        服务网格（Service Mesh）是新一代的微服务架构，它的提出主要是为了解决SpringCloud生态繁杂的组件使用版本兼容性所带来的微服务过于绑定特定技术栈、代码侵入过高、老旧项目难以维护兼容的问题。简单来说，服务网格是一组用来处理服务间通讯的网络代理，是为了解决微服务的侵入性问题。

核心内容：

• 控制平面： 控制和管理数据平面中的 Sidecar 代理，完成配置分发、服务发现、流量路由、授权鉴权等功能，以达到对数据平面的统一管理。
• 数据平面： 由整个网格内的 Sidecar 代理组成，这些代理以 Sidecar 的形式和应用服务一起部署。这些代理负责协调和控制应用服务之间的所有网络通信。每一个 Sidecar 会接管进入和离开服务的流量，并配合控制平面完成流量控制等方面的功能。

1.2 分布式架构下的原则

在系统学习微服务架构之前，我们需要对分布式架构有一个更为深入的了解，其中分布式设计的原则以及CAP理论无疑是重点考察的东西！

1.2.1 强一致性的ACID 

FLP原理

        在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性共识算法。该原理描述了在异步消息传递系统中的一致性问题。也就是说，在异步环境中当节点间的网络延迟没有上限时，如果发生节点故障，系统无法避免出现两种情况中的至少一种：一是无法保证节点之间的消息传递是可靠的，即有些消息可能会被丢失；二是无法保证系统能够对外提供一致性的服务。

        这个定理的重要性在于它揭示了分布式系统中一致性的内在困难：在分布式系统中，节点之间的通信延迟可能是不确定的，而这种不确定性可能导致无法在设计分布式系统时保证一致性。

DLS理论

        DLS理论指的是分布式锁服务（Distributed Lock Service）理论。它是一种保证在分布式系统中对共享资源进行互斥访问的服务。DLS理论主要关注如何在分布式环境中实现锁的管理和同步，以确保不同节点对共享资源的访问不会发生冲突。DLS理论提供了一种机制来协调和管理分布式系统中的并发访问。需要注意的是，DLS理论仅仅是一种理论框架，实际实现分布式锁服务需要考虑更多的细节和复杂性，例如锁的超时处理、锁的粒度控制、锁服务的容错性等。

CAP理论

        CAP理论指的是分布式系统提出的三个指标：一致性Consistency、可用性Availability、分区容错性Partition-tolerance。一般来说，一个分布式系统一定会充分考虑到分区容错的机制，避免某一服务器因为宕机带来损失。这里的分区指的是网络分区，产生网络分区的原因是由于系统部分节点出现故障导致。

需要注意的是：考虑到分布式系统的分区容错性一定成立，因此分布式系统架构是一个2选1的问题，也就是AP和CP之间的权衡。但是如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C和A能够同时保证。

接着荔枝找到了这篇文章，跟着来仰慕一下吧~~~

 神一样的CAP理论被应用在何方 - 掘金 (juejin.cn)

文章提出了四个问题来描述CAP架构的选择：

• 注册中心，是选择CA还是CP ? --- 主要是对比了Zookeeper(CP)和SpringCloud的Eureka(AP)
• 分布式锁，是选择CA还是CP ? --- 对比了数据库、redis和zookeeper实现分布式锁的情况讨论
• 分布式事务，是怎么从ACID到CAP/BASE ? --- 分布式事务在可用性和一致性之间的妥协
• 从MQ高可用的例子，如何选择CA还是CP

Guide修正了一下有关文章中zookeeper保证数据一致性描述：

        ZooKeeper 通过可线性化（Linearizable）写入、全局 FIFO 顺序访问等机制来保障数据一致性。多节点部署的情况下， ZooKeeper 集群处于 Quorum 模式。Quorum 模式下的 ZooKeeper 集群， 是一组 ZooKeeper 服务器节点组成的集合，其中大多数节点必须同意任何变更才能被视为有效。

        由于 Quorum 模式下的读请求不会触发各个 ZooKeeper 节点之间的数据同步，因此在某些情况下还是可能会存在读取到旧数据的情况，导致不同的客户端视图上看到的结果不同，这可能是由于网络延迟、丢包、重传等原因造成的。ZooKeeper 为了解决这个问题，提供了 Watcher 机制和版本号机制来帮助客户端检测数据的变化和版本号的变更，以保证数据的一致性。

        redis集群或者哨兵本身的设计就是AP架构的，官方推荐我们使用红锁Redlock的方式来保证数据的可用性，但红锁的坑有点多，并且在实际使用的时候至少需要三个redis实例来组成集群，因此业界使用的比较少。对此根据业务场景，如果要求数据的强一致性的话，可能通过redis来实现分布式锁这种方式相对来说不是很可靠。但是redis依旧可以为我们提供更高性能的AP模型，相对来说使用zookeeper来实现分布式锁提供了一种比较可靠的CP模型分布式锁实现方式。

1.2.2 弱一致性：Base理论

        在分步式场景下，我们不可能如同前面CAP中所说只追求CP或者只追求AP，而且在多数情况下，其实我们也并非一定要求强一致性，为了兼顾两者我们在追求一致性上做出妥协，牺牲强一致性获得可用性，发展出来了最终一致性理论 BASE。BASE 是指基本可用（Basically Available）、柔性状态（ Soft State）、最终一致性（ Eventual Consistency）。BASE理论是对CAP的延伸和补充，但Base中的一致性区别于CAP中的C指的是状态的一致性。

• 基本可用（Basically Available）：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。
• 柔性状态（Soft state）：指允许系统存在中间状态，并认为该中间状态不会影响系统整体可用性。比如，允许不同节点间副本同步的延时就是柔性状态的体现。
• 最终一致性（Eventually consistent）：指系统中的所有副本经过一定时间后，最终能够达到一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

1.2.3 一致性原理 

• 弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。但经过“不一致时间窗口”这段时间后，后续对该数据的读取都是更新后的值。
• 强一致性：系统中的某个数据被成功更新后，后续任何对该数据的读取操作都将得到更新后的值。
• 最终一致性：是弱一致性的特殊形式，存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值。它是很多分布式系统的一致性选择，因为它保证了在没有新的数据更新的情况下，经过一段时间后，所有的数据访问都将是最后的更新值。

1.3 分布式事务

        分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，且属于不同的应用的事务。分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证位于不同服务节点中数据库的数据一致性。

分布式事务的几种解决方案

• 两阶段提交（2PC）
• 补偿事务（TCC）
• 本地消息表 --- 将分布式事务拆分成本地事务处理，利用数据库的本地事务一致性
• MQ事务消息 --- 将本地消息表封装起来并放入MQ中，对事务进行了异步解耦

1.4 微服务架构 

        微服务架构本身就是一种分布式架构，只是微服务架构更为强调的是对于部署在各个计算机节点上的应用服务的粒度的控制，可以理解为对于前面的SOA中拆分的服务节点做出更进一步的粒度的解耦，每个拆分出来的更小的粒度的服务就是微服务。这样拆分的好处就是使得程序的扩展性更强，开发的迭代效率也会更高。在微服务架构下，一个大的项目拆分为一个个小的可独立部署的微服务，每个微服务都有自己的数据库。

二、微服务的基本架构以及组件构成

        前面简单提及微服务，微服务其实就是一种新的软件架构(虽然现在已经遍地开花了)，是现在主流的软件架构。要想弄清楚微服务是什么，就要弄懂它的架构组成、特点和技术栈、解决了什么问题，又存在着什么问题。

2.1 架构组件

微服务的核心要素在于：服务注册与发现、路由、熔断、降级、分布式配置。

        以Spring Cloud为例的微服务的架构组件如上图，其中服务的注册与发现相当于是一个目录的功能，不同的服务都需要把自己的地址和接口注册到服务注册中心上，方便服务调用方调用。服务提供方一般以多实例的形式提供服务，因此我们需要使用负载均衡让服务调用方连接到合适的服务节点。API网关中可以实现用户鉴权、动态路由、灰度发布、负载限流等功能，统一配置管理会将本地化的配置信息，比如：properties、yml等配置信息，注册到配置中心，实现程序包在开发、测试、生产环境的无差别性方便程序迁移。

Spring Cloud Alibaba微服务架构 

2.2 特点

• 服务拆分：应用程序被拆分为多个小型服务，每个服务负责一个明确的业务功能。
• 独立部署：每个服务都可以独立进行部署和升级，不会影响其他服务的正常运行。
• 分布式通信：服务之间通过轻量级的通信机制进行交互，如RESTful API、消息队列等。
• 自治性：每个服务都是自治的，可以使用不同的技术栈和数据库，独立进行开发和维护。
• 垂直扩展：可以根据需要独立地扩展特定的服务，而不必扩展整个应用程序。

2.3 服务的注册中心、服务网关、API网关三者区别

我们首先需要明确一个概念：微服务之间的交互需要去中心化，即服务之间需要从注册中心拿到其它的服务的接口，才能发起请求。

服务网关：我们需要微服务接口暴露给前端应用，所以我们需要做一个服务网关承接微服务地址和前端APP或者BS，否则其实一个服务注册发现中心就可以了

API网关：如果存在跨应用的协同，我们需要做的是不同的应用之间的微服务提供的API接口注册到更上层的API网关中，这是一种更为细粒度的控制，因为这就可以避免服务A把所有的API暴露给另外一个应用，而把对于应用和应用之间的边界调控在一个更为细粒度的层面上——微服务提供的API接口能力。现在大多数的微服务架构都需要使用到API网关！

RPC框架

有关RPC的内容大家可以看看荔枝的这篇博文：

微服务：何为RPC框架-CSDN博客

2.4 微服务解决了什么问题？

• 解决了单体应用和SOA架构下的服务间耦合度高的问题；
• 灵活度高、扩展性好、适合云环境、开发功能周期急剧减少；

2.5 微服务又存在着什么问题呢？

• 分布式系统保障业务功能的复杂度高；
• 部署 、测试和调控的成本更高；
• 分布式事务以及在分步式系统的有关AP、CP和最终一致性的问题。

总结

        微服务的知识体系还是让人叹为观止的，Spring Cloud恐怖的组件生态估计可以让荔枝学好几年哈哈哈哈，但真正的深入原理的学习依旧会在不远的将来。对于技术选择来说，最好的往往是最合适的，现实的业务场景往往决定着我们选择的软件架构，希望未来某一天当荔枝的知识储备达到一定程度的时候可以肆意“指点江山”吧~~~

今朝已然成为过去，明日依然向往未来！我是荔枝，在技术成长之路上与您相伴~~~

如果博文对您有帮助的话，可以给荔枝一键三连嘿，您的支持和鼓励是荔枝最大的动力！

如果博文内容有误，也欢迎各位大佬在下方评论区批评指正！！！