智能的服務，愚蠢的通信管道

超文本轉移協議（HTTP）是伴隨互聯網而生的最棒的工具之一。人們將HTTP設計為無狀態，但又通過巧妙地結合cookies，從而讓客戶端可以保持狀態。這些事出現在Web 1.0時代，那時還沒有人談論REST API和移動應用。讓我們來看一個HTTP請求的例子：

正如你所看到的，這是一個人類可讀的協議，無須太多解釋就能被人理解。

如今，大家都已經明白，HTTP並不局限於在Web中使用。正如它的作者們所設計的，它目前已經被當作通用協議來使用，可用於在兩個端點之間傳輸數據。HTTP正是我們所需要的、可用於微服務之間進行通信的協議：它可以傳輸數據，並在傳輸出錯的情況下儘可能完成自我修復。

在過去的若干年裡，尤其是在企業內部，人們花費了大量的精力來創建智能的通信機制，例如BPEL。BPEL是業務流程執行語言（Business Process Execution Language）的簡稱，它專註圍繞各業務環節之間的銜接行為，而非通信行為本身。

這樣一來便在通信協議中引入了一定程度的複雜度，使得應用的業務邏輯從端點滲透到了通信協議之中，從而導致了端點之間出現了一定程度的耦合。

應該將業務邏輯限定在各個端點之內，而不是任由其滲透到通信信道之中，這樣的系統更便於測試與擴展。多年來，我們認識到，通信層必須是一個能確保數據在端點（微服務）之間有效傳輸且相對扁平、簡單的協議。我們應該將業務邏輯封裝在端點的實現中，因為在實際情況中，一個服務並不能保證每時每刻都在線（應對這一狀況的能力被稱為彈性，會在本章的後續部分繼續討論），而網路也可能會時不時出現一些通信問題。

HTTP通常是用以構建面向微服務的軟體的最廣泛的協議，而另一個值得我們關注且需要進一步探索的選項是使用隊列來簡化端點之間的通信，比如Rabbit MQ和Kafka。

隊列技術以緩衝的形式為我們提供了一種管理通信的全新方式，它對高度事務性系統中消息確認機制的複雜性進行了封裝。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！