只堆技術(shù)組件，微服務(wù)中臺或者說企業(yè)中臺只包含常用的技術(shù)組件，比如使用 spring cloud 微服務(wù)框架，再加上 MQ,Redis, quartz,nginx,activity,servicemesh,docker 幾個組件之后認(rèn)為這個就是企業(yè)的中臺，要什么技術(shù)能力拿過去用即可，說法其實(shí)并沒有錯，只是站的角度不同，確實(shí)是能力的抽象，封裝和開放，但并不是純粹的堆砌技術(shù)組件。
2. 擁有服務(wù)治理就是中臺
為 spring cloud 這樣微服務(wù)開發(fā)框架增強(qiáng)了服務(wù)治理的能力，然后在綁定上業(yè)務(wù)就是技術(shù)中臺或者中臺。
這樣的看法不是完全正確，這只能代表在技術(shù)的基礎(chǔ)底座和支撐上前進(jìn)了一步，還遠(yuǎn)遠(yuǎn)不夠。
3. 增加部分業(yè)務(wù)功能就是中臺
對老系統(tǒng)增加新功能確實(shí)是構(gòu)建中臺道路上必須經(jīng)歷的一件事，但如果只是單純的從增加新功能角度出發(fā)而不是為了能力組件化，服務(wù)化，封裝和開放，協(xié)同作戰(zhàn)的思想去建設(shè)，那么只是給老系統(tǒng)增加負(fù)擔(dān)而不是減負(fù)。
4. Cloud Native 就是中臺
Cloud Native 是目前比較火的領(lǐng)域，很多企業(yè)認(rèn)為做了微服務(wù)，容器，DevOps 就已經(jīng)構(gòu)成了中臺體系，這也是比較片面的看法，只能說有了這三大塊，對于構(gòu)建中臺體系有了一個很好的基座，但真正的中臺還并未出現(xiàn)。
@/先從技術(shù)中臺方面來探討一下技術(shù)中臺的落地建設(shè)，后續(xù)我們再來討論業(yè)務(wù)中臺。/
剛剛上面我們認(rèn)為中臺應(yīng)該不是什么樣子，那到底中臺應(yīng)該是什么樣子，有什么價值，就如我們上面所說，它一定是為業(yè)務(wù)和組織而生，你可以從很多角度去解讀它，本篇文章我們結(jié)合在新項(xiàng)目建設(shè)中，我們先從技術(shù)中臺方面來探討一下技術(shù)中臺的落地建設(shè)，后續(xù)我們再來討論業(yè)務(wù)中臺。
技術(shù)中臺
如下圖，我先把技術(shù)中臺分為這幾部分，當(dāng)然它包含很大的范圍和其他的角度，但我們可以根據(jù)這幾點(diǎn)展示出部分技術(shù)中臺思想：
容器平臺，虛擬機(jī)
微服務(wù)框架 (分布式服務(wù)框架) && 微服務(wù)管理控制臺
技術(shù)組件
公共基礎(chǔ)服務(wù)和技術(shù)服務(wù)
DevOps&&AIOps
效能
容器云，虛擬機(jī)
虛擬機(jī)和應(yīng)用上云對 Iaas 廠商有了更高的要求，不僅在穩(wěn)定性和可用性方面要有出色的表現(xiàn)，更加應(yīng)該在易用性和便捷性方面展示出強(qiáng)大的功能，這方面必須能提供具有豐富功能和配置的 UI 界面，它有助于我們在 Iaas 的配置和運(yùn)維層面減少工作量，優(yōu)化人員配置，提高我們對 Iaas 的掌控能力，這是一個有和優(yōu)的問題，另外對于廠商的選擇和團(tuán)隊(duì)的選擇，一定是要能及時響應(yīng)的。
虛擬機(jī)和應(yīng)用上云對 Iaas 廠商有了更高的要求，不僅在穩(wěn)定性和可用性方面要有出色的表現(xiàn)，更加應(yīng)該在易用性和便捷性方面展示出強(qiáng)大的功能，這方面必須能提供具有豐富功能和配置的 UI 界面，它有助于我們在 Iaas 的配置和運(yùn)維層面減少工作量，優(yōu)化人員配置，提高我們對 Iaas 的掌控能力，這是一個有和優(yōu)的問題，另外對于廠商的選擇和團(tuán)隊(duì)的選擇，一定是要能及時響應(yīng)的。
對于采用了容器的廠商，起碼要在這幾方面需要做好，集群的管理和調(diào)度，網(wǎng)絡(luò)方案，服務(wù)編排，日志方案，存儲方案，應(yīng)用和服務(wù)的管理，容器的監(jiān)控和告警，鏡像倉庫的管理，鏡像的打包和構(gòu)建，用戶的權(quán)限，優(yōu)秀的 UI 操作界面等等。
同樣的對于容器，如果它是一個優(yōu)秀的產(chǎn)品，那它還應(yīng)該是這樣的：
充分開放的和可擴(kuò)展的接口。
可以和多個產(chǎn)品進(jìn)行對應(yīng)快速，如微服務(wù)產(chǎn)品。
豐富和體驗(yàn)方便的 UI， 高度集成功能的 UI，可見即可得。
充分的對接 DevOps 文化，豐富的 CICD 流程，鏡像一鍵打包。
容器應(yīng)用與非容器應(yīng)用通信，跨集群通信。
優(yōu)秀的監(jiān)控體系。
等等。
這部分的能力是讓整個技術(shù)中臺有一個好的基礎(chǔ)設(shè)施層支撐，能快速的進(jìn)行應(yīng)用的部署和交付，出問題時能迅速定位和恢復(fù)，降低 MTTR, 并能充分的利用現(xiàn)有資源進(jìn)行合理的分配，讓技術(shù)和業(yè)務(wù)降低耦合，劃分出業(yè)務(wù)實(shí)現(xiàn)者與技術(shù)支撐的 BC，關(guān)注各自的領(lǐng)域，所以你需要一個非常靠譜和好用的底層支撐。
微服務(wù)框架 (分布式服務(wù)框架) && 微服務(wù)管理控制臺
對于傳統(tǒng)老應(yīng)用而言，它可能是傳統(tǒng)的單體應(yīng)用，整個系統(tǒng)的功能都融合在一起。它們在迎接需求劇烈變化和傳統(tǒng)開發(fā)迭代方面遇到了瓶頸，那么在轉(zhuǎn)型時就會考慮服務(wù)化的架構(gòu)，在做服務(wù)化架構(gòu)時，我們就需要一個完整而健全的分布式服務(wù)化框架來幫助我們，諸如 Pivotal 的 Spring Cloud 框架。
但這里要提醒的是，如果你要打造一款真正的技術(shù)中臺，我認(rèn)為一個純粹的 Spring Cloud 的框架是非常不夠的，它只能說是一款開發(fā)框架，而不是一個真正的微服務(wù)產(chǎn)品，不能為業(yè)務(wù)開發(fā)提供充足的保障。那么究竟什么是一款完整的微服務(wù)產(chǎn)品呢? 我起碼認(rèn)為它應(yīng)該擁有這兩個基本的能力：
第一，要擁有微服務(wù)框架技術(shù)能力。
第二，要擁有完整的服務(wù)治理能力，擁有應(yīng)用全生命周期的管理能力。
第一部分是基礎(chǔ)的微服務(wù)框架能力，這里面應(yīng)當(dāng)包括：服務(wù)注冊，服務(wù)發(fā)現(xiàn)，負(fù)載均衡，熔斷保護(hù)，服務(wù)路由，服務(wù)通信等。
第二部分是擁有完整的服務(wù)治理能力，這里面的內(nèi)容比較多，一般會有： 服務(wù)的管理，可視化治理界面，服務(wù)構(gòu)建發(fā)布，分布式事務(wù)，流量控制，監(jiān)控告警，服務(wù)契約，鏈路跟蹤，灰度發(fā)布，服務(wù)降級等等。
微服務(wù)產(chǎn)品這一節(jié)可以單獨(dú)拿出來說，這里就不過多討論，其實(shí)好的產(chǎn)品應(yīng)該還要有其他部分考量，如對接各種其他技術(shù)組件和其他產(chǎn)品的能力。
業(yè)界的微服務(wù)產(chǎn)品有很多，這里列幾款：
騰訊 TSF 產(chǎn)品，Tars 產(chǎn)品。
阿里的 Dubbo, EDAS 系列。
華為的 ServiceComb，ServiceStage 系列。
螞蟻金服 SOFA 系列。
Pivotal 的 Cloud Foundary。
微軟的 Service Fabric。
網(wǎng)易的輕舟微服務(wù)。
這部分的內(nèi)容是我們技術(shù)中臺的基座，它可以幫我們解決大部分在開發(fā)測試，網(wǎng)絡(luò)通信，分布式等方面的難題，也是我們在構(gòu)建微服務(wù)應(yīng)用，技術(shù)組件，公共支撐等方面的基礎(chǔ)，加上完整的微服務(wù)治理能力，能充分幫我們解決在微服務(wù)拆分后的管理和運(yùn)維問題，所以這部分內(nèi)容是相當(dāng)重要的。
技術(shù)組件
我們這里探討的是中臺能力不是只堆砌技術(shù)組件，不是缺消息隊(duì)列和定時任務(wù)調(diào)度框架就裝一個 RabbitMQ 和 Quartz，然后就拋給業(yè)務(wù)開發(fā)去使用，我們而是思考如何讓業(yè)務(wù)開發(fā)更好更快速地上手使用，如何讓多個項(xiàng)目組使用時保證組件的穩(wěn)定和可用性。比如項(xiàng)目需要使用某個技術(shù)組件，我們可以經(jīng)歷以下幾個步驟：
寫一個文檔，告訴開發(fā)需要哪些依賴，引用什么樣的配置即可。
發(fā)現(xiàn)每個人都要這樣很麻煩，我們即把依賴引入父工程或公共依賴。
發(fā)現(xiàn)每個人還需要配各種配置后，我們可剩下不能減少的配置，如服務(wù)名，其他的都放在遠(yuǎn)程配置中心或環(huán)境變量或其他地方。
增加 UI 可視化能力，可視化管理能力。
標(biāo)準(zhǔn)化，微服務(wù)化，業(yè)務(wù)域、系統(tǒng)級、公司級別統(tǒng)一微服務(wù)，多租戶能力，如給每個應(yīng)用分配權(quán)限，單獨(dú)的進(jìn)行數(shù)據(jù)操作，維護(hù)，管理。
發(fā)現(xiàn)需求，優(yōu)化迭代。
通常一般的只是做 1,2,3 點(diǎn)，稍微好點(diǎn)的可以會增加第四點(diǎn)，如果真正的落地技術(shù)中臺，應(yīng)該在第四點(diǎn)，第五點(diǎn)和第六點(diǎn)發(fā)力，進(jìn)行能力的抽象，進(jìn)而形成標(biāo)準(zhǔn)化的能力，還能非常快速的提供給業(yè)務(wù)和其他技術(shù)部門使用，維護(hù)成本也低，這才是真正能為團(tuán)隊(duì)和業(yè)務(wù)帶來價值的地方，也是提高研發(fā)效能和組織效率的途徑，這三點(diǎn)就需要單獨(dú)去開發(fā)和建設(shè)了。
這部分的能力就是讓我們開發(fā)、測試、運(yùn)維人員能快速的使用這些技術(shù)組件幫助我們解決特定問題，并且利用這些能力開發(fā)出公共微服務(wù)，提供給公司使用。
公共基礎(chǔ)服務(wù)和技術(shù)服務(wù)
對于公共基礎(chǔ)服務(wù)和技術(shù)服務(wù)其實(shí)包含的東西也很多，只要能抽取出公共能力的服務(wù)或技術(shù)，都可以單獨(dú)拿出來進(jìn)行操作：
公共基礎(chǔ)服務(wù)：用戶權(quán)限服務(wù)，業(yè)務(wù)配置服務(wù), 通知服務(wù)，數(shù)據(jù)分析服務(wù)等。
技術(shù)服務(wù)：緩存服務(wù)，分布式 ID 服務(wù)，消息隊(duì)列，分布式任務(wù)調(diào)度服務(wù)等。
比如權(quán)限服務(wù)，那么是否考慮整個公司或者大的業(yè)務(wù)域是一套權(quán)限中心，這個權(quán)限中心應(yīng)當(dāng)是多租戶的，傳統(tǒng)的老架構(gòu)很多是各自獨(dú)立的，那這里我們就考慮是否可合并。我這里沒有列完，這部分內(nèi)容其實(shí)是非常多的，也是非常重要的，是真正提高開發(fā)效率和效能的地方，往往也是很多公司欠缺的部分，有些公司可能有部分能力，更多的時候還是像我們之前說的，只是純技術(shù)組件，而不是服務(wù)，耦合度也較高，也沒有真正的支持多用戶能力，使用起來也很繁瑣，這樣的東西和傳統(tǒng)的架構(gòu)方式并沒有太大區(qū)別，也沒有真正的為業(yè)務(wù)和開發(fā)去考慮，很有可能還是各自為政重復(fù)造輪子，最終造成流程的繁瑣和數(shù)據(jù)的不一致。
技術(shù)組件、公共基礎(chǔ)服務(wù)、技術(shù)服務(wù)這三塊是真正需要公司下大力氣去規(guī)劃實(shí)現(xiàn)的內(nèi)容，也是比較容易把控和落地的，這里面操作的空間非常之大，做好之后給業(yè)務(wù)帶來的好處是直接可見的。
DevOps&&AIOps
DevOps 層面，我們這里討論的可能不是技術(shù)層面的實(shí)現(xiàn)，如如何使用 jenkins，寫好 pipeline 進(jìn)行 CICD，也不是如何利用 docker + k8s+Jenkins 做到動態(tài) CICD 等，也不是如何做好 DevOps 模板，而更多的是 DevOps 現(xiàn)狀做一些思考。
首先在實(shí)施 DevOps 時候，我們發(fā)現(xiàn)很多項(xiàng)目組只是在 DevOps 工具鏈方面做了很好的處理，比如采用 CI/CD 方法論，加上 git, Gradle, maven ,jenkins，jacoco, sonar, CodeDeploy, Ansible,docker 等等工具鏈，已經(jīng)讓 CICD 在企業(yè)和公司里實(shí)行了起來，并且還能運(yùn)用好運(yùn)維平臺，在自動化方面做了很多工作，這些都給企業(yè)帶來了好處和效率的提升。
其次，DevOps 是可以貫穿需求，設(shè)計(jì)，開發(fā)，測試，上線，運(yùn)維等多個方面的，它應(yīng)該是要以應(yīng)用為中心，以組織作為依托，來促進(jìn)公司整個效能的提升，進(jìn)而還能推動創(chuàng)新能力的增強(qiáng)，和促進(jìn)人才、組織的優(yōu)化，這才是有價值的 DevOps。
不足的方面是文化、組織、流程方面，我們發(fā)現(xiàn)技術(shù)方面很多問題其實(shí)是管理的不足帶來的，DevOps 為了打破開發(fā)和運(yùn)維墻而產(chǎn)生的文化在傳統(tǒng)企業(yè)的組織層面還比較難調(diào)整，泰勒的金字塔管理結(jié)構(gòu)還是持續(xù)發(fā)揮作用，部門墻還是繼續(xù)維持，作為技術(shù)實(shí)施方的我們，肯定是希望完美的解決問題，在一開始就讓團(tuán)隊(duì)或者組織進(jìn)行調(diào)整，其實(shí)這對于很多企業(yè)來說是不太現(xiàn)實(shí)的，但我們發(fā)現(xiàn)隨著 CI、CD、CO 能力落地，組織間的配合越來越多，人員的技能在逐步滲透，這時在無法立馬解決組織層面問題的時候，可以逐步的讓團(tuán)隊(duì)發(fā)生技術(shù)融合，職責(zé)傳遞和培訓(xùn)，從而推動團(tuán)隊(duì)的整合，形成我們期望的，融合的 2 個披薩團(tuán)隊(duì)，完成真正的 DevOps 文化和工具的全面落地。
AIOps 層面：
在我們 Ops 運(yùn)維方面，我們已經(jīng)從過去的人工運(yùn)維走到了如今的自動化運(yùn)維，但我們發(fā)現(xiàn)這里的自動化只能是管控臺，工具和腳本層面，如果在人的思想方面做到自動化其實(shí)是比較困難的，那也必將造成我們?nèi)斯さ倪M(jìn)行分析和決策，也需要人工的進(jìn)行檢測點(diǎn)及規(guī)則點(diǎn)的錄入，所以這也是 AIOps 能幫我們帶來的好處，AIOps 主要還是在 AI 層面發(fā)揮它獨(dú)有的優(yōu)勢，在數(shù)字化運(yùn)營，智慧運(yùn)維這塊發(fā)力，這部分內(nèi)容也是建設(shè)中臺可以考慮的部分。
效能：
我們的目標(biāo)是持續(xù)的交付有價值且穩(wěn)定的軟件，效能方面其實(shí)是貫穿整個項(xiàng)目的，我認(rèn)為它不單單指研發(fā)效能這一個點(diǎn)的，我們應(yīng)該是思考如何站在整體的角度上去衡量團(tuán)隊(duì)和項(xiàng)目效率的提升，猶如坐在飛機(jī)上俯瞰大地，這里一個好的做法是成立一個平臺型效能微團(tuán)隊(duì)，能定期的對項(xiàng)目和團(tuán)隊(duì)進(jìn)行梳理，可以是任意方面，并可以借助一些產(chǎn)品和方法進(jìn)行輔助，如利用看板，限制在制品數(shù)量等。另外這個團(tuán)隊(duì)重要的工作是能抽時間和站在更高的角度去發(fā)現(xiàn)整個中臺的價值，改進(jìn)點(diǎn)和缺陷，如形成好的公共支撐服務(wù)和標(biāo)準(zhǔn)化的服務(wù)，對中臺進(jìn)行不斷優(yōu)化和迭代。
時間倉促，涉及的東西很多，我們這次只談?wù)摿思夹g(shù)中臺的部分內(nèi)容，當(dāng)然整個的范圍遠(yuǎn)遠(yuǎn)不止這幾部分，拋磚引玉，希望有機(jī)會跟大家一起交流心得。
作者介紹
朱德明，騰訊云技術(shù)架構(gòu)師，十年軟件開發(fā)經(jīng)驗(yàn)，《重新定義 Spring Cloud 實(shí)戰(zhàn)》作者之一，業(yè)界首個微服務(wù)標(biāo)準(zhǔn)核心編寫者之一，長期從事微服務(wù)和云原生方面的工作，研發(fā)過多款微服務(wù)產(chǎn)品，主導(dǎo)和參與了多個大型企業(yè)微服務(wù)架構(gòu)和云原生架構(gòu)的設(shè)計(jì)，咨詢等工作。在微服務(wù)，云原生，互聯(lián)網(wǎng)解決方案等方面有著豐富的實(shí)戰(zhàn)和落地經(jīng)驗(yàn)。
聯(lián)系客服
