上图摘自阿里实现的RPC项目，Dubbo ，该图展现了现在服务的架构演化。接下来我们将一一解释：
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
什么是RPC
在分布式计算，遠端程序呼叫（英語：Remote Procedure Call，縮寫為 RPC）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间（通常为一个开放网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额外地为这个交互作用编程（无需关注细节）。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。
---- 维基百科
通俗点说就是你老婆给你打电话让你给她带点吃的，你老婆只是拿起了电话（PRC）告诉你要买东西，而具体实现则由你去买，等你买完打电话（RPC）告诉你老婆。
无伦你有多爱C语言，你也要学一学C++，不为别的，就因为C++有对象。（ 逃
回归正题吗，我们了解了基本概念。下面讨论下为什么要用RPC和RPC的缺点。
为什么要用RPC？
- 将程序的功能服务化和解耦合
- 服务的调用者和提供者不在同一个机器里或一个（VM）里
- 由于采用自定义TCP/UDP格式，性能会提升
- 可扩展性和可维护性好
- 可以在微服务出现时进行服务降级
- 保证封装可用性
- 可以实现高可用
- 负载均衡
- 自动重试
RPC的问题
- 比起Http复杂很多
- 接口的包同步问题
- 跨平台，跨语言复杂
手写一个RPC
我写了一个简单的RPC 在我的Github ：simpleRPC
如果你想了解这个项目，可以尝试为它添加注释和提交 PR，虽然在这个项目中我分别用BIO，NIO 实现了一遍，但没有涉及服务注册，服务发现，自动重连等机制。如果你想深入了解RPC的设计理念或实现技术，可以关注Dubbo的官方文档。
另外如果大家对UNIX系统的5种I/O模型有兴趣，请关注我下次的文章。
