【51CTO.com原創(chuàng)稿件】

導(dǎo)語：CTO訓(xùn)練營第二季已經(jīng)圓滿收官，作為一個學(xué)習(xí)分享和社交的平臺，CTO訓(xùn)練營提供的不光是知識分享，還有一個屬于技術(shù)管理者的人脈圈子。結(jié)課之后，第二季學(xué)員提交了畢業(yè)設(shè)計，來對四個月以來的學(xué)習(xí)進(jìn)行總結(jié)與回顧，部分論文由CTO導(dǎo)師進(jìn)行點評和打分。

技術(shù)架構(gòu)分析及改造-產(chǎn)品SaaS化帶來的架構(gòu)思考 趙軍偉 IBM架構(gòu)師

[[179629]]
背景
PANDA團(tuán)隊一直負(fù)責(zé)HORIZON產(chǎn)品的開發(fā)工作，并與UX（用戶體驗設(shè)計）團(tuán)隊，QA（質(zhì)量保證）團(tuán)隊，SU（服務(wù)）團(tuán)隊一同提供產(chǎn)品生命周期內(nèi)的發(fā)布和支持工作。在過去幾年中，該產(chǎn)品一直服務(wù)于企業(yè)用戶，按照安裝數(shù)目授權(quán)的方式銷售給用戶。從去年開始，按照公司戰(zhàn)略方向的調(diào)整，所有產(chǎn)品都遷移到云上，以SaaS的產(chǎn)品方式發(fā)布，服務(wù)大量并不具備IT基礎(chǔ)架構(gòu)的小微企業(yè)，同時保持現(xiàn)有已安裝企業(yè)用戶本地部署的支持，并為他們提供逐漸遷移到SaaS上的解決方案。
HORIZON產(chǎn)品已經(jīng)有十年以上的歷史，其最初設(shè)計并沒有考慮對云，尤其是多租戶的方案支撐，而僅僅是一個便于安裝部署的單體架構(gòu)，功能架構(gòu)如圖一所示。部署架構(gòu)如圖二所示。
在***步遷移到云時，為了快速可用，我們做了一個僅僅是自動化部署以及和門戶的集成工作，并未在基礎(chǔ)架構(gòu)上做任何調(diào)整。相當(dāng)于把原有在企業(yè)用戶中安裝的版本在云上為每個用戶做了一個自動部署，實際上每個用戶還是獨立的享有一個VM，而不是多租戶的模式。雖然這樣做可以非?？斓赝瓿晒緫?zhàn)略轉(zhuǎn)移的要求，但同時也帶來了比較多的問題：
1.資源浪費。在企業(yè)用戶中，服務(wù)端需要一個8核以上CPU，16G以上內(nèi)存的服務(wù)器，以接入多達(dá)5000個以上的探針采集器。但在云上很多小微用戶也不得不使用一個類似配置的虛擬機(jī)，即使用戶只接1個探針。這種方案極大浪費了服務(wù)端資源，無法做到處理能力的有效發(fā)揮，從成本上也投入很高；
2.無法橫向擴(kuò)展。所有的模塊都安裝在同一虛擬機(jī)內(nèi)，模塊間的通信已經(jīng)配置為本地連接，不能擴(kuò)展到多臺服務(wù)器部署，且每個模塊無法啟動多實例以提供更多的處理能力，在將來擴(kuò)展到多租戶支持上存在架構(gòu)上的設(shè)計缺陷；
3.沒有容錯方案。如果某個模塊出現(xiàn)僵死或者崩潰的情況，沒有統(tǒng)一的管理框架去自動監(jiān)測并啟動失敗模塊；對于模塊失敗后手工恢復(fù)缺乏統(tǒng)一的狀態(tài)恢復(fù)方案；即使增加前面兩點講到的缺失功能，對于虛擬機(jī)整體崩潰這樣的事情也超出了該架構(gòu)能夠處理的范圍。

圖一 既有技術(shù)架構(gòu)

圖二 既有部署架構(gòu)

現(xiàn)有架構(gòu)分析
現(xiàn)有架構(gòu)均基于企業(yè)安裝用戶快速部署的需求，并沒有針對云，尤其是多租戶的部署模型有考量。因此，首先要針對基于云的SaaS解決方案提出架構(gòu)改進(jìn)的需求：
1.多租戶支持。多租戶支持主要解決多個用戶共享服務(wù)器上計算，存儲，網(wǎng)絡(luò)等資源，以細(xì)粒度方式調(diào)度資源，達(dá)到資源的有效利用；
2.水平擴(kuò)展支持。每個模塊必須做到多實例支持，以組成數(shù)據(jù)處理集群，通過多個實例協(xié)作突破單個實例處理上限，并在多租戶的場景下做到那個模塊處理能力不足便擴(kuò)展哪個模塊，達(dá)到資源高效利用；
3.容災(zāi)設(shè)計。每個模塊本身的功能集合均可認(rèn)為是一種服務(wù)提供，該服務(wù)對于服務(wù)的消費者具有透明性，或者說服務(wù)消費者并不需要關(guān)心服務(wù)提供者有多少個實例，也不關(guān)心具體由那個服務(wù)實例提供服務(wù)。即使一個服務(wù)實例崩潰，系統(tǒng)能自動屏蔽到該實例的請求，從而做到服務(wù)的不中斷執(zhí)行，且系統(tǒng)能夠恢復(fù)崩潰模塊到可用狀態(tài)，從而保證服務(wù)質(zhì)量不下降；
4.自動化運維。模塊實例隨著用戶數(shù)量增加而不斷增加，當(dāng)達(dá)到一定規(guī)模之后，傳統(tǒng)系統(tǒng)運維的弊端就逐漸顯現(xiàn)，甚至變?yōu)椴豢赡?。自動化運維要求系統(tǒng)對于常見的水平擴(kuò)展/收縮操作，崩潰模塊實例的恢復(fù)，服務(wù)提供者和消費者的連接配置，新建實例的配置更新等均做到自動化，并提供報告以逐步優(yōu)化；
5.數(shù)據(jù)安全與數(shù)據(jù)完整性。多租戶需求帶來了安全性的要求。每個用戶都希望自己的數(shù)據(jù)在SaaS服務(wù)上是安全的，不被未授權(quán)用戶訪問和篡改；同時，即使是同一租戶的不同業(yè)務(wù)部門，也有數(shù)據(jù)權(quán)限的設(shè)置，以保證企業(yè)信息的正確使用。數(shù)據(jù)完整性的保證包括了數(shù)據(jù)的不被篡改，也同時要求數(shù)據(jù)的一致性，可恢復(fù)性，可追蹤性；
6.可維護(hù)性。該特性并非為終端用戶所要求，而是由于SaaS運維操作集中于運維團(tuán)隊，面對龐大的用戶群體，高度可維護(hù)性能夠極大增加系統(tǒng)的可用性和出現(xiàn)問題時快度修復(fù)的速度;
7.DevOps。該特性同樣為運維團(tuán)隊需求。以SaaS方式發(fā)布產(chǎn)品，要求改變傳統(tǒng)半年一個版本發(fā)布周期的傳統(tǒng)，盡可能快速推出新的功能，提高用戶滿意度。另外DevOps也要求建立一個自動化的發(fā)布流水線，在流水線的每個環(huán)節(jié)保證發(fā)布的質(zhì)量，避免出現(xiàn)問題版本到達(dá)終端用戶的情況發(fā)生。
上述需求為遷移到云的基礎(chǔ)要求，另外還由此引入一些非直接的衍生需求，我們將上述所有需求整理為如下幾個方面：
1.功能模型。功能模型的變化主要為部署模型從傳統(tǒng)的單體式模型變?yōu)榉植际侥Ｐ鸵氲男绿匦詫?dǎo)致的?；蛘呖梢员硎鰹椴渴鹉Ｐ偷贡乒δ苣Ｐ偷囊环N方式。在傳統(tǒng)的功能實現(xiàn)中，主要以快速滿足用戶需求為主，并沒有考慮分布式部署帶來的額外的非功能需求，例如可維護(hù)性對大規(guī)模分布式部署的集中日志查看需求，多實例對于集群管理的任務(wù)分配，數(shù)據(jù)分區(qū)，配置更新，緩存同步等引入的新需求等等；
2.部署模型。部署模型以分布式部署為主要考量，并做到集群實例分散部署以減少集中部署中對底層IT支撐系統(tǒng)單點失敗帶來的壓力；部署方式還應(yīng)支持分布式部署的運行時配置，自動將互相依賴模塊的連接關(guān)系配置完成；部署方式能夠做到服務(wù)隔離，在實例失敗時屏蔽其功能并在自動恢復(fù)后繼續(xù)為服務(wù)消費之服務(wù)；部署分布式系統(tǒng)時能夠支持彈性伸縮；
3.流程更新。運維團(tuán)隊和開發(fā)團(tuán)隊更緊密的結(jié)合，梳理發(fā)布流程，改變以前瀑布式開發(fā)，階段性發(fā)布的模式，將SaaS服務(wù)做成真正自動化的云發(fā)布流水線。更緊湊的發(fā)布節(jié)奏要求更嚴(yán)格的質(zhì)量控制，這些都要求更多的構(gòu)建，功能測試，壓力測試，集成測試，全球化測試等步驟被自動化，且能夠做到流水線階段提升。
根據(jù)上面的分析，我們可以有針對性的對現(xiàn)有技術(shù)架構(gòu)做改造升級，以適應(yīng)新的應(yīng)用環(huán)境。

架構(gòu)改造方案
功能模型
從云的特性講，分布式部署、彈性伸縮和容錯設(shè)計要求我們做到服務(wù)/組件的隔離和發(fā)現(xiàn)，并在每個服務(wù)/組件內(nèi)做到集群管理功能。從圖一的功能模型可以看到，目前組件已經(jīng)具有了比較規(guī)范的邊界劃分，但在隔離度和動態(tài)配置上尚有欠缺。故做功能模型改造如圖三所示。

圖三 改造后功能模型
此圖中，各個組件分別構(gòu)建為一個微服務(wù)，每個微服務(wù)為自承性的組件，通過與其他服務(wù)交互共同完成整個產(chǎn)品的功能集合。各個微服務(wù)之間通過兩種方式相互連接：
1.數(shù)據(jù)總線。數(shù)據(jù)總線提供隊列和發(fā)布/訂閱支持，以解耦服務(wù)的提供者和消費者之間的直接連接。由于有服務(wù)總線的隔離，服務(wù)提供者和消費者并不直接互聯(lián)，且互相不知道對方的存在，故而對于任何一方只需要和數(shù)據(jù)總線通信就足夠了。這也提供了可插拔的一種服務(wù)配置方式，對于靈活擴(kuò)展數(shù)據(jù)處理服務(wù)提供了極大的支持。
2.RESTFul服務(wù)。大部分的服務(wù)不僅供產(chǎn)品組件使用，同時也提供外部產(chǎn)品集成的能力。此時組件應(yīng)該暴露RESTFul API給服務(wù)消費者。通過這種方式，各個組件僅需要使用一種最通用的通信協(xié)議即可和很多種服務(wù)通信，避免了多種協(xié)議適配帶來的額外工作量。
組件的實現(xiàn)要盡可能做到無狀態(tài)化，這樣新的實例將不必與其他實例通信以恢復(fù)或者同步狀態(tài)，而是僅僅提供計算能力，或者僅僅通過與某種持久化層服務(wù)即可獲取本服務(wù)的狀態(tài)，并快速對外提供服務(wù)。
部署模型
部署模型對于功能模型是透明的，即功能模型的實現(xiàn)可以在不同的部署環(huán)境里通過部署適配做到靈活部署。
鑒于部署在云中的運行時配置在微服務(wù)架構(gòu)下較為復(fù)雜，需要針對組件抽象出服務(wù)的發(fā)現(xiàn)與自動配置，這些功能不能實現(xiàn)在組件代碼里，而是實現(xiàn)在云環(huán)境適配代碼里。注意，此處云并非單指公有云，也包括私有云和混合云，這樣對于傳統(tǒng)企業(yè)用戶，尤其是對數(shù)據(jù)安全性高的企業(yè)仍然能夠提供支持。功能代碼和適配代碼的分離可以帶來穩(wěn)定的功能組件和可裁剪的環(huán)境適配上的便利性。
對于上述配置的分離，部署模型上采用每個微服務(wù)均以Docker鏡像的模式發(fā)布（功能代碼封裝），并在不同云環(huán)境適配中對于Docker鏡像做運行時配置，一般我們依賴于云提供商的編排服務(wù)（環(huán)境適配代碼封裝）。
此處我們采用目前比較熱門的Docker+Kubernetes，修改部署模型的設(shè)計如圖四所示。

圖四 改造后的部署模型
Docker鏡像保證里每個服務(wù)在運行時的環(huán)境一致性，包括Linux的發(fā)行版，運行依賴庫等所有本地依賴，而Kubernetes則通過Service這個概念解耦了兩個服務(wù)之間的直接連接，天然地為服務(wù)解耦，服務(wù)自動發(fā)現(xiàn)和自動配置，甚至是彈性伸縮提供了基礎(chǔ)架構(gòu)級別的支持。
圖四中給出了一個服務(wù)A的部署例子，該服務(wù)A除了與總線通信外，也同時通過數(shù)據(jù)庫持久化層暴露的RESTFul服務(wù)完成狀態(tài)的持久化和還原操作。同時，每個實例的分布式部署會考慮跨機(jī)柜，甚至是數(shù)據(jù)中心（如果需要這么高的可用性的話）的配置策略。以獲取足夠高的可用性。
目前Kubernetes提供了各種IAAS的適配，該模型同時利用了這種開源框架的適配能力，在各種云，如AWS，Azure，甚至是企業(yè)內(nèi)部的VMware集群中均可以做到部署和編排。這大大減少了我們自己適配各種IAAS的工作量。
流程更新
構(gòu)建自動化的發(fā)布流程即使是在傳統(tǒng)的瀑布開發(fā)模式時代，產(chǎn)品中已經(jīng)有大量采用，不過當(dāng)時主要是解決多個模塊自動化測試，以減少集成風(fēng)險為目的。而在采用云的服務(wù)發(fā)布模式以后，DevOps的采用勢必成為一種流程上的強(qiáng)制要求，并上升自動化測試為自動化發(fā)布，縮短發(fā)布周期的同時保證發(fā)布的質(zhì)量。
根據(jù)現(xiàn)有團(tuán)隊的服務(wù)支持模式，需要調(diào)整部分服務(wù)支撐人員到新的運維團(tuán)隊，并與研發(fā)團(tuán)隊一同工作，保證產(chǎn)品質(zhì)量的同時實現(xiàn)快速的迭代發(fā)布。研發(fā)團(tuán)隊不僅負(fù)責(zé)產(chǎn)品的功能開發(fā)，同時自動化測試，云環(huán)境適配的開發(fā)工作也同時需要在研發(fā)團(tuán)隊完成；運維團(tuán)隊針對產(chǎn)品上線后的問題，實時反饋給研發(fā)團(tuán)隊并據(jù)此更新優(yōu)化。在此我們主要關(guān)心自動化DevOps的流水線設(shè)計，其它部分不在本文討論范圍之內(nèi)。
DevOps的流程設(shè)計如圖五所示。

圖五 改造后的DevOps流程
1.開發(fā)人員完成代碼在IDE環(huán)境中單元測試之后，需要提交代碼到源碼庫，代碼包括產(chǎn)品代碼，測試代碼，云環(huán)境適配代碼。DevOps通過工作流調(diào)度程序自動觸發(fā)產(chǎn)品的構(gòu)建，Docker鏡像封裝，自動化部署到沙盒再次運行所有自動化測試腳本；
2.當(dāng)上述測試通過后，Docker鏡像和云適配配置自動提升到集成測試環(huán)境（圖中iBVT），與其他開發(fā)小組提升的組件集成，做集成測試；
3.集成測試通過后提升到復(fù)雜場景測試環(huán)境（圖中SVT）。復(fù)雜場景測試模擬真實用戶的操作，把各個產(chǎn)品功能串在一起完成典型用戶場景和異常用戶場景的測試；
4.SVT通過后提升到預(yù)演環(huán)境（圖中Staging），該測試除了通過完整回歸驗證產(chǎn)品的功能，性能外，還要經(jīng)過至少一個星期的穩(wěn)定性測試；
5.最終通過的產(chǎn)品版本自動提升到產(chǎn)品環(huán)境（圖中Production），為終端用戶提供服務(wù)。
上述任何一個環(huán)節(jié)出現(xiàn)問題，自動提升的條件便會收到破壞，系統(tǒng)會通知開發(fā)團(tuán)隊修復(fù)錯誤，重復(fù)上述流程。
總結(jié)
一個完成的架構(gòu)遷移，不僅僅涉及到功能模型，部署模型等傳統(tǒng)技術(shù)架構(gòu)所應(yīng)用的范圍，實際上團(tuán)隊技能的調(diào)整，角色的邊界定義，甚至是組織架構(gòu)的優(yōu)化都對一個產(chǎn)品架構(gòu)的遷移有著非常重要的影響。作為一個技術(shù)主管，需要從各個視角，多維度地觀察和解決在改造遷移過程中發(fā)現(xiàn)的短板，不斷迭代優(yōu)化，從而最終保證目標(biāo)的達(dá)成。

導(dǎo)師點評：跟誰學(xué)聯(lián)合創(chuàng)始人李鋼江
評分：92
評語： 文章說明了一種典型的SAAS服務(wù)改造的場景，***補(bǔ)充一些量化的數(shù)據(jù)說明改造的成果，在創(chuàng)新性方面做的稍有不足，不過整體做的不錯，體現(xiàn)了作者實施復(fù)雜項目研發(fā)管理的能力。

CTO訓(xùn)練營是51CTO高招主辦，面向中高端技術(shù)管理者的學(xué)習(xí)分享及社交平臺，匯集業(yè)界資深技術(shù)高管、投資人資源，以“打造技術(shù)經(jīng)理的MBA”為核心，全心全力幫助中國***潛力的技術(shù)管理者，成長為未來技術(shù)領(lǐng)域的***及榜樣。第三季CTO訓(xùn)練營將在原有優(yōu)質(zhì)內(nèi)容體系的基礎(chǔ)上，延伸四大選修活動，滿足不同技術(shù)管理者的個性化需求。

[[179630]]

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】