引言

單體應用已經無法適用於雲的高可用、可擴充套件的特性，對於網際網路應用來說，將傳統的單體應用進行微服務化改造後並上雲（不論是私有云還是公有云），就成為了遷移到雲原生應用方案的不二之選。

微服務簡介

微服務的這個詞出現已經有幾年了，隨之產生的元件也有不少，微服務可以抽離出那些大家都會關注的問題，並將它們進行元件化，很多元件聚合到一起就行成了一套微服務框架，目前比較成熟的微服務框架和機構有很多，比如：Spring Cloud,CNCF等。那麼微服務框架當中都有那些元件呢？下面展示一張圖來讓大家有一個整體的認識。

1.服務閘道器

將後端的多個服務變成黑盒，對外只暴露唯一的服務閘道器，閘道器根據路由配置將外面訪問的請求轉發到具體的某一個服務上。一些成熟的閘道器元件其實除了路由功能以外，還集成了諸如，許可權驗證，服務註冊/發現/負載均衡，熔斷,限流和降級的功能。

2.許可權驗證

若想要請求後端的微服務，需要對請求進行相應驗證，第一次訪問時根據相應的授權憑證（例如:使用者名稱/密碼），到授權服務那裡進行許可權鑑定，若鑑定成功，根據相應的加鹽加密演算法會生成一個Token串，下次請求再來時需要攜帶此Token串，授權服務會對Token串進行解密校驗，該Token串是唯一的，並且可以標識使用者的身份以及儲存一些profile資訊。

3.服務註冊/發現/負載均衡

每個微服務啟動需要到註冊中心那裡去註冊自己，將自己的地址以及服務名告訴註冊中心，若要實現基於效能的負載均衡，同時還要上傳自己的CPU,記憶體等資訊給註冊中心。當需要消費服務時需要先到註冊中心那裡根據服務名來獲取提供服務的服務地址。每個服務一般會註冊多個例項，一般會根據一些策略（wrr，round robin等）來挑選具體某一個服務例項，註冊中心需服務例項會保持著心跳機制，若服務例項掛掉就會從註冊中心消失，因為註冊中心沒有繼續收到服務傳過來的心跳資訊，則會判定該服務死亡，那麼就會從服務列表中將其刪除。

4.限流/熔斷/降級

熔斷其實類似日常生活中的“保險絲”，一個使用者請求的呼叫，在微服務內部可能是多個服務之間的連環呼叫，若其中一個或幾個服務產生了系統瓶頸，就會導致超時，這樣會阻礙整體呼叫鏈的呼叫進度，從而導致整個系統連線數過多，造成系統癱瘓，那麼熔斷要做的就是當發現某一服務的錯誤、超時、負載，達到某一指標時候來攔截後續的請求。當服務產生熔斷後，那麼就需要對服務進行降級，降級可以立即給使用者一個返回，及時的返回空白內容或是錯誤資訊。顧名思義限流就是限制請求的qps，將請求的數量控制在該服務可以接受的範圍內。

5.訊息中心

它在微服務中起到了很多作用，利用訊息的訂閱釋出可以解決分散式最終一致性的問題，而且也可以實現服務之間的非同步呼叫，讓服務與服務之間進行解耦。

6.分散式跟蹤

分散式微服務中，對外暴露的使用者請求，在微服務內部可能會是服務之間互相呼叫多次的結果，某一個請求超時或出現錯誤，我們都需要了如指掌。目前一些開源元件也有很好的實現，主要就是根據連結串列的資料結構，對整個呼叫鏈進行唯一的TraceID標識，每個呼叫節點也有自己的SpanID和上一個呼叫節點的ParentID,ParentID為Null時就是起始呼叫節點。每個節點會儲存相應的資訊，包括客戶端發起請求時間，服務端收到請求的時間等等。預設這些資訊都會存入記憶體中，也可進行資料持久化，然後通過WebUI檢視整個呼叫鏈的詳細資訊，便於分析。

7.REST/RPC/序列化

微服務中，無論是對外暴露的介面，還是服務之間互相呼叫的介面，都離不開通訊協議與序列化。通訊協議有我們所熟知的http, soap, websocket,rpc等，序列化有json,xml,protobuf,bytes,text等。對外提供服務的介面一般都會使用http+json的方式，服務內部之間呼叫的話通常會使用rpc+prtobuf的方式，rcp是二進位制的，它比http傳輸效能要高，而且protobuf的序列化/反序列化效能同樣比json的要高，http是可以跨語言的，沒有語言的約束，但rpc對語言是有一定約束的，雖然如此但目前有很多成熟的rpc框架以樣也可以實現跨語言。

8.統一配置管理

微服務自然會有很多個小服務，若每個服務都有自己的一些配置，那麼運維起來簡直就是噩夢，所以統一的配置管理是必要的，目前有一些成熟的開源的框架都可以做到，有了配置中心，我們就可以根據不同環境應用不同的配置，多種配置都可以存到git中，進行版本控制，根據路徑規則匹配不用的配置。同樣也可以支援熱更新，無需重啟服務。

9.CI/CD

持續整合與持續交付，快速的迭代是微服務所需的，服務多了本來就複雜，而且服務之間的介面變更和新功能的新增都會比較容易造成互相制約，若不採用持續整合與交付的話，那專案進度就會被拉的很長，目前CI/CD比較好的實現方式就是，git + jenkins + docker, git負責原始碼版本控制，jenkins進行自動化的打包，編譯，測試，部署，這裡部署我們可以使用docker容器，也可以不使用，直接放到物理機上執行，主要還是看專案的底層架構

10.日誌

分散式的微服務，每個服務都會產生日誌，那麼當要分析問題時我們肯定不會每臺機器的去檢視日誌，這也會是一場噩夢，好的辦法就是收集聚合所有服務的日誌，然後彙總到一起，根據服務名，TraceID,IP等一些關鍵字進行過濾來找出有用的日誌。ELK就是解決此類日誌問題的利器。

11.監控

單點應用定位問題相對來說是比較好定位的，但是服務多了，微服務之間互相的介面互動，哪個節點出現了問題都需要快速定位到出現問題的點，若微服務執行在容器當中，我們同樣要考慮容器的監控，以及app的日誌監控，同樣還有app的業務監控。

以上已經把微服務的大部分功能模組做了一個簡明扼要的闡述，那麼下面我們就來仔細聊聊微服務的監控。

微服務的監控

對於微服務系統來說，相對比較複雜的是監控，容器編排，還有日誌收集，容器編排目前有很好的實現，比如Kubernetes,Swarm,Mesos,等等，這些都解決了容器的編排問題，這裡之所以提到容器編排，是因為微服務的落地比較好的實現方式就是執行在容器當中，多虧了這些開源元件的存在，很多微服務所要考慮的問題都被整合到這些平臺中了。那麼對於這種多說上千萬個虛擬容器的大叢集來說，監控到底怎麼實現呢？

基於容器的微服務監控大致可以分為，容器與宿主機的監控(基礎監控)，API監控，呼叫鏈監控以及應用本身的監控，那麼接下來就簡單的說一下這幾種方案。

1. 容器與宿主機的監控

基於容器的微服務監控和原始的監控是有很大區別的，因為服務的例項生存週期很短，分分鐘可能就會有容器的生滅。微服務的容器與宿主機的監控離不開CPU,記憶體,磁碟,網絡卡這些基礎的效能指標，對於宿主機的監控來說，我們可以依然使用原始的監控方式，每個宿主機安裝一個代理來採集伺服器的效能指標，代理在採集效能指標的時候可以打上時間戳和相應的標籤來區分不同效能指標的資料維度（metric），然後將監控資料彙總到時間序列資料庫，裡面的資料可以對接目前一些開源的元件來進行視覺化的展示，也可以對接報警服務（結合報警服務的報警策略）進行報警。容器的監控自然就和宿主機不太一樣了，我們不能說給每個容器映象內部都整合一個監控代理（agent）,這樣的話侵入性太強, 不易於維護。目前有比較成熟的開源產品Prometheus，它有很多的Exporter可以用來採集監控資料，例如我們想採集Kubernetes上所有容器（pod）的效能指標的話，Promethus可以通過直接配置多個Kubernetes ApiServer的Endpoints來監控整個Kubernetes叢集。

2.API監控

微服務對外暴露的api都是經過服務閘道器來訪問的，那麼我們可以在閘道器上對這些api進行流量的分析與監控，二手手遊賬號地圖監控api的訪問量，api的響應體狀態碼，當某些指標達到閥值時我們就可以進行報警，目前也有很多開源的產品可以使用，例如Kong，它可以安裝很多功能性外掛，其中就有dashboard外掛，以及監控外掛。

3.呼叫鏈監控

有了對整個微服務呼叫鏈的監控，我們就會有一種一覽全域性的感覺，對整個微服務叢集的部署情況，以及執行情況瞭如指掌，可以很快的定位問題，協同開發人員進行效能調優，量化運維部門的價值。目前有谷歌的Google Dapper但是沒有開源只有論文，Zipkin,OpenTracing,這些都是根據谷歌的論文開發的開源產品都很不錯。

4.應用本身的監控

微服務應用本身的監控的方式就比較多樣了。這裡我就說一下我自己基於Kubernetes實現的微服務應用級的監控外掛，先上個圖：

在Kubernetes的master節點，也就是安裝apiserver的那臺伺服器上執行一個監控外掛，該外掛可以通過一個kubernetes提供的官方客戶端來訪問apiserver,首先我們要告知外掛要監控哪個namespace下的哪個service，然後，外掛通過和apiserver進行互動獲取某個service下所有Pods的例項，外掛會併發訪問所有pod提供的/metrics介面（Path可配）,並給每個pod的返回資料（json格式，遵守一定的資料格式契約）打上pod_name的標籤來標識每個pod返回的metrics，打上pod_name標籤的同時也會打上service_name的標籤用來區分具體是哪個service的監控資料。通過外掛收集整理後的資料會上傳到時間序列資料庫中，後續就可以根據資料進行視覺化分析以及展示（Granfana），同樣若是結合開源監控Prometheus,OWL也可以實現監控報警，只不過結合不同的監控需要返回它們所需要的監控資料格式罷了。

最後

微服務目前也是在如火如荼的發展著，隨之產生的技術棧和開源元件也是百花齊放，到底什麼樣的方式和元件是最適合的，這些都是仁者見仁，智者見智。技術無好壞，用的順手合適就可以，解決相應的問題用合適的方法和武器，知己知彼，不一定所以的問題都要使用微服務來解決，殺雞焉用宰牛刀。以上是鄙人的一些拙見，閱讀了一些技術性文章和書籍加上自己的一些理解所總結，希望能給那些還沒有走進以及即將走進微服務的人帶來一絲啟發。