多種因素驅(qū)動(dòng)著技術(shù)架構(gòu)復(fù)雜性不斷增大，要做好運(yùn)維管理難度將呈指數(shù)增大。在運(yùn)維過程中，運(yùn)維需要持續(xù)推進(jìn)架構(gòu)的優(yōu)化，比如應(yīng)用與數(shù)據(jù)庫在服務(wù)器層面分離，利用集群部署方式提升并發(fā)能力，數(shù)據(jù)庫讀寫分離提升數(shù)據(jù)庫性能，反向代理及CDN加速提升前端訪問速度，拆分業(yè)務(wù)或數(shù)據(jù)庫提升性能，同步改異步方式提升并發(fā)能力，有損服務(wù)與降級(jí)提升故障恢復(fù)能力等。發(fā)揮運(yùn)維核心價(jià)值，不僅要保障基礎(chǔ)設(shè)施層面的高可用，還要不斷向業(yè)務(wù)側(cè)深入，加強(qiáng)軟件架構(gòu)管理能力。同時(shí)，架構(gòu)是運(yùn)維數(shù)字世界的骨架，沉淀了團(tuán)隊(duì)眾多專家的經(jīng)驗(yàn)，是一項(xiàng)核心資產(chǎn)，需要在運(yùn)維側(cè)建立架構(gòu)管理的工作機(jī)制，沉淀架構(gòu)資產(chǎn)，達(dá)到持續(xù)提升業(yè)務(wù)連續(xù)性、加快軟件交付速度、提高服務(wù)質(zhì)量、提升客戶體驗(yàn)的運(yùn)維價(jià)值創(chuàng)造。
一、關(guān)于架構(gòu)
技術(shù)架構(gòu)是一個(gè)基礎(chǔ)設(shè)施、應(yīng)用平臺(tái)、企業(yè)應(yīng)用系統(tǒng)、應(yīng)用模塊的技術(shù)基礎(chǔ)，是根據(jù)業(yè)務(wù)、技術(shù)、組織、可擴(kuò)展性、可維護(hù)性等因素驅(qū)動(dòng)，由企業(yè)研發(fā)、測(cè)試、運(yùn)維，以及供應(yīng)商、業(yè)務(wù)人員等領(lǐng)域?qū)＜覍?duì)信息系統(tǒng)的知識(shí)沉淀。運(yùn)維要深入了解系統(tǒng)，需要深入理解架構(gòu)，優(yōu)化架構(gòu)，并為架構(gòu)提供標(biāo)準(zhǔn)及平臺(tái)能力支持。
百度百科中，對(duì)軟件架構(gòu)作了定義“是一系列相關(guān)的抽象模式，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)，是一個(gè)系統(tǒng)的草圖，描述的對(duì)象是直接構(gòu)成系統(tǒng)的抽象組件。各個(gè)組件之間的連接則明確和相對(duì)細(xì)致地描述組件之間的通訊。”以下，嘗試從定義中摘四個(gè)關(guān)鍵詞：模式、組件、連接、描述，看看架構(gòu)：
模式：解決特定問題提出的通用、可重用的解決方案，比如分層、事件驅(qū)動(dòng)、分布式、緩存、異步、冗余等。
組件：獨(dú)立的模塊，比如應(yīng)用服務(wù)、數(shù)據(jù)庫、中間件等。
連接：組件間的調(diào)用、訪問關(guān)系。
描述：對(duì)模式、組件、連接的整體描述，比如架構(gòu)圖。
也就是說，理解一個(gè)技術(shù)架構(gòu)先理解是屬于哪一種或哪幾種模式組成，基于這些模式我們通常都能相對(duì)方便的獲得最佳實(shí)踐的指導(dǎo)，了解模式也是為了將復(fù)雜、多樣化的業(yè)務(wù)、中間件、數(shù)據(jù)庫、基礎(chǔ)設(shè)施等信息進(jìn)行抽象簡(jiǎn)化，更好的理解及執(zhí)行舉措。接下來是梳理組成系統(tǒng)的技術(shù)組件，組件是基于模式最佳實(shí)踐進(jìn)行配置。組件之間會(huì)產(chǎn)生關(guān)系而非孤立運(yùn)行，系統(tǒng)內(nèi)部組件之間以及系統(tǒng)間組件之間會(huì)有調(diào)用訪問關(guān)系，應(yīng)用層的組件與系統(tǒng)、中間件、平臺(tái)、基礎(chǔ)設(shè)施之間也會(huì)有縱向的依賴關(guān)系。架構(gòu)很重要，但要讓架構(gòu)真正賦能運(yùn)維，需要讓架構(gòu)可觀察，需要利用數(shù)字化手段描述架構(gòu)，讓架構(gòu)可觀察，更好的使用。
二、常見架構(gòu)
技術(shù)架構(gòu)的核心價(jià)值是為業(yè)務(wù)服務(wù)提供最優(yōu)解，只有最合適的架構(gòu)，以下從應(yīng)用、系統(tǒng)軟件、基礎(chǔ)設(shè)施3個(gè)層面大概羅列一下在運(yùn)維過程中經(jīng)常關(guān)注的架構(gòu)。
1、應(yīng)用層面
單體、SOA、微服務(wù)是軟件層面常見的三種技術(shù)架構(gòu)，對(duì)于運(yùn)維而言，每種架構(gòu)都有各自的優(yōu)劣勢(shì)。
（1）單體架構(gòu)
在企業(yè)存量系統(tǒng)中，尤其是內(nèi)部管理類，或?qū)Σl(fā)要求不高，或變更迭代少系統(tǒng)，很多屬于單體架構(gòu)。單體架構(gòu)通常指所有功能模塊的制品打包在一起，并部署在一個(gè)中間件容器中運(yùn)行，單體架構(gòu)廣泛應(yīng)用在存量比較舊的系統(tǒng)以及一些簡(jiǎn)單應(yīng)用。在運(yùn)維側(cè)，單體架構(gòu)有利有弊，好的地方是系統(tǒng)架構(gòu)邏輯簡(jiǎn)單好理解，應(yīng)急保障、變更部署、技術(shù)驗(yàn)證及測(cè)試、系統(tǒng)擴(kuò)容方案等運(yùn)維行為容易固化、標(biāo)準(zhǔn)化，有利于專家經(jīng)驗(yàn)的培養(yǎng)；不好的地方是單體架構(gòu)面臨模塊緊耦合，制品包過大，牽一發(fā)動(dòng)全身，可維護(hù)性、擴(kuò)展性會(huì)隨著時(shí)間推移而降低，維護(hù)成本會(huì)加大，故障隔離性差，程序故障修復(fù)慢。
（2）SOA
面向服務(wù)的架構(gòu)（SOA）是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）進(jìn)行拆分，每個(gè)組件對(duì)應(yīng)一個(gè)完整的業(yè)務(wù)邏輯，并通過這些服務(wù)之間定義良好的接口和協(xié)議聯(lián)系起來。與單體架構(gòu)相比，SOA架構(gòu)采用一種松耦合服務(wù)架構(gòu)，以服務(wù)為中心各個(gè)系統(tǒng)之間依靠ESB進(jìn)行調(diào)用。從運(yùn)維側(cè)看，SOA的架構(gòu)在初期通常會(huì)給運(yùn)維增加難度。從運(yùn)維人員角度，單體架構(gòu)從硬件服務(wù)器、中間件、應(yīng)用程序、數(shù)據(jù)庫等組件部署方式很清晰，當(dāng)出一個(gè)故障時(shí)，運(yùn)維人員憑經(jīng)驗(yàn)即可快速定位問題。但是采用SOA架構(gòu)，軟件、服務(wù)部署在不同的設(shè)備上，同一個(gè)業(yè)務(wù)涉及多個(gè)系統(tǒng)、多個(gè)團(tuán)隊(duì)的協(xié)同，而某一個(gè)服務(wù)組件的單點(diǎn)或異常也會(huì)產(chǎn)生全局性的影響。好在，隨著應(yīng)用架構(gòu)高可用不斷完善，以及運(yùn)維工具平臺(tái)賦能，改善了SOA架構(gòu)的運(yùn)維難度，并更好的利用好SOA帶來的擴(kuò)展性。
（3）微服務(wù)
微服務(wù)在SOA的基礎(chǔ)上，強(qiáng)調(diào)了服務(wù)組件的“微”，微服務(wù)的每個(gè)服務(wù)對(duì)應(yīng)單獨(dú)的功能或任務(wù)，同時(shí)微服務(wù)不再?gòu)?qiáng)調(diào)SOA架構(gòu)中ESB企業(yè)服務(wù)總線這種中央管控式的架構(gòu)。由于每個(gè)服務(wù)都專注某一細(xì)分的功能，邏輯相對(duì)單一，單個(gè)服務(wù)更加易于開發(fā)與維護(hù)，在架構(gòu)上更利于擴(kuò)展性。同樣，站在運(yùn)維側(cè)，微服務(wù)帶來一系列優(yōu)點(diǎn)同時(shí)，也進(jìn)一步增加了運(yùn)維的難度，原來一個(gè)單體系統(tǒng)主要采用幾臺(tái)強(qiáng)大性能的服務(wù)器部署，而采用微服務(wù)可能會(huì)被拆成幾十個(gè)服務(wù)部署在不同的服務(wù)器上，調(diào)用鏈路更加復(fù)雜。
2、系統(tǒng)軟件層面
（1）數(shù)據(jù)庫
數(shù)據(jù)不丟是運(yùn)維的生命線，數(shù)據(jù)庫架構(gòu)重點(diǎn)圍繞高可用、高性能、一致性、擴(kuò)展性。常見的數(shù)據(jù)庫架構(gòu)高可用方案包括：
主備架構(gòu)：主機(jī)負(fù)責(zé)讀寫，備機(jī)只負(fù)責(zé)故障轉(zhuǎn)移，通常采用主備共享一份數(shù)據(jù)存儲(chǔ)，或采用數(shù)據(jù)復(fù)制方法同步數(shù)據(jù)到備機(jī)。主備切換通過心跳機(jī)制自動(dòng)或手工切換，分別對(duì)應(yīng)熱備與冷備。
主從架構(gòu)：包括一主一從或一主多從的架構(gòu)，主機(jī)負(fù)責(zé)寫，從庫負(fù)責(zé)讀，實(shí)現(xiàn)讀寫分離，主從架構(gòu)根據(jù)應(yīng)用需要可以設(shè)置主從數(shù)據(jù)一致性要求。
分布式架構(gòu)：重點(diǎn)解決了大表的讀寫問題，通常是利用數(shù)據(jù)庫分布式中間件，實(shí)現(xiàn)數(shù)據(jù)庫事務(wù)、數(shù)據(jù)處理。數(shù)據(jù)庫中間件使底層分布式數(shù)據(jù)對(duì)于上層應(yīng)用而言是透明的，相當(dāng)一個(gè)邏輯數(shù)據(jù)庫。在數(shù)據(jù)庫分布式中間件下，對(duì)原本大表進(jìn)行分庫分表。
針對(duì)數(shù)據(jù)庫性能問題，通常首先會(huì)從SQL語句、索引、清理數(shù)據(jù)、優(yōu)化程序邏輯等方式進(jìn)行優(yōu)化。其次是架構(gòu)層面的優(yōu)化，比如主備架構(gòu)的優(yōu)化通常采用縱向擴(kuò)容方式，即加服務(wù)器資源，換性能更強(qiáng)的服務(wù)器提升服務(wù)能力，或遷移大表；或從應(yīng)用角度將查詢多與寫入多的邏輯區(qū)分開，對(duì)應(yīng)將數(shù)據(jù)庫進(jìn)行垂直切分成多個(gè)數(shù)據(jù)庫。
（2）其他模塊
其他系統(tǒng)軟件的組件還包括：像服務(wù)注冊(cè)與發(fā)現(xiàn)涉及的ZK、Eureka，消息中間件中的kafka，多種XXXXMQ，DNS域名解釋服務(wù)，CDN服務(wù)，nginx等負(fù)載均衡軟件，ES搜索引擎等，這些主流的架構(gòu)組件通常都會(huì)有一些比較成熟的部署方案。我覺得運(yùn)維側(cè)重點(diǎn)要推動(dòng)研發(fā)對(duì)于組件的標(biāo)準(zhǔn)化，同時(shí)配備相應(yīng)的云資源服務(wù)，以及監(jiān)控、自動(dòng)化相關(guān)工具，以更好的支持此類組件模塊的可維護(hù)性。
3、基礎(chǔ)設(shè)施層面
基礎(chǔ)設(shè)施層面，對(duì)于金融行業(yè)，在數(shù)據(jù)中心層面主要采用兩地三中心的架構(gòu)，三中心指主中心、同城備份中心、異地災(zāi)備中心，在實(shí)際的實(shí)施上有些企業(yè)會(huì)在兩地三中心基礎(chǔ)上增加同城災(zāi)備中心解決異常災(zāi)備中心數(shù)據(jù)同步時(shí)效性問題，租用異地機(jī)房解決終端接入，或引入行業(yè)云、公有云補(bǔ)充彈性擴(kuò)容能力等方式，組成了混合云的基礎(chǔ)設(shè)施架構(gòu)。對(duì)于應(yīng)用系統(tǒng)架構(gòu)，基礎(chǔ)設(shè)施層架構(gòu)一方面屏蔽了基礎(chǔ)設(shè)施層的復(fù)雜性，提供良好擴(kuò)展性的基礎(chǔ)設(shè)施服務(wù)；另一方面基礎(chǔ)設(shè)施架構(gòu)也向上層應(yīng)用提出雙活、多活等更高的要求，驅(qū)動(dòng)應(yīng)用系統(tǒng)的架構(gòu)升級(jí)，云原生應(yīng)用架構(gòu)、微服務(wù)架構(gòu)模式為新的業(yè)務(wù)系統(tǒng)架構(gòu)提供了最佳實(shí)踐，在用的存量系統(tǒng)則是另一個(gè)難題。
三、運(yùn)維側(cè)關(guān)注的架構(gòu)問題
不同的崗位角色對(duì)于架構(gòu)的關(guān)注點(diǎn)不同，比如業(yè)務(wù)架構(gòu)師重點(diǎn)業(yè)務(wù)規(guī)劃，業(yè)務(wù)模塊、業(yè)務(wù)流程，對(duì)整個(gè)系統(tǒng)業(yè)務(wù)進(jìn)行拆分，對(duì)領(lǐng)域模型進(jìn)行設(shè)計(jì)，抽象模型；研發(fā)工程師重點(diǎn)關(guān)注架構(gòu)分層、數(shù)據(jù)模型、設(shè)計(jì)模式、接口、數(shù)據(jù)交互等，運(yùn)維工程師則更關(guān)注高可用、故障恢復(fù)、性能擴(kuò)展性、數(shù)據(jù)完整性、數(shù)據(jù)備份、自動(dòng)化及灰度發(fā)布、可觀察等。
1、高可用角度
站在運(yùn)維角度看技術(shù)架構(gòu)的高可用，通俗的話就是消滅單點(diǎn)風(fēng)險(xiǎn)，像前面數(shù)據(jù)庫中提到的主備、主從、分布式，以及數(shù)據(jù)中心的兩地三中心都是高可用方案之一，而像RPO與PTO則是高可用的量化評(píng)估方案。運(yùn)維強(qiáng)調(diào)高可用主要是由于運(yùn)維面臨的研發(fā)團(tuán)隊(duì)通常更關(guān)注業(yè)務(wù)功能的實(shí)現(xiàn)，而對(duì)架構(gòu)的高可用關(guān)注較少，這種情況尤其出現(xiàn)在新系統(tǒng)交付生產(chǎn)的情況。所以，一方面，運(yùn)維需要在硬件、軟件、平臺(tái)等層面，為應(yīng)用提供高可用的基礎(chǔ)服務(wù)能力，比如將一個(gè)應(yīng)用系統(tǒng)同一個(gè)服務(wù)組件部署在多個(gè)數(shù)據(jù)中心機(jī)房，不同物理機(jī)的多個(gè)虛擬機(jī)上，為應(yīng)用的負(fù)載均衡提供網(wǎng)絡(luò)硬件或軟件負(fù)載均衡器，提供具備高可用架構(gòu)的數(shù)據(jù)庫、消息中間件等PAAS云服務(wù)。另一個(gè)方面，運(yùn)維需要提前提供架構(gòu)高可用的規(guī)范，制定通用組件高可用技術(shù)參考模式，將高可用理念更早的落地在研發(fā)過程中。
2、性能角度
關(guān)于性能會(huì)有一些黃金指標(biāo)，比如：響應(yīng)時(shí)間（系統(tǒng)，功能，或服務(wù)組件完成一次外部請(qǐng)求處理所需的時(shí)間）、吞吐率（在指定時(shí)間內(nèi)能夠處理的最大請(qǐng)求量）、負(fù)載（服務(wù)組件當(dāng)前負(fù)荷情況）、效率（性能除以資源，比如QPS=并發(fā)量/平均響應(yīng)時(shí)間）、可擴(kuò)展性（垂直或水平擴(kuò)容的能力）等是運(yùn)維需要關(guān)注的一些性能指標(biāo)。
性能問題對(duì)于運(yùn)維的挑戰(zhàn)不僅僅是單組件不可用，更嚴(yán)重的是某個(gè)組件性能問題不斷擴(kuò)散到別的組件，導(dǎo)致大規(guī)模的故障，這種故障可能是由于一個(gè)極小的問題迅速擴(kuò)散出去。業(yè)務(wù)運(yùn)維可能經(jīng)常會(huì)遇到這樣的場(chǎng)景：某個(gè)服務(wù)組件功能響應(yīng)時(shí)間增長(zhǎng)，外部請(qǐng)求等待時(shí)間增加，等待的并發(fā)進(jìn)程增加（假設(shè)響應(yīng)時(shí)間過長(zhǎng)、非異部響應(yīng)），數(shù)據(jù)庫并發(fā)連接數(shù)增加，數(shù)據(jù)庫連接數(shù)據(jù)全部占滿，數(shù)據(jù)庫無法接收新的請(qǐng)求，引發(fā)全局性故障。這類性能問題在谷歌SRE解密一文中有一章關(guān)于連鎖故障的介紹。運(yùn)維需要驅(qū)動(dòng)研發(fā)側(cè)一起梳理這類鏈路請(qǐng)求的風(fēng)險(xiǎn)點(diǎn)，故障恢復(fù)角度進(jìn)行架構(gòu)的優(yōu)化。
3、故障恢復(fù)角度
從架構(gòu)角度看故障恢復(fù)，運(yùn)維可以依據(jù)一些最佳實(shí)踐的思路，推動(dòng)架構(gòu)的優(yōu)化，比如：
應(yīng)用拆分：邏輯上分析業(yè)務(wù)主流程，將分支交易進(jìn)行分離，按業(yè)務(wù)功能拆分獨(dú)立的服務(wù)；物理上將獨(dú)立的服務(wù)進(jìn)行分離，獨(dú)立部署，出現(xiàn)問題后可以快速采取措施進(jìn)行隔離或擴(kuò)容。
服務(wù)或系統(tǒng)交互解耦：如WEB到邏輯服務(wù)前加隊(duì)列層，減少前端放開流量導(dǎo)致后端處理能力跟不上的問題；數(shù)據(jù)庫前加上緩存層，減少數(shù)據(jù)庫的并發(fā)壓力。
減少總線節(jié)點(diǎn)服務(wù)的依賴：由多節(jié)點(diǎn)組成的邏輯交互改為端對(duì)端的訪問方式，一方面減少影響交易的因素，另一方面減少自身性能問題影響其它應(yīng)用系統(tǒng)。
增加異步訪問機(jī)制：同步的機(jī)制在性能出現(xiàn)問題時(shí)，會(huì)在短時(shí)間花完最大連接數(shù)，哪怕這個(gè)最大并發(fā)數(shù)是正常情況下的10倍。這方面可以直接改異步通訊，也可以引入一些隊(duì)列工具實(shí)現(xiàn)。
多層次的緩存：緩存的引入可以多層次，從前端、應(yīng)用內(nèi)部、數(shù)據(jù)庫等，比如：前端頁面可以利用緩存技術(shù)減少頁面刷新，這方面可以采用網(wǎng)絡(luò)工具解決；數(shù)據(jù)庫前可以采用REDIS等；應(yīng)用自身同樣可以用緩存代替數(shù)據(jù)庫的讀操作；
數(shù)據(jù)庫優(yōu)化：1）架構(gòu)上：拆庫、在線庫與歷史庫分離、分布式數(shù)據(jù)庫、讀寫分離、非關(guān)系型數(shù)據(jù)庫。比如：第1點(diǎn)應(yīng)用拆分后，則可以按業(yè)務(wù)拆庫；分布式數(shù)據(jù)庫實(shí)現(xiàn)數(shù)據(jù)分片讀寫等等。2）編碼上：SQL優(yōu)化、索引新增、數(shù)據(jù)定時(shí)清理，這個(gè)優(yōu)化方式最快，最容易出效果；減少數(shù)據(jù)庫訪問次數(shù)、減少數(shù)據(jù)庫一次返回的結(jié)果集；
前端限流、削峰機(jī)制，前端系統(tǒng)因?yàn)檫壿嫼?jiǎn)單往往可以支持更多請(qǐng)求，但后端系統(tǒng)則不同。所以需要前端系統(tǒng)做交易并發(fā)控制，并通過一些前端交互設(shè)計(jì)減少客戶的體驗(yàn)影響；
基礎(chǔ)設(shè)施支持快速擴(kuò)容：支持彈性擴(kuò)容（第1點(diǎn)系統(tǒng)拆分獨(dú)立部署很重要，可以減少擴(kuò)容復(fù)雜性）。
服務(wù)降級(jí)：重要服務(wù)重點(diǎn)保障，次要服務(wù)有損保障，緊急情況下進(jìn)行降級(jí)。
4、數(shù)據(jù)角度
大部份系統(tǒng)都會(huì)涉及持久化數(shù)據(jù)的相關(guān)組件，比如像關(guān)系型與非關(guān)系型數(shù)據(jù)庫，文件內(nèi)容管理等組件，對(duì)于數(shù)據(jù)通常需考慮架構(gòu)的高可用、事務(wù)一致性、數(shù)據(jù)完整性、性能擴(kuò)展能力、運(yùn)行及運(yùn)營(yíng)數(shù)據(jù)監(jiān)控管理等；同時(shí)，持久化數(shù)據(jù)的生命周期會(huì)比系統(tǒng)與硬件的生命周期還要長(zhǎng)，很多新系統(tǒng)上線或架構(gòu)調(diào)整都考慮數(shù)據(jù)遷移的工作；另外，還有一些系統(tǒng)涉及一些復(fù)雜性的數(shù)據(jù)處理，比如：批次、清算、對(duì)賬等操作，這些操作極易受數(shù)據(jù)問題影響，運(yùn)維側(cè)需要關(guān)注數(shù)據(jù)處理的異常中斷原因定位、哪些環(huán)節(jié)是可以應(yīng)急斷過、中斷后是否支持多次重試、與第三方系統(tǒng)約定數(shù)據(jù)不一致時(shí)以哪方為基準(zhǔn)等等應(yīng)急處置機(jī)制；最后，隨著系統(tǒng)復(fù)雜度變高，系統(tǒng)產(chǎn)生了更多的數(shù)據(jù)，數(shù)據(jù)被應(yīng)用的場(chǎng)景更多，對(duì)數(shù)據(jù)準(zhǔn)確性與性能響應(yīng)要求更高，這要求運(yùn)維能夠加強(qiáng)數(shù)據(jù)準(zhǔn)確性的管理，比如如何加強(qiáng)應(yīng)急數(shù)據(jù)維護(hù)的準(zhǔn)確性，減少臟數(shù)據(jù)，同時(shí)也要求運(yùn)維能夠增加對(duì)數(shù)據(jù)性能的管理。
5、非功能設(shè)計(jì)角度
從運(yùn)維側(cè)出發(fā)看非功能性設(shè)計(jì)，重點(diǎn)關(guān)注系統(tǒng)的可運(yùn)維性，可運(yùn)維性的好壞直接決定了系統(tǒng)在生產(chǎn)環(huán)境的成本與收益，甚至決定系統(tǒng)的生命周期的長(zhǎng)短。以下嘗試羅列一下運(yùn)維側(cè)需要推動(dòng)的非功能設(shè)計(jì)：
系統(tǒng)運(yùn)行狀況可觀察?？捎^察主要包括：監(jiān)控、日志、鏈路三塊，很多時(shí)候運(yùn)維是在一個(gè)成品上進(jìn)行監(jiān)控、日志、鏈路的完善，像NPM、APM、BPM等是運(yùn)維側(cè)發(fā)起的一些方案。從非功能設(shè)計(jì)看可觀察，需要運(yùn)維前移，推動(dòng)必要的監(jiān)控、日志、鏈路相關(guān)的研發(fā)規(guī)范，提升主動(dòng)上報(bào)監(jiān)控性能指標(biāo)數(shù)據(jù)的能力，優(yōu)化日志的可讀性，并提供必要的基礎(chǔ)設(shè)施服務(wù)支持，比如支持系統(tǒng)監(jiān)控?cái)?shù)據(jù)上報(bào)、日志采集分析等。
故障隔離與服務(wù)降級(jí)。故障隔離和服務(wù)降級(jí)的目的是以犧牲部分業(yè)務(wù)功能或者犧牲部分客戶業(yè)務(wù)為代價(jià)，保障更關(guān)鍵的業(yè)務(wù)或客戶群體服務(wù)質(zhì)量，是防止連鎖性故障蔓延的方法。在設(shè)計(jì)中，運(yùn)維側(cè)需要從系統(tǒng)或業(yè)務(wù)角度，梳理應(yīng)用系統(tǒng)所調(diào)用的各個(gè)服務(wù)組件，對(duì)各個(gè)服務(wù)組件出現(xiàn)故障時(shí)的假設(shè)，及應(yīng)對(duì)措施。
終端版本向下兼容。移動(dòng)化后終端版本的管理越來越重要，在架構(gòu)上一方面需要盡量保證升級(jí)后的版本要向下兼容正在流通的低版本的可用性；另一方面要對(duì)流通的版本進(jìn)行收斂管理，支持多種在線更新機(jī)制。
基于公司平臺(tái)運(yùn)行。無論是基礎(chǔ)設(shè)施平臺(tái)，還是PAAS層的應(yīng)用平臺(tái)，或持續(xù)交付工具鏈，系統(tǒng)均需要盡量與公司現(xiàn)有平臺(tái)對(duì)接，避免引入新的技術(shù)棧。
性能冗余設(shè)計(jì)。系統(tǒng)設(shè)計(jì)時(shí)要考慮最高并的情況，并在些基礎(chǔ)上增加性能支持的能力，防范業(yè)務(wù)量突增帶來的性能影響，相比業(yè)務(wù)連續(xù)性，資源成本的控制應(yīng)排后。
可配置而非硬編碼。經(jīng)常在應(yīng)急時(shí)，發(fā)現(xiàn)有些“參數(shù)”硬編碼在程序中，無法快速調(diào)整。另外，像IP這類信息的DNS域名改造也是可配置的一個(gè)方向，減少人工在后臺(tái)修改。
四、架構(gòu)管理流程
1、持續(xù)評(píng)估與優(yōu)化
運(yùn)維側(cè)推動(dòng)的架構(gòu)評(píng)審，按軟件生命周期看，主要包括四類：
一是運(yùn)維工作前移，在新項(xiàng)目設(shè)計(jì)階段進(jìn)行架構(gòu)評(píng)審。這類評(píng)審需標(biāo)準(zhǔn)化先行，由運(yùn)維側(cè)先提供高可用、性能、故障恢復(fù)、數(shù)據(jù)、可維護(hù)性涉及的架構(gòu)要求，并根據(jù)標(biāo)準(zhǔn)提供必要的基礎(chǔ)設(shè)施服務(wù)能力，讓研發(fā)側(cè)能更好的適配相關(guān)架構(gòu)要求。評(píng)審發(fā)現(xiàn)的問題，最好能夠作為一份備忘錄，在上線變更前進(jìn)行審核確認(rèn)，所以這項(xiàng)評(píng)審需要更早的介入，否則發(fā)現(xiàn)的問題無法得到有效解決。
二是上線前的變更評(píng)審。這類評(píng)審?fù)ǔＪ莚eview一下是否有重大的架構(gòu)風(fēng)險(xiǎn)，會(huì)影響現(xiàn)有業(yè)務(wù)或新業(yè)務(wù)的連續(xù)性，以決策何時(shí)變更，以及變更涉及的相應(yīng)的保障措施。評(píng)審發(fā)現(xiàn)的問題，根據(jù)緊迫程度需要由變更評(píng)審會(huì)建立相應(yīng)的待跟蹤任務(wù)。
三是系統(tǒng)上線后主動(dòng)組織的架構(gòu)評(píng)審。這種架構(gòu)評(píng)審是針對(duì)存量系統(tǒng)進(jìn)行主動(dòng)的架構(gòu)評(píng)審，和設(shè)計(jì)階段的架構(gòu)評(píng)審相比，這里的評(píng)審更加細(xì)致，范圍上可以是高可用、性能、故障恢復(fù)、數(shù)據(jù)、可維護(hù)性的所有點(diǎn)評(píng)審，也可以圍繞某一個(gè)點(diǎn)進(jìn)行專題的評(píng)審。評(píng)審后的改進(jìn)工作，通常可以通過問題單或任務(wù)的方式進(jìn)行跟進(jìn)。
四是基于事件驅(qū)動(dòng)推動(dòng)的架構(gòu)評(píng)審。事件驅(qū)動(dòng)的架構(gòu)評(píng)審?fù)ǔＪ轻槍?duì)某個(gè)生產(chǎn)故障、風(fēng)險(xiǎn)事件，或外部監(jiān)管要求等，圍繞某個(gè)特定的主題，可以針對(duì)事件涉及的系統(tǒng)，也可以舉一反三擴(kuò)大系統(tǒng)范圍。
在架構(gòu)評(píng)審過程中，建議有幾個(gè)方法供參考：
明確圍繞評(píng)審目標(biāo)范圍，比如前面提到的“高可用、性能、故障恢復(fù)、數(shù)據(jù)、可維護(hù)性”。
有標(biāo)準(zhǔn)才有公信力，師出有名；
流程機(jī)制保障評(píng)審的落實(shí)與評(píng)審結(jié)果跟蹤到位；
更早做評(píng)審，更早發(fā)現(xiàn)問題；
持續(xù)優(yōu)化的checklist；
讓評(píng)審專家有“權(quán)、利”；
以“找問題，找亮點(diǎn)”方式挖掘風(fēng)險(xiǎn)點(diǎn)，推廣最佳實(shí)踐；
設(shè)計(jì)好評(píng)審會(huì)的計(jì)劃、角色、過程。
2、架構(gòu)資產(chǎn)管理
架構(gòu)是團(tuán)隊(duì)專家經(jīng)驗(yàn)的結(jié)果，要將架構(gòu)資產(chǎn)化，得到專家經(jīng)驗(yàn)的傳承，架構(gòu)圖的管理是架構(gòu)資產(chǎn)化的一個(gè)輸出物。架構(gòu)圖的類型比較多，以4+1的架構(gòu)視圖為例，包括：
邏輯視圖：主要針對(duì)服務(wù)組件需求，即系統(tǒng)給用戶提供哪些服務(wù)。
開發(fā)視圖：主要針對(duì)軟件在開發(fā)環(huán)境下實(shí)現(xiàn)模塊的關(guān)系。
過程視圖：主要針對(duì)組件之間的通訊關(guān)系。
物理視圖：主要針對(duì)物理或系統(tǒng)軟件環(huán)境，物理即服務(wù)器或終端，系統(tǒng)軟件即虛擬機(jī)、容器等。
場(chǎng)景視圖：主要從功能角度的關(guān)系。
運(yùn)維需要關(guān)注邏輯、過程、物理、場(chǎng)景四類架構(gòu)圖，以往我們主要用一些辦公文檔進(jìn)行管理，存在架構(gòu)圖信息難更新，且架構(gòu)信息協(xié)同傳遞效果不佳等問題。要將架構(gòu)圖按資產(chǎn)化管理起來，需要回到架構(gòu)的幾個(gè)要素：模式、組件、關(guān)系、描述，要讓架構(gòu)圖中的模式分類，服務(wù)組件、組件關(guān)系數(shù)字化，通過線上化的架構(gòu)圖方式描述架構(gòu)。同時(shí)還要讓架構(gòu)圖成為能力融入到日常的工作場(chǎng)景中，比如在架構(gòu)評(píng)審、應(yīng)急管理、容量分析。
