一：微服務概念
1、微服務的產生
隨著領域驅動開發、持續交付、按需虛擬化、基礎設施自動化、容器技術、小型自治團隊、大型集群系統等等實踐的過程中，發現細粒度的服務架構可用提交交付速度，并且有更多的機會嘗試新技術。微服務在技術決策上給予更大的自由度，更快遞響應未知或者不可避免的變化。
2、微服務的概念
微服務是小而自治的服務。小是只專注做好一件事，粒度和業務邊界匹配。自治是自我治理，服務方和消費方解耦。修改一個微服務并且對其進行部署，并不影響其他的服務。
3、微服務的優點
1）技術的異構性：一個公司系統可能用不同的技術棧解決不同的應用場景，服務提供的API的支持不同的技術調用就很重要
2）彈性：服務邊界就是艙壁。單塊系統中，如果服務不可用，那么所有功能都不可用。微服務中一個組件不可用，并不導致級連故障。微服務善于處理不可用和功能降級問題。
3）擴展：單塊系統只能一個整體進行擴展，一小部分存在性能問題，也需要整體驚醒擴張。微服務因為是細粒度的，所以容易擴展。
4）簡化部署：單塊系統修改小部分代碼、也需要整體應用程序發布變更，導致風險很高。微服務架構中，各個服務部署都是獨立的。
5）與組織結構相匹配：微服務架構可以的與組織結構匹配，從而提高團隊的生產力。
6）可組合性：單純的PC時代已過去，微服務架構中，提供接口給各個端使用，可組合成各個服務想要的功能。
7）可替代性風險低：在單體遺留系統中，需要替換工作量大，風險很高。微服務因為小而自治，可以簡單并且小風險的替換或重寫。
4、微服務與SOA的關系
微服務架架構師面向服務架構（SOA）的一種特定實現
5、微服務不是銀彈
微服務需要面對所有分布式系統所面對復雜性，比如面對部署、測試、監控和擴展等工作。微服務是否適合你，需與公司的組織、系統等很多因素有關。如果組織是中心化、集中化管理的可能不適合使用微服務。
二：微服務建模
1、什么樣的服務是好服務
1）低耦合：一個修改不影響另一個服務，一個服務盡可能少的知道與之協作的相關服務的信息2）高內聚：相關的行為聚集在一起，找到問題域的邊界確保相關行為聚集。
2、限界上下文
限界上下文包括兩部分內容，一部分需要與外部通訊，另一部分不需要和外部通訊。上下文必須都要有明確的接口，接口決定暴露哪些模型給其他的上下文。想要從一個限界上下文中獲取信息，需使用模型和他的對外通訊的邊界進行通訊。
1）共享的隱藏模型
同一個名字在不同的上下文中有完全不同的含義。比如退貨，在客戶上下文中，意味著寄送包裹，退款等、在倉庫上下文中，退貨是一個即將到來的包裹，重新入庫等。所以庫存是共享的模型，不能完全暴露或者盲目的暴露出去。
2）模塊和服務
模塊：同一進程內可以使用模塊減少彼此之間的耦合。發現領域內部的限界上下文，一定要對模塊對其進行建模，同時使用共享和隱藏模型。服務：模塊成為轉為微服務的候選。模塊上下文越清晰，轉為微服務成了可能，最終服務邊界和領域上下文保持一致。
3）過早的劃分
過早的進行服務劃分，發展一段時間后，服務的邊界上下文可能和之前有所不同，導致很多跨服務的修改代價高，導致合并成單塊系統的風險。面度新的領域時，很多時候將一個已有的系統劃分成微服務，要比從頭開始構建微服務簡單的多。
4、業務建模
1）方法：當你在思考業務的上下文時，不應該從數據共享的角度考慮，而應該從這些上下文提供的功能來考慮。這些功能操作提供給其他業務。
2）溝通：在組織內，不僅僅共享上下文的概念，還應該統一和共享術語和想法。
5、劃分上下文
1）劃分方法：一開始識別粗粒度的限界上下文、這些粗粒度的上下文可能包括一些套嵌的限界上下文，這些套嵌的上下文不直接對外可見。
2）暴露原則：使用粗粒度上下文還是套嵌上下文暴露服務，哪個更合理，應該有組織結構來決定的。
6）技術邊界
技術邊界有顯示層、業務層和數據層，微服務可以按照技術邊界搭建技術架構。搭建這個架構之前需按照業務進行垂直劃分。
三、微服務集成
微服務的集成做到好，可以保持自治性、可以獨立發布修改和發布。
1、集成原則
1）避免破壞性修改
服務的一些修改不能導致該服務的消費方發生改變。
2）保證API與技術的無關性
3）保證API的易用性
4）隱藏內部實現細節
2、同步與異步
同步：調用方發起遠程服務調用后，調用方阻塞自己并且等待服務方的返回。
異步：調用方不需要等待服務方返回，甚至可能不關心這個操作完成與否。
3、編排與協同
編排：同步調用一組服務，等待各個服務的返回結果。優點知道業務流程中每一步跨服務調用結果，缺點容易承擔太多的調用，太耗時，導致調用方的不穩定性。
協同：異步調用一組服務或服務調用加入隊列中，降低服務之間的耦合度，帶來的額外工作業務流程跨服務的監控，不過可通過消費方處理完成后，回調服務方告知處理結果。
4、版本管理
1）盡可能推遲破壞性修改
寬進嚴出的原則
2）盡早發現破壞性的修改
按照契約，通過測試及早發現是服務方還是消費方破壞性的修改
3）不同的接口版本共存
最好共存兩個版本
四、微服務規模化
1、故障無所不在
網絡是不可靠，只能盡力限制引起故障的因數，達到一定規模后，故障不可避免。
2、跨功能需求
服務吞吐量、可用性和數據持久性等這些需求需要持續測量，并保證服務滿足可接受的目標。
3、功能降級
構建彈性系統，因微服務功能分散，在有可能down機的微服務上，能夠安全的降級以保證彈性
4、反服務脆弱
為了不會引起嚴重級聯影響，需要正確的設置超時、實現艙壁隔離或斷路層等以避免在第一時間調用一個不健康的服務。
1）超時
設置超時時間對于調用下游服務十分重要，超時時間設置太長有可能把下游系統拖慢，設置太短可能下游服務未處理完成。最好設置一個默認的超時時間，當超時發生時后，記錄到日志里看看發生了什么，并且做響應的調整。
2）斷路器
使用斷路器，當請求下游服務發生一定數量的失敗后，短路器打開，接下來的請求快速失敗。一斷時間后，查看下游服務是否已服務，重置斷路器。
3）艙壁
未每個下游服務建立單獨的連接池。超時和斷路器資源受限時釋放資源，艙壁第一時間確保它不成為限制。還有一個拒絕請求的艙壁，用以避免資源飽和，稱之為減載。
4）隔離
當下游服務離線，上游服務不受影響。設置成為服務間隔離。
5、冪等
冪等操作，多次執行所產生的影響，均與一次執行影響相同。可以把某些特定業務操作設計成冪等的，比如客戶下單送積分。
6、擴展
增加負載、減少延遲。
1）更強大的主機：垂直擴展，更好的機器。
2）拆分負載：按業務拆分成不同的微服務
3）分散風險：數據跨機房，異地備份等
4）負載均衡：避免服務單點故障
5）作業分離：Job獨立服務執行
6）重新設計：一般設計系統需要考慮10倍容量增長。重新設計系統應對規模化，是成功的標志。
7、擴展數據庫
1）服務的可用性
2）服務的持久性：多副本
3）讀取數據擴展：讀寫分離
4）寫操作擴展：分表分庫
5）共享數據庫設施：容易形成單點故障
6）CQRS：命令查詢職責分離
8、緩存
通過存儲之前的操作結果，以便后續請求使用這個結果，而無需花重新計算或查詢。
1）客戶端緩存
客戶端緩存獲取的結果，客戶端決定何時獲取新副本。一般是有下游服務提供緩沖的過期時間。客戶端緩存可以減少網絡調用次數，并且減少下游服務負載的最快方法之一，客戶端緩存數據，讓數據失效需要做額外的工作。
2）服務端緩存
服務端來負責處理緩存，容易跟蹤和優化緩存的命中率。
3）代理服務器緩存
緩存在服務的和客戶端之間，比如方向代理或CDN等。對一切客戶端和服務端不透明
4）HTTP緩存
5）為寫使用緩存
先寫入本地緩存，之后某個時刻將數據寫入下游的，可能更規范化的數據源中。
6）為彈性使用緩存
下游服務不可用，客戶端可以緩存可能失效的數據。
7）隱藏源服務
保護源服務，不直接暴露源服務。如果緩存不命中，立即失敗，異步重建緩存。
8）保持簡單
避免太多地方使用緩存，緩存越多，數據越可能失效，就越難保證數據的新鮮程度。
9、自動伸縮
響應型伸縮、預測型伸縮
10、CAP定理
在分布式系統中有三方面需要彼此權衡：一致性、可用性和分區容忍性。這個定理告之我們最多只能能保證三個中的兩個。CA系統在分布式系統中根本不存在。
11、服務發現
1）DNS
2）動態服務注冊：zookeeper、redis、consul
12、文檔
接口文檔的重要性
五、微服務總結
什么時候你不應該使用微服務
越不了解一個領域，為服務找到合適的限界上下文就越難，邊界清晰穩定后，再進行拆分。
