XX運營商公司應(yīng)用上云架構(gòu)指導(dǎo)意見方案分享

1、XX運營商公司應(yīng)用上云架構(gòu)指導(dǎo)意見、背景和目標XX公司支撐網(wǎng)私有云整體建設(shè)取得階段性成果，IAAS層基礎(chǔ)能力已經(jīng)具備，PAAS層相關(guān)能力逐步按照規(guī)劃建設(shè)推進中，資源池相關(guān)資源也初具規(guī)模，與此同時資源與能力運營的相關(guān)體系也已經(jīng)初步建立，并經(jīng)過一年多的試行，推動相關(guān)流程和模式的不斷完善，XX公司融合資源池使用指導(dǎo)意見、XX公司融合資源池管理辦法、XX公司大數(shù)據(jù)平臺運營管理辦法等管理制度與規(guī)范相繼發(fā)布。隨著資源兩級管理運營模式有序開展，各租戶資源使用規(guī)模逐步擴大，上云的應(yīng)用或系統(tǒng)也越來越多，在租戶對于資源的使用過程中，發(fā)現(xiàn)較多不合理使用資源，或者不合理的架構(gòu)設(shè)計，造成云上系統(tǒng)的諸多問題，無法獲得系統(tǒng)

2、云化帶來的優(yōu)勢與便捷，反而給系統(tǒng)使用和維護造成不便和問題，基于這些因素，信運部組織專家團隊，總結(jié)以往在私有云上相關(guān)系統(tǒng)、項目的建設(shè)、設(shè)計、部署、運維相關(guān)工作的經(jīng)驗，特此編制此指導(dǎo)意見， 旨在指導(dǎo)云上應(yīng)用系統(tǒng)的架構(gòu)設(shè)計，系統(tǒng)集成和部署，充分發(fā)揮系統(tǒng)云化特性，提升系統(tǒng)和應(yīng)用服務(wù)能力，提高資源利用合理性，發(fā)揮資源規(guī)模效應(yīng)和平臺優(yōu)勢，提升私有云總體效益。、總體原則1. XX公司私有云上承載的應(yīng)用系統(tǒng)，只能在私有云提供的能力，組件，技術(shù)，資源下, 按照相關(guān)技術(shù)特點和要求，構(gòu)建其應(yīng)用系統(tǒng)。2. 云上應(yīng)用系統(tǒng)構(gòu)建，采用的技術(shù)、組件應(yīng)最大程度考慮通用性和標準化，系統(tǒng)架構(gòu)應(yīng)符合云計算演進方向，核心技術(shù)優(yōu)先選擇主

3、流技術(shù)路線，最大程度考慮應(yīng)用業(yè)務(wù)，系統(tǒng)組件，與平臺資源的解耦。3. 原有傳統(tǒng)應(yīng)用系統(tǒng)的上云，要避免簡單粗暴的系統(tǒng)資源遷移，即原有物理機部署的簡單遷移至虛擬機部署，必須根據(jù)原有系統(tǒng)情況，挑選合適組件和技術(shù)，綜合考慮架構(gòu)適應(yīng)，遷移復(fù)雜度和風(fēng)險，以及資源需求，合理有序進行上云遷移工作。4. 架構(gòu)設(shè)計合理適配，既不能架構(gòu)能力不足，造成業(yè)務(wù)中斷，數(shù)據(jù)丟失，或者擴容繁瑣，資源浪費等問題，也不能過渡設(shè)計，例如無實際場景需求的容災(zāi)配套，造成建設(shè)成本的浪費。架構(gòu)設(shè)計需要自上而下，從業(yè)務(wù)應(yīng)用需求出發(fā)，根據(jù)業(yè)務(wù)場景和相關(guān)指標要求，綜合考慮功能需求和非功能需求，架構(gòu)設(shè)計時選擇合適合理的技術(shù)，以較小的成本滿足應(yīng)用業(yè)務(wù)場

4、景相關(guān)的功能和非功能需求。5. 應(yīng)用系統(tǒng)上云后，由于資源、技術(shù)等一些變化，需要提前考慮系統(tǒng)相關(guān)運營運維流程的變化，對原有相關(guān)流程環(huán)節(jié)進行評估和確認，以避免上云后原有運營運維工作流程出現(xiàn)不匹配或不適應(yīng)的情況。三、上云架構(gòu)設(shè)計要件1. 性能質(zhì)量本條目主要從應(yīng)用業(yè)務(wù)場景出發(fā)，綜合考慮業(yè)務(wù)、運營、故障、維護等情況下，如何提升系統(tǒng)服務(wù)性能，提高系統(tǒng)運營和運維質(zhì)量。1.1 分層異步處理設(shè)計對于前端使用具有較高業(yè)務(wù)響應(yīng)時限要求的場景，例如面向最終客戶，或者一線業(yè)務(wù)人員使用的web 類、 app 等業(yè)務(wù)系統(tǒng)，在前后端訪問，前后臺接口調(diào)用的設(shè)計時，應(yīng)考慮分層異步處理的設(shè)計，并且結(jié)合端到端服務(wù)指標的要求，合理設(shè)置

5、各環(huán)節(jié)的超時閾值，以達到快速響應(yīng)、快速返回、快速失敗的要求，滿足整體業(yè)務(wù)場景中前端使用人員服務(wù)質(zhì)量，提升使用友好度。1.2 分層分級緩存機制對于前端使用具有較高業(yè)務(wù)響應(yīng)時限要求的場景，如果前后端調(diào)用，數(shù)據(jù)流轉(zhuǎn)，事物處理等環(huán)節(jié)，存在處理邏輯復(fù)雜，數(shù)據(jù)交互量大，IO 量大或者頻繁等風(fēng)險影響服務(wù)性能的情況，可以采取分層分級緩存的機制，來降低IO 或數(shù)據(jù)處理的時延，提升前后端調(diào)用響應(yīng)速度。但是，對于動態(tài)實時緩存的設(shè)計，特別還需要注意數(shù)據(jù)一致性問題，避免前端，緩存，與固化數(shù)據(jù)交互過程中的異常情況造成的數(shù)據(jù)不一致，從而引起業(yè)務(wù)問題。1.3 分級數(shù)據(jù)管理對于存在數(shù)據(jù)收集、處理、分發(fā)、留存的業(yè)務(wù)場景，包括但不

6、限于業(yè)務(wù)記錄、報表、日志、多媒體對象等，在對數(shù)據(jù)做存儲和管理設(shè)計時，應(yīng)按實時/異步，明細/匯聚，年/月 /日等維度對數(shù)據(jù)的收集和使用進行分級管理，并對相應(yīng)數(shù)據(jù)的存儲做分層管理，并配套規(guī)劃相應(yīng)的創(chuàng)建、保護（備份和加密）、訪問、遷移、歸檔和銷毀機制，實現(xiàn)數(shù)據(jù)和信息的生命周期管理。從而提高數(shù)據(jù)的存儲、使用和維護的效率，系統(tǒng)運營質(zhì)量。1.4 系統(tǒng)組網(wǎng)邊界清晰在業(yè)務(wù)系統(tǒng)架構(gòu)方案時，特別是組網(wǎng)架構(gòu)上，應(yīng)明確系統(tǒng)邊界，做到結(jié)構(gòu)合理、邊界清晰。對于業(yè)務(wù)系統(tǒng)內(nèi)部的交互，應(yīng)全部在邊界內(nèi)部完成，業(yè)務(wù)系統(tǒng)對于外部的出和入，都應(yīng)單獨設(shè)計的暴露機制，根據(jù)業(yè)務(wù)場景對于暴露能力需求建立相應(yīng)的能力指標，系統(tǒng)投產(chǎn)前根據(jù)指標要求進

7、行相應(yīng)的壓力測試。一般邊界不清晰系統(tǒng)的情況，對于主動出去訪問外部系統(tǒng)的，對端可以看到本系統(tǒng)暴露接口之外的資源，諸如系統(tǒng)其他內(nèi)部節(jié)點、主機名、域名、IP、 MAC 等等；對于被動接入外部系統(tǒng)訪問的，對端可以訪問到本系統(tǒng)暴露接口之外的資源，諸如統(tǒng)其他內(nèi)部節(jié)點、主機名、域名、IP、URL、端口、服務(wù)等等1.5 數(shù)據(jù)一致性對于存在數(shù)據(jù)交互的業(yè)務(wù)場景，如果是分布式組件，或者采用前后端調(diào)用、異步事物處理、 動態(tài)緩存等機制時，應(yīng)在流程設(shè)計時考慮到數(shù)據(jù)一致性的問題，通過數(shù)據(jù)稽核審計、或者流程內(nèi)部的校驗機制來保障前后端、緩存、 固話數(shù)據(jù)之間的數(shù)據(jù)一致性，避免由于數(shù)據(jù)不同步造成的業(yè)務(wù)問題。按數(shù)據(jù)一致性的實現(xiàn)方式，

8、分為通過流程設(shè)計保證數(shù)據(jù)一致性，通過稽核審計保證數(shù)據(jù)一致性，通過流程設(shè)計+稽核審計實現(xiàn)數(shù)據(jù)一致性三類。2. 靈活和便捷性在系統(tǒng)方案設(shè)計時，應(yīng)充分考慮架構(gòu)、組網(wǎng)、數(shù)據(jù)流轉(zhuǎn)、選用組件等方面，根據(jù)不同業(yè)務(wù)功能和非功能需求的要求，滿足系統(tǒng)在部署、擴容、業(yè)務(wù)運營、系統(tǒng)維護等場景下的靈活性和便捷性。2.1 產(chǎn)品、方案與系統(tǒng)、組件耦合度對于云上的業(yè)務(wù)系統(tǒng)，應(yīng)從產(chǎn)品選型、方案設(shè)計、系統(tǒng)邏輯、組件選擇方面考慮通用性和便捷性。對于同樣功能點的組件，應(yīng)設(shè)計為能夠支持多種通用性產(chǎn)品，或多個通用版本，避免對特定產(chǎn)品和特定版本的依賴。如應(yīng)用對操作系統(tǒng)環(huán)境的要求應(yīng)適配通用的linux 版本， 中間件當支持tomcat、 n

9、ginx、 httpd 等多種產(chǎn)品，數(shù)據(jù)庫可兼容oracle、 mysql、pg 等，并支持組件的多個常見通用版本。2.2 配置化程度對于云上的業(yè)務(wù)系統(tǒng)，從靈活便捷的角度，建議考慮在集成部署、運維管理、業(yè)務(wù)運營、業(yè)務(wù)服務(wù)四個層面，根據(jù)實際場景需要，設(shè)計可配置化的機制。以此增強系統(tǒng)對于不同底層環(huán)境、網(wǎng)絡(luò)環(huán)境、操作系統(tǒng)、組件、業(yè)務(wù)環(huán)境、管理流程和機制等方面的外部環(huán)境有更好的適配度和兼容性，滿足云資源池不同組件和環(huán)境下的承載需要。2.3 彈性伸縮彈性伸縮即根據(jù)需求或者預(yù)定策略，快速調(diào)整計算資源，且對系統(tǒng)運行和業(yè)務(wù)服務(wù)沒有重大影響。例如，可通過設(shè)置定時、周期或監(jiān)控條件策略，自動或手動調(diào)整組件實例、進程

10、或者服務(wù)資源配置，使云資源能夠靈活的分配到業(yè)務(wù)需求的應(yīng)用上去，降低服務(wù)成本。 根據(jù)彈性伸縮設(shè)計的機制，可分三類，一是在線進行，即手動配置部署組件、進程、服務(wù)等方式，不中斷業(yè)務(wù)服務(wù)情況下進行資源伸縮；二是半自動化，即通過一鍵式或者一個腳本方式，實現(xiàn)快速資源伸縮，對比第一類資源伸縮達成速度更快（秒級）；三是全自動化，即根據(jù)預(yù)定義策略，根據(jù)時間、業(yè)務(wù)量、監(jiān)控閾值等無人工干預(yù)的實現(xiàn)資源伸縮。2.4 無狀態(tài)化對于云上的業(yè)務(wù)系統(tǒng)，阻礙服務(wù)處理能力平行擴展的最大制約在于狀態(tài)的處理。狀態(tài)化的系統(tǒng)會將業(yè)務(wù)邏輯、系統(tǒng)配置、調(diào)用關(guān)系等應(yīng)用和系統(tǒng)的狀態(tài)保存在本地，從而阻礙架構(gòu)的快速橫向擴展。為保證云上系統(tǒng)的快速橫向擴

11、展能力，建議在架構(gòu)設(shè)計時實現(xiàn)系統(tǒng)配置無狀態(tài)化，對業(yè)務(wù)處理邏輯實現(xiàn)無狀態(tài)，而將狀態(tài)信息保存到諸如緩存、數(shù)據(jù)庫、共享存儲、消息隊列等有狀態(tài)的組件中。一般無狀態(tài)化的系統(tǒng)，具備較好的彈性伸縮能力。2.5 分布式架構(gòu)對于云上的業(yè)務(wù)系統(tǒng)，為提高服務(wù)性能和業(yè)務(wù)擴展能力，建議在設(shè)計時全部或部分地采用分布式架構(gòu)設(shè)計。根據(jù)分布式組件工作范圍，分為整體采用分布式架構(gòu)設(shè)計，核心組件或部分主要組件采用分布式架構(gòu)設(shè)計，部分組件實現(xiàn)分布式架構(gòu)設(shè)計等情況。3. 服務(wù)連續(xù)性 本條目從云上系統(tǒng)業(yè)務(wù)服務(wù)連續(xù)性需求角度出發(fā)，對于常見系統(tǒng)架構(gòu)、機制、組件、節(jié)點等方面給予參考意見，以確保系統(tǒng)業(yè)務(wù)服務(wù)滿足要求。3.1 服務(wù)自啟動云上的業(yè)務(wù)

12、系統(tǒng)，對于節(jié)點、虛機、容器等承載資源服務(wù)中斷后的恢復(fù)，資源之上的系統(tǒng)、應(yīng)用、進程、服務(wù)、組件等應(yīng)當能夠在自動啟動并恢復(fù)功能，以適應(yīng)云計算平臺的運行特性，減少非必要的業(yè)務(wù)中斷。3.2 集群化或主備部署對于云上的業(yè)務(wù)系統(tǒng)，建議主要功能節(jié)點、組件通過集群化或者主從模式進行部署，避免出現(xiàn)單點故障。當個別實例或節(jié)點故障時，業(yè)務(wù)應(yīng)當盡可能無感知地實現(xiàn)接管和切換。按照接管時的影響情況，分為降級無感知、降級弱感知和手動切換三類。3.3 負載均衡云上的業(yè)務(wù)系統(tǒng)建議在前端接入配置負載均衡的機制，以確保服務(wù)接入側(cè)的性能擴展能力和服務(wù)高可用性。按接管和切換方式，分為無感知接管，弱感知接管（刷新或者重新登錄）或者手動調(diào)

13、整接入（域名調(diào)整、路由調(diào)整）等類型。3.4 組件和節(jié)點間松耦合，調(diào)用弱關(guān)聯(lián)云上的應(yīng)用方案或系統(tǒng)架構(gòu)，建議各組件或者節(jié)點間采用松耦合方式，系統(tǒng)調(diào)用弱關(guān)聯(lián)，例如使用連接池、集群化、短連接、異步、消息隊列等方式降低各環(huán)節(jié)的耦合性。實現(xiàn)各個節(jié)點、進程、服務(wù)均可實現(xiàn)單獨配置、啟停，特別要避免單個組件或節(jié)點的異?；謴?fù)，需要系統(tǒng)各組件按照一定順序啟動的情況。3.5 應(yīng)急容災(zāi)能力系統(tǒng)根據(jù)業(yè)務(wù)場景需求出發(fā)，根據(jù)自身服務(wù)連續(xù)性需要進行容災(zāi)或應(yīng)急能力考慮，在云環(huán)境下從應(yīng)用架構(gòu)層面規(guī)劃和設(shè)計應(yīng)用和系統(tǒng)級的容災(zāi)及應(yīng)急方案。應(yīng)急容災(zāi)能力的實效性顆粒分為實時和延時。實時容災(zāi)或應(yīng)急能力可以在秒級甚至毫秒級實現(xiàn)系統(tǒng)容災(zāi)切換或應(yīng)

14、用應(yīng)急接管。延時容災(zāi)或應(yīng)急能力可以在有限干預(yù)的條件下實現(xiàn)系統(tǒng)容災(zāi)切換或應(yīng)用應(yīng)急接管工作。一般情況下應(yīng)急從業(yè)務(wù)服務(wù)層面考慮，容災(zāi)是從數(shù)據(jù)安全和環(huán)境安全層面考慮，容災(zāi)系統(tǒng)一般采用異地方式構(gòu)建。3.6 服務(wù)能力降級設(shè)計云上的業(yè)務(wù)系統(tǒng)應(yīng)實現(xiàn)服務(wù)能力降級設(shè)計，當硬件、系統(tǒng)、組件等部件出現(xiàn)異常時，可提供降級的服務(wù)能力，如服務(wù)規(guī)模的降級，服務(wù)功能降級，服務(wù)性能降級等。例如， CRM系統(tǒng)中，部分組件或者硬件故障，不會引起整體系統(tǒng)服務(wù)中斷，如單個功能業(yè)務(wù)記錄查詢可以查詢到部分用戶記錄，或者可以查詢到用戶的部分時段記錄，再如業(yè)務(wù)變更、銷賬等功能關(guān)聯(lián)組件異常，不會影響到其他開戶、充值等業(yè)務(wù)的服務(wù)。4. 維護管理本條

15、目從運維管理角度對云上的業(yè)務(wù)系統(tǒng)進行評估，提高系統(tǒng)的可維護性。4.1 監(jiān)控告警體系云上的業(yè)務(wù)系統(tǒng)應(yīng)實現(xiàn)完整的監(jiān)控告警體系.可分層分級實現(xiàn)端到端監(jiān)控，并實現(xiàn)多觸點通告和統(tǒng)一配置處理功能，并提供告警處理手冊和標準化的告警接口。4.2 日志管理體系云上的業(yè)務(wù)系統(tǒng)應(yīng)當具備完善的日志管理體系?？煞謱臃旨売涗洃?yīng)用及系統(tǒng)日志，實現(xiàn)業(yè)務(wù)與系統(tǒng)的串聯(lián)分析，日志目錄空間的自循環(huán)和統(tǒng)一集中管理。4.3 集中統(tǒng)一的運維管理云上的業(yè)務(wù)系統(tǒng)應(yīng)當具備集中統(tǒng)一的運維管理界面，可通過管理界面實現(xiàn)系統(tǒng)部署，平行擴容，架構(gòu)變更，系統(tǒng)配置，上線發(fā)布，服務(wù)、組件、集群啟停，應(yīng)急管理，數(shù)據(jù)備份等運維工作。4.4 備份機制云上的業(yè)務(wù)系統(tǒng)應(yīng)

16、當考慮建立健全的備份機制，從系統(tǒng)備份、數(shù)據(jù)備份、歷史數(shù)據(jù)歸檔等層級分級實現(xiàn)備份功能。并且可定期進行恢復(fù)測試驗證。5. 信息安全5.1 安全漏洞云上的業(yè)務(wù)系統(tǒng)應(yīng)當及時修復(fù)各類中、高危漏洞，業(yè)務(wù)系統(tǒng)本身不能存在可被利用的安全漏洞，系統(tǒng)基線配置應(yīng)符合公司和行業(yè)的安全管理要求。5.2 系統(tǒng)安全設(shè)計云上的業(yè)務(wù)系統(tǒng)在系統(tǒng)設(shè)計層面應(yīng)考慮系統(tǒng)安全因素，對敏感數(shù)據(jù)的存放、傳輸?shù)葢?yīng)進行加密保護。對相應(yīng)的操作應(yīng)具備記錄和審計管理功能。在日志記錄及數(shù)據(jù)暴露環(huán)節(jié)應(yīng)對敏感數(shù)據(jù)進行脫敏處理。5.3 敏感數(shù)據(jù)訪問敏感數(shù)據(jù)訪問應(yīng)符合相關(guān)的管理規(guī)范要求。6. 傳統(tǒng)非云化系統(tǒng)設(shè)計本條目列舉了一些傳統(tǒng)非云化的業(yè)務(wù)類型，此類業(yè)務(wù)系統(tǒng)并

17、不適合云環(huán)境部署。6.1 物理設(shè)備或鏈路要求的業(yè)務(wù)應(yīng)用或服務(wù)依賴于物理設(shè)備或物理鏈路的業(yè)務(wù)類型不適合云環(huán)境部署。如依賴于USB證書認證的服務(wù)，或者需要物理心跳網(wǎng)絡(luò)的業(yè)務(wù)。6.2 有針對物理設(shè)備冗余機制的業(yè)務(wù)對物理設(shè)備本身即具備冗余機制的業(yè)務(wù)類型不適合部署到云環(huán)境。比如對存儲環(huán)境有多副本需求的場景，如 hadoop集群的三副本機制、access軟件定義存儲的鏡像機制等。6.3 數(shù)據(jù)密集型業(yè)務(wù)本身包含并存儲了海量數(shù)據(jù)的業(yè)務(wù)類型不適合部署到云環(huán)境。如大數(shù)據(jù)類業(yè)務(wù)、數(shù)據(jù)倉庫、海量靜態(tài)數(shù)據(jù)、視頻類、流媒體業(yè)務(wù)。四、上云系統(tǒng)架構(gòu)先進性評上云系統(tǒng)架構(gòu)評工作，旨在系統(tǒng)架構(gòu)設(shè)計之初，能夠根據(jù)業(yè)務(wù)服務(wù)、業(yè)務(wù)運營、

18、系統(tǒng)運營、系統(tǒng)維護等IT 系統(tǒng)各環(huán)節(jié)場景需求，結(jié)合云平臺資源池資源與服務(wù)能力，綜合考慮云化系統(tǒng)各方面設(shè)計情況，評上云系統(tǒng)架構(gòu)情況與風(fēng)險，指導(dǎo)后續(xù)的系統(tǒng)運營和業(yè)務(wù)運營工作。上云架構(gòu)先進性評主要分為以下幾個步驟開展：1. 上云系統(tǒng)的建設(shè)單位，新建系統(tǒng)在立項完成后，老系統(tǒng)遷移上云在計劃資源申請之前，由系統(tǒng)建設(shè)單位負責，將本指導(dǎo)意見及評估表交系統(tǒng)建設(shè)團隊或開發(fā)集成團隊，在系統(tǒng)架構(gòu)設(shè)計，系統(tǒng)整體設(shè)計方案時， 應(yīng)充分參考本指導(dǎo)意見的各項內(nèi)容，在系統(tǒng)整體方案設(shè)計完成的同時，完成上云系統(tǒng)架構(gòu)評估表的自評部分，并對各項自評評分進行充分的解釋說明。并將系統(tǒng)整體方案與評估表提交私有云運營單位。2 .私有云運營單位收到相關(guān)材料后，根據(jù)情況對系統(tǒng)架構(gòu)