小結：

1、

微服務中臺不是

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

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

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

/4Cloud Native 就是中臺

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

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

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

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

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

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

為 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 實戰》作者之一，業界首個微服務標準核心編寫者之一，長期從事微服務和雲原生方面的工作，研發過多款微服務產品，主導和參與了多個大型企業微服務架構和雲原生架構的設計，咨詢等工作。在微服務，雲原生，互聯網解決方案等方面有著豐富的實戰和落地經驗。

微服務中臺落地 中臺誤區