微服務中臺落地 中臺誤區

小結：

一、

微服務中臺不是

/1堆砌技術組件就是中臺

/2擁有服務治理就是中臺

/3增長部分業務功能就是中臺

/4Cloud Native 就是中臺

 

https://mp.weixin.qq.com/s/uuaraAWReOYeZuEJiLs9dw

企業微服務中臺落地實踐和思想之我見

From  朱德明 InfoQ 4/3

微服務和中臺是這幾年很是時髦隨處可見的詞，最早在一批互聯網企業中開始談論和建設，並逐漸的蔓延至一些傳統企業和傳統的 IT 部門，以致於如今在構建信息系統時，不少企業都在說要建一箇中臺，但究竟要建成什麼樣還不是很清楚或者說有些迷茫，筆者在微服務出來的時候也不是特別的明白到底如何建好一個企業中臺，只是跟着感受走，隨着主導和經歷多個項目後，有了本身的部分認識，能夠與你們在此分享。

咱們認爲中颱的意義應該是什麼，不管是技術中臺，業務中臺仍是數據中臺，我想它應該是爲業務和組織而生，爲能更加快速敏捷的響應業務的變化，給公司帶來效能上的提高，價值上的提高，創新能力的加強，進而還能促進人才和組織的優化，這是中臺所存在的意義。

首先在不知道微服務中臺是什麼樣的時候，它必定不是這幾個樣子：

 1. 堆砌技術組件就是中臺

 

 

只堆技術組件，微服務中臺或者說企業中臺只包含經常使用的技術組件，好比使用 spring cloud 微服務框架，再加上 MQ,Redis, quartz,nginx,activity,servicemesh,docker 幾個組件以後認爲這個就是企業的中臺，要什麼技術能力拿過去用便可，說法其實並無錯，只是站的角度不一樣，確實是能力的抽象，封裝和開放，但並非純粹的堆砌技術組件。

 2. 擁有服務治理就是中臺

 

爲 spring cloud 這樣微服務開發框架加強了服務治理的能力，而後在綁定上業務就是技術中臺或者中臺。

這樣的見解不是徹底正確，這隻能表明在技術的基礎底座和支撐上前進了一步，還遠遠不夠。

 3. 增長部分業務功能就是中臺

對老系統增長新功能確實是構建中臺道路上必須經歷的一件事，但若是隻是單純的從增長新功能角度出發而不是爲了能力組件化，服務化，封裝和開放，協同做戰的思想去建設，那麼只是給老系統增長負擔而不是減負。

 4. Cloud Native 就是中臺

Cloud Native 是目前比較火的領域，不少企業認爲作了微服務，容器，DevOps 就已經構成了中臺體系，這也是比較片面的見解，只能說有了這三大塊，對於構建中臺體系有了一個很好的基座，但真正的中臺還並未出現。

 

@/先從技術中臺方面來探討一下技術中臺的落地建設，後續咱們再來討論業務中臺。/

剛剛上面咱們認爲中颱應該不是什麼樣子，那到底中臺應該是什麼樣子，有什麼價值，就如咱們上面所說，它必定是爲業務和組織而生，你能夠從不少角度去解讀它，本篇文章咱們結合在新項目建設中，咱們先從技術中臺方面來探討一下技術中臺的落地建設，後續咱們再來討論業務中臺。

 技術中臺

以下圖，我先把技術中臺分爲這幾部分，固然它包含很大的範圍和其餘的角度，但咱們能夠根據這幾點展現出部分技術中臺思想：

1. 容器平臺，虛擬機

2. 微服務框架 (分佈式服務框架) && 微服務管理控制檯

3. 技術組件

4. 公共基礎服務和技術服務

5. DevOps&&AIOps

6. 效能

 

  容器雲，虛擬機

虛擬機和應用上雲對 Iaas 廠商有了更高的要求，不只在穩定性和可用性方面要有出色的表現，更加應該在易用性和便捷性方面展現出強大的功能，這方面必須能提供具備豐富功能和配置的 UI 界面，它有助於咱們在 Iaas 的配置和運維層面減小工做量，優化人員配置，提升咱們對 Iaas 的掌控能力，這是一個有和優的問題，另外對於廠商的選擇和團隊的選擇，必定是要能及時響應的。

虛擬機和應用上雲對 Iaas 廠商有了更高的要求，不只在穩定性和可用性方面要有出色的表現，更加應該在易用性和便捷性方面展現出強大的功能，這方面必須能提供具備豐富功能和配置的 UI 界面，它有助於咱們在 Iaas 的配置和運維層面減小工做量，優化人員配置，提升咱們對 Iaas 的掌控能力，這是一個有和優的問題，另外對於廠商的選擇和團隊的選擇，必定是要能及時響應的。

對於採用了容器的廠商，起碼要在這幾方面須要作好，集羣的管理和調度，網絡方案，服務編排，日誌方案，存儲方案，應用和服務的管理，容器的監控和告警，鏡像倉庫的管理，鏡像的打包和構建，用戶的權限，優秀的 UI 操做界面等等。

一樣的對於容器，若是它是一個優秀的產品，那它還應該是這樣的：

1. 充分開放的和可擴展的接口。

2. 能夠和多個產品進行對應快速，如微服務產品。

3. 豐富和體驗方便的 UI， 高度集成功能的 UI，可見便可得。

4. 充分的對接 DevOps 文化，豐富的 CICD 流程，鏡像一鍵打包。

5. 容器應用與非容器應用通訊，跨集羣通訊。

6. 優秀的監控體系。

7. 等等。

這部分的能力是讓整個技術中臺有一個好的基礎設施層支撐，能快速的進行應用的部署和交付，出問題時能迅速定位和恢復，下降 MTTR, 並能充分的利用現有資源進行合理的分配，讓技術和業務下降耦合，劃分出業務實現者與技術支撐的 BC，關注各自的領域，因此你須要一個很是靠譜和好用的底層支撐。

 微服務框架 (分佈式服務框架)  && 微服務管理控制檯

對於傳統老應用而言，它多是傳統的單體應用，整個系統的功能都融合在一塊兒。它們在迎接需求劇烈變化和傳統開發迭代方面遇到了瓶頸，那麼在轉型時就會考慮服務化的架構，在作服務化架構時，咱們就須要一個完整而健全的分佈式服務化框架來幫助咱們，諸如 Pivotal 的 Spring Cloud 框架。

但這裏要提醒的是，若是你要打造一款真正的技術中臺，我認爲一個純粹的 Spring Cloud 的框架是很是不夠的，它只能說是一款開發框架，而不是一個真正的微服務產品，不能爲業務開發提供充足的保障。那麼究竟什麼是一款完整的微服務產品呢? 我起碼認爲它應該擁有這兩個基本的能力：

第一，要擁有微服務框架技術能力。

第二，要擁有完整的服務治理能力，擁有應用全生命週期的管理能力。

第一部分是基礎的微服務框架能力，這裏面應當包括：服務註冊，服務發現，負載均衡，熔斷保護，服務路由，服務通訊等。

第二部分是擁有完整的服務治理能力，這裏面的內容比較多，通常會有： 服務的管理，可視化治理界面，服務構建發佈，分佈式事務，流量控制，監控告警，服務契約，鏈路跟蹤，灰度發佈，服務降級等等。

微服務產品這一節能夠單獨拿出來講，這裏就不過多討論，其實好的產品應該還要有其餘部分考量，如對接各類其餘技術組件和其餘產品的能力。

業界的微服務產品有不少，這裏列幾款：

• 騰訊 TSF 產品，Tars 產品。

• 阿里的 Dubbo, EDAS 系列。

• 華爲的 ServiceComb，ServiceStage 系列。

• 螞蟻金服 SOFA 系列。

• Pivotal 的 Cloud Foundary。

• 微軟的 Service Fabric。

• 網易的輕舟微服務。

這部分的內容是咱們技術中臺的基座，它能夠幫咱們解決大部分在開發測試，網絡通訊，分佈式等方面的難題，也是咱們在構建微服務應用，技術組件，公共支撐等方面的基礎，加上完整的微服務治理能力，能充分幫咱們解決在微服務拆分後的管理和運維問題，因此這部份內容是至關重要的。

 技術組件

咱們這裏探討的是中臺能力不是隻堆砌技術組件，不是缺消息隊列和定時任務調度框架就裝一個 RabbitMQ 和 Quartz，而後就拋給業務開發去使用，咱們而是思考如何讓業務開發更好更快速地上手使用，如何讓多個項目組使用時保證組件的穩定和可用性。好比項目須要使用某個技術組件，咱們能夠經歷如下幾個步驟：

1. 寫一個文檔，告訴開發須要哪些依賴，引用什麼樣的配置便可。

2. 發現每一個人都要這樣很麻煩，咱們即把依賴引入父工程或公共依賴。

3. 發現每一個人還須要配各類配置後，咱們可剩下不能減小的配置，如服務名，其餘的都放在遠程配置中心或環境變量或其餘地方。

4. 增長 UI 可視化能力，可視化管理能力。

5. 標準化，微服務化，業務域、系統級、公司級別統一微服務，多租戶能力，如給每一個應用分配權限，單獨的進行數據操做，維護，管理。

6. 發現需求，優化迭代。

一般通常的只是作 1,2,3 點，稍微好點的能夠會增長第四點，若是真正的落地技術中臺，應該在第四點，第五點和第六點發力，進行能力的抽象，進而造成標準化的能力，還能很是快速的提供給業務和其餘技術部門使用，維護成本也低，這纔是真正能爲團隊和業務帶來價值的地方，也是提升研發效能和組織效率的途徑，這三點就須要單獨去開發和建設了。

這部分的能力就是讓咱們開發、測試、運維人員能快速的使用這些技術組件幫助咱們解決特定問題，而且利用這些能力開發出公共微服務，提供給公司使用。

 公共基礎服務和技術服務

對於公共基礎服務和技術服務其實包含的東西也不少，只要能抽取出公共能力的服務或技術，均可以單獨拿出來進行操做：

• 公共基礎服務：用戶權限服務，業務配置服務, 通知服務，數據分析服務等。

• 技術服務：緩存服務，分佈式 ID 服務，消息隊列，分佈式任務調度服務等。

好比權限服務，那麼是否考慮整個公司或者大的業務域是一套權限中心，這個權限中心應當是多租戶的，傳統的老架構不少是各自獨立的，那這裏咱們就考慮是否可合併。我這裏沒有列完，這部份內容實際上是很是多的，也是很是重要的，是真正提升開發效率和效能的地方，每每也是不少公司欠缺的部分，有些公司可能有部分能力，更多的時候仍是像咱們以前說的，只是純技術組件，而不是服務，耦合度也較高，也沒有真正的支持多用戶能力，使用起來也很繁瑣，這樣的東西和傳統的架構方式並無太大區別，也沒有真正的爲業務和開發去考慮，頗有可能仍是各自爲政重複造輪子，最終形成流程的繁瑣和數據的不一致。

技術組件、公共基礎服務、技術服務這三塊是真正須要公司下大力氣去規劃實現的內容，也是比較容易把控和落地的，這裏面操做的空間很是之大，作好以後給業務帶來的好處是直接可見的。

 DevOps&&AIOps

DevOps 層面，咱們這裏討論的可能不是技術層面的實現，如如何使用 jenkins，寫好 pipeline 進行 CICD，也不是如何利用 docker + k8s+Jenkins 作到動態 CICD 等，也不是如何作好 DevOps 模板，而更多的是 DevOps 現狀作一些思考。

首先在實施 DevOps 時候，咱們發現不少項目組只是在 DevOps 工具鏈方面作了很好的處理，好比採用 CI/CD 方法論，加上 git, Gradle, maven ,jenkins，jacoco, sonar, CodeDeploy, Ansible,docker 等等工具鏈，已經讓 CICD 在企業和公司裏實行了起來，而且還能運用好運維平臺，在自動化方面作了不少工做，這些都給企業帶來了好處和效率的提高。

其次，DevOps 是能夠貫穿需求，設計，開發，測試，上線，運維等多個方面的，它應該是要以應用爲中心，以組織做爲依託，來促進公司整個效能的提高，進而還能推進創新能力的加強，和促進人才、組織的優化，這纔是有價值的 DevOps。

不足的方面是文化、組織、流程方面，咱們發現技術方面不少問題實際上是管理的不足帶來的，DevOps 爲了打破開發和運維牆而產生的文化在傳統企業的組織層面還比較難調整，泰勒的金字塔管理結構仍是持續發揮做用，部門牆仍是繼續維持，做爲技術實施方的咱們，確定是但願完美的解決問題，在一開始就讓團隊或者組織進行調整，其實這對於不少企業來講是不太現實的，但咱們發現隨着 CI、CD、CO 能力落地，組織間的配合愈來愈多，人員的技能在逐步滲透，這時在沒法立馬解決組織層面問題的時候，能夠逐步的讓團隊發生技術融合，職責傳遞和培訓，從而推進團隊的整合，造成咱們指望的，融合的 2 個披薩團隊，完成真正的 DevOps 文化和工具的全面落地。

AIOps 層面：

在咱們 Ops 運維方面，咱們已經從過去的人工運維走到了現在的自動化運維，但咱們發現這裏的自動化只能是管控臺，工具和腳本層面，若是在人的思想方面作到自動化實際上是比較困難的，那也必將形成咱們人工的進行分析和決策，也須要人工的進行檢測點及規則點的錄入，因此這也是 AIOps 能幫咱們帶來的好處，AIOps 主要仍是在 AI 層面發揮它獨有的優點，在數字化運營，智慧運維這塊發力，這部份內容也是建設中臺能夠考慮的部分。

效能：

咱們的目標是持續的交付有價值且穩定的軟件，效能方面實際上是貫穿整個項目的，我認爲它不僅僅指研發效能這一個點的，咱們應該是思考如何站在總體的角度上去衡量團隊和項目效率的提高，猶如坐在飛機上俯瞰大地，這裏一個好的作法是成立一個平臺型效能微團隊，能按期的對項目和團隊進行梳理，能夠是任意方面，並能夠藉助一些產品和方法進行輔助，如利用看板，限制在製品數量等。另外這個團隊重要的工做是能抽時間和站在更高的角度去發現整個中臺的價值，改進點和缺陷，如造成好的公共支撐服務和標準化的服務，對中臺進行不斷優化和迭代。

時間倉促，涉及的東西不少，咱們此次只談論了技術中臺的部份內容，固然整個的範圍遠遠不止這幾部分，拋磚引玉，但願有機會跟你們一塊兒交流心得。

做者介紹

朱德明，騰訊雲技術架構師，十年軟件開發經驗，《從新定義 Spring Cloud 實戰》做者之一，業界首個微服務標準核心編寫者之一，長期從事微服務和雲原生方面的工做，研發過多款微服務產品，主導和參與了多個大型企業微服務架構和雲原生架構的設計，諮詢等工做。在微服務，雲原生，互聯網解決方案等方面有着豐富的實戰和落地經驗。