rpc相关技术调研

REST：无状态的数据传输结构，适用于通用、快速迭代和标准化语义的场景。
gRPC：轻量的传输方式，特殊适合对性能高要求或者环境苛刻的场景，比如 IOT。
GraphQL: 请求者可以自定义返回格式，某些程度上可以减少前后端联调成本。
Webhooks: 推送服务，主要用于服务器主动更新客户端资源的场景。

nanomsg

website

zmq作者重新设计的一个框架，解决了一些zmq的问题。

作者的博客
http://250bpm.com/

go 实现

github

https://bravenewgeek.com/fast-scalable-networking-in-go-with-mangos/

scalability protocols are currently available

• PAIR - simple one-to-one communication
• BUS - simple many-to-many communication
• REQREP - allows to build clusters of stateless services to process user requests
• PUBSUB - distributes messages to large sets of interested subscribers
• PIPELINE - aggregates messages from multiple sources and load balances them among many destinations
• SURVEY - allows to query state of multiple applications in a single go

transports mechanisms

• INPROC - transport within a process (between threads, modules etc.)
• IPC - transport between processes on a single machine
• TCP - network transport via TCP
• WS - websockets over TCP

gRPC

The grpc library uses HTTP2 as a transport layer and provides a code generator based on the protocol buffer syntax making it very simple to use.

GraphQL

GraphQL 不是 REST 的替代品，而是另一种交互形式：前端决定后端的返回结果。

GraphQL 带来的最大好处是精简请求响应内容，不会出现冗余字段，前端可以决定后端返回什么数据。但要注意的是，前端的决定权取决于后端支持什么数据，因此 GraphQL 更像是精简了返回值的 REST，而后端接口也可以一次性定义完所有功能，而不需要逐个开发。

GraphQL 需要配套
GraphQL 不是 REST 的替代品，所以不要想着团队从 Http 接口迁移到 GraphQL 就能提升 X% 的开发效率。GraphQL 方案是一种新的前后端交互约定，所以上手成本会比较高，同时，为了方便前端同学拼 query，等于把一部分后端工作量转移给了前端，如果此时没有一个足够好用的平台快速查阅、生成、维护这些定义，开发效率可能不升反降。

总的来说，对外开放 API 或者拥有完整配套的场景，使用 GraphQL 是比较理想的，但对于快速迭代，平台又不够成熟的团队，继续使用标准 Http 接口可以更快完成项目。

Protocol Buffers vs json

优点：

• 資料輕量化：資料非常輕量，省去了不必要的 { 或 : 累贅。
• 混淆性：在一般人眼中無法輕易地猜測出資料結構為何，因為有經過編碼。
• 效能高：處理速度很快。
• 極具方便性：結構就是你的資料模型，你能夠直接在程式中使用這些結構，而不用建立新的物件來接納、映射（Mapping）這些資料。
• 清晰明瞭、無需文件：.proto 檔案本身就是你的文件，不需要額外撰寫 API 或結構文件來告訴別人你接受怎樣的資料。

适合使用 json 的场景：

• 當你希望資料是人類可解讀的時候。
• 你不打算直接把接收到的資料拿來處理，你希望從中拿取部分資料作為處理。
• 你希望在純文字、終端機的情況下就能夠與伺服器溝通。
• 不想經過任何特殊處理，想直接在瀏覽器中解讀。