如何设计 RPC 接口

如果说之前清晰知道如何 设计HTTP API 就可以了，那么随着微服务走热，服务越来越多，每个服务都要对外暴漏接口，对如何设计RPC接口有个清晰的认识，变得比以前任何时候都重要。

虽然设计 RPC 接口很重要，但是却并不容易，经历过多少折腾，才能理解接口那些痛：

• 莫“名”其妙

读取数据可能会因为数据不一样，分别称为： GetXxx vs GetXxxLite ，所以 lite 不 lite 有啥不一样？类似的太多太多，关于如何取一个好名字，可以看这里：《如何代码命名》

• 接口过多

由于页面需要各式各样的数据，导致查询条件差异很大，很容易出现：

• 一个查询条件，一个接口的尴尬
• 直接新增接口，但实际上该接口可能已经出现过，只是被隐藏在众多接口里

• 难以扩展

面向需求设计接口，不进行任何抽象，导致接口难以扩展

三者就像追命绳索，一环套一环，环环相扣，最终将服务带入墓地。

认识复杂性

举个例子，当从DB表读取表数据时，可以按照以下三种维度读取数据：

1. DB的维度，允许表之间 join，即操作复合数据
   
2. 表的维度，允许且只允许操作一条数据的所有字段
   
3. 字段的维度，允许接口操作表的部分字段。
   

假设数据库 d 有 t 张表，平均每个表有 f 个字段，每种数据有 n 种操作。则:

• 第一种方案，有 n * t! 个接口；
• 第二种方案，有 n * t 个接口；
• 第三种方案，有 n * t * f! 个接口
• 没有方案，则有 n * t! * f! * n 个接口

聪明的你会选择哪一种方案，你的依据又是什么？想弄清楚这些，就需要继续往下看

认识资源

看接口先看资源，所有的接口都是为了操作资源。对资源了解多深刻，也就大概限制了对接口认识多深刻。

资源在用户侧以 hyper media 存在；资源流到服务中以对象来组织；资源落到存储里就变成了id + content。索引 content 的 id，一般又以 单个 和 集合 的形态存在，具体到数据库中，id 以 聚簇索引存在，content 以聚簇索引叶节点存在

越来越多的产品按照先获取 id 再读取 content 来访问资源，之前是搜索引擎，现在是各式各样的内容推荐

认识操作

有了对数据的基本认识，对数据的操作无非是：增、删、改、查（包括：ID / 内容列表查询、根据 ID 批量查询内容）

再加上 80 / 20 原则，为 80%的请求量 设计高性能语义清晰简洁的接口；为 20% 的请求量，引入 规约模式（Specification-Pattern），设计扩展性更强的接口；将复杂的查询，变化为 id collection（搜索引擎） + content （批量查询接口）。

总结

有了以上这些认知，那么如何为服务设计收敛的接口，也就不再是个问题。

课后作业

请为以下需求设计一套查询的API接口

主播侧需求

当主播点开直播直播入口时

• 如果有未开始的直播，则进行直播设置；
• 如果有进行中的直播，则直接进入该场直播；
• 如果没有进行中的直播

• 第一次直播，则创建一场新的直播
• 第一场之外的直播，则使用上一场直播的设置，创建一场新的未开始的直播。

用户侧

当用户点开直播间时

• 获取该直播的所有信息，包括：

• 主播信息
• 直播信息
• 是否关注该主播
• 在线人数
• 点赞数
• …

本文作者 ： cyningsun

本文地址 ： https://www.cyningsun.com/07-27-2020/how-to-write-rpc-interface.html

版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！

# API Design

1. 如何设计资源标识符？
2. REST API 设计规范
3. 如何选择合适的分布式ID生成方案？