圍繞業務能力組織服務、自動化部署、智能端點、對語言及數據的去集中化控制。
微服務的結構
- 將組件定義爲可被獨立替換和升級的軟件單元。
- 以業務能力爲出發點組織服務的策略。
- 倡導誰開發，誰運營的開發運維一體化方法。
- RESTful HTTP協議是微服務架構中最常用的通訊機制。
- 每個微服務可以考慮選用最佳工具完成(如不同的編程語言)。
- 允許不同微服務採用不同的數據持久化技術。
- 微服務非常重視建立架構及業務相關指標的實時監控和日誌機制，必須考慮每個服務的失敗容錯機制。
- 注重快速更新，因此係統會隨時間不斷變化及演進。可替代性模塊化設計。
微服務通信方式：
1. 同步：RPC，REST等
2. 異步：消息隊列。要考慮消息可靠傳輸、高性能，以及編程模型的變化等。
消息隊列中間件如何選型
1.協議：AMQP、STOMP、MQTT、私有協議等。2.消息是否需要持久化。3.吞吐量。4.高可用支持，是否單點。5.分佈式擴展能力。6.消息堆積能力和重放能力。7.開發便捷，易於維護。8.社區成熟度。RabbitMQ是一個實現了AMQP(高級消息隊列協議)協議的消息隊列中間件。RabbitMQ支持其中的最多一次和最少一次兩種。網易蜂巢平臺的服務架構，服務間通過RabbitMQ實現通信。
傳統微服務架構
我們的核心挑戰是降低複雜性並增強可擴展性：一個強勁的骨幹網，用於統一資源訪問和權限並改善路由和內部服務通信。
改進的微服務架構
這更像一個網絡操作系統，管理和調度資源。
參考
網易蜂巢微服務架構：用RabbitMQ實現輕量級通信 www.cnblogs.com/yangxiaolan/p/5786119.html
微服務架構強化的實時通信 dockone.io/article/1795