微服務架構基本原理學習筆記（三）

上一篇：微服務架構基本原理學習筆記（二）

五、微服務之間的通信

微服務通信模式

　　微服務本身并沒有規定通信規則，換句話說，一個微服務并沒有規定可以被哪些應用程式訪問，或者被哪些其它的微服務呼叫，應用程式與微服務間的直接通信，或者微服務與微服務間的直接呼叫，往往會因為其中錯綜復雜的關系而導致級聯故障，任何一個環節的錯誤都會導致與其關聯的其它部分無法正常作業，而且，如果執行某個操作需要呼叫多個不同的微服務才能完成，也會導致整個系統性能下降，我們應該盡量較少微服務之間的通信，

　　下圖展示了一個較好的微服務之間的通信架構圖：

　　微服務之間可以將資料以訊息的方式發布到事件總線上，這樣其它的微服務就可以以訊息訂閱的方式來完成微服務之間的資料通信，后面我們會討論這樣做的好處，另外，我們也可以在前端應用程式和微服務之間建立一個API網關，用來隔離它們之間的直接通信，對于前端應用程式而言，后端的微服務是透明的，所有來自前端應用程式的呼叫都可以通過API網關路由到對應的微服務，這樣的設計可以帶來幾個好處：首先我們可以在API網關級別實作用戶身份認證；其次是將前端應用程式與后端微服務之間進行解耦，從而使我們可以更加靈活地對微服務進行修改，同時保證面向公眾的API的一致性，假如有第三方的開發團隊基于我們的公共API來開發客戶端程式，那么保證API的一致性就變得尤其重要，因為我們無法控制第三方開發團隊的升級計劃，在API網關中，我們甚至可以針對不同的客戶端來聚合或轉換資料格式，以滿足前端的需要，

　　在示例eShopOnContainers的微服務架構中，我們可以看到，它有一個用來接收前端請求的API網關，并且移動應用和兩個網站都通過API網關來訪問后端的微服務，此外，我們從架構圖中也可以看到，微服務之間并不會直接訪問，而是通過事件總線以訊息訂閱的方式來實作異步資料通信，

同步通信

　　這里所說的同步通信與我們在編程語言中（例如Node.js中的同步與異步）所遇到的同步是兩個不同的概念，在前端應用程式通過API網關呼叫后端服務的程序中，有時我們需要等待服務器馬上回傳結果，而不是將該請求發送到訊息佇列，然后服務器在處理完之后再回傳結果，例如eShopOnContainers中有一個需要顯示前10個最受歡迎的商品的功能，它是通過API網關向Catalog微服務發送一個請求，然后Catalog微服務從資料庫中獲取對應的資料并回傳給前端應用程式，就整個程序而言，這是一種同步通信機制，因為前端應用程式在發送請求之后一直處于等待狀態，直到后端服務回傳結果，才進行下一步的動作（在網頁上顯示資料，或者給出錯誤提示），

　　有許多方式可以用來實作通信，但HTTP仍是迄今為止最為流行的方式，它作為行業標準，幾乎所有的編程語言都支持，這意味著我們可以非常方便地在網頁或移動應用中來呼叫我們的API和微服務，另外，HTTP還具備一些其它的特性，例如回應頭檔案和狀態標識、快取功能、代理機制等等，在用HTTP請求資料時，通常使用JSON或XML資料格式，但推薦使用JSON，其優勢之一是絕大多數編程語言都原生支持JSON格式，而且如果你使用JavaScript作為編程語言，JSON本身就是其資料型別的一部分，所以如果你正在開發網頁應用程式，那么JSON資料格式是最完美的選擇，

　　另外一種經常與微服務架構相關的模式是將API封裝為RESTful資源，這是另一種用來組織和有效表達服務器資源的實踐方式，我在《RESTful服務最佳實踐》一文中對此有非常詳細的介紹，

異步通信

　　有時我們在呼叫后端服務時不希望一直等待服務器回傳結果，服務器會在適當的時候處理我們的請求，例如eShopOnContainers中提交訂單的程序：

　　當客戶通過前端應用程式提交訂單時，后端系統需要完成一系列的操作，包括從第三方支付系統檢查客戶是否已成功完成支付，從供應商處檢查商品庫存狀態并啟動發貨流程等，這個程序可能會持續幾天的時間，所以對前端用戶而言，他只需要知道訂單已經成功提交，而并不需要一直等待整個程序處理完畢，他可以在稍后查詢訂單的處理進度，我們甚至可以在這個程序中添加訂單狀態更新通知功能，當訂單的狀態更新時，通過電子郵件或者短信告知用戶訂單的狀態，并在成功發貨后通知用戶，

　　常用的微服務異步通信模式是將訊息發送到事件總線（即訊息佇列），微服務間并不直接進行通信，而是創建一條訊息并發送給訊息代理，其它的微服務訂閱這些訊息并在適當的時候處理訊息的內容，這種模式帶來許多好處，首先，它將微服務彼此完全解耦，微服務間通過訊息代理完成通信，當某一個微服務暫時不可用時，仍然不影響其它微服務的正常運行，它可以繼續向訊息代理發送訊息，當不可用的微服務再次上線后，便可以從訊息佇列中繼續處理訊息內容，其次，這種架構也有利于支持更高級的縮放，如果訊息佇列中的訊息數量不斷增加，我們可以對微服務進行擴展，以幫助快速處理積壓的訊息，如果你使用云托管平臺，通常可以自動支持這一操作，如果使用容器，則可以通過為運行容器的虛擬機集群配置一些自動擴展的功能來實作這一操作，

　　訊息的型別有很多，但最常用的有兩種，即命令和事件，

　　命令表示要執行某種特定的操作，例如發送電子郵件，它不一定需要同步完成，該命令只需要將電子郵件的地址和內容說明清楚，剩下的事情就交給電子郵件微服務來完成，如果我們將大量的命令訊息發布到訊息佇列中，電子郵間微服務可能不會馬上處理這些訊息，但最終它們都會被一一處理完，

　　另一種訊息型別是事件，它表示發生了某件事，這有點像語法中的過去式，當事件發布時，系統中任何對此事件“感興趣”并訂閱了該事件的微服務都可以回應并執行它們各自定義的操作，在面向物件編程中，這一模式被稱為“發布-訂閱”模式，例如C#中的事件處理機制就是采用的這種模式，在eShopOnContainers中，提交訂單的程序就存在OrderPlaced事件，該事件會執行多個不同的操作，如支付、發送電子郵件、檢查商品庫存等，這里每個需要回應該事件的微服務都從發布到事件總線上的訊息觸發對應的操作，

彈性通信模式

　　我們無法保證系統中所有的微服務都一直正常運行，甚至我們無法保證網路通信沒有故障，所以，我們需要提前預料到可能出現的各種問題，這里有幾種技術和模式可以用來幫助我們提高系統的穩定性和通信彈性，

1. 自動重試功能，有時會因為網路通信故障或者微服務本身不可用而導致某個操作在一開始的時候失敗，如果系統能夠在稍后自動重試會是一個不錯的設計，例如通過一個HTTP請求對資料庫進行查詢，第一次嘗試失敗了，然后過幾秒鐘再試一次，如果仍然失敗則等待一段時間后再試一次，許多現代的編程框架已經內置了對這種功能的支持，可以使我們非常容易地實作這一特性，例如.NET中的Polly，
2. 斷路器，自動重試功能固然好用，但是如果由于某種原因導致重試的次數過多，或者一直處于重試狀態，則可能會導致系統性能下降，或者由于過于頻繁的請求而讓下游服務拒絕回應，斷路器可以用來很好地解決這一問題，斷路器位于客戶端和服務器之間，一開始它允許所有的請求通過，此時我們稱斷路器處于關閉狀態，一旦檢測到任何錯誤，例如服務器回傳特定的錯誤代碼或者根本沒有回應，那么斷路器就會打開，這意味著客戶端的所有請求都會立刻失敗而不會發送給服務器，我們可以在斷路器上配置超時時間，超時時間過后，斷路器再次關閉，所有客戶端的請求會被正常發送給服務器，如果服務器仍然沒有回應，斷路器會再次打開并保持一段時間，所有來自客戶端的請求都被會拒絕，這是一種實作起來非常簡單但是功能卻很強大的技術，同樣，許多編程框架也都內置了該功能，你完全不必自己來實作，

   

3. 快取，靈活地運用快取可以提高系統的彈性，如果我們快取從服務器或者下游服務中接收的資料，那么如果短時間內服務不可用，我們仍然可以使用快取中的資料，當然，前提是我們已經考慮過舊資料給系統帶來的影響，

 　　訊息代理在微服務架構中如此受歡迎的原因之一是它具有對彈性的內在支持，我們可以向訊息代理發布訊息，下游服務當前是否在線都沒有關系，當服務再次啟動時，可以繼續處理積壓的訊息，另外，訊息代理通常還具備重試發送訊息的能力，如果訊息處理程式因為某種原因無法正常處理訊息，訊息可以回傳給訊息代理以便稍后重新發送，當然，重試的次數也不是無限的，如果訊息在被進行一定數量的重試后仍然無法被訊息處理程式正常處理，訊息代理會認為這是一條“死”訊息而將它放入“死”訊息佇列中，

　　另外需要注意的一點是我們無法保證訊息總是按順序被接收的，這是由異步通信的本質所決定的，所以對訊息處理程式而言，即便收到的訊息是無序的，也能按照正確的邏輯進行處理，還有一種情況是訊息處理程式可能會接收到重復的訊息，這往往是因為訊息代理重復發送訊息而導致的，我們需要確保訊息處理是冪等的，對于一條訊息而言，訊息處理程式處理一次和處理兩次的結果相同，則認為訊息處理是冪等的，在eShopOnContainers中，提交訂單時的扣款和發貨程序就屬于這種情況，我們不希望這個程序中客戶被扣款兩次，而且也不希望對同一訂單重復發貨，所以，我們必須確保在代碼中進行了嚴格的檢查來避免出現這樣的情況，

微服務發現

　　為了讓微服務能夠相互通信，每個微服務都需要有一個地址，如何才能知道所有微服務的地址呢？假設我們有三臺虛機，每臺虛機上都運行著各種微服務，甚至同一個微服務的多個不同實體分別運行在不同的虛機中，我們不可能給每一個在虛機上運行的微服務都分配一個固定的IP地址，那么如果解決這個問題呢？

　　一種方法是使用注冊中心，它記錄了所有當前運行的微服務的地址，每個微服務在啟動時都向注冊中心報告并注冊自己的資訊，這樣其它微服務在需要的時候就可以通過注冊中心找到該微服務，如果你使用云托管平臺，通常它都支持這部分功能，我們不需要自己創建注冊中心，而且，在云托管平臺上，我們部署的每個微服務通常都會自動分配一個DNS名稱，同時它還支持負載均衡，這意味著我們可以通過DNS名稱來找到微服務，而不用關心微服務是在哪臺虛擬機上，

　　如果使用容器，則可以考慮使用Kubernetes，Kubernetes內置了DNS，我們不需要知道每個容器的IP地址，只需要知道微服務的名稱即可，Kubernetes負責將請求路由到對應容器并在必要時進行負載均衡，

六、微服務安全

　　微服務應用程中通常都要存盤和處理大量資料，這些資料常常都包含了各種敏感資訊，例如，在eShopOnContainers中，Catalog微服務用來處理商品資訊，這些資訊應該對所有客戶開放，因此這部分資料不是敏感資料，但是在Ordering微服務中，我們需要保存哪些客戶訂購了哪些商品，同時還包含客戶的送貨地址和付款資訊，這些資料都是非常敏感的，如果一旦泄露，將會產生非常嚴重的后果，因此，對于那些處理敏感資料的微服務，我們必須采取有效的保護措施，

對資料進行加密

　　資料的加密包括幾個方面，首先是資料傳輸程序中的加密，以防止資料被中間方監聽，推薦使用業界標準的加密演算法，而不要嘗試自己發明新的加密演算法，對于HTTP通信，可以通過配置傳輸層安全或者TLS（Transport Layer Security）來實作加密，使所有的請求都通過HTTPS進行訪問，實作HTTPS訪問需要配置SSL證書，這是一個比較復雜的程序，你需要為每一個服務申請一個證書，該證書由第三方受信任的機構頒發，證書有一定的有效期，過期之后需要更新證書，使用云托管平臺可以簡化這個程序，它默認就支持HTTPS訪問機制，

　　資料的加密還包括對靜態資料的加密，所謂靜態資料，就是指存盤在硬碟上的資料，任何保存在硬碟上的資料都應該被加密，許多云提供商都提供了標準的靜態資料加密服務，所以我們無需自己花時間去配置和管理加密密鑰，需要注意的一點是，不應該僅僅對正在使用的靜態資料進行加密，任何備份的資料也應該被加密，

身份認證

　　僅僅對資料進行加密是遠遠不夠的，我們還需要確保所有的HTTPS請求是安全的，換句話說，我們需要知道請求者是誰，他們是否獲得授權以訪問我們的服務，最常見的實作身份認證的方式是在每一個HTTP請求中包含一個Header，其中帶有用來識別用戶身份的用戶名和密碼，這種方式被稱為基本身份認證方式（Basic authentication），例如用來實作用戶登錄的功能就可以使用此方法，但是這種認證方式會暴露用戶的密碼，而且微服務代碼中如果對用戶的密碼處理不當，也會帶來一定的安全隱患，因此這種認證方式并不推薦，

　　還有一種方式是為微服務的每個客戶端提供自己的密鑰，然后客戶端在HTTP請求頭中包含API密鑰，但是這種方式帶來了密鑰管理上的問題，一旦密鑰管理程式受到攻擊或者密鑰被泄露，后果也是非常嚴重的，

　　另外一種方式是使用客戶端證書，通過使用公鑰加密，證書為我們提供了一種非常安全的身份認證方式，不過，證書的安裝和管理也會帶來一些的問題，最好的方式是按照業界標準在微服務中實作身份認證，例如OAuth 2.0和OpenID，這通常是通過授權服務器（Authorization Server）來實作的，在eShopOnContainers中，這一部分的功能包含在Identity微服務中，首先，客戶端通過發送某種憑據向授權服務器進行身份認證，如果認證通過，授權服務器回傳一個有限時間的訪問令牌（token），然后，客戶端將該令牌放在HTTP請求頭中訪問微服務，由于令牌使用了公鑰加密進行簽名，所以授權服務器可以驗證令牌的真實性和有效性，因為OAuth 2.0和OpenID都是行業標準，有很多現成的第三方組件和服務可以直接使用，所以你不需要自己來實作，例如示例程式eShopOnContainers中使用了名為IdentityServer4的開源產品，

授權

　　身份認證用來告訴我們訪問者是誰，而授權的作用是知道可以干什么，例如，當用戶登錄到eShopOnContainers時，他有權查看自己的歷史訂單，但無權查看其他用戶的歷史訂單，許多Web API框架都內置了授權機制，用于檢查用戶的角色和權限，例如eShopOnContainers中使用的ASP.NET Core框架，

　　對于微服務提供的每一個API，我們都應該認證考慮哪些用戶可以被訪問，哪些用戶不能訪問，在微服務中，有一種特殊的情況我們需要特別注意，假設用戶Mark通過了身份認證并成功訪問了Ordering微服務的某個功能，而該功能又會呼叫另一個微服務，例如Payment微服務，Ordering微服務知道當前訪問的用戶是Mark，并知道Mark可以執行哪些操作，但是當Ordering微服務呼叫Payment微服務時，由于Payment微服務信任Ordering微服務，它假定所有來自Ordering微服務的請求都是安全的，所以可能會存在某種安全隱患，使得用戶Mark能以某種方式欺騙Payment微服務而使用其他用戶的信用卡來支付自己的訂單，解決方法就是當Ordering微服務訪問Payment微服務時也需要同時傳入用戶Mark的訪問令牌，用來告訴Payment微服務最終的用戶身份，如果Payment微服務識別出請求者不是Mark用戶，則請求被拒絕，這樣可以有效地避免Payment微服務的呼叫被欺騙的問題，

網路安全

　　我們可以使用防火墻、IP白名單和虛擬網路等網路功能來共同保護我們的微服務，下圖中，我們可以看到其中有三個相互通信的微服務，如果我們將其放到虛擬網路中，那么我們就有能力拒絕任何來自虛擬網路外部的訪問請求，而只允許微服務之間彼此進行通信，這種方式可以很好地保護后端服務的網路安全，這些微服務可能只需要在它們之間進行通信，而不需要從外部直接訪問，但是，如果確實存在需要從外部直接訪問微服務的情況呢？例如，一個單頁面應用程式（SPA），它可能需要直接訪問某個微服務，這是否意味著我們需要放開虛擬網路對外部請求的限制而允許訪問某些微服務呢？有關這一點我們在前面“微服務通信模式”一節中已經討論過了，一個好的實踐方式是使用API網關將外部請求與虛擬網路中的微服務隔離開，這樣我們就可以非常有選擇性地確定哪些API可以從外部訪問，哪些API不能從外部訪問，而且，單一的訪問入口也有利于對API網關配置防火墻，以防范DDOS攻擊和SQL注入等，

　　通常，在微服務應用中，有一個面向公眾的網站，例如eShopOnContainers網站，但同時可能還有一些其它的應用只面向一小部分用戶，例如針對系統管理員訪問的系統后臺管理程式，或者專門針對市場部進行營銷活動的頁面等，對于這部分應用，我們希望只有特定的用戶才能訪問，而不是對公眾開放，我們可以通過IP白名單的方式只允許來自特定IP地址的請求（例如系統管理員或市場部用戶的IP地址），而拒絕來自其它IP地址的請求，

　　微服務的安全涉及到多方面的技術，而不僅僅是其中的一兩個，為了保證后臺服務的安全，我們應該避免僅僅依賴單個的保護機制，而應該盡可能地使用多層安全保護，這就是所謂的縱深防御機制，

縱深防御機制

　　前面我們談了有關微服務安全的許多方面，包括對資料進行加密、對用戶進行身份認證、授權用戶只訪問允許的資源、通過使用虛擬網路和IP白名單拒絕來自未經授權的網路請求等，縱深防御指的是我們不應該只依賴于其中一種技術來保護我們的應用程式和服務，這是因為一旦某一個防御被突破，那么攻擊者就可以免費獲取到所有資料，我們需要結合多種不同的安全措施來保證我們資料的安全性，從而盡可能地降低資料泄露的可能性，處理的資料越敏感，所需要的防護也就越多，除了上面提到的一些安全防護機制外，還有一些額外的防御措施，

　　黑客們會使用各種非常復雜的工具和技術來入侵和破壞我們的服務和應用，對于開發人員而言，了解這些攻擊技術可以有效地采取一些防護措施來阻止攻擊，我們可以安排資訊安全專家對應用程式進行滲透測驗，這可以知道我們的應用程式是否能夠防御最先進的黑客技術，同時專家也可以提供一些有關如何提供應用程式安全性的建議，另外，創建自動化測驗來驗證安全性設定是否正常作業并有效，而不要僅僅假設我們已經進行了正確的網路和安全設定，可以有針對性地進行一些安全測驗，例如用未經授權的用戶訪問API，還可以檢測攻擊行為何時進行，例如嘗試多次重復登錄和HTTP請求、對于敏感檔案的網路釣魚訪問、SQL注入攻擊等，所有這些攻擊都可以實時檢測到，我們可以進行系統報警配置，當攻擊行為發生時，系統可以主動做出回應，例如阻止攻擊者的IP地址請求，或者暫時關閉系統的部分功能以防止攻擊等，最后，我們應該對系統中所有正在執行的操作都記錄日志，這樣我們才可以準確地知道誰在什么時間做了什么，當系統受到攻擊或者資料發生泄露時，才能有機會了解事情是如何發生的，以及哪些資料被泄露，

七、發布微服務

自動化部署

　　在單體應用程式中，部署程序往往比較簡單，而且通過手動就可以輕易地完成，我們只需要將所有步驟和注意事項在檔案中描述清楚，然后按部就班地逐一執行就可以了，但是這種操作方式對微服務而言并不適用，因為微服務需要部署的東西往往非常多，相互之間的依賴關系也比較復雜，而且部署程序相對也較為頻繁，所以我們強烈推薦通過自動化的方式來完成微服務的部署，

　　在微服務的部署中，這一程序被稱之為CICD（Continuous Integration/Continuous Delivery），即所謂的持續集成和部署，那么如何構建一個可以持續集成和部署的自動化程序呢？持續集成從我們將代碼簽入到Github使開始，首先集成服務器會執行一系列的單元測驗，以保證我們簽入代碼的質量是相對可靠的；然后通過CI管道（Pipeline）按照預先定義好的步驟部署微服務，可以將微服務部署到本地虛擬機或者云端；一旦微服務部署成功，就需要進行服務級別的集成測驗；如果測驗通過，接下來就可以將微服務部署到QA環境中進行整個系統級別的測驗，如運行自動化的端到端的測驗；在正式將微服務投入到生產環境之前，通常還需要一些額外的準備作業，如進行一些必要的手動測驗、執行風險評估掃描、相關簽署作業等；最后，我們將準備好的release發布到生產環境，一個完整的流程看起來像這樣：

部署環境

　　通常，我們希望微服務能夠被部署到不同的環境中，開發人員希望將微服務部署到本地虛擬機，以便在開發程序中能夠在本地除錯代碼，同時我們還需要有一個測驗環境，能夠在其中對微服務進行端到端的測驗，并且QA小組也希望能夠在測驗環境中進行一些必要的手動測驗，有時，我們可能還需要專門用于滲透測驗和性能測驗的環境，除此之外，我們還需要生產環境，這是我們的微服務最終運行的環境，也是我們交付給客戶能夠真正使用的環境，不言而喻，生產環境是最重要的，在某些情況下，我們可能會有多個生產環境，比如為不同的客戶準備不同的生產環境，在不同的地理區域中準備不同的生產環境等，因此，引數化我們的自動化部署腳本非常有必要，這可以使我們的部署程序盡可能簡單，我們可以使用JSON或者YAML為不同的環境定義不同的引數，當然，也可以使用各種工具如Docker Compose或者Kubernetes來獲得更加成熟的解決方案，

構建注冊表（Artifact Registry）

　　將構建工件（Artifact）存盤在某種注冊表中可以使我們非常方便地部署微服務的任意版本，從而使得我們可以輕松地將微服務回滾到之前的某個特定版本，示例應用程式eShopOnContainers選擇將每個微服務構建為Docker容器鏡像，這樣做有很多好處，其中之一是版本命名的標準化，并且可以存盤在容器注冊表中，當我們使用Docker來進行部署時，操作會變得很容易，例如名稱“eshoponcontainers/orderingservice:1.3.1”代表eshop應用程式中ordering微服務的1.3.1版本，由于eShopOnContainers應用程式使用容器作為交付機制，因此它非常適合使用Kubernetes，如果我們使用Kubernetes集群，那么可以通過YAML組態檔來定義應用程式中所有的微服務，Kubernetes是基于狀態策略來運行的，組態檔定義了哪些微服務需要運行以及如何進行設定，Kubernetes將組態檔中的內容與集群上的組態檔進行比較，如果不一致，則相應地添加或洗掉容器，直到運行的內容與所要求的內容相匹配，所以，對于微服務版本的升級，或者其它任何屬性的改變（例如環境變數或者副本數量等），只需要更改組態檔即可，有關Kubernetes的詳細介紹可以參考官網網站的說明，

獨立升級

　　在前面的章節中，我們討論過微服務之間松耦合的重要性，我們不希望單個微服務的升級同時依賴于其它的微服務，我們的自動化流程可以一次性部署所有的微服務，但是一次只能更新（或升級）一個微服務，如何對單個微服務進行升級是一個值得思考的問題，你可能會想，不就是停止服務，更新，然后再重新啟動嗎？如此簡單的步驟還需要大費周折嗎？當然，如果你不想服務被中斷，這個方法當然行之有效，不過，在生產環境中，某些微服務是不允許被中斷的，我們應該通過技術手段盡可能地在微服務的升級程序中減少或者避免停機時間，

　　一種有效的方法是同時運行新舊兩個版本的微服務，然后通過負載均衡將流量從舊版本移動到新版本，這樣升級程序中不會有停機時間，客戶幾乎不會感覺到升級程序中的任何停頓，

　　另一種方法是同時運行多個微服務的副本，然后逐個升級替換，例如有三個V1版本的微服務實作負載均衡，我們可以每次添加一個V2版本的新實體并同時洗掉一個V1版本的實體，直到所有的V1被替換成V2，并最終完成對整個微服務的升級程序，但前提是兩個不同版本的微服務之間能夠兼容，值得一提的是，Kubernetes集成了許多高級的升級策略，你可以查看官方檔案并使用這些策略，

　　另外還需要考慮的一個問題是，當升級出現問題時，我們可以無縫地回滾到之前的版本，Kubernetes同樣可以非常輕松地幫我們解決這一問題，回滾操作只需要更新組態檔使其指向之前版本的標簽即可，

監控微服務

　　微服務的一大挑戰是我們需要監控的東西非常多，一個微服務可能同時在多個不同的服務器上以多個不同的行程運行，所以通過手動的方式連接到這些虛擬機集群中的每個作業節點來檢查和查看作業日志幾乎變得不可能，而我們需要的是通過一個系統來自動監控和管理這些日志，管理員可以在一個集中的地方操作和查看這些日志，通常，這個系統會有一個稱之為儀表盤（Dashboard）的界面，能夠讓我們實時了解系統的整體運行狀況，并在出現問題時報告具體原因，通常，它分為這幾個部分：

• 主機指標，包括CPU和記憶體使用情況，通過這些指標我們可以檢測是否需要對主機容量進行擴充以滿足更多的需求，許多云提供商都會提供這一類的監測資料，同時還包括警報功能，當主機運行狀況超過閾值時會自動發出通知（短信、郵件或其它通知方式），
• 應用程式級別的監測資料（Web API），包括HTTP請求數量，以及失敗的請求數量和錯誤代碼等，例如，如果日志中有很多401 Unauthorized的回應代碼，那么很可能我們的服務受到了黑客攻擊，或者存在錯誤的配置項；如果日志中有很多500的錯誤代碼，那么表明我們的代碼中存在某種錯誤，如果使用訊息代理，則需要跟蹤并查看訊息佇列中是否存在大量的死訊息，以表明我們的程式是否在處理訊息時遇到了問題，另外，一個好的實踐是讓每一個微服務都支持端點檢查，這是一個特定的Web API，允許定期被呼叫來檢查微服務運行是否正常，當它被呼叫時，只需要回復是否OK即可，用以表明服務是否啟動并作業正常，同時它還可以回傳一些額外的資訊，例如該微服務所依賴的下游服務是否正常作業等，
• 易于訪問的日志檔案，每個微服務都應該記錄日志，我們需要將這些日志集中到一個地方，以方面查看和管理，使用容器的好處是可以通過一種標準化的方式來捕獲日志，并將日志集中到一個統一的地方，有許多第三方的開源產品可以幫助我們實作這個功能，例如可以將日志發送到Elasticsearch，然后使用Kibana查看日志，或者在Microsoft Azure中使用Application Insights，許多云托管平臺也提供了很多易于啟用的監控和日志功能，

標籤：架構設計

上一篇：如何做好垂直域穩定性

下一篇：返回列表