术语定义：

  • 前端

    • 贴近真实用户侧的软件，主要与后端服务交互并将其可视化为用户提供界面的软件，通常在用户侧的设备上运行，

  • 通信

    • 两个不在一个内存空间甚至不在一个设备上运行的程序，需要通过网络来进行通信以表达请求、传递数据的过程。

  • 通信协议

    • 对软件通信进行了一定的规范和约束定义，使得软件交互过程更加清晰、明了，这里指软件在应用层交互的协议如HTTP协议、FTP协议、gRPC。

  • 序列化/反序列化

    • 这里的序列化指软件运行时内存态数据转化为通信协议所需数据的过程。

软件通信技术指南

现代常见通信协议比较

这里不对他们进行介绍，进对他们进行优缺点的比较

Restful API

REST：表述性状态传递 Roy Fielding博士在2000年他的博士论文中提出REST（Representational State Transfer）风格的软件架构模式，REST出现后，迅速取代了复杂而笨重的SOAP，成为Web API的标准， Restful：REST 风格的设计。 Restful API REST风格的应用程序接口。Restful 接口规范

基于HTTP/1协议设计，由于其足够简单，几乎被互联网完全认可，是互联网的通用协议，绝大多数设备均支持，协议穿透性好。由于其基于HTTP的文本协议，与其他二进制通信协议相比较重，性能自然差一些。

适用于系统的开放边界，与第三方交互的地方。

Dubbo

  • 最初为 Alibaba 开源的基于 TCP 传输层的Java语言RPC框架。

  • 性能好，足够灵活，生态较好，能同时支持多协议的暴露和消费，周边完善（服务注册、发现、治理）。

  • 但其属于定制化的私有协议，不够通用，虽然各个语言实现了一些客户端，但还是存在一些问题，如扩展性不够好、请求信息冗余、设计与特定语言绑定、协议版本升级问题。

gRPC

  • google 设计的 RPC 框架，基于 HTTP/2，默认使用 protobuf 协议序列化。

  • 性能好，原生 TLS 支持，传输内容压缩，设计时候便考虑跨语言，协议版本升级，扩展性好。

  • 学习曲线陡峭，周边设施少，

dubbo + gRPC

  • 由于 Dubbo 周边完善，且可以同时支持多种其他协议的暴露和消费，因此可以作为桥接者，底层使用其他协议，充分利用其他协议的有点和自身的治理优势。

通信协议选型

  • 系统边界

    • 通常与第三方系统进行交互，推荐使用兼容性好、简单的协议，首选 HTTP Restful API。

  • 系统内部服务与前端通信

    • 首选 Restful API 因其简单。

    • 特殊场景选择 GraphQL，性能更好，前端更简单，但其对后端要求较高。

  • 系统内部服务间通信

    • 有性能需求场景、且在考虑调用方与服务提供方开发成本的前提下，优先选择 dubbo/gRPC 系列

    • 通用场景可以选择 Restful 进行快速迭代。