如何设计 RPC 接口


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

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

  • 莫“名”其妙

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

  • 接口过多

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

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

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

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

认识复杂性

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

  1. DB的维度,允许表之间 join,即操作复合数据

  2. 表的维度,允许且只允许全部操作一条数据的所有字段

  3. 字段的维度,允许接口操作表的部分字段。

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

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

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

认识资源

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

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

Data=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