10個微服務架構設計的最佳實踐
微服務極大的改變了服務端引擎的架構方式。微服務不是一個單一的巨型的用來托管應用程序所有業務邏輯的代碼庫，而是反映了分布式系統模型，在該模型中，一組應用程序組件協同工作來滿足業務需求。通過遵循十項基本的微服務最佳實踐，你可以實現一個高效的微服務生態系統，從而避免不必要的架構復雜性。
微服務架構的收益
當從單體應用正確的遷移到微服務架構的時候，可以獲得以下收益：
- 你可以根據自己的意愿選擇一門語言開發微服務，按照自己的節奏獨立發布它，并獨立擴展。
- 組織中的不同團隊可以獨立的擁有自己特定的微服務，并且隨著并行開發以及重用的增加，產品發布的時間會更快。
- 可以更好的隔離故障，因為發生在特定微服務中的錯誤會在對應的服務中被處理掉，因此不會影響到生態系統中的其他服務。
但是，如果在構建微服務時未遵循正確的原則，則最終可能會陷入像糾纏在一起的意大利面一樣的狀態。
這讓維護變得非常困難，因為這需要不同的團隊一起協作來做變動，發布或者實現容錯。
充分利用微服務是一門科學并且需要一些刻意練習。以下微服務最佳實踐和設計原則將幫助你構建松散耦合，分布式和優化的微服務，以實現最佳價值。
10個微服務最佳實踐
1.單一責任原則
就像代碼中的類一樣，它僅僅在單個原因情況下改變，微服務也是采用類似的方式建模。構建可能會改變一個以上的業務這種臃腫的服務是一個壞的實踐。
例如：你正在構建用于訂購披薩的微服務。你可以基于功能構建下面這些組件，諸如InventoryService，OrderService，PaymentService，UserProfileService，DeliveryNotificationService等。InventoryService僅僅有獲取或更新披薩種類或配料庫存相關的API，同樣的，其他也只會提供對應功能的API。
2.獨立的數據存儲
如果你的所有微服務都共享一個數據庫，這就違背了使用微服務的目的。對這個數據庫的任何的改變或者故障都會影響使用該數據庫的所有微服務。根據微服務的需要選擇正確的數據庫，定制化基礎設施以及對應數據的存儲，并且讓你的服務獨占它。理想情況下，任何需要訪問該數據的其他微服務只能通過擁有寫權限的微服務提供的API來訪問。
3.使用異步通信實現松散耦合
為了避免構建出一個緊密耦合的組件網格（mesh），可以考慮在微服務之間使用異步通信。
a.對依賴的服務異步調用，如下例子。
例如：有一個服務A依賴服務B的例子。當服務B返回響應消息，服務A再返回成功給調用服務A的調用者。如果調用者對服務B的內容不關心，那么服務A可以異步調用服務B，并且這個時候可以立即返回成功給調用者。
b.一個更好的選擇是在微服務通信之間使用事件機制。你的微服務可以發布一個事件消息到消息總線上，可以用來通知一個狀態的改變或者一個失敗事件，并且任何對該事件感興趣的微服務都可以獲得該消息然后做出相應的處理。
例如：上面提到的披薩訂單系統中，當客戶的訂單被接收到或者訂單已經完成以及運輸的狀態消息都可以使用異步通信給客戶發送通知消息。通知服務可以監聽訂單提交的消息事件然后將相應的通知推送給客戶。
4.使用熔斷器快速實現故障容錯
如果你的微服務依賴于另一個系統來提供響應，并且該系統需要很長時間才會響應，那么你的總體響應SLA將會受到影響。為了避免這種場景并且快速做出響應，你需要遵循的一個簡單的微服務最佳實踐是使用熔斷器來使外部的調用超時，然后返回一個默認響應或者錯誤。熔斷器模式可以參考最下面的引用。這種方式可以隔離故障服務，而不會導致級聯故障，可以讓你的服務保持在健康的狀態。你可以選擇使用流行的產品，比如Netflix開發的 Hystrix 。這要比使用HTTP CONNECT_TIMEOUT和READ_TIMEOUT設置更好，因為它不會啟動超出配置范圍的其他線程。
5.通過API網關代理微服務請求
相比于系統中的每個微服務都單獨提供API授權，請求/相應日志以及限流功能，使用一個單獨API網關做這些事情會更有價值。調用你微服務的客戶端可以連接到API網關而不是直接調用微服務接口。這種方式可以讓你的微服務避免做那些額外的調用，并且微服務內部URL可以被隱藏，這可以讓你更靈活的從API網關重定向流量到一個微服務的更新版本。當允許第三方訪問你的微服務時，那么更有必要使用這種方式，因為你可以在請求到達微服務之前對傳入流量進行限流以及拒絕來自API網關的未授權請求。你也可以選擇一個單獨的外部網關，讓它可以接收外部網絡的流量。
6.確保API變更向后兼容
你可以安全的對API進行變更并且快速的發布它們，只要這些改變不影響已有的調用者。一種可能的選項是通知你的調用者，讓他們通過集成測試來對做出的變更進行驗證。但是，這種代價會比較高，因為所有依賴項都需要在一個環境中排隊，這會使你的協調工作變慢。一個更好的選項是對你的API使用合約測試。你的API消費者對API提供預期響應結果的合約。作為API提供者的你可以集成這些合約測試作為你構建的一部分并且這些可以安全的保證重大的API變更。消費者可以測試你發布的存根（stubs）作為他們構建的一部分。這種方式可以讓你通過獨立測試合約變更來更快速的發布產品。
7.版本化微服務重大變更
不可能讓變更總是保持向后兼容。當你做了一個重大的變更的時候，同時需要繼續支持老的接口，這時候可以暴露一個新版本的接口。消費者可以在方便的時候選擇新的版本。但是有太多版本的API對于維護相應的代碼人來說會是一場噩夢。因此，有一種規范的方法是通過和客戶端一起協作或在內部將流量重新路由到較新的版本，從而棄用較舊的版本。
8.使用專用基礎設施托管微服務
你已經開發出了滿足所有檢查的最好的微服務，但是使用了一個很差的托管平臺，那么最終的效果依然會表現的很差。將你的微服務基礎設施與其他組件隔離可以實現故障隔離和最佳性能。隔離微服務依賴的組件基礎設施也同樣重要。
例如：上面披薩訂單的案例中，庫存微服務使用庫存數據庫。使用專用的托管機器不僅對于庫存微服務很重要，而且對于庫存數據庫同樣也很重要。
9.創建獨立的發布通道
你的微服務需要有一個單獨的發布通道，這個通道不和你所在組織中的其他組件關聯。這樣的話你就不會和別人有沖突以及浪費和多個團隊協調的時間。
10.建立組織效率
盡管微服務給你提供了獨立開發和發布的自由，但是對于跨領域關注（cross cutting concerns）來說，某些標準還是需要遵循的，這樣才不會讓每個團隊都花費時間為這些問題創建獨特的解決方案。這在諸如微服務分布式架構中是非常重要的，在這種架構中，你需要能夠連接難題（puzzle）中的所有部分才能看清全局。因此，對于API安全，日志聚合，監控，API文檔，秘鑰管理，配置管理，分布式追蹤等，企業級解決方案是必須要有的。
***
通過遵循這些微服務最佳實踐，你可以獲得一個松散耦合，分布式以及獨立的微服務系統，同時你可以獲得本文開頭列出的微服務架構的真正好處。
