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

远程调用技术

服务调用者与服务提供者之前通过远程调用技术进行交互，如图所示：

目前常用的远程调用技术主要有两种：RPC和Restful。

RPC

RPC（Remote Procedure Call）一种进程间通信方式，允许像调用本地服务那样调用远程服务，其主要目标就是让远程调用更简单、透明，负责屏蔽底层的传输方式（TCP/UDP）、序列化方式和通信细节。开发人员只需要知道服务在哪里，提供了哪些接口，整个调用过程不用关心。如下图所示

整个调用与返回过程如图绿色和蓝色实线所示，但开发者见到的是绿色虚线和蓝色虚线。

Restful

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

RPC 与Restful比较

比较项	Restful	RPC
通讯协议	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的。

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