开放平台架构的本质

前言

很多公司开放平台架构图都很大，大到很多人抓不住重点。本文分析开放平台架构的本质，更多细节有人感兴趣的话以后可以展开写。

思考

可以思考一下开放平台的本质。

如果没有开放平台，在公司内部各个微服务应用之间怎么交互数据的呢？

这时就会发现主要有两类数据交换方式：

1. 同步调用：RPC 请求。类似的有 Dubbo、gPRC、Thrift 等协议，简单场景用 HTTP 也可以；

2. 异步调用：MQ 服务。类似的有 Kafka、RocketMQ 等，提供基于 Provider-Consumer 模型的异步消息服务；

从一方走向三方（内部到外部）

对应到三方的话，RPC 和 MQ 这种内部中间件就不合适了。但是仔细思考就会发现本质上其实没有变化，依然还是应用之间的两类数据交互。

只不过针对更开放的场景把协议更换掉：

1. 同步调用：采用 HTTP，例如 REST API 代替内部 RPC 协议；

2. 异步调用：采用基于 HTTP 的 Webhook callback 方式；（备注：钉钉还提供了基于 WebSocket 的 Stream 模式，不用公网域名、不用公网 IP，原生支持内网穿透，对本地开发 &运维部署非常友好。

权限管理

开放到公域之后，又多了个权限管理的需求，避免三方应用违规访问数据。

最终架构核心就是两条大腿（API 网关、事件中心），一个底座（权限）。

最后

我负责过每天千亿次请求的网关服务，也主导过大规模开放平台技术架构，对各个细分模块有兴趣可以评论留言，我单开一篇文章来介绍（可以延展开的地方非常多）。