導讀
本篇文章為微服務轉型系列第五篇。
微服務化建設需要做很多方面的改造和適應，比如適應微服務開發、適應敏捷運維、打造專門的微服務團隊，以及符合雲原生指導下的架構設計等。所以微服務化轉型，要做好持久戰的準備，同時亦不可疏忽每一步的決策。
在上一篇文章中（理念指導實踐，釐清微服務建設的主要內容和順序）我們提到微服務化轉型可以先從執行態入手，微服務執行態是微服務化轉型中關鍵的一步，也是最能體現階段性成果的一步，這篇我們將主要總結一下，微服務執行態支撐平臺應該具備哪些能力。
執行態一定具備的能力是管理、觀測、執行和變更，再加上微服務自身關注的治理特性，這樣我們就可以將微服務執行態支撐平臺的基本核心功能整理出來了：
-
應用服務管理：包括應用服務基本資訊、例項狀態、業務關係等；
-
執行觀測：主要是監控、拓撲圖、日誌，當然這都是以應用服務的視角；
-
故障定位：微服務環境下主要依賴於呼叫鏈的追蹤，定位真實場景中的問題；
-
配置管理：無論是服務釋出、服務執行、策略生效，無不需要配置的管理和下發；
-
流量控制：包括限流、熔斷、負載，當然最主要的是訪問許可權的控制。
接下來我們逐條分析一下。
應用服務管理能力
在未搭建微服務執行平臺時，微服務的使用者通常都是研發人員，面對註冊中心中註冊的一堆英文服務名，研發人員至少能區分自己研發的業務服務，對其他的服務也無需關注太多。然而，當微服務的管理者或運維人員檢視全註冊中心的服務的時候，通常會變得無比痛苦。
舉個例子，當我們從註冊中心看到“monitor-provider”（SpringCloud框架下的某個服務）這個服務的時候，除了該服務的研發能準確知道其功能外，其他人只能去臆測這是監控相關的提供資料的服務；如果看到的服務名稱是“com.jrca.purview.sdk.export.session.MonitorProviderService”（ZooKeeper註冊中心的某個服務)，除了經常使用和呼叫該服務的研發之外，其他人則更加難以瞭解其作用，更不用說當註冊中心的服務列表全是這樣的服務名稱時，將會給管理和運維帶來多大的困擾。
所謂微服務治理，不同的人有不同的理解和認知，但是最基本的“理”應該是能讓管理者知道有哪些系統，有哪些服務，每個服務是幹什麼用的，有個便於認知和交流的名稱，這就是管理的能力（很多專案描述為服務目錄，也有一些叫做應用管理）。
這種看似很簡單，很容易的建設，其實才是微服務執行平臺建設中最關鍵和最核心的，因為實際上所有的開源元件都沒有給到我們想要的應用管理能力。我們需要的應用管理能力是這樣的：
-
應用服務的目錄：每個應用服務的最直觀的管理，包括其名稱、功能描述、使用方法，可能還有編號、負責人等資訊的管理。
-
應用服務視角的管理：這個是關鍵，也是執行支撐平臺區別於開源元件最大的特徵。開源的元件只提供功能的實現，比如服務定址、健康檢查有註冊中心，服務配置管理有配置中心，服務效能監控有APM，服務訪問許可權有許可權中心限制，等等。一個服務的觀測，需要同時登入五個平臺、開啟五個介面、核對五次在各個平臺中的ServiceName，最終拿到一個服務的綜合資料。因此，應用服務視角的管理，解決的就是資料和功能的整合展示。
-
應用服務的觀測和治理：依賴於應用服務視角的管理，我們能在當前服務下看到服務的效能資料，同時根據該服務的效能統計和資源佔用，適當的調配限流、熔斷策略。
-
層級分明的結構：通常應用服務都有上層管理結構，比如從部門視角的行政組織結構，或者以業務劃分的業務域結構，總之如果是建設全企業的微服務平臺，就更應該貼合真實的使用場景，靈活的支援多種管理結構和模式。
綜上所述，應用服務管理平臺是集管理、目錄、統計、展示、更改、限制於一體的平臺，從服務的視角整合監控、配置、日誌、策略、告警等功能，又不同於監控中心、告警中心、日誌中心這些大而全的平臺，應用視角下精準定位要求更高，更便於快速檢視。
執行觀測能力
觀測至少應該具備：監控、拓撲、日誌的能力。
微服務層面的監控區別於傳統的監控系統，微服務通常重點關注效能監控，這是由於微服務間依賴關係複雜，導致單個服務的效能可能會直接影響到整體的效能。因此微服務的效能監控至關重要，通過觀測微服務的效能，適當調整服務的例項數、流控策略，以保障整體的健康和穩定。
另外，服務數量增多，業務細化，將導致服務間依賴關係龐雜，很難梳理清楚。因此通過執行中的拓撲圖將真實的呼叫關係展示出來，便於明確服務的呼叫關係，也便於做架構的優化調整。
服務的業務日誌，通常是服務執行觀測中經常使用到的，執行狀況、交易狀況、問題定位都離不開日誌的幫助。
因此，效能的監控、拓撲圖的展示、服務日誌的展示，都是執行支撐平臺的建設範圍。
故障定位
通常微服務執行平臺中，故障定位是最有價值的功能點。如果帶有實時除錯bug的功能，將更會受到開發、運維人員的歡迎。但是功能越有價值，代表的建設難度也越大，因而也可以逐步細化功能來建設。
故障定位，需要從粗到細，逐步鑽取定位。一筆真實的業務，可能會經過很多個應用服務，每個環節的問題都有可能導致業務失敗。那麼一條用於記錄業務呼叫的鏈路，將顯得尤為重要，鏈路會記錄整條業務所走過的每一處痕跡，在哪裡出的問題將會一目瞭然。
如果只是鏈路，對於故障的定位可能還是較為粗糙，通常開源元件也只能做到這一步。而在實際使用中，我們對於故障定位需要更為精準地知道問題出在哪個服務、哪個介面，以及在該介面的呼叫資訊和產生的日誌，甚至需要觀測具體介面呼叫中的執行緒情況，並可以線上除錯。而這則需要將鏈路追蹤、效能剖析、線上運維做整合，提供更好的觀測和定位功能。
配置管理
目前使用較多的配置中心是攜程的 Apollo，配置檔案格式、管理功能都較為全面，通常我們建設時也比較推崇使用。
在執行平臺中，服務的建立釋出、策略下發等工作，都依賴於配置管理，因此平臺也需要整合此項功能。當然建設中由於使用習慣的問題，仍然想要使用原生的Apollo，那麼微服務平臺中的服務與 Apollo 中的專案就有很大的風險不能對應，給使用帶來不小的麻煩，這個細節需要注意。
訪問、流量的治理
微服務框架主要是解決呼叫問題，因此負載均衡、限流、熔斷、訪問許可權等很多與訪問、流量有關的功能，都是微服務最早提出的治理功能。在對標的時候，限流熔斷是微服務的必備，但是生產執行中卻很少有開啟限流策略的。原因很簡單，限流容易導致交易失敗，所以寧可增加伺服器節點，也儘量不開啟限流等策略。
其實限流並不是沒有使用場景，只是微服務轉型初期有點低迷，相比之下訪問的黑白名單控制，就很有用武之地了。介面級別的呼叫控制，將是未來紛繁雜亂的微服務執行中，使用最多的功能。
總結
總結一下，微服務執行支撐平臺其實就是微服務執行中的以服務為視角的管理、觀測平臺，其主要意義在於打破管理者對微服務紛雜、神祕的固有認識，提供更直觀、更透明的微服務管理能力，讓使用者真正掌握微服務的執行細節。