【51CTO.com原創稿件】

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

技術架構分析及改造-產品SaaS化帶來的架構思考 趙軍偉 IBM架構師

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

圖一 既有技術架構

圖二 既有部署架構

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

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

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

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

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

導師點評：跟誰學聯合創始人李鋼江
評分：92
評語： 文章說明了一種典型的SAAS服務改造的場景，***補充一些量化的數據說明改造的成果，在創新性方面做的稍有不足，不過整體做的不錯，體現了作者實施復雜項目研發管理的能力。

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

[[179630]]

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】