本文分享自华为云社区《云原生时代，远程服务调用和RESTful，如何分析和抉择？》，作者：breakDawn 。

随着云原生的概念越来越火，服务的架构应该如何发展和演进，成为很多程序员关心的话题。大名鼎鼎的《深入理解 java 虚拟机》一书作者于 21 年推出了新作《凤凰架构》，从这本书中可以看到当前时下很多最新的技术或者理念。

本博文将沉淀发布这本书的学习笔记和思考。 如果希望了解更加详细的内容，欢迎购买该书继续详细学习。

访问远程服务

1 远程服务调用

这一个章节主要讲解 rpc 的设计理念和发展历史。先是讲解了 IPC（进程间通信）所需要的各个必要因素接着解释 RPC 是 IPC 的一种特例（这是最初科学家们的想法）但 PRC 存在很多可靠性的问题，并不能直接等同 IPC 的扩展。

接着提出了 RPC 的三个基本问题：

• 如何表示数据

即序列化协议， 有 grpc 的 proto-buffer、json、xml、java-rmi 基于 java 自带序列化之列的

• 如何传递数据

基于什么网络协议传输

java-rmi 的远程协议

JSON-RPC 协议

SOAP 协议（web service 简单对下访问）

• 如何表示方法

如何定义方法，如何在不同语言、不同系统环境中保证 方法签名唯一。

需要对接口描述定义语言有一个选型

再后面讲解了 rpc 的发展历史 CORBA 的使用过于复杂，被抛弃 SOAP 使用 xml 很简单，但是性能奇差可以看出 RPC 想同时满足简单、普适、高性能是很难的于是得出一个结论：

不存在完美的 RPC 框架

最近几年的 RPC 框架更倾向于往高层次、插件化发展。即不再独立解决 RPC 的所有问题，而是提供一些扩展点由用户自己选择（比如 dubbo）可以任意切换 json 或者 fastjson 等序列化方式可以切换传输协议等。

2 REST

rest 并不是一种远程调用协议， 他只能说是一种风格。REST 的传输效率提升潜力有限，但是可以简化调用。

2.1 REST 核心概念（基于 HTTP 超文本传输协议）

• 资源

资源指你希望获取或者修改的东西、信息本身，他的表现形式可以不同，但是里子是相同的

• 表征

就是表现资源的形式，用 html 还是 pdf 来返回

• 状态

指的是服务端对某次会话是否持有状态。

例如读下一篇文章时，当前文章 id 由服务端存储还是浏览器存储，这就是有状态和无状态的区别。

• 转移

就是服务端提供的行为逻辑， 通常叫做 资源的转移

• 统一接口

就是 HTTP 协议里提供的 GET\HEAD\POST\PUT\DELETE\TRACE\OPTIONS 这七种操作，通过这些操作触发转移

• 超文本驱动

浏览器的行为经常是通过服务端返回的 url 或者各种信息触发了驱动行为

• 自描述消息

为了方便客户端识别表征，返回类似于 Content-Type 等内容，方便用何种字符集处理

2.2 REST 核心设计原则

• 客户端与服务端分离

服务端不处理渲染， 由客户端来处理

• 无状态

尽可能希望服务端不要存储 rest 会话状态，达到分布式的高价值回报。

但是不太可能特别是客户端持有会话数量级很大的情况下，所以仍旧会持有一定状态

• 可缓存

服务端的应答中要直接或者间接告知客户端是否可以缓存，缓存多久

• 分层系统

客户端不需要知道是否真的连接到了最终的服务器

代表是 CDN 内容分发网络

• 统一接口

面向资源编程

系统设计时聚焦在资源而不是行为上

例如面向行为时， 登录就是 login 接口，注销就是 logout 接口

而面向资源时，登录就是 PUT Session, 注销就是 DELETE Session

• 按需代码

客户端的代码可以有一部分让服务端发回进行装载。

2.3 REST 的好处

降低服务接口的学习成本

资源天然具有集合与层次接口

这样很多资源可以很容易组合在一起并让使用者想到接口 url 是什么

例如获取 用户 icyfenix 的购物车中的第 2 本书，这个是有层次的，那么接口就是 GET /user/icyfenix/cart/2

REST 绑定于 HTTP 协议，HTTP 又是大家非常熟悉的

2.4 RMM（Richardson 提出的 restful 成熟度模型）

第 0 级：完全不 rest

提供的 api 定义里总是包含了各种动作，例如/queryXXX/applyXXX 类似于 RPC 的行为接口坏处是一旦要提供其他对 XXX 的操作，必须重新编写接口，无法对 XXX 的查询能力进行复用！

第 1 级：开始引入资源的概念

api 的 endpoint 定义应该围绕名词+资源 id 而不是动词来定义。POST /doctors/mjones 获取医生的档期 POST /schedules/{id} 触发对这个 id 的调度

第 2 级： 引入统一接口，映射到 HTTP 方法上

上面的 method 都是 POST，实际上可以把 HTTP 方法的 method、返回码都给利用上

• 对一个资源的增加用 POST，删除用 DELETE，更新用 PUT

• 依赖 HTTP 的返回码定义资源可能的异常情况。例如 201 代表创建成功，409 代表冲突（被人抢先预约）

• 利用 HTTP 自带的认证和授权信息。

第 3 级：超文本控制，转移行为通过响应控制

第 2 级里， 所有接口的定义仍然需要使用者自己查询文档来记忆和应用实际上应该只需要一个操作起始入口， 例如获取医生的档期接口这个接口要返回的 body 里，已经告知了对应资源的名称，例如档期资源的 key 就叫做 schedules 那么就能马上知道下一个接口查询用 schedules 了！这样代码里可以做好适配，当你要把档期的 key 名做修改时，客户端代码根本不用变动！

2.2.4 REST 的不足和争议

• restful 面向资源编程只适合做 CRUD，不适合过于复杂的业务逻辑

面向过程编程，以算法和处理过程为中心，这符合计算机世界中主流的交互方式

面向对象编程，将数据和对象行为统一起来，因为这符合现实世界的主流交互方式

面向资源编程，数据作为主体，行为看成统一接口，为了符合网络世界的主流交互方式

• rest 不利于事务支持

作者不同意这个观点， 认为不会有阻碍，取决于系统的事务设计

• rest 没有传输可靠性支持

虽然确实没有类似于重发等机制的保证，但 rest 接口一般尽可能要求幂等性，来做到应用代码做重发时可以不用担心重复的问题

• 缺少对资源做部分或者批量处理的能力

rest 语义里不能涵盖这种情况，得定义特殊的接口或者参数，那么低 3 级里面就不能涵盖了。

相关思考

基于 REST 的规范，调用者可以非常快速地理解自己需要的接口内容是什么样的，例如华为云当前的很多云服务公开接口都会基于 REST 理念进行开放， 并且各云服务的开放接口都会集成到API Explorer和华为云SDK中心供开发者直接调用，这些平台提供了丰富的接口文档和示例代码，帮助开发者更快地上手和使用 REST 接口。

相信未来 REST 规范将会变得更加流行和普及。随着云计算和大数据技术的不断发展，REST 接口将会被广泛应用于各种领域，例如医疗、金融、电商等。REST 接口的开放性、可扩展性和易用性，将会为开发者带来更加高效、便捷和可靠的开发体验。

点击关注，第一时间了解华为云新鲜技术~