|
只堆技術(shù)組件，微服務(wù)中臺或者說企業(yè)中臺只包含常用的技術(shù)組件,，比如使用 spring cloud 微服務(wù)框架,，再加上 MQ,Redis, quartz,nginx,activity,servicemesh,docker 幾個(gè)組件之后認(rèn)為這個(gè)就是企業(yè)的中臺，要什么技術(shù)能力拿過去用即可,，說法其實(shí)并沒有錯(cuò),，只是站的角度不同，確實(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)建中臺體系有了一個(gè)很好的基座，但真正的中臺還并未出現(xiàn),。
@/先從技術(shù)中臺方面來探討一下技術(shù)中臺的落地建設(shè),，后續(xù)我們再來討論業(yè)務(wù)中臺。/ 剛剛上面我們認(rèn)為中臺應(yīng)該不是什么樣子,，那到底中臺應(yīng)該是什么樣子,，有什么價(jià)值，就如我們上面所說,，它一定是為業(yè)務(wù)和組織而生,，你可以從很多角度去解讀它，本篇文章我們結(jié)合在新項(xiàng)目建設(shè)中,，我們先從技術(shù)中臺方面來探討一下技術(shù)中臺的落地建設(shè),，后續(xù)我們再來討論業(yè)務(wù)中臺。 技術(shù)中臺 如下圖,，我先把技術(shù)中臺分為這幾部分,，當(dāng)然它包含很大的范圍和其他的角度，但我們可以根據(jù)這幾點(diǎn)展示出部分技術(shù)中臺思想：
容器云,，虛擬機(jī) 虛擬機(jī)和應(yīng)用上云對 Iaas 廠商有了更高的要求，不僅在穩(wěn)定性和可用性方面要有出色的表現(xiàn),，更加應(yīng)該在易用性和便捷性方面展示出強(qiáng)大的功能,，這方面必須能提供具有豐富功能和配置的 UI 界面，它有助于我們在 Iaas 的配置和運(yùn)維層面減少工作量,，優(yōu)化人員配置,，提高我們對 Iaas 的掌控能力，這是一個(gè)有和優(yōu)的問題,，另外對于廠商的選擇和團(tuán)隊(duì)的選擇,，一定是要能及時(shí)響應(yīng)的,。 虛擬機(jī)和應(yīng)用上云對 Iaas 廠商有了更高的要求，不僅在穩(wěn)定性和可用性方面要有出色的表現(xiàn),，更加應(yīng)該在易用性和便捷性方面展示出強(qiáng)大的功能,，這方面必須能提供具有豐富功能和配置的 UI 界面，它有助于我們在 Iaas 的配置和運(yùn)維層面減少工作量,，優(yōu)化人員配置,，提高我們對 Iaas 的掌控能力，這是一個(gè)有和優(yōu)的問題,，另外對于廠商的選擇和團(tuán)隊(duì)的選擇,，一定是要能及時(shí)響應(yīng)的。 對于采用了容器的廠商,，起碼要在這幾方面需要做好,，集群的管理和調(diào)度，網(wǎng)絡(luò)方案,，服務(wù)編排,，日志方案，存儲方案,，應(yīng)用和服務(wù)的管理,，容器的監(jiān)控和告警，鏡像倉庫的管理,，鏡像的打包和構(gòu)建,，用戶的權(quán)限，優(yōu)秀的 UI 操作界面等等,。 同樣的對于容器,，如果它是一個(gè)優(yōu)秀的產(chǎn)品，那它還應(yīng)該是這樣的：
這部分的能力是讓整個(gè)技術(shù)中臺有一個(gè)好的基礎(chǔ)設(shè)施層支撐,，能快速的進(jìn)行應(yīng)用的部署和交付,，出問題時(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ǒng)老應(yīng)用而言,，它可能是傳統(tǒng)的單體應(yīng)用，整個(gè)系統(tǒng)的功能都融合在一起,。它們在迎接需求劇烈變化和傳統(tǒng)開發(fā)迭代方面遇到了瓶頸,，那么在轉(zhuǎn)型時(shí)就會考慮服務(wù)化的架構(gòu)，在做服務(wù)化架構(gòu)時(shí),，我們就需要一個(gè)完整而健全的分布式服務(wù)化框架來幫助我們,，諸如 Pivotal 的 Spring Cloud 框架。 但這里要提醒的是,，如果你要打造一款真正的技術(shù)中臺,，我認(rèn)為一個(gè)純粹的 Spring Cloud 的框架是非常不夠的，它只能說是一款開發(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ù)注冊,，服務(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)品有很多,，這里列幾款：
這部分的內(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ì)列和定時(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)的可以會增加第四點(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ù)帶來價(jià)值的地方，也是提高研發(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)行操作：
比如權(quán)限服務(wù),，那么是否考慮整個(gè)公司或者大的業(yè)務(wù)域是一套權(quán)限中心,，這個(gè)權(quán)限中心應(yīng)當(dāng)是多租戶的，傳統(tǒng)的老架構(gòu)很多是各自獨(dú)立的,，那這里我們就考慮是否可合并,。我這里沒有列完，這部分內(nèi)容其實(shí)是非常多的,，也是非常重要的,，是真正提高開發(fā)效率和效能的地方，往往也是很多公司欠缺的部分,，有些公司可能有部分能力,，更多的時(shí)候還是像我們之前說的，只是純技術(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 時(shí)候,，我們發(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)維等多個(gè)方面的,，它應(yīng)該是要以應(yīng)用為中心,，以組織作為依托，來促進(jìn)公司整個(gè)效能的提升,，進(jìn)而還能推動創(chuàng)新能力的增強(qiáng)，和促進(jìn)人才,、組織的優(yōu)化,，這才是有價(jià)值的 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 能力落地,，組織間的配合越來越多,，人員的技能在逐步滲透，這時(shí)在無法立馬解決組織層面問題的時(shí)候,，可以逐步的讓團(tuán)隊(duì)發(fā)生技術(shù)融合,，職責(zé)傳遞和培訓(xùn)，從而推動團(tuán)隊(duì)的整合,，形成我們期望的,，融合的 2 個(gè)披薩團(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ù)的交付有價(jià)值且穩(wěn)定的軟件,，效能方面其實(shí)是貫穿整個(gè)項(xiàng)目的，我認(rèn)為它不單單指研發(fā)效能這一個(gè)點(diǎn)的,，我們應(yīng)該是思考如何站在整體的角度上去衡量團(tuán)隊(duì)和項(xiàng)目效率的提升,，猶如坐在飛機(jī)上俯瞰大地，這里一個(gè)好的做法是成立一個(gè)平臺型效能微團(tuán)隊(duì),，能定期的對項(xiàng)目和團(tuán)隊(duì)進(jìn)行梳理,，可以是任意方面，并可以借助一些產(chǎn)品和方法進(jìn)行輔助,，如利用看板,，限制在制品數(shù)量等。另外這個(gè)團(tuán)隊(duì)重要的工作是能抽時(shí)間和站在更高的角度去發(fā)現(xiàn)整個(gè)中臺的價(jià)值,，改進(jìn)點(diǎn)和缺陷,，如形成好的公共支撐服務(wù)和標(biāo)準(zhǔn)化的服務(wù)，對中臺進(jìn)行不斷優(yōu)化和迭代,。 時(shí)間倉促,，涉及的東西很多,，我們這次只談?wù)摿思夹g(shù)中臺的部分內(nèi)容，當(dāng)然整個(gè)的范圍遠(yuǎn)遠(yuǎn)不止這幾部分,，拋磚引玉,，希望有機(jī)會跟大家一起交流心得。 作者介紹 朱德明,，騰訊云技術(shù)架構(gòu)師,，十年軟件開發(fā)經(jīng)驗(yàn)，《重新定義 Spring Cloud 實(shí)戰(zhàn)》作者之一,，業(yè)界首個(gè)微服務(wù)標(biāo)準(zhǔn)核心編寫者之一,，長期從事微服務(wù)和云原生方面的工作，研發(fā)過多款微服務(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)。
|
|
|
