讀《微服務從設計到部署》筆記

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

2.更容易差別化部署，好比有些服務對硬件要求低，有些就很高，能夠差別化購買或搭建雲服務。

3.符合DevOps 文化，什麼是DevOps：http://www.javashuo.com/article/p-tsinxekl-dq.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通信

進程間通信：

1.定義API，不管您選擇何種 IPC 機制，使用接口定義語 言（interface definition language，IDL）來嚴格定義服務 API 都是很是有必要的。 有論據證實使用 API 優先法定義服務更加合理。

2.API定義的新舊版本問題，如何作到各類服務的升級協調一致性。解決方案：若是您使用了基於 HTTP 的機制（如 REST），則一種方法是將版本號嵌入 URL 中。。每一個服務實例可能同時處理多個版本。或 者，您能夠部署多個不一樣的實例，每一個實例用於處理特定版本。

3.處理局部故障：

斷路器：追蹤成功和失敗請求的數量。若是錯誤率超過配置閾值，則斷開斷路器，以便後 續的嘗試能當即失敗。若是出現大量請求失敗，則代表服務不可用，發送請求將 是無心義的。發生超時後，客戶端應從新嘗試，若是成功，則關閉斷路器。

 

4,異步、基於消息的通訊：

a）點對點通道發送一條消息給一個切確的、正在從通道讀取消息的消費者。服務使 用點對點通道，就是上述的一對一交互方式。

b）發佈訂閱通道將每條消息傳遞給全部已訂閱的消費者。服務使用發佈訂閱通道， 就是上述的一對多交互方式。

c）基於消息的 IPC（進程間通訊）的優勢：將客戶端與服務分離 客戶端經過向相應的通道發送一條消息來簡單地發出一個請求。服務實例對客戶 端而言是透明的。客戶端不須要使用發現機制來肯定服務實例的位置。  消息緩衝 使用如 HTTP 的同步請求/響應協議，客戶端和服務在交換期間必須可用。相比之 下，消息代理會將消息寫入通道入隊，直到消費者處理它們。這意味着，例如， 即便訂單執行系統出現緩慢或不可用的狀況，在線商店仍是能夠接受客戶的訂單。 訂單消息只須要簡單地排隊。

d）同步的請求/響應 IPC，如Swagger，容許您定義請求和響應消息的格式。

e）微服務必須使用進程間通訊機制進行通訊。在設計服務如何進行通訊時，您須要考慮 各類問題：服務如何交互、如何爲每一個服務指定 API、如何演變 API 以及如何處理局 部故障。微服務可使用兩種 IPC 機制：異步消息傳遞和同步請求/響應。爲了進行 通訊，一個服務必須可以找到另外一個服務

 

5.服務發現機制