微服務架構(gòu)是一種軟件開發(fā)模式，它將一個復雜的應用程序拆分為多個個獨立的、小型的、可復用的服務，每個服務負責一個特定的業(yè)務功能。

微服務架構(gòu)有許多優(yōu)點，例如提高系統(tǒng)的可擴展性、可維護性、可測試性和故障容忍性。

但是，微服務架構(gòu)也有很多問題需要注意，例如如何設計合理的劃分服務接口、如何在服務間實現(xiàn)高效通信、如何保證數(shù)據(jù)一致性等。因此要想成功地使用微服務架構(gòu)，我們需要遵循一些最佳實踐。

以下是一些微服務架構(gòu)的最佳實踐，我將盡我所了解的知識給大家進行講解。本文大綱如下，

圖片

1. 不使用微服務架構(gòu)

沒錯，我們應該盡量避免使用微服務架構(gòu)。

認真地說，使用微服務架構(gòu)只能被視為最后的選擇。從項目實際應用場景開發(fā)，少看一些網(wǎng)上關(guān)于微服務的吹捧。務實一點，根據(jù)項目體量、業(yè)務復雜度選擇一個適合當前項目的架構(gòu)。

首先嘗試構(gòu)建一個單體的模塊化架構(gòu)，而不是一上來就搞微服務架構(gòu)。

2. 針對失敗場景進行處理

在任何使用微服務的分布式系統(tǒng)里面，總是有調(diào)用失敗的可能，比如網(wǎng)絡分區(qū)、某個服務宕機不可用等。

所以我們在系統(tǒng)調(diào)用層面針對失敗場景的處理，應該設計得越早越好。

故障設計最好三個級別，

• 基礎設施級別
• 數(shù)據(jù)庫級別和
• 單個微服務級別

實際的針對失敗場景處理，可以使用斷路器、服務降級和 "隔板模式"。

隔板模式在分布式系統(tǒng)中就是指資源隔離，在分布式系統(tǒng)里，資源隔離通常按業(yè)務分為進程級別的隔離和線程級別的隔離，某些簡單的服務質(zhì)量要求不高的業(yè)務場景下實現(xiàn)進程級別的隔離就夠了，但是在某些對服務質(zhì)量要求較高的分布式場景下需要線程級別的細粒度隔離。

3. 構(gòu)建小型服務

微服務架構(gòu)中，每個服務應該都按單一職責進行設計。

每個微服務應該只負責一個業(yè)務領域，并且盡量避免涉及其他領域。

這樣可以提高代碼的可讀性、可測試性和可維護性，也可以降低系統(tǒng)的復雜度和耦合度。

4. 使用輕量級通信協(xié)議

微服務架構(gòu)中，服務之間的通信協(xié)議時非常重要的。因為在一些對性能要求較高的場景里，選擇一個輕量級協(xié)議所能帶來的 QPS 提升，也是非?？陀^的。

比如服務間可以使用 REST、GRPC 或消息隊列等通信協(xié)議，這樣可以盡可能減少服務通信帶來的開銷并提升性能。

5. 服務發(fā)現(xiàn)

微服務架構(gòu)下，服務實例的網(wǎng)絡地址是動態(tài)分配和變化的，因此需要一種機制，能夠及時獲取服務實例的最新的網(wǎng)絡地址，以便進行服務間通信。

并且服務實例的數(shù)量和狀態(tài)都是隨著業(yè)務需求和故障情況而變化的，還需要有能夠及時感知服務實例的上線、下線、故障等情況的能力。

因此我們需要使用服務發(fā)現(xiàn)組件，它負責自動發(fā)現(xiàn)服務實例，負載均衡和故障轉(zhuǎn)移。

服務發(fā)現(xiàn)組件有 Eureka 、Consul、Nacos 等，國內(nèi)的話，推薦大家使用 Nacos。

6. 數(shù)據(jù)庫隔離

微服務架構(gòu)下，每個服務的數(shù)據(jù)庫應該都是單獨部署的，它們之間相互隔離。

一個服務要操作另一個服務數(shù)據(jù)庫中的數(shù)據(jù)時，都應該只能通過調(diào)用另一個服務的接口來實現(xiàn)，而不是粗暴的直接訪問其他服務的數(shù)據(jù)庫進行讀寫。

數(shù)據(jù)庫隔離的最終目標就是為了減少服務之間的耦合，使它們能夠獨立發(fā)展。

7. 實施彈性模式

為了提高微服務架構(gòu)中各個服務的彈性，我們應該盡量使用彈性模式。

所謂彈性，其實就是服務的可用性，專業(yè)一點的話說就是從某些類型的故障中恢復并保持自身服務的能力。

那么，我們應該如何實施實施彈性模式嘞？

其實很簡單，我給大家分成兩個部分進行講解，一個是服務內(nèi)，另一個是服務外。

服務內(nèi)指的是別人調(diào)用我們的服務時，需要注意的點有，

• 添加緩存
• 資源隔離
• 接口限速

服務外指的是我們調(diào)用別人的服務時，需要注意的點有，

• 調(diào)用超時
• 請求重試
• 斷路器應用

8. 服務監(jiān)控于鏈路追蹤

有句話說得好，"在任何分布式系統(tǒng)中，會宕機的服務最終都會宕機"。??

特別是在微服務系統(tǒng)，系統(tǒng)間的服務調(diào)用鏈路越長，發(fā)生異常時的排查難度就越大。

所以為了跟上微服務的步伐，我們需要發(fā)現(xiàn)各個服務中存在的問題。進一步也就需要針對微服務的性能、狀態(tài)、異常等指標進行收集、分析、展示和告警。這有助于提高系統(tǒng)的可觀察性、可運維性和可靠性。

鏈路追蹤是一種技術(shù)，用于監(jiān)控和分析分布式系統(tǒng)中的請求流程，以及各個服務之間的調(diào)用情況。

在分布式系統(tǒng)中，鏈路追蹤就是為每個請求分配一個全局唯一的標識（TraceId），并在請求在各個服務之間傳遞時，記錄每個服務的調(diào)用信息（SpanId），包括調(diào)用時間、耗時、狀態(tài)等。通過收集、存儲、展示和分析這些信息，就可以還原出請求的完整鏈路，以及各個服務的性能表現(xiàn)。

在如今流行云原生的潮流下，推薦使用 Prometheus、Grafana 為微服務構(gòu)建全面的監(jiān)控能力，使用 Skywalking 為微服務構(gòu)建一套性能分析以及鏈路追蹤平臺。

9. 服務的安全性

微服務架構(gòu)中，各個服務的安全性設計也非常重要。

常見的有如下幾種安全性設計的舉措，

• API 網(wǎng)關(guān)：使用 API 網(wǎng)關(guān)作為服務的統(tǒng)一入口，對所有進入和離開的請求進行鑒權(quán)、路由、負載均衡、限流、緩存等功能，提高服務的可用性和性能，同時也增加了服務的安全性，防止內(nèi)部服務被直接訪問或攻擊。
• 令牌安全：使用 JWT、OAuth 2.0 等標準化的令牌格式和協(xié)議來實現(xiàn)服務之間或服務與客戶端之間的身份驗證和授權(quán)，防止服務被冒充或濫用。
• 請求過濾：對 API 網(wǎng)關(guān)所接收到的所有請求數(shù)據(jù)，進行 SQL 注入攻擊、XSS 攻擊和 CORS 攻擊過濾攔截處理。
• 風控報警：在 API 網(wǎng)關(guān)添加風控措施，針對發(fā)起惡意請求的用戶做黑名單風控處理，針對服務內(nèi)部的非業(yè)務異常進行報警通知。

10. 統(tǒng)一日志采集

分布式系統(tǒng)中，各個服務的日志都位于不同的機器上，因此機器越多，日志統(tǒng)一采集的需求就越強烈。

統(tǒng)一日志采集是微服務架構(gòu)中的一個重要的運維需求，它負責收集和管理分布式系統(tǒng)中的各種日志，如運行日志、訪問日志、錯誤日志等，以便于進行問題排查、性能分析、數(shù)據(jù)挖掘等。

推薦使用 ELK 或者 Graylog 搭建一套統(tǒng)一日志采集平臺。

因為我使用 Graylog 比較多，所以這里給大家推薦了解一波 Graylog 這個統(tǒng)一日志采集平臺。

Graylog 是一個開源的集中式日志管理系統(tǒng)，它可以收集、存儲、分析、展示和告警各種機器數(shù)據(jù)，為開發(fā)團隊提供安全、應用和 IT 基礎設施方面的問題的答案。

圖片

Graylog 可以讓我們在一個美觀的 web ui 界面上組合、關(guān)聯(lián)、查詢所有的日志數(shù)據(jù)。

圖片

Graylog 具有以下特點和優(yōu)勢：

• 高性能：Graylog 可以處理每秒數(shù)百萬條日志，支持多節(jié)點集群，實現(xiàn)水平擴展和負載均衡。
• 易用性：Graylog 提供了一個友好的 Web 界面，讓您可以輕松地構(gòu)建復雜的查詢，創(chuàng)建自定義的儀表盤，設置靈活的告警規(guī)則，生成定期的報告等。
• 靈活性：Graylog 支持多種日志來源，如文件、網(wǎng)絡、數(shù)據(jù)庫、應用程序等，可以通過插件和 API 進行擴展和集成，滿足不同的業(yè)務需求和場景。
• 安全性：Graylog 支持使用 HTTPS、SSL/TLS 等加密技術(shù)來保護日志數(shù)據(jù)的傳輸和存儲，同時也支持使用 LDAP、OAuth 2.0 等認證和授權(quán)機制來控制用戶的訪問權(quán)限。

Graylog 使用教程：https://learn.microsoft.com/zh-cn/azure/network-watcher/network-watcher-analyze-nsg-flow-logs-graylog