微服務架構是一種軟體開發模式，它將一個複雜的應用程式拆分為多個個獨立的、小型的、可復用的服務，每個服務負責一個特定的業務功能。 微服務架構有許多優點，例如提高系統的可擴展性、可維護性、可測試性和故障容忍性。 但是，微服務架構也有很多問題需要註意，例如如何設計合理的劃分服務介面、如何在服務間實現高效通 ...
微服務架構是一種軟體開發模式，它將一個複雜的應用程式拆分為多個個獨立的、小型的、可復用的服務，每個服務負責一個特定的業務功能。
微服務架構有許多優點，例如提高系統的可擴展性、可維護性、可測試性和故障容忍性。
但是，微服務架構也有很多問題需要註意，例如如何設計合理的劃分服務介面、如何在服務間實現高效通信、如何保證數據一致性等。因此要想成功地使用微服務架構，我們需要遵循一些最佳實踐。
以下是一些微服務架構的最佳實踐，我將盡我所瞭解的知識給大家進行講解。本文大綱如下，
1. 不使用微服務架構
沒錯，我們應該儘量避免使用微服務架構。
認真地說，使用微服務架構只能被視為最後的選擇。從項目實際應用場景開發，少看一些網上關於微服務的吹捧。務實一點，根據項目體量、業務複雜度選擇一個適合當前項目的架構。
首先嘗試構建一個單體的模塊化架構，而不是一上來就搞微服務架構。
2. 針對失敗場景進行處理
在任何使用微服務的分散式系統裡面，總是有調用失敗的可能，比如網路分區、某個服務宕機不可用等。
所以我們在系統調用層面針對失敗場景的處理，應該設計得越早越好。
故障設計最好三個級別，
- 基礎設施級別
- 資料庫級別和
- 單個微服務級別
實際的針對失敗場景處理，可以使用斷路器、服務降級和 "隔板模式"。
隔板模式在分散式系統中就是指資源隔離，在分散式系統里，資源隔離通常按業務分為進程級別的隔離和線程級別的隔離，某些簡單的服務質量要求不高的業務場景下實現進程級別的隔離就夠了，但是在某些對服務質量要求較高的分散式場景下需要線程級別的細粒度隔離。
3. 構建小型服務
微服務架構中，每個服務應該都按單一職責進行設計。
每個微服務應該只負責一個業務領域，並且儘量避免涉及其他領域。
這樣可以提高代碼的可讀性、可測試性和可維護性，也可以降低系統的複雜度和耦合度。
4. 使用輕量級通信協議
微服務架構中，服務之間的通信協議時非常重要的。因為在一些對性能要求較高的場景里，選擇一個輕量級協議所能帶來的 QPS 提升，也是非常客觀的。
比如服務間可以使用 REST、GRPC 或消息隊列等通信協議，這樣可以儘可能減少服務通信帶來的開銷並提升性能。
5. 服務發現
微服務架構下，服務實例的網路地址是動態分配和變化的，因此需要一種機制，能夠及時獲取服務實例的最新的網路地址，以便進行服務間通信。
並且服務實例的數量和狀態都是隨著業務需求和故障情況而變化的，還需要有能夠及時感知服務實例的上線、下線、故障等情況的能力。
因此我們需要使用服務發現組件，它負責自動發現服務實例，負載均衡和故障轉移。
服務發現組件有 Eureka 、Consul、Nacos 等，國內的話，推薦大家使用 Nacos。
6. 資料庫隔離
微服務架構下，每個服務的資料庫應該都是單獨部署的，它們之間相互隔離。
一個服務要操作另一個服務資料庫中的數據時，都應該只能通過調用另一個服務的介面來實現，而不是粗暴的直接訪問其他服務的資料庫進行讀寫。
資料庫隔離的最終目標就是為了減少服務之間的耦合，使它們能夠獨立發展。
7. 實施彈性模式
為了提高微服務架構中各個服務的彈性，我們應該儘量使用彈性模式。
所謂彈性，其實就是服務的可用性，專業一點的話說就是從某些類型的故障中恢復並保持自身服務的能力。
那麼，我們應該如何實施實施彈性模式嘞？
其實很簡單，我給大家分成兩個部分進行講解，一個是服務內，另一個是服務外。
服務內指的是別人調用我們的服務時，需要註意的點有，
- 添加緩存
- 資源隔離
- 介面限速
服務外指的是我們調用別人的服務時，需要註意的點有，
- 調用超時
- 請求重試
- 斷路器應用
8. 服務監控於鏈路追蹤
有句話說得好，"在任何分散式系統中，會宕機的服務最終都會宕機"。
