前文說了一下《什麼是微服務》，在文末提到，初創團隊不建議直接使用微服務，對於初創團隊，最根本的是活下去，而想要使用微服務，需要有很多基礎建設。本文就來說下，微服務都需要哪些基礎建設。
需要說明的是，下面這些組件，都是基於服務太多這個前提。
微服務的出現是爲了研發效能的提升：相同的人數可以處理更多的需求、維護更多的產品，可以更快的交付產品。基於這點，微服務的基礎組件，就從解放人力，減少人爲失誤出發。
1 容器
1.1 運行容器
服務運行的容器是支持服務提供對外訪問的基礎，根據微服務的要求，每個服務單獨運行的獨立進程中，所需要的運行容器就需要小巧靈活，運行容器可以集成在運行環境中，或者能夠集成在服務可執行包中。
在Java領域，各大廠商都有自己的web容器：WebLogic、JBoss、Tomcat、Jetty等。SpringBoot內嵌了Tomcat和Jetty，默認打包方式是FatJar，jar保證包含了服務運行所有的基礎，可以支持微服務部署的基本要求。
1.2 部署容器
部署容器是服務運行的加成組件，容器的好處在於一套鏡像可以支撐測試和生成部署。這樣做可以避免測試環境沒有問題，生產環境各種報錯的情況。但是想要實現一套鏡像到處運行，還需要集中配置的支持。
而且對於部署容器，最好有一套容器調度平臺，這樣能夠更有效的使用資源。如果沒有，可能用部署容器和普通部署方式，區別不是很大。
2 服務註冊/發現
通常服務註冊/發現是兩個組件，彼此沒有必然關係，但是這兩個組件是成對出現解決相同問題的，所以就歸爲一個。
在單體架構時代，企業內部只有幾個大系統，想要調用其他服務，只需要提前指定IP地址就行了。隨着後來系統模塊化進程，再到SOA架構，到現在的微服務架構，服務已經成百上千，而且隨時可能擴容或遷移服務，如果還是靠手工，不僅浪費時間，而且容易出錯。
最好的辦法就是，服務自己上報位置，然後客戶端自己能夠找到需要調用的服務，這就是服務註冊/發現組件。
3 網關
網關是爲了屏蔽內部細節，爲調用者提供統一入口，接收所有調用者請求，通過路由機制轉發到服務實例的組件。網關不是一個新概念，很多服務代理組件（比如HAProxy、Nginx、SLB等），都可以稱爲網關。
目前在網關上有很多優秀的實踐，將反向路由、安全認證、限流熔斷、日誌監控、灰度發佈等功能放在網關上，將功能前置，簡化微服務功能，讓微服務團隊可以更加專心於業務。
4 授權認證
安全第一，什麼行業都是安全第一。
授權認證是兩個概念：用戶授權和安全認證。用戶授權是指給指定用戶授權訪問資源，然後某個用戶訪問資源的時候，認證用戶是否有訪問資源的權限。兩者配合，共同完成資源的安全保護。業界比較常用的是使用OAuth2協議實現授權認證。
5 配置管理
配置管理和前面說的服務註冊/發現一樣，都是爲了解決服務太多，人工出差這個痛點的。
通常開發人員把配置放在配置文件中，這樣配置不夠規範，配置項追溯都比較麻煩。比較危險的是，涉及到用戶名密碼等一些安全性配置的，又不符合審計要求。而且，一旦需要大規模修改配置，改動時間長，改動之後就需要重新部署，可能對整個產品造成影響。所以就需要一個集中的配置管理服務。
6 日誌收集
日誌是記錄服務運行情況的主要來源，也可以在發生異常情況時還原現場。但是隨着服務的增多，日誌分佈在許多的服務器中，如果不進行聚合，在排查問題的時候，難上加難。
7 監控告警
監控告警不是微服務的專利，當服務集羣或服務器達到一定規模，想要做到7*24不停機、不宕機提供服務，就需要監控告警。因爲微服務的服務規模比較大，會將監控的必要性放大。
7.1 指標
通常監控指標是會從系統、應用、業務等幾個維度進行：
- 系統監控：主要是監控物理機、虛擬機、操作系統的運行情況，主要指標包括CPU、內存、磁盤、網絡等，其他的一些相關的數據包括物理機運行時間、操作系統版本、操作系統內核，這些也是排查問題的一些基本依據。這裏還需要重點說一下網絡，微服務都是通過網絡調用或被調用，一旦網絡出現問題，整個微服務集羣都是不可用的，所以網絡監控需要細化到流量、數據包、丟包、錯報、連接數等指標。
- 應用監控：主要是監控應用的運行情況，包括應用運行時間、http服務端口、服務url、http服務響應碼、http服務響應時間、SQL、緩存命中、TPS、QPS等。對於Java應用，還需要包括JVM運行情況：JDK版本、內存使用（堆內存、非堆內存等）、GC等Java虛擬機運行情況。
- 業務監控：主要是監控一些核心業務執行情況，對業務有一定的侵入性，各個服務的指標不同，各家監控方式也不同，通常是埋碼。比如監控登錄註冊、商品信息、庫存情況、下單、支付、發貨等各個業務。
7.2 健康
一般健康檢查是通過心跳檢測進行的，通常會分爲兩種：
- 一種是建立TCP鏈接，執行ping/pong調用。這種方式需要服務中與監控系統建立TCP鏈接，需要在服務中嵌入監控組件，對服務有侵入。但是因爲其執行效率高，而且針對性強，不會出現漏報的情況。
- 一種是監聽服務端口，這種方式只需要在容器內或者虛擬機增加監控插件，對服務沒什麼侵入，但是由於端口可用和服務可用不是一個概念，所以會出現漏報的情況。
7.3 調用鏈
微服務之間彼此調用，整個的調用鏈路彼此交錯，如果不加管理，很有可能演變成請求風暴。
調用鏈監控是爲了分析系統依賴、請求耗時、請求瓶頸的一種方式。目前，市面上多數調用鏈監控組件都是基於Google Dapper開發的。下面給出調用鏈監控的原理示意圖（因爲調用鏈監控的內容比較多，所以會在後面單獨開一章）：
7.4 異常收集
異常分成兩種，邏輯異常和行爲異常。邏輯異常是說代碼中存在異常邏輯，比如常見的NPE；行爲異常時用戶行爲不可預期而出現的異常，這兩種情況對系統都有一定危害。所以需要收集這些異常情況，並且能夠定位異常發生的位置。異常信息收集主要是爲了定位問題，所以上報的信息一定要全面而且容易定位。所以上報信息中需要保護異常碼，可以自定義一定長度的字符串，便於定位位置。然後是要上報參數，用於還原現場。還要上報異常信息，用來分析異常情況。
8 最後
上面提到的組件，都是爲了更好的管理微服務，減少人肉運維，減少人爲失誤。寥寥數語，難以道盡上述組件的優點，每個組件都需要單獨細聊，這裏就當是個引子。
個人主頁: http://www.howardliu.cn
個人博文: 微服務的基建工作
CSDN主頁: http://blog.csdn.net/liuxinghao
CSDN博文: 微服務的基建工作
