凤凰架构2——访问远程服务

访问远程服务

远程服务调用

进程间通信 （Inter-Process Communication，IPC） 的办法

• 管道（Pipe）或者具名管道（Named Pipe）： 传递少量的字符流或字节流， 普通管道只用于有亲缘关系进程（由一个进程启动的另外一个进程）间的通信，具名管道摆脱了普通管道没有名字的限制，除具有管道所有的功能外，它还允许无亲缘关系进程间的通信
• 信号（Signal）：通知目标进程有某种事件发生
• 信号量（Semaphore）: 两个进程之间同步协作手段
• 消息队列（Message Queue）:可以传送大量信息，但是实时性相对受限
• 共享内存（Shared Memory）：允许多个进程访问同一块公共的内存空间
• 套接字接口（Socket）： 可用于不同机器之间的进程通信

RPC的三个基本问题

• 如何表示数据：将交互双方所涉及的数据转换为某种事先约定好的中立数据流格式来进行传输，将数据流转换回不同语言中对应的数据类型来进行使用（比如序列化与反序列化）
• 如何传递数据：通过网络，在两个服务的 Endpoint 之间相互操作、交换数据（应用层协议）。
• 如何确定方法：不同语言如何表示同一方法

不同的RPC

没有一个RPC能完美满足上面三点，所以出现了不同的RPC

• 朝着面向对象发展：RMI，这条线有一个别名叫做分布式对象
• 朝着性能发展（序列化效率和信息密度）：gRPC （基于 HTTP/2 的，支持多路复用和 Header 压缩）和 Thrift（基于传输层的 TCP 协议来实现，省去了额外应用层协议的开销）
• 朝着简化发展，代表为 JSON-RPC（协议的简单轻便，接口与格式都更为通用）

REST 设计风格

RPC 面向过程调用，REST 面向资源调用

Fielding 认为，一套理想的、完全满足 REST 风格的系统应该满足以下六大原则：

1. 服务端与客户端分离（Client-Server）：将用户界面所关注的逻辑和数据存储所关注的逻辑分离开来，有助于提高用户界面的跨平台的可移植性
2. 无状态（Stateless）：客户端发送的请求中，应包括所有的必要的上下文信息，会话信息也由客户端负责保存维护，服务端依据客户端传递的状态来执行业务处理逻辑
3. 可缓存（Cacheability）：运作良好的缓存机制可以减少客户端、服务器之间的交互
4. 分层系统（Layered System）：客户端一般不需要知道是否直接连接到了最终的服务器
5. 统一接口（Uniform Interface）：
6. 按需代码（Code-On-Demand）：客户端无需事先知道所有来自服务端的信息应该如何处理、如何运行的宽容度

优点和不足

优点

1. 降低的服务接口的学习成本：对资源的标准操作都映射到了标准的 HTTP 方法上去
2. 资源天然具有集合与层次结构：以资源为中心抽象的接口，由于资源是名词，天然就可以产生集合与层次结构。GET /users/icyfenix/cart/2
3. REST 绑定于 HTTP 协议。

不足与争议

1. 面向资源的编程思想只适合做 CRUD，面向过程、面向对象编程才能处理真正复杂的业务逻辑：面向资源的编程思想与另外两种主流编程思想只是抽象问题时所处的立场不同，只有选择问题，没有高下之分
2. REST 与 HTTP 完全绑定，不适合应用于要求高性能传输的场景中：面向资源编程与协议无关，但是 REST的确依赖着 HTTP 协议的标准方法、状态码、协议头等各个方面，对于需要直接控制传输，如二进制细节、编码形式、报文格式、连接方式等细节的场景中，REST 确实不合适，这些场景往往存在于服务集群的内部节点之间
3. REST 不利于事务支持：如果放弃刚性事务，使用 REST 肯定不会有什么阻碍
4. REST 没有传输可靠性支持
5. REST 缺乏对资源进行“部分”和“批量”的处理能力