瞎幹，就完了！邁好微服務化的第一步

子曾經曰過：工欲善其事，必先利其器。要作微服務架構的轉型，不是「幹就完了」，而應該「謀定然後動」。以前咱們談到過，微服務化的轉型是一個量變引發質變的過程，這就意味着微服務轉型不是逐個拆分和替換就能解決的，微服務化轉型的難點在於統一管理控制。

那麼，對應前兩篇文章中提到的微服務轉型的煩惱和誤區，怎樣經過統一管理解決微服務化難點，咱們認爲要作到如下四點：

1. 統一應用服務管理：將敏態、穩態的全部業務系統、全部不一樣框架的應用服務統一管理和展現，這是建設的最基本目標，也是最核心的目標，其餘的所有圍繞這裏展開。

1. 統一權限控制管理：這裏的權限控制是指服務間調用的訪問權限控制，經過不一樣的控制維度，最終達到穩態、敏態、異構框架、異構協議間的訪問，作到服務間通訊的自由控制和動態生效。

1. 統一技術架構規範：儘管現狀是極其的五花八門，可是咱們的最終目標仍是想要統一技術架構。目前包括銀行在內的較多的企業機構，都存在 SOA、獨立的單體應用系統、獨立的通訊協議和報文，也許還有 SpringCloud 的微服務和 Dubbo 的微服務並存，可是無論有多少種架構和體系，咱們要作的就是先兼容，後統一。那麼在統一以前，咱們須要先立規範。

1. 統一設計服務化系統：這裏就涉及了容易「談虎色變」的拆分問題，拆分首先是總體的考慮，功能模塊的複用率、業務量、獨立性，都是考量的範圍。服務化的將來是中臺，獨立的考慮某一個業務系統，對中臺化毫無幫助，因此須要統一的設計和建設，這也是雲原生的基本理念。

這「四個統一」基本上已經覆蓋了微服務化建設的全部工做。那麼這四個統一應該從哪裏入手呢？

應用服務的管理依賴於服務發現，微服務間訪問控制依賴於通訊架構，服務發現和通訊架構基本上被微服務框架所決定。所以微服務建設的第一步就從微服務框架入手，制定統一的微服務架構和通訊規範，用於新系統的建設，對於老系統就一邊逐步改造，一邊兼容現狀。

接下來進入本文的重點，統一技術架構規範須要從如下方面開始建設：

01

微服務

統一微服務框架規範

首先，微服務多數是須要依賴於微服務框架的，說「多數」是由於在微服務的理念下，只要是分佈式的、獨立運行又互相依賴的應用服務，均可以叫作微服務。這裏微服務框架提供了一些功能的便利，如服務發現、服務間通訊、負載均衡策略等通訊治理的功能。所以，微服務框架的選擇會影響到註冊中心和通訊協議的選型。

這裏有必要羅列一下目前使用較多的兩種框架 SpringCloud 和 Dubbo： SpringCloud上手比較簡單，通訊採用 http 協議，配套組件很豐富，並且社區比較活躍，比較適合數字化轉型中的企業使用；若是選用 Dubbo 框架，則服務間通訊協議爲一種基於 RPC的 Dubbo 協議，配套的組件較匱乏，社區曾停更過一段時間，可是使用習慣的人在編程時很舒服，服務間調用跟工程內調用沒有差異，比較適合 Dubbo 老手使用。另外，使用 SpringCloud 框架，在作能力開放場景中，http 的協議更容易發佈在 OpenAPI上，Dubbo 則不得不增長協議轉換。

總之，須要先肯定好企業級微服務框架及版本，並推行企業內部適配和使用，以此規範通訊協議。

02

微服務

統一註冊中心建設

微服務間通訊依賴於註冊中心的服務發現，微服務經過註冊中心尋址，才能實現服務間互訪。在微服務化建設過程當中，統一註冊中心的建設會遇到不少複雜的狀況，如跨網絡、跨業務域等問題會增長建設的難度。

註冊中心的健康檢測功能須要與應用服務作通訊鏈接，所以註冊中心的搭建須要考慮企業內部的網絡現狀。一般的解決方案是每一個網絡區域建設一套註冊中心，固然若是考慮其餘的因素，也能夠將註冊中心之間打通。

那麼在同一個網絡區域內，若是須要業務域的隔離，就不適合再部署多套註冊中心去解決了，那樣會增長管理和建設難度，而且極大的增長資源的消耗。解決方法跟具體使用的註冊中心有關，咱們以 SpringCloud 框架爲例，註冊中心能夠選擇 Eureka、Nacos、Consul，分別看一下對應的解決辦法：

Consul 中能夠劃分數據中心，經過 token 劃分權限，以此區分不一樣的業務域，可是 Consul 註冊中心在中國已經漸漸要走下舞臺的趨勢；

Nacos 中有叫作 namespace 的概念，將註冊的服務劃分開，可是 namespace 的功能須要使用 mysql 存儲；

Eureka 卻沒有相似隔離，或者劃分區域的功能，可是咱們依然能夠經過訪問控制，經過白名單的方式阻止業務域間服務的互訪功能。

註冊中心的建設就暫且記錄這些。

03

微服務

統一配置中心建設

微服務的使用一直離不開配置中心，建設統一配置中心與建設註冊中心較爲相似。在組件選型上也較爲簡單和統一，多數都使用攜程 Apollo，功能比較強大，能夠適合各類場景。固然也有使用 SpringCloud 全家桶中的 config 組件的，可是做爲全企業統一的配置中心，組件仍是使用 Apollo 較好。

做爲統一配置管理的功能組件，Apollo 仍是比較好用的，可是做爲企業級微服務建設的一部分，服務配置的使用場景就有點不恰當。從使用方法上來講，在 Apollo 中建立一個 APPID，也就是一個配置單元，至於這個配置單元是做用於一個微服務，仍是做用於一個業務域，在 Apollo 中沒有概念。

所以，咱們基於攜程 Apollo 組件做爲配置的基礎原件，真正的業務功能是須要在應用服務管理平臺中實現的。

04

微服務

統一觀測平臺建設

觀測應該至少包括監控、鏈路、日誌，那這裏的統一觀測是指的統一監控平臺嗎？其實不算是。微服務建設中觀測平臺是必須建設的一部分，其主要關注點在於服務間通訊中的性能監控、服務間調用拓撲、業務調用鏈追蹤，以及業務調用中的業務日誌，固然還有性能的告警。這些在微服務運行觀測中必不可少，但與統一監控平臺還有些差距。

如今有不少 APM 廠商能夠提供微服務的相關監控，包括資源、性能、瀏覽器、線程、app，固然也有拓撲圖、鏈路圖等等。其實剛剛介紹的這每個建設模塊，若是作到極致均可以單獨做爲一個項目建設，好比以前咱們基於 gRPC 自研的微服務框架，好比在某銀行作的微服務配置管理中心等等。

APM 更是不少企業單獨立項的，可是在這裏可能不太適合。由於咱們的主要目的是微服務的運行觀測，那麼微服務運行狀態數據來源是註冊中心，運行性能數據來自 APM，運維策略基於配置下發，依賴於配置中心作運維反饋。那麼這三方面的數據在註冊中心註冊的是服務名，在 APM 中是手動輸入的業務名，在配置中心是 APPID，只要三個名字對不齊，就會對使用形成必定的難度，而後就會被廢棄不用。

所以，觀測平臺的建設目標就是必定要「觀」起來，因此須要與統一應用服務管理共同建設。

最後總結下，微服務框架、註冊中心、配置中心、運行觀測都是微服務的工具組件，這四個組件的搭建奠基了微服務改造的技術規範和運行治理規範，所以這是微服務建設的第一步。基於這幾個工具組件建設的統一應用服務管理，將是微服務化項目建設的主要內容，咱們將在下一篇文章中作詳細介紹。

點擊BoCloud博雲瞭解更多解決方案