从RPC 到微服务

从 RPC 到微服务的演化经过了RPC->Message Queue->SOA->微服务。

早期的 RPC

早期实现夸物理机的远程访问另一个进程唯一的方式就是RPC（Remote Procedure Call）远程过程调用（Socket 属于私有协议数据通信），期初各种语言各自为政，RPC是不能夸平台通信的。

由于不仅需要夸物理机，还要实现夸操作系统，跨语言等等，在这种背景下COBRA诞生，COBRA 解决了不同平台间的通信问题，红极一时。

早期的RPC协议都是二进制协议，主要是限于当时网速和带宽。随着网速的提高，由于文本协议更容易开发和调试，文本协议成为主流。

例如：SOAP，XML-RPC

序列化是伟大的发明

早期的通信协议使用结构体或者特定字符分隔的文本，到后来XML协议。这些协议都没有很好的解决，易开发，易调试，夸语言等问题。

1. 结构体在C/C++ 中广泛使用，其他语言想要很C程序通信就涉及到 pack/unpack 封包和拆包操作，二进制协议不能直接阅读，给开发调试带来不方便。如果遇到协议频繁升级，开发者和测试者是很痛苦的。
2. 特定字符分隔的文本，可以使用二进制分隔，也可以使用逗号，竖线等。你需要自己分析这些字符，还要避开数据中包含这些字符。
3. XML 协议优点很多，但有一个致命缺点，就是性能。一是体积庞大，臃肿。二是，分析，取出数据的性能非常慢。
4. 序列化，这是个伟大的发明，不仅实现了跨语言序列化与反序列化，还实现了二进制序列化与反序列化。序列化还提供非常丰富的数据类型，包含了字符串，数组，对象与数据结构等等。

无状态协议是趋势

通过TCP协议，SOCKET建立连接后提供持久连接的场景需求越来越少。

基于HTTP 无状态协议的 RPC 通信成为主流。

SOA（Service Oriented Ambiguity）面向服务架构

SOA 是一个概念，是一种以业务为中心的 IT 架构方法，可以将您的业务作为彼此链接的、可重复的业务任务或服务来进行整合，SOA使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

消息队列的出现

消息队列解决了 RPC 的被动调用问题，通过发布与订阅，实现消息异步处理。

消息队列逐渐成为面向服务开发的一部分。

传统SOA如果有十个节点，那么每个节点都需要相互连接另外九个节点，这给部署，监控，故障排查代理很多问题，消息队列的出现解决了这个问题，使网络模型从网状模型转到星型模型，所有的节点从消息服务器订阅，数据流也是推送到消息服务器。

有了上面的RPC，消息队列，SOA，为什么还需要微服务？

SOA 所有业务逻辑运行在一个物理机上，它们共用CPU以及内存地址空间，运行在一个进程中。通过负载均衡设备分配物理机给终端用户。当然也能做到不同业务逻辑被负载到不同的物理机的不同进程，这需要开发和运维通力配合完成。

而微服务，是将业务逻辑分散到不同的物理机，不同的进程下，它们使用相同的物理机，CPU，内存地址空间。微服务的注册中心是一个应用交付控制器，颗粒度比七层负载均衡更先进，更复杂，它能提供，服务注册，路由分配，熔断等等，配合配置中心，完成更复杂的工作。但性能肯定不如3/4层和7层负载均衡设备。

前者可以理解为IP地址和端口或者URL和HTTP的负载均衡，后者是基于 Class 和 method 的负载均衡。

微服务强调，组件化与服务化，分散治理，分散数据管理，容错性，自动化......