一、交互方式
在爲服務選擇的API選擇進程間通信機制之前，首先要考慮服務與其客戶端的交互方式。
交互方式的選擇影響應用程序的可用性。
交互方式可以幫助選擇合適的集成測試策略。
交互方式分爲兩個維度：
1、一對一和一對多
一對一：每個客戶端請求由一個服務實例處理；
一對多：每個客戶端請求由多個服務實例處理。
2、同步和異步
同步：客戶端請求需要服務端實時響應，客戶端等待響應時可能導致阻塞；
異步：客戶端請求不會阻塞進程，服務端的響應可以是非實時的。
交互方式組合見表格：
|
|
一對一 |
一對多 |
|
同步模式 |
請求/響應（服務緊耦合） |
無 |
|
異步模式 |
異步請求/響應 單向通知 |
發佈/訂閱 發佈/異步響應 |
二、API版本
如何定義API取決於使用的進程間通信機制。如果使用的是消息機制，則API由消息通道、消息類型、消息格式組成；如果使用的是HTTP，則API由URL、HTTP動詞以及請求和響應格式組成。
語義化版本控制
作用：指定如何使用版本號、並且以正確的方式遞增版本號。
要求：版本號由三部分組成-MAJOR.MINOR.PATCH。必須按照如下方式遞增版本號：
MAJOR：對API進行不兼容的更改時
MINOR：對API進行向後兼容的增強時
PATCH：向後兼容的錯誤修復時；
三、消息格式
消息格式的選擇會對進程間通信的效率、API的可用性、可演化性產生影響。
消息的格式分爲兩類：文本、二進制。
基於文本的消息格式
常用的：JSON、XML
好處：可讀性高、自描述的，允許消息的接收方只挑選它們感興趣的值。對消息結構的修改可以做到很好的後向兼容。
弊端：消息過於冗長，特別是XML；解析文本引入的額外開銷，尤其是消息較大時。
JSON消息：命名屬性的集合；XML消息：命名元素和值的集合。
二進制消息格式
常用的：Protocol Buffers、Avro（提供類強類型定義的IDL-接口描述文件，用於定義消息的格式）
筆記來自：《微服務架構設計模式》一書，作者 [美] 克里斯·理查森 著，喻勇譯 第三章P63-70