微服务架构整理-(二、远程调用技术与CAP原理)

远程调用技术

服务调用者与服务提供者之前通过远程调用技术进行交互,如图所示:
在这里插入图片描述
目前常用的远程调用技术主要有两种:RPC和Restful。

RPC

RPC(Remote Procedure Call)一种进程间通信方式,允许像调用本地服务那样调用远程服务,其主要目标就是让远程调用更简单、透明,负责屏蔽底层的传输方式(TCP/UDP)、序列化方式和通信细节。开发人员只需要知道服务在哪里,提供了哪些接口,整个调用过程不用关心。如下图所示
在这里插入图片描述
整个调用与返回过程如图绿色和蓝色实线所示,但开发者见到的是绿色虚线和蓝色虚线。

Restful

在服务调用之间使用的是种基于HTTP实现的RestFul技术,通过在服务提供者中暴露一个可以请求的地址来实现。关于Restful技术可以参考其教程

RPC 与Restful比较

比较项RestfulRPC
通讯协议Http一般使用TCP
性能略低较高
灵活度
应用微服务架构SOA架构

Restful 基于Http,而Http 相对更规范、更标准、更通用,无论哪种语言都支持http协议,现在的开放平台,外部的编程语言多种多样,无法拒绝对每种语言的支持,所以最先支持的肯定是Restful。
RPC作为架构微服务化的基础组件,它能大大降低架构 微服务化的成本,提高调用方与服务提供方的研发效率,屏蔽跨进程调用函数的各类复杂细节,让调用方感觉就像调用本地函数一样调用远端函数。

CAP原理

分布式系统最大的难点就是各个节点的状如何同步,在开发一个分布式系统时都通过CAP三个方向来设计此系统。

C:Consistency

即一致性,对于任何从客户端发送到分布式系统的数据读取请求,要么读到最新的数据要么失败。换句话说,一致性是站在分布式系统的角度,对访问本系统的客户端的一种承诺:要么我给您返回一个错误,要么我给你返回绝对一致的最新数据,不难看出,其强调的是数据正确。这需要确保分布式系统能实时同步各节点之间的数据。

A:Availability

即可用性,对于任何求从客户端发送到分布式系统的数据读取请求,都一定会收到数据,不会收到错误数据,但不保证客户端收到的数据一定是最新的数据。换句话说,可用性是站在分布式系统的角度,对访问本系统的客户的另一种承诺:我一定会给您返回数据,不会给你返回错误数据,但不保证数据最新,强调的是不出错

P: Partition Tolerance

即分区容忍性,这里的分区是指网络意义上的分区。由于网络是不可靠的,所有节点之间很可能出现无法通讯的情况,在节点不能通信时,要保证系统可以继续正常服务,强调的是不挂掉。分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择

一个数据分布式系统不可能同时满足C和A和P这3个条件。所以系统架构师在设计系统时,不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。由于网络的不可靠性质,大多数开源的分布式系统都会实现P,也就是分区容忍性,之后在C和A中做抉择。

CAP原理简单证明

当前有如下设计:
在这里插入图片描述
刚开始结点A中 a=1,假如收到一个变更请求,结果A中的a=2。接下来A应该将数据同步到B中,使B中a=2,即实现数据一致性。
3个场景分别证明:

满足C和P

在数据同步时,即将B中的a置为2时,由于网络的问题,使得A和B之间的通信出现了延迟,但此时B收到了一个读取a的请求,但此时a还不是最新的,因此只有等,一直到a更新完,这就导致了客户端一直拿不到返回结果,即系统的可用性比较差,即违反了A。
所以,在保证C和P的情况下,是无法同时保证A的。

满足A和P

为了保证客户端能及时响应,即高可用性,所有请求必须在有限时间内返回。同样在数据同步时,需要将B中的a置为2时,由于网络的问题,使得A和B之间的通信出现了延迟,但此时B收到了一个读取a的请求,但为了在有限时间内必须给出响应,所以只能将旧数据返回给客户端,即违反了C。
所以,在保证C和P的情况下,是无法同时保证C的。

满足A和C

如果要保证高可用和一致性,只有在网络情况良好且可靠的情况下才能实现。这样A才能立即将更新消息发送给B。但是网络情况不能保证,出现延迟,阻塞,丢包等现象。所以要满足A和C,只有将结点A和结点B放到一个区内才可以(可以理解为将数据副本存放在同一个服务器上),也就丧失了P这个保证,这样的话已经不算是分布式系统了。
所以,在保证C和A的情况下,是无法同时保证P的。

架构的两个核心概念介绍完了,希望能给大家一定的帮助,不足之出欢迎留言指出

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

浦江之猿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值