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