微服务架构设计模式与CAP定理

﹏ヽ暗。殇╰゛Y 2022-12-09 15:52 174阅读 0赞

# 微服务架构设计模式与CAP定理 #

### 前言 ###

hello 大家好,我是一名Java后端开发的程序猿。由于国庆假期已经来了,所以我打算把这一星期的时间用来好好提升下自己的技术水平。微服务呢,在大学期间最后一年也学过,但是工作后却用的比较少。为了防止以后公司业务需要用到微服务的时候,我不至于一脸懵然后还要临时学,所以这个国庆打算对微服务进行一个总结。计划是花五天时间。首先我要声明一下,自己是个菜鸟,如果总结的不好或者很糟糕欢迎指出我们大家一起学习。嘿嘿~

### 微服务有什么用? ###

在早期的互联网开发中,包括现在也有很多的项目都是单体的应用程序。一般这个单体的应用程序是由客户端用户界面,模块和数据库三个部分组成。一般模块会有很多个,最后打成一个包部署在服务器上。在项目的早期阶段,这样的方式会比较容易开发,部署也方便。可是到了后期麻烦可就大了,因为随着用户需求的增加项目功能也会跟着扩展。之前的小应用会变得越来越复杂。一旦出现了Bug就会牵一发而动全身,所以说在单体应用中每个服务的更新和改变都会导致重新部署整个应用,灵活性太低...而分布式就是解决这个问题的。

微服务顾名思义其实就是把一个庞大的应用程序拆分成一套小而互联的服务。

### SOA架构 ###

SOA架构它是面向服务的,在单体架构的基础上按照业务功能进一步进行垂直拆分。每一个服务都包含了自己的业务逻辑和多个适配器。把模块拆分再用接口互相通信。就像我们搞开发前后端分离一样,后端使用Responsebody发Json给前端,前端根据后端的接口得到数据。这样在开发的时候,谁都不用等谁先做,各顾其职就好了。SOA架构通常以独立的形式存在于操作系统的进程中,每个服务之间通过网络通信。而微服务的话呢,它其实就是对SOA的拆分进行再拆分。微服务架构比SOA架构拆分的更加彻底。

## 微服务架构常见的设计模式 ##

### 聚合器微服务设计模式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNDI0Njg4_size_16_color_FFFFFF_t_70_pic_center]

这个设计模式通过负载均衡使用聚合器调动多个服务,其中每个服务都有自己的缓存服务器和数据库。所有服务的接口都会暴露出来,最后由聚合器把所有检索到的数据进行处理和展示,也可以把数据增加业务逻辑形成新的微服务。这是一种最常见也最简单的设计模式。

### 代理微服务设计模式 ###

这个设计模式和刚刚的图基本上一样我就懒得再画,聚合器换成代理。这个模式主要是由刚才的聚合器模式演变而来的。这种模式在客户端不会聚合数据,而是根据业务需求的差别来调动不同的微服务。代理可以委派请求,也可以进行数据转换工作。每个微服务都是自己独立的缓存和数据库系统。

### 链式微服务设计模式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNDI0Njg4_size_16_color_FFFFFF_t_70_pic_center 1]

当服务A接收到消息就会去和B通信,然后B又去和C进行通信。因为是链式的,所以服务之间的消息同步传递,在客户端发出请求之后没收到响应的这段时间之内一直都是阻塞的,直到整个链条全部走完响应给客户端。所以说我们在链式服务设计模式的时候就不要让它的服务链太长,不然客户端就会长时间等待。

### 分支微服务设计模式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNDI0Njg4_size_16_color_FFFFFF_t_70_pic_center 2]

这个设计模式比较像是聚合微服务设计模式还有链式微服务设计模式的结合体。我们可以同时调用两个服务链,客户端发送请求调用服务A的时候,而A就需要调用服务B的同时又要去调用服务C，而服务C又需要去调用服务D。所以就形成了分支微服务模式。

### 异步消息传递微服务设计模式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNDI0Njg4_size_16_color_FFFFFF_t_70_pic_center 3]

在这里呢,服务A请求服务C的时候,服务C又要去请求服务B。这个时候如果同步就会导致阻塞,所以部分微服务架构就会去采用消息队列来请求响应。在这里呢,C就是一个生产者,然后B是消费者。消息队列就是持久化服务C生产的消息,队列会帮助缓存消息一直到消费服务开始工作

## CAP定理 ##

CAP定理其实它就是指在一个分布式的系统中,Consistency(一致性),Availability(可用性)和Partition Tolerance(分区容错性)这三者在实际开发中不能同时兼顾。

##### Consistency(一致性) #####

这个其实就是说用户更新完数据之后操作成功返回客户端,然后所有的节点在同一时间内数据会保持一致,这就是分布式的一致性。

##### Availability(可用性) #####

这个可用性就是服务一直处于可用的状态,一旦接收用户的请求,服务器就必须给出回应,而且是正常响应时间。保持可用性主要还是为了给客户更好的体验,不会出现什么操作失败,访问链接半天访问不到,访问超时等情况。

##### Partition Tolerance(分区容错性) #####

其实分区容错性呢就是指单台服务器或者多台服务器出现问题后,其他正常的服务器依然可以正常提供服务。在分布式系统中如果遇到某些结点或者网络分区故障的时候,仍然可以继续对外提供满足一致性和可用性的服务。大多数分布式系统中都会存在多个子网络,然后每个子网络都可以称为一个区。

### 取舍策略 ###

因为在分布式系统中CPA三个特性只能同时满足其中两个特性所以取舍策略就会有三种那就是:CA,CP,AP。

假如我选择了CA策略,那么就是希望能够使系统同时满足一致性和可用性,但是也放弃了分区容错性。这样一来就不能够再部署子节点,放弃了系统的可扩展性很明显违背了分布式系统的初衷。

那么,我选择CP呢?那么就是希望系统可以同时满足一致性和分区容错性。所有的更新操作都要等同步完成后才能响应返回结果。一旦发生网络故障或者其他事件的时候牺牲可用性影响客户的体验。

最后就是AP策略了,这个策略就是希望系统满足分区容错性和可用性。但是每个节点的数据只能为本地应用提供服务,导致全局不一致性。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNDI0Njg4_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/cf90cc27351f4f5a85b4c499d8b7b9d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNDI0Njg4_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/24bd5bab4a5543a2afb9350ea00e6c8c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNDI0Njg4_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/716a8d5e02dd499ca71d5d411a449548.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNDI0Njg4_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/f03658412e2140e5b42717b4f1085acf.png