雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
微服務極大的改變了服務端引擎的架構方式。微服務不是一個單一的巨型的用來託管應用程序所有業務邏輯的代碼庫，而是反映了分佈式系統模型，在該模型中，一組應用程序組件協同工作來滿足業務需求。通過遵循十項基本的微服務最佳實踐，你可以實現一個高效的微服務生態系統，從而避免不必要的架構複雜性。
微服務架構的收益
當從單體應用正確的遷移到微服務架構的時候，可以獲得以下收益：
- 你可以根據自己的意願選擇一門語言開發微服務，按照自己的節奏獨立發佈它，並獨立擴展。
- 組織中的不同團隊可以獨立的擁有自己特定的微服務，並且隨着並行開發以及重用的增加，產品發佈的時間會更快。
- 可以更好的隔離故障，因爲發生在特定微服務中的錯誤會在對應的服務中被處理掉，因此不會影響到生態系統中的其他服務。
但是，如果在構建微服務時未遵循正確的原則，則最終可能會陷入像糾纏在一起的意大利麪一樣的狀態。
這讓維護變得非常困難，因爲這需要不同的團隊一起協作來做變動，發佈或者實現容錯。
充分利用微服務是一門科學並且需要一些刻意練習。以下微服務最佳實踐和設計原則將幫助你構建鬆散耦合，分佈式和優化的微服務，以實現最佳價值。
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文檔，祕鑰管理，配置管理，分佈式追蹤等，企業級解決方案是必須要有的。
通過遵循這些微服務最佳實踐，你可以獲得一個鬆散耦合，分佈式以及獨立的微服務系統，同時你可以獲得本文開頭列出的微服務架構的真正好處。
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK
原文發佈時間：2020-08-06
本文作者：w9527
本文來自：“dockone”，瞭解相關信息可以關注“dockone”