1.每個微服務都是自 包含（self-contained），各自維護自己的資料儲存，這樣就必須在設計資料庫的時候考慮服務的相對獨立性。

2.更容易差異化部署，比如有些服務對硬體要求低，有些就很高，可以差異化購買或搭建雲服務。

3.符合DevOps 文化，什麼是DevOps：https://www.cnblogs.com/liufei1983/p/7152013.html

4.API閘道器，提供了統一的微服務單入口，提供負載均衡、快取、訪問控制、API 計量和監控。

5.微服務架構中的程序間通訊，微服務之間的相互通訊。

6.微服務架構中的服務發現，當服務執行在一個動態環境中，想要找到他們並不是一件簡單的事情，我的理解是因為環境是動態的，所以用註冊發現機制可以實現相對穩定的訪問機制。不應該因為微服務換了IP或者是主機而改變其他服務呼叫該微服務的方式。

7.微服務事件驅動資料管理：由於每個微服務維護一個數據儲存，導致應用變得複雜。所以引入了這個概念。

8.選擇微服務部署策略

9.微服務架構模式明顯影響到了應用程式與資料庫之間的關係，與其他共享單個數據庫 模式（schema）服務有所不同，其每一個服務都有自己的資料庫模式

微服務最佳實踐：

1.一個微服務儘可能的解決一個問題。

微服務的缺點：

1.分散式系統肯定比單系統複雜。

2.分割槽資料庫架構，使得資料之間也相對獨立，業務難於處理。

3.測試微服務也相對難。

4.另一個主要挑戰是實現了跨越多服務變更，依賴影響太複雜。

5.部署微服務也相對單服務複雜。

API閘道器相關：

1.客戶端和微服務直接通訊？？？？  直接通訊是否就不能用負載均衡和叢集了？？

2.API 閘道器負責請求路由、組合和協議轉換，API 閘道器通常會通過呼叫多個微服務和聚合結果來處 理一個請求。它可以在 Web 協議（如 HTTP 和 WebSocket）和用於內部的非 Web 友 好協議之間進行轉換。

3.API 閘道器需要支援各種 通訊機制。有時候不只是http通訊

程序間通訊：待續~~~