距今微服务的提出已经过去快十个春秋,网络上的博文讲微服务也是一抓一大把,但是荔枝仍然觉得还是有必要自己梳理一下整个知识体系。在这篇文章中,荔枝将会以一个初学者的角度来切入,从分布式系统和微服务架构引入,简单梳理微服务的架构体系和组件方案,为后续的学习确定方向,希望能够帮助到有需要的小伙伴~~~
前言
一、分布式与微服务
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 微服务又存在着什么问题呢?
总结
分布式是一组通过网络进行通信,并且为了完成共同计算任务的计算机节点组成的系统。分布式的设计理念起因是由于在小型机或大型机中计算瓶颈的成本增加,在单一系统或者集合系统里面单纯地增加硬件地CPU和内存,但这很明显会带来更多地成本增加,在计算需求越发庞大的前提下,集群的架构已经不能满足了,这就产生了分布式计算和分布式存储。也就是说把一个计算任务分配给多个计算机节点进行计算,把用户的数据分片到不同的计算机节点中存储,但是这种计算方式对于用户是不可见的。
分布式的特点
面临的问题
通信异常:分布式系统需要在各个节点之间进行网络通信,因此网络通信都会伴随着网络不可用的风险或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外,即使分布式系统各节点之间的网络通信能够正常进行,其延时也会远大于单机操作,会影响消息的收发的过程,因此消息丢失和消息延迟变得非常普遍。
网络分区:当网络由于发生异常情况,导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够进行正常通信,而另一些节点则不能——我们将这个现象称为网络分区,就是俗称的“脑裂”。当网络分区出现时,分布式系统会出现局部小集群,在极端情况下,这些局部小集群会独立完成原本需要整个分布式才能完成的功能,这就对分布式一致性提出类非常大的挑战。
三态:分布式系统的每一次请求与响应,存在特有的“三态”概念,即成功、失败与超时。当出现超时现象时,网络通信的发起方是无法确定当前请求是否被成功处理的。
节点故障:节点故障则是分布式环境下另一个比较常见的问题,指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象。
分布式缺点
由于分布式架构部署的服务越来越多时,重复的代码就会变得越来越多,不利于代码的复用和系统维护,原有的软件架构也需要不断进行调整,在原来的单体应用拆分前提下,不同的服务之间通过远程通信协议去实现计算结果的数据交互,最后对计算结果进行汇总返回给客户端,同时还需要增加一个统一的调度中心对集群进行实时管理,这就是SOA面向服务架构。但是SOA架构在面对更加庞大的项目时会显得力不从心, 它通过注册中心解决了各个服务之间服务依赖和调用关系的自动注册与发现,但却带来了一个系统中的服务间依赖耦合度高,单点故障容易带来系统崩溃的问题,所以软件架构还是需要继续演进,这就出现了微服务的架构,微服务是对SOA架构的更细粒度的拆分。
这里可以看一篇比较好的博文:
https://blog.csdn.net/hzbooks/article/details/120916132
分布式架构的经典场景:https://mikechen.cc/15795.html
服务网格的兴起
服务网格(Service Mesh)是新一代的微服务架构,它的提出主要是为了解决SpringCloud生态繁杂的组件使用版本兼容性所带来的微服务过于绑定特定技术栈、代码侵入过高、老旧项目难以维护兼容的问题。简单来说,服务网格是一组用来处理服务间通讯的网络代理,是为了解决微服务的侵入性问题。
核心内容:
在系统学习微服务架构之前,我们需要对分布式架构有一个更为深入的了解,其中分布式设计的原则以及CAP理论无疑是重点考察的东西!
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架构的选择:
Guide修正了一下有关文章中zookeeper保证数据一致性描述:
ZooKeeper 通过可线性化(Linearizable)写入、全局 FIFO 顺序访问等机制来保障数据一致性。多节点部署的情况下, ZooKeeper 集群处于 Quorum 模式。Quorum 模式下的 ZooKeeper 集群, 是一组 ZooKeeper 服务器节点组成的集合,其中大多数节点必须同意任何变更才能被视为有效。
由于 Quorum 模式下的读请求不会触发各个 ZooKeeper 节点之间的数据同步,因此在某些情况下还是可能会存在读取到旧数据的情况,导致不同的客户端视图上看到的结果不同,这可能是由于网络延迟、丢包、重传等原因造成的。ZooKeeper 为了解决这个问题,提供了 Watcher 机制和版本号机制来帮助客户端检测数据的变化和版本号的变更,以保证数据的一致性。
redis集群或者哨兵本身的设计就是AP架构的,官方推荐我们使用红锁Redlock的方式来保证数据的可用性,但红锁的坑有点多,并且在实际使用的时候至少需要三个redis实例来组成集群,因此业界使用的比较少。对此根据业务场景,如果要求数据的强一致性的话,可能通过redis来实现分布式锁这种方式相对来说不是很可靠。但是redis依旧可以为我们提供更高性能的AP模型,相对来说使用zookeeper来实现分布式锁提供了一种比较可靠的CP模型分布式锁实现方式。
在分步式场景下,我们不可能如同前面CAP中所说只追求CP或者只追求AP,而且在多数情况下,其实我们也并非一定要求强一致性,为了兼顾两者我们在追求一致性上做出妥协,牺牲强一致性获得可用性,发展出来了最终一致性理论 BASE。BASE 是指基本可用(Basically Available)、柔性状态( Soft State)、最终一致性( Eventual Consistency)。BASE理论是对CAP的延伸和补充,但Base中的一致性区别于CAP中的C指的是状态的一致性。
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,且属于不同的应用的事务。分布式事务需要保证这些操作要么全部成功,要么全部失败。本质上来说,分布式事务就是为了保证位于不同服务节点中数据库的数据一致性。
分布式事务的几种解决方案
微服务架构本身就是一种分布式架构,只是微服务架构更为强调的是对于部署在各个计算机节点上的应用服务的粒度的控制,可以理解为对于前面的SOA中拆分的服务节点做出更进一步的粒度的解耦,每个拆分出来的更小的粒度的服务就是微服务。这样拆分的好处就是使得程序的扩展性更强,开发的迭代效率也会更高。在微服务架构下,一个大的项目拆分为一个个小的可独立部署的微服务,每个微服务都有自己的数据库。
前面简单提及微服务,微服务其实就是一种新的软件架构(虽然现在已经遍地开花了),是现在主流的软件架构。要想弄清楚微服务是什么,就要弄懂它的架构组成、特点和技术栈、解决了什么问题,又存在着什么问题。
微服务的核心要素在于:服务注册与发现、路由、熔断、降级、分布式配置。
以Spring Cloud为例的微服务的架构组件如上图,其中服务的注册与发现相当于是一个目录的功能,不同的服务都需要把自己的地址和接口注册到服务注册中心上,方便服务调用方调用。服务提供方一般以多实例的形式提供服务,因此我们需要使用负载均衡让服务调用方连接到合适的服务节点。API网关中可以实现用户鉴权、动态路由、灰度发布、负载限流等功能,统一配置管理会将本地化的配置信息,比如:properties、yml等配置信息,注册到配置中心,实现程序包在开发、测试、生产环境的无差别性方便程序迁移。
Spring Cloud Alibaba微服务架构
我们首先需要明确一个概念:微服务之间的交互需要去中心化,即服务之间需要从注册中心拿到其它的服务的接口,才能发起请求。
服务网关:我们需要微服务接口暴露给前端应用,所以我们需要做一个服务网关承接微服务地址和前端APP或者BS,否则其实一个服务注册发现中心就可以了
API网关:如果存在跨应用的协同,我们需要做的是不同的应用之间的微服务提供的API接口注册到更上层的API网关中,这是一种更为细粒度的控制,因为这就可以避免服务A把所有的API暴露给另外一个应用,而把对于应用和应用之间的边界调控在一个更为细粒度的层面上——微服务提供的API接口能力。现在大多数的微服务架构都需要使用到API网关!
RPC框架
有关RPC的内容大家可以看看荔枝的这篇博文:
微服务:何为RPC框架-CSDN博客
微服务的知识体系还是让人叹为观止的,Spring Cloud恐怖的组件生态估计可以让荔枝学好几年哈哈哈哈,但真正的深入原理的学习依旧会在不远的将来。对于技术选择来说,最好的往往是最合适的,现实的业务场景往往决定着我们选择的软件架构,希望未来某一天当荔枝的知识储备达到一定程度的时候可以肆意“指点江山”吧~~~
今朝已然成为过去,明日依然向往未来!我是荔枝,在技术成长之路上与您相伴~~~
如果博文对您有帮助的话,可以给荔枝一键三连嘿,您的支持和鼓励是荔枝最大的动力!
如果博文内容有误,也欢迎各位大佬在下方评论区批评指正!!!