【云安全聯(lián)盟】微服務(wù)架構(gòu)模式

微服務(wù)架構(gòu)模式t

應(yīng)用容器和微服務(wù)工作組的網(wǎng)址：

https://doudsecirtiyalliancaorg/research/working-groups/containerization/

序言

隨著數(shù)字化時(shí)代的到來，微服務(wù)應(yīng)用進(jìn)入飛速發(fā)展時(shí)代。微服務(wù)是一種新興的分布式系統(tǒng)

開發(fā)范式，在架構(gòu)層面，安全性是必需認(rèn)真考慮的重要工作。我國隨著《數(shù)據(jù)安全法》和《個(gè)

人信息保護(hù)法》的頒布，對(duì)安全和數(shù)據(jù)保護(hù)的重視程度日益提高，架構(gòu)層的安全問題必將上升

到組織安全治理層面。

如何保證微服務(wù)架構(gòu)的安全？本文檔給出了CSA的最佳實(shí)踐與總結(jié)，通過CSA微服務(wù)安

全參考架構(gòu)以及安全控制措施疊加的新思路，保證了微服務(wù)在架構(gòu)層面的安全性，CSA微服務(wù)

安全工作組也在陸續(xù)推出微服務(wù)安全相關(guān)的指南與白皮書.文章深入淺出，值得大家參考。

李雨航Y(jié)aleLi

CSA大中華區(qū)主席兼研究院院長

3

致

謝

本文檔《微服務(wù)架構(gòu)模式》(MicroservicesArchitecturePattern)由CSA應(yīng)用容器和微服務(wù)工

作組專家編寫，CSA大中華區(qū)秘書處組織翻譯并審校。

中文版翻譯專家組(排名不分先后)：

組長：高卓

翻譯組：高卓賀進(jìn)李巖廖武鋒馬琳琳

審校組：郭鵬程姚凱

感謝以下單位對(duì)本文檔的支持與貢獻(xiàn)：

北京江南天安科技有限公司浪潮云信息技術(shù)有限公司

北京北森云計(jì)算股份有限公司

英文版本

主編/工作組聯(lián)合主席：AnilKarine1AndrewWild

主要供稿者：GustavoNievesArreazaMarinaBregkouCraigEllrod

MichaelHoldenJohnJiangKevinKeane

NumrataKulkarniVaniMurthyPradeepNampiar

VinodBbuVanjarapuMarkYanaiitis

審稿者：AnkurGargiAlexReboMichaelRozaAnkitSharma

CSA分析師：HillaryBaronMarinaBregkou

CSA全球人員：ClaireLehnertAnnMarieUlskey

4

在此感謝以上專家。如譯文有不妥當(dāng)之處，敬請(qǐng)讀者聯(lián)系CSAGCR秘書處給與雅正！聯(lián)系

郵箱：research@c-csa.cn；云安全聯(lián)盟CSA公眾號(hào)。

5

目錄

序言3

致謝..............................................................................4

121=="7

1*JI.........................................................................??????................../

2目的9

************************************************************************************************************************************???????????????????????????????????????????1

4.1模式和控制措施疊力口..................................................................11

4.2微服務(wù)架構(gòu)模式簡(jiǎn)介...................................................................13

5.微服務(wù)架構(gòu)模式..............................................................................15

5.1模式.................................................................................15

5.1.1卸載（Offload）模式.............................................................15

5.1.2路由（路由選擇）模式..........................................................17

5.1.3聚合模式......................................................................19

5.1.4緩存模式......................................................................22

5.1.5代理..........................................................................24

5.1.7AuthZ（授權(quán)；模式.............................................................29

5.1.8Facade模式....................................................................32

5.1.9StranglerFig模式.............................................................34

5.1.10斷路器（CircuitBreaker）模式..................................................37

5.1.11適配器（包裝器/轉(zhuǎn)化/轉(zhuǎn)換）模式...............................................40

6.安全控制措施疊力口............................................................................42

6.1疊加介紹..............................................................................44

6.1.2IAM”口50

*1?1I

6.1.6微服務(wù)的彈性和可用性疊加.......................................................61

於、件/結(jié)論67

附錄C：參考文獻(xiàn)...............................................................................76

1.0微服務(wù)架構(gòu)模式模板........................................................................80

1.2二式模板1.I...............................................................................80

2.1安全疊加作.業(yè)練習(xí)指導(dǎo).................................................................82

211介紹82

2.1.2V備知識(shí).......................................................................83

6

1.引言

以較弱方式構(gòu)建微服務(wù)的影響始終存在「表現(xiàn)為不夠安全和把應(yīng)用編程接口（API）過度

暴露，構(gòu)成了微服務(wù)應(yīng)用程序風(fēng)險(xiǎn)的核心部分。一些業(yè)務(wù)和技術(shù)負(fù)責(zé)人跳過搭建架構(gòu)的方法2,

僅憑幾條粗略的要求尋找軟件解決方案。然而在開放市場(chǎng)上尋求解決方案的人們最終還是要用

搭建架構(gòu)的方式把采購的解決方案融入到現(xiàn)有控制環(huán)境中。即便是新建的微服務(wù)應(yīng)用程序也耍

與企業(yè)舊有的其他部分集成一一沒有哪家公司會(huì)年年淘汰現(xiàn)有架構(gòu)。不采用架構(gòu)方法而單純購

買解決方案將不可避免地在日后引入各種制約和附加組件.修修補(bǔ)補(bǔ)的資金成本會(huì)隨著時(shí)間的

推移而不斷增加。

無論企業(yè)領(lǐng)導(dǎo)者傾向于購買現(xiàn)成解決方案還是支持“內(nèi)部構(gòu)建”，API消費(fèi)和微服務(wù)集成

都會(huì)是一種常見的系統(tǒng)集成預(yù)期。最好能有一種辦法指導(dǎo)將架構(gòu)的使用、架構(gòu)模式和安全控制

措施疊加集成為一個(gè)整體，確保信息安全成為既定要求的集合。微服務(wù)架構(gòu)模式和相應(yīng)的安全

控制措施的疊加為微服務(wù)的開發(fā)奠定了基礎(chǔ)，形成一種完整的思路。模式和疊加可確保信息安

全根植于產(chǎn)品之內(nèi)。如果做得好，安全控制措施疊加會(huì)變得與用于創(chuàng)建微服務(wù)應(yīng)用程序的架構(gòu)

和設(shè)計(jì)方法難以區(qū)分。有人稱這種現(xiàn)象為“DevSecOps”（開發(fā)-安全-運(yùn)維）/安全控制措施

疊加的概念起源于美國《聯(lián)邦信息系統(tǒng)管理法案（FISMA）》。"根據(jù)卜'ISMA的說法，“安全疊

加是運(yùn)用裁剪指南對(duì)控制基線裁剪后得出的一個(gè)全套特定控制措施、控制措施強(qiáng)化和補(bǔ)充指南

集?！泵绹鴩覙?biāo)準(zhǔn)和技術(shù)研究所（NIST）特別出版物SP800-53《聯(lián)邦信息系統(tǒng)和機(jī)構(gòu)安全

和隱私控制措施》第4版第3.3節(jié)'對(duì)安全控制措施疊加作了進(jìn)一步闡述。盡管疊加是NIST引

入的概念，但是ISACACOBIT5、PCI-DSS3.2.1或CSACCMv3.0.1等其他控制框架也可使用。

軟件開發(fā)的展開離不開以軟件設(shè)計(jì)模式為引導(dǎo)工安全控制措施疊加（overlay）是指由全

1Hinkley,C.(2019,November6).DissectingtheRisksandBenefitsofMicroserviceArchitecture

TechZone360.httDS://www.techzor>/topics/techzone/articles/2019/ll/06/44366Q-dissecting~risks-beneflls-niicroservice~archilecliirehim

2TheOpenGroup.TheTOGAFStandard,Version9.2Ovendew,PhaseA,RCPEEandG.RetrievedAugust11,2021,from

https:〃www.oDenH/togaf.

2CloudSecurityAlliance.(2019,August1).InformationSecurityManagementthroughReflexiveSecurity

https://d0udsecuritvalliance.0r2/artifacts/informatiorrsecuritymanagement~throughrcflcxiv(rsecurity/(l3t14,16).

4NIST.SecurityandPrivateControlOverlayOverview.RetrievedAugust11,2021,from

https:〃csrc.nist.ROv/proiects/riskmanagemcnt/sp800-53-controls/overlay~rcpositcry/ovcrlavovcrview.

5NIST.(2020,September).NISTSpecialPublication800-53,Revision5:SecurityandPrivacyControlsforInformationSystemsand

Organizations.https://nvlpubsrdstgov/nistpubs/SpecialPublications/NISTSP.800-53r4.pdf

6Bass,L,Clement^RC,&Kazman,R.(2012,September).SoftwareArchitectureinPracticeThird

Edition.https://resource&seiemuedu/libi'ary/asset-view.cfm?assetid=30264.

7

套特定控制措施、控制措施強(qiáng)化和補(bǔ)充指南組成的離散集，可集成到架構(gòu)設(shè)計(jì)流程中，充當(dāng)嵌

入和既定的管理、技術(shù)或物理要求。軟件設(shè)計(jì)模式與安全控制措施疊加結(jié)合到一起會(huì)告訴我們，

軟件開發(fā)工作要把安全作為一個(gè)設(shè)計(jì)元素“內(nèi)置”到軟件產(chǎn)品之中，而不能只把安全當(dāng)作最后

才涂抹到軟件產(chǎn)品上的一層外衣，而這一層外衣到了日后成為必須付出極高代價(jià)才能做出改變

的地方。本文后面的章節(jié)將為使軟件架構(gòu)形成一個(gè)完整思路打下基礎(chǔ)。架構(gòu)意義上的完整思路

是指表現(xiàn)得像一個(gè)完美數(shù)學(xué)方程式的架構(gòu)表達(dá)方式；把這個(gè)思路向前推進(jìn)，可以得到它的預(yù)期

產(chǎn)品，向后推演，則可以看到它的非功能和功能要求。

開發(fā)人員一旦掌握軟件設(shè)計(jì)模式和安全控制措施疊加.就可以在架構(gòu)成熟度上更.上一層樓,

從特定的微服務(wù)視角揭示底層服務(wù)交付框架具體方面（如數(shù)據(jù)、集成和部署架構(gòu)）所需耍的控

制狀態(tài)。雖然這些還不是“微服務(wù)架構(gòu)”，但可以支持對(duì)于那些要求保證系統(tǒng)行為可重復(fù)性、

可靠性、準(zhǔn)確性和完整性的架構(gòu)和設(shè)計(jì)。

微服務(wù)架構(gòu)風(fēng)格體現(xiàn)在分布式應(yīng)用程序的處理足跡里，其中靜態(tài)配置、動(dòng)態(tài)適應(yīng)和抽象化

設(shè)想組合在一起所形成的能力，產(chǎn)生人們所說的“應(yīng)用功能”。在微服務(wù)和容器化轉(zhuǎn)型出現(xiàn)之

前，許多配置和抽象化設(shè)想存在于單個(gè)整體式應(yīng)用程序邊界之內(nèi)。隨著整體代碼庫變得越來越

大，內(nèi)部應(yīng)用程序的狀態(tài)和相互依賴變得越來越難以分辨，從而帶來許多架構(gòu)、開發(fā)和運(yùn)維上

的挑戰(zhàn)。然而，讓一名業(yè)務(wù)代表負(fù)責(zé)業(yè)務(wù)流程功能.同時(shí)讓另一名產(chǎn)品負(fù)責(zé)人履行應(yīng)用托管義

務(wù)并在一個(gè)組織結(jié)構(gòu)下管理聯(lián)合開發(fā)人員的情況依然十分常見。微服務(wù)架構(gòu)風(fēng)格改變了組織結(jié)

構(gòu)，就像改變軟件的構(gòu)建和組裝樣。架構(gòu)的每個(gè)部分，無論是在平臺(tái)、軟件定義、應(yīng)用編程

接口（API）層面，還是在軟件開發(fā)層面，都是在微服務(wù)應(yīng)用程序交付的整體功能中執(zhí)行具體

和特定功能。機(jī)構(gòu)把多個(gè)開發(fā)團(tuán)隊(duì)組織到一起應(yīng)對(duì)技術(shù)變化，響應(yīng)計(jì)算、內(nèi)存、存儲(chǔ)和網(wǎng)絡(luò)虛

擬化成一種能力的趨勢(shì)。存儲(chǔ)、網(wǎng)絡(luò)和服務(wù)器計(jì)算機(jī)團(tuán)隊(duì)的混合體由分散的團(tuán)隊(duì)組合而成。

隨著微服務(wù)軟件開發(fā)深入人心，業(yè)界越來越重視DevSecOps（開發(fā)-安全-運(yùn)維）、軟件組

7

裝和應(yīng)用程序安全。例如，一個(gè)業(yè)務(wù)負(fù)責(zé)人可能擁有涵蓋整個(gè)工作流程的應(yīng)用程序，但是只負(fù)

責(zé)處理涉及改進(jìn)現(xiàn)有能力或建立新能力的前瞻性請(qǐng)求。業(yè)務(wù)負(fù)責(zé)人關(guān)心的是已交付或可交付成

品的價(jià)值最大化；這個(gè)角色游離于軟件構(gòu)建團(tuán)隊(duì)之外。在微服務(wù)架構(gòu)風(fēng)格中，多個(gè)產(chǎn)品負(fù)責(zé)人

服從于某一個(gè)業(yè)務(wù)負(fù)責(zé)人，與業(yè)務(wù)負(fù)責(zé)人保持一致的情況是可能存在的。產(chǎn)品負(fù)責(zé)人和相關(guān)軟

件開發(fā)團(tuán)隊(duì)（也就是敏捷用語中所說的“機(jī)組”[crew]）可能擁有特定功能的所有權(quán)，如搜索

8

功能（API使用、排序、算法、元數(shù)據(jù)編目），而第二個(gè)產(chǎn)品負(fù)責(zé)人則專注于前端客戶的用戶

體驗(yàn)（風(fēng)格、演示、流程和整體體驗(yàn)）。數(shù)據(jù)的集成可能會(huì)由服務(wù)于多個(gè)產(chǎn)品負(fù)責(zé)人數(shù)據(jù)需求

的一個(gè)聯(lián)合“機(jī)組”負(fù)責(zé)。整體應(yīng)用程序把所有這些角色和行動(dòng)捆綁進(jìn)一個(gè)垂直的支持體系，

這便是微服務(wù)架構(gòu)風(fēng)格的一個(gè)關(guān)鍵特點(diǎn)一一微服務(wù)軟件的開發(fā)和生產(chǎn)部署行動(dòng)使機(jī)構(gòu)的傳統(tǒng)

垂直體系扁平化。不僅應(yīng)用程序的功能是分散布局的，而且它的支撐結(jié)構(gòu)也是分布式的，從而

迫使我們更多地依靠自動(dòng)化提供以前在垂直體系中相互隔離的各種基礎(chǔ)設(shè)施、策略、安全、身

份和網(wǎng)絡(luò)功能。運(yùn)維部門通常擁有一套部署和管理IT服務(wù)的流程，但是部署和測(cè)試的責(zé)任有

時(shí)會(huì)左移給構(gòu)建軟件的開發(fā)人員。架構(gòu)師往往需要在實(shí)施軟件工程的過程中掌握新的技能，才

能更好地把習(xí)慣和傳統(tǒng)的架構(gòu)工作轉(zhuǎn)換成微服務(wù)架構(gòu)風(fēng)格。

附錄B進(jìn)一步定義業(yè)務(wù)負(fù)責(zé)人、產(chǎn)品負(fù)責(zé)人、開發(fā)人員、運(yùn)維人員和架構(gòu)師的角色。有關(guān)

這五種角色的更多詳細(xì)信息和具體定義，請(qǐng)參見詞匯表。

2.目的

CSA于2020年2月出版《實(shí)現(xiàn)安全微服務(wù)架構(gòu)的最佳實(shí)踐》\為讀者提供了可信安全系

統(tǒng)設(shè)計(jì)指南，其中最后一章著重從開發(fā)人員、運(yùn)維人員和架構(gòu)師的視角闡述。

本文旨在提川一種可重復(fù)的方法,用于按“MAP"（MicroservicesArchitecturePattern,

微服務(wù)架構(gòu)模式）構(gòu)建、開發(fā)和部署微服務(wù)。我們提出的這個(gè)“MAP”包含微服務(wù)獨(dú)立運(yùn)行和

與其他微服務(wù)通信所需要的全部信息一一這些微服務(wù)聚合到一起，會(huì)形成轉(zhuǎn)而又會(huì)成為應(yīng)用程

序成分的能力。本文描述了“MAP”的關(guān)鍵元素、應(yīng)該怎樣設(shè)計(jì)和部署，以及應(yīng)該怎樣通過一

種合規(guī)即代碼方法把安全和合規(guī)左移。

本文的主要目的是開發(fā)一個(gè)廠商中性的參考架構(gòu)基礎(chǔ)，從這個(gè)基礎(chǔ)分解出軟件和平臺(tái)（企

業(yè)）平面體現(xiàn)的軟件架構(gòu)模式，以后還可以通過添加安全控制措施疊加重新構(gòu)建。微服務(wù)架構(gòu)

模式的成功分解和重組就證明了這一點(diǎn)；其中的集成操作便是安全控制措施的疊加。

8CloudSecurityAlliance(202QFebruary24).BestPracticesinImplemeritingaSecureMicrosendees

Architecture.https://cloudsecmisallianceorg/aitifocts/bestrpractices4irimplementing-a-securemicrosemces-architecture/m.

9

3.讀者

本文的目標(biāo)讀者是應(yīng)用程序開發(fā)人員、應(yīng)用程序架構(gòu)師、系統(tǒng)和安全管理員、安全項(xiàng)目經(jīng)

理、信息系統(tǒng)安全官以及其他對(duì)應(yīng)用程序容器和微服務(wù)的安全負(fù)有責(zé)任或感興趣的人員。

我們假定讀者具備一定程度的操作系統(tǒng)、網(wǎng)絡(luò)和安全專業(yè)知識(shí)，同時(shí)還掌握了應(yīng)用程序容

器、微服務(wù)和敏捷應(yīng)用程序方面的專業(yè)知識(shí)。由于應(yīng)用程序容器技術(shù)具有不斷變化的性質(zhì)，因

此我們鼓勵(lì)讀者借助其他資源（包括本文列出的參考文獻(xiàn)）獲得更新和更詳細(xì)的信息。

4.架構(gòu)與解決方案

架構(gòu)并不是解決方案。解決方案是指通過架構(gòu)、模式和設(shè)計(jì)上的努力滿足特定行業(yè)需要或

解決具體業(yè)務(wù)問題的辦法。解決方案旨在向客戶和企業(yè)負(fù)責(zé)人提供持續(xù)的價(jià)值。以POS機(jī)系統(tǒng)

為例，POS機(jī)系統(tǒng)是人員之間交互、技術(shù)支持的業(yè)務(wù)流程和后端支付平臺(tái)運(yùn)行的綜合體現(xiàn)，用

于創(chuàng)建一種只靠架構(gòu)無法實(shí)現(xiàn)的特定業(yè)務(wù)能力。POS機(jī)解決方案的設(shè)計(jì)是概念、系統(tǒng)屬性和模

式為應(yīng)對(duì)某一特定業(yè)務(wù)挑戰(zhàn)而組合到一起的結(jié)果。任何問題都會(huì)有化解挑戰(zhàn)癥結(jié)的解決方案。

但是你若想搞清問題的來龍去脈，就必須回到源頭去了解這個(gè)問題之所以會(huì)產(chǎn)生的條件和決定。

架構(gòu)與解決方案的區(qū)別在于：解決方案的根本在于設(shè)計(jì)。設(shè)計(jì)包含一組模式，而這些模式

起源于最早的抽象形式一一??個(gè)架構(gòu)。架構(gòu)構(gòu)成了運(yùn)行環(huán)境中系統(tǒng)的基本概念或?qū)傩?，由系統(tǒng)

的元素、關(guān)系以及系統(tǒng)的設(shè)計(jì)和進(jìn)化原則體現(xiàn)出來。商業(yè)和技術(shù)草圖和圖紙依然是架構(gòu)師向工

程設(shè)計(jì)團(tuán)隊(duì)表述自己想法的主要手段。為了進(jìn)一步消除開發(fā)過程中的可變性，架構(gòu)師與工程師

一起挑選商定的模式，共同奠定設(shè)計(jì)和框架設(shè)計(jì)活動(dòng)的基礎(chǔ)。架構(gòu)、模式和設(shè)計(jì)不引用特別命

名的技術(shù)，保持了廠商中性。設(shè)計(jì)完成后，業(yè)務(wù)負(fù)責(zé)人和技術(shù)負(fù)責(zé)人決定是全部自行構(gòu)建、全

部對(duì)外采購還是結(jié)合這兩種構(gòu)建方法，從而針對(duì)具體問題創(chuàng)建一個(gè)符合業(yè)務(wù)需要的技術(shù)解決方

案。有些業(yè)務(wù)和技術(shù)負(fù)責(zé)人選擇跳過構(gòu)建架構(gòu)的過程并僅憑一組要求尋找現(xiàn)成的解決方案，而

其他人則選擇根據(jù)要求自己構(gòu)建解決方案。

那些到市場(chǎng)上尋求一站式、垂直集成、低代碼或無代碼解決方案的公司，最終也還是要用

構(gòu)建架構(gòu)的方法把買來的解決方案融進(jìn)現(xiàn)有的控制環(huán)境。而這將不可避免地導(dǎo)致權(quán)衡，其中有

些對(duì)初始條件極為敏感，日后倒是能夠引入約束或解決方案重構(gòu)，但是到了那時(shí)，改造會(huì)帶來

10

經(jīng)濟(jì)成本的上升；而這無非是在償還不斷積累的技術(shù)負(fù)債。

許多人認(rèn)為微服務(wù)也是一種架構(gòu)，但微服務(wù)其實(shí)只是一種架構(gòu)風(fēng)格。大肆使用水泥預(yù)制板

的粗野主義和依托精雕細(xì)刻的橡木承載使命感的工匠風(fēng)格代表了能夠渲染整棟建筑物的架構(gòu)

風(fēng)格。每種風(fēng)格都有自己的架構(gòu)原則，應(yīng)用得當(dāng)時(shí)，這些原則會(huì)體現(xiàn)在藍(lán)圖中，引導(dǎo)產(chǎn)生特定

設(shè)計(jì)，從而在物理上呈現(xiàn)出預(yù)期的風(fēng)格。如果目標(biāo)是構(gòu)建高度模塊化的分布式應(yīng)用程序，則應(yīng)

用微服務(wù)原理、架構(gòu)、模式和設(shè)計(jì)會(huì)導(dǎo)致出現(xiàn)一款微服務(wù)應(yīng)用程序。

4.1模式和控制措施疊加

模式是指以可預(yù)測(cè)方式發(fā)生的一組可重復(fù)動(dòng)作和安排。模式是可以通過物理外觀、直接或

間接觀察或分析看出的。設(shè)計(jì)應(yīng)用系統(tǒng)時(shí)，軟件模式是用于解決一類計(jì)算機(jī)編程問題的一種已

知可重用方法。軟件模式顯示構(gòu)建元素之間的關(guān)系，但不規(guī)定問題或要求的最終艇決方案。我

們可以把軟件模式視為軟件代碼與支持軟件的系統(tǒng)之間的中間結(jié)構(gòu)體現(xiàn)。以往的軟件模式缺乏

一個(gè)關(guān)鍵的宏觀架構(gòu)表述：安全控制措施指南。開發(fā)人員通常不會(huì)自行開發(fā)安全解決方案，而

是選擇依靠從平臺(tái)或應(yīng)用程序繼承的功能，只有在迫不得已的情況下才會(huì)創(chuàng)建自己的安全控制

措施。用加鹽的散列函數(shù)給保存的口令單向加密是開發(fā)人員自己構(gòu)建安全控制措施的一個(gè)例子。

歷史上軟件模式都是指導(dǎo)軟件開發(fā)，并不使用信息技術(shù)(IT)安全控制措施。

IT安全控制措施提供了調(diào)節(jié)和管理應(yīng)用系統(tǒng)行為的手段。IT安全控制措施是一種抽象說

法，表述了與應(yīng)對(duì)感知風(fēng)險(xiǎn)的預(yù)防、檢測(cè)或糾正對(duì)策相應(yīng)的底層技術(shù)、管理或物理能力。IT

安全控制措施的目標(biāo)是把潛在風(fēng)險(xiǎn)降低到可接受、無害或無關(guān)緊要的水平。控制目標(biāo)也是一種

抽象說法，但不同之處在于它是對(duì)以特定方式實(shí)施控制措施所要達(dá)到的預(yù)期結(jié)果或目的的陳述。

控制目標(biāo)通過使用一個(gè)或通常的一組控制措施實(shí)現(xiàn)；后者便是所謂的深度防御一一用不同類型

的多個(gè)控制措施協(xié)同預(yù)防、檢測(cè)和/或糾正次優(yōu)運(yùn)行狀態(tài)?？刂颇繕?biāo)源自一個(gè)控制框架，后者

是可用于幫助業(yè)務(wù)流程負(fù)責(zé)人履行防止信息丟失職責(zé)的一組基本控制措施。多層布局的控制措

施可以在應(yīng)用程序生命周期的不同階段以及應(yīng)用程序運(yùn)行環(huán)境的不同層面發(fā)揮作用。IT安全

控制措施從新軟件創(chuàng)意誕生，到構(gòu)建、部署，再到平臺(tái)運(yùn)行的所有階段一直存在；這些階段構(gòu)

成了所謂軟件開發(fā)生命周期。

安全專業(yè)人員確實(shí)在推動(dòng)開發(fā)人員左移，但是應(yīng)用程序安全領(lǐng)域要求的專業(yè)水平與IT安

全平臺(tái)專業(yè)人員技術(shù)水平的差異越來越大，距離也越來越遠(yuǎn)。機(jī)構(gòu)可以通過培養(yǎng)或雇用具有開

11

拓精神的軟件開發(fā)人員或者使用由不同領(lǐng)域?qū)I(yè)人員組成的角色組合管理技能上的差距。在整

體式應(yīng)用程序下，管理技能差距是可以實(shí)現(xiàn)的，但是分布式應(yīng)用程序設(shè)計(jì)的實(shí)體化會(huì)擴(kuò)大豎井

式組織結(jié)構(gòu)部門的控制范圍，從而進(jìn)一步加劇技能差距和所有權(quán)之爭(zhēng)。

表現(xiàn)不同且論述或探索最少的是企業(yè)平臺(tái)層面一一這里有多個(gè)豎井式組織結(jié)構(gòu)部門使用

IT控制措施（網(wǎng)絡(luò)、安全、服務(wù)器、存儲(chǔ)、消息傳遞）一一與軟件開發(fā)層面（安全軟件開發(fā)

生命周期和安全測(cè)試自動(dòng)化）之間的空間。安全控制措施疊加可以把企業(yè)平臺(tái)層面與較低的軟

件開發(fā)層面聯(lián)系到一起。安全疊加的使用代表了一個(gè)適合可擴(kuò)展安全架構(gòu)角色的領(lǐng)域，其中保

密性、完整性和可用性可擴(kuò)展到把彈性和隱私問題也包括進(jìn)來。隨著世界轉(zhuǎn)向使用以軟件為中

心的抽象化方法以及企業(yè)接受軟件中心主義，依賴不僅耍求服務(wù)具有彈性，而且還要求可通過

整個(gè)人機(jī)交互過程中自我管理數(shù)據(jù)訪問能力實(shí)現(xiàn)完整的隱私。安全架構(gòu)作為一種完整思路涵蓋

了人、平臺(tái)，外加軟件。

安全架構(gòu)代表了企業(yè)架構(gòu)中專門解決信息系統(tǒng)彈性問題并為滿足安全要求的功能提供架

構(gòu)信息的部分。微服務(wù)語境F的安全架構(gòu)不僅在現(xiàn)有平臺(tái)和軟件架構(gòu)上引入了控制措施疊加的

概念，而且安全架構(gòu)師有責(zé)任和義務(wù)劃出一條界線，把體現(xiàn)在平臺(tái)層面的控制措施疊加與體現(xiàn)

在軟件本身的控制措施疊加區(qū)分開來。作為一種完整的安全架構(gòu)思路，安全疊加是用于降低風(fēng)

險(xiǎn)的多項(xiàng)控制措施的集合體，是管理、技術(shù)和物理控制措施的組合。

全面考慮問題的安全架構(gòu)師往往會(huì)先構(gòu)建威脅模型，然后才把控制措施運(yùn)用到復(fù)雜的解決

方案架構(gòu)之中。威脅建模是把控局面的一種方式。紅藍(lán)對(duì)抗、STRIDE,攻擊樹、Trike、VAST、

PASTA和ISO-31010Delphi是風(fēng)險(xiǎn)識(shí)別方法的示例。威脅建模在很大程度上屬于圍繞著人展

開的一種活動(dòng)。最好的分析產(chǎn)生于各有側(cè)重的多樣化人群，這樣的群體對(duì)攻擊面各個(gè)方面的深

入體驗(yàn)，遠(yuǎn)遠(yuǎn)超過一個(gè)人的單獨(dú)認(rèn)知。即便是分析受到的系統(tǒng)性沖擊，群體分析也不太容易變

得脆弱。強(qiáng)健的威脅模型來自于對(duì)當(dāng)前狀態(tài)、制度歷史和想象力的深入的行業(yè)縱向認(rèn)識(shí)，以及

選擇一種適合問題的分析方法.而不是安全架構(gòu)師的方便程度。讓威脅模型契合戰(zhàn)術(shù)實(shí)施范圍

并避免空幻、存在主義和黑天鵝場(chǎng)景至關(guān)重要。威脅模型得出的結(jié)果會(huì)使IT安全控制措施的

落實(shí)合法化，從而形成個(gè)可以抑制已知或假定風(fēng)險(xiǎn)的強(qiáng)大疊加。在這一點(diǎn)上，安全架構(gòu)不同

于解決方案架構(gòu)，因?yàn)樗梢詼p輕乃至消除在擬議的解決方案架構(gòu)中發(fā)現(xiàn)的潛在技術(shù)、管理或

物理風(fēng)險(xiǎn)。

一個(gè)微服務(wù)應(yīng)用程序不會(huì)把每個(gè)設(shè)計(jì)模式和每個(gè)安全控制措施疊加全部囊括其中，但是會(huì)

12

包含那些被認(rèn)為對(duì)于有效設(shè)計(jì)不可或缺，可以解決客戶問題的軟件架構(gòu)模式和安全疊加。而這

正是軟件層面實(shí)現(xiàn)扁平化并融進(jìn)平臺(tái)層面的結(jié)合部。在微服務(wù)架構(gòu)風(fēng)格中，任何解決方案除非

在每個(gè)所用模式都配備了相應(yīng)的安全控制措施疊加，否則都談不上概念完整。所有疊加都與模

式配套，才算解決方案架構(gòu)構(gòu)建完成。模式與疊加組合到一起，構(gòu)成了微服務(wù)應(yīng)用程序的安全

控制措施狀態(tài)。

4.2微服務(wù)架構(gòu)模式簡(jiǎn)介

為了便于指導(dǎo)安全控制措施疊加對(duì)微服務(wù)的施用，通用微服務(wù)架構(gòu)模式用兩個(gè)分支形成了

兩個(gè)不同的視角。第一個(gè)視角著眼于企業(yè)層面。企業(yè)層面包含了可協(xié)助實(shí)現(xiàn)微服務(wù)架構(gòu)治理的

信息技術(shù)資產(chǎn)。企業(yè)期望減少控制措施狀態(tài)的變數(shù)。自定義編碼、生產(chǎn)狀態(tài)變通方案和一次性

修改都會(huì)增加開發(fā)成本。技術(shù)負(fù)債（如以增添安全設(shè)備形式出現(xiàn)的技術(shù)負(fù)債）、在設(shè)計(jì)中引入

會(huì)限制靈活性的緊耦合等，可能會(huì)妨礙基礎(chǔ)設(shè)施作為代碼部署的能力，從而形成沒有必要的持

久存在。企業(yè)環(huán)境期望軟件開發(fā)盡可能多地繼承安全控制措施，以防開發(fā)團(tuán)隊(duì)在編制應(yīng)用程序

安全指南的過程中出現(xiàn)可變性和不可靠性。安全疊加同時(shí)存在于企業(yè)層面和軟件層面。API注

冊(cè)中心處理已完成開發(fā)的微服務(wù)的清單和版本以及主導(dǎo)服務(wù)供應(yīng)商和第三方集成。服務(wù)存儲(chǔ)庫

（存放API規(guī)范、模板、代碼腳手架、用于構(gòu)建過程的構(gòu)件等）在微服務(wù)開發(fā)過程中建立統(tǒng)一

性、自動(dòng)進(jìn)行靜態(tài)和動(dòng)態(tài)安全測(cè)試，并把微服務(wù)引入容器，最終通過公共管道交付合為一體的

功能（例如會(huì)先觸發(fā)安全檢查，然后觸發(fā)配置管理資源部署計(jì)劃的Jenkins操作）。理想狀態(tài)

是，按企業(yè)層面的要求在執(zhí)行引導(dǎo)進(jìn)程的過程中交付平臺(tái)層面的安全鉤、調(diào)用和集成，這樣可

以避免在運(yùn)行期間不得不進(jìn)行的修改。

第二個(gè)視角著眼于軟件層面。圖1是分布式微服務(wù)應(yīng)用的分解圖，這種狀況存在于軟件層

面，是最接近軟件代碼的表現(xiàn)方式。該圖描述了合成的分布式微服務(wù)應(yīng)用程序的一般性圖景。

它像是一張X光片，在上半部分顯示主要的可繼承的企業(yè)層面的系統(tǒng)集成，在下半部分顯示微

服務(wù)組件。各類機(jī)器客戶端（瀏覽器、物聯(lián)網(wǎng)、移動(dòng)、API集成）和物理消費(fèi)者通過企業(yè)層面

訪問分布式微服務(wù)應(yīng)用程序提供的功能。API控制著客戶端使用的表示邏輯，并提供一項(xiàng)且只

有一項(xiàng)業(yè)務(wù)功能，同時(shí)包含用來控制客戶端可以從暴露的API獲取哪些內(nèi)容的其他業(yè)務(wù)規(guī)則。

API可以整理來自多個(gè)來源的數(shù)據(jù)，并且可以訪問安放在托管微服務(wù)API的容器外面數(shù)據(jù)卷上

的數(shù)據(jù)。微服務(wù)利用企業(yè)層面的服務(wù)和軟件層面的API網(wǎng)關(guān)服務(wù)在容器之間平衡負(fù)載，允許多

個(gè)微服務(wù)實(shí)例在生產(chǎn)中同時(shí)運(yùn)行。在軟件層面的微服務(wù)環(huán)境下，由sidecar服務(wù)代表公用程序

13

服務(wù)處理與微服務(wù)中存在業(yè)務(wù)邏輯無關(guān)的任務(wù)。每個(gè)微服務(wù)API都有一個(gè)sidecar與之配對(duì)，

而在集群容器環(huán)境中，sidecar根據(jù)服務(wù)通信策略和安全策略交付服務(wù)的手段。通信流的主要

組成機(jī)制是網(wǎng)絡(luò)訪問控制邏輯?？刂茣?huì)以虛擬局域網(wǎng)、基于策略的路由選擇、基于上下文的

ACL、特定網(wǎng)關(guān)邏輯和軟件定義的網(wǎng)絡(luò)的形式出現(xiàn)。這些企業(yè)層面執(zhí)行方案中的每一個(gè)都自帶

安全疊加權(quán)衡。構(gòu)成通信流和控制流的主要手段，是企業(yè)層面嚴(yán)格管理的授權(quán)，以及攜帶被加

密客戶端權(quán)限（即OAuth）、外部管理的托管憑證（如平臺(tái)層面機(jī)對(duì)機(jī)憑證托管和管理）和mTLS

（企業(yè)層面相互傳輸層安全證書管理）的訪問令牌。安全控制措施疊加可以在一個(gè)層面內(nèi)以及

跨企業(yè)和軟件層面發(fā)揮作用一一從而實(shí)現(xiàn)深度防御。安全控制措施疊加同時(shí)存在于兩個(gè)層面。

客戶端

（客戶'設(shè)備、第三方APIJII點(diǎn)、可值和半可信方）

企業(yè)層面

企業(yè)內(nèi)容交付和ONS圈務(wù)

企業(yè)路由和交換凰務(wù)

企業(yè)防火墻股務(wù)

企業(yè)代理冊(cè)務(wù)

身份供應(yīng)裕KIK務(wù)雷碼程務(wù)DEVOPS/安全SMC容4注霸API注冊(cè)

（生命冏期、挑范、

聯(lián)合和JR務(wù)ID管理入侵,欺保、異常定犯和迂書管理Cl/COTRia（影像.檔案.快照）

運(yùn)行時(shí)配

軟件層面

集群/集群API

:段式

容器容器

極式枚式：ifeKB

SDCKFacade/~^p\融凰務(wù)參考

珞由選擲

傲原務(wù)（UI）\/（業(yè)務(wù)邏輯）

震合

代理

SidecarSidecar

API網(wǎng)關(guān)記錄

數(shù)據(jù)源

段式

贛脫務(wù)

（包奘X）

極式

舊有應(yīng)用程序

Sidecar

企業(yè)層面監(jiān)控和遙測(cè)

OS.踩速、淵■指標(biāo)，??.工作流、成擬化）

圖4T微服務(wù)參考架構(gòu)一一企業(yè)層面和軟件層面

14

5.微服務(wù)架構(gòu)模式

5.1模式

以下架構(gòu)模式適用于將微服務(wù)開發(fā)成業(yè)務(wù)應(yīng)用。研究這些模式時(shí)一定會(huì)注意到，正是許多

模式的共同作用，構(gòu)成了一個(gè)安全的系統(tǒng)。盡管最初可能要從某一個(gè)模式(如身份驗(yàn)證)入手,

但必須搞清，這些模式是怎樣通過彼此交互支撐起一個(gè)安全而富有彈性的業(yè)務(wù)解決方案的。

5.1.1卸載(Offload)模式

卸載是針對(duì)具體環(huán)境的一個(gè)通用數(shù)據(jù)流動(dòng)作。卸載可以與API網(wǎng)關(guān)功能緊密耦合，例如通

過內(nèi)核軟件或加速器硬件提供TLS密碼終止功能，從而使后端設(shè)備不必管理TLS連接。卸載也

可以與數(shù)據(jù)訪問層緊密耦合，在這一層把數(shù)據(jù)寫入分散到多個(gè)同時(shí)進(jìn)行的數(shù)據(jù)提交動(dòng)作中，從

而提高數(shù)據(jù)寫入或讀取的速度。卸載還可以應(yīng)用了身份驗(yàn)證和授權(quán)。一般來說，被卸載的功能

是常被許多其他服務(wù)作為共享服務(wù)使用的功能。如果選擇卸載一項(xiàng)服務(wù)，就表明一個(gè)資源不必

再被微服務(wù)API納入它的代碼庫。

版本1.0

15

模式目的展現(xiàn)鞏固技術(shù)能力的機(jī)會(huì)

層面位置企業(yè)(平臺(tái))層面

結(jié)構(gòu)描述API網(wǎng)關(guān)是外部流量進(jìn)入微服務(wù)應(yīng)用的入口。

行為描述卸載TLS證書托管；TLS終止；AuthN和AuthX請(qǐng)求中介服務(wù)

數(shù)據(jù)特性傳輸中的數(shù)據(jù)

主要依賴性平臺(tái)層面與IAM平臺(tái)、證書管理平臺(tái)相互連接;上游入口堡壘防火墻；

上游負(fù)載平衡平臺(tái)

次要依賴性容器集合體(containerfleet.)；相鄰的安全U志相互連接

內(nèi)部事件/消息HTTPSv2/3；AS2

傳遞需要

外部事件/消息傳遞API層面日志；網(wǎng)關(guān)層面系統(tǒng)日志；AuthN和AuthX消息交換

鏈接

事件響應(yīng)行為發(fā)送，不接收。沒有轉(zhuǎn)換；原始機(jī)器輸出

共同的上游鏈接防火墻：全局和/或本地通信流負(fù)載平衡；網(wǎng)絡(luò)間ACL

共同的下游鏈接發(fā)證機(jī)構(gòu)；配置管理；API注冊(cè)中心；集群管理API安全環(huán)境；機(jī)器

ID/服務(wù)ID憑證托管

Ops安全回接API性能監(jiān)控；syslog監(jiān)控；機(jī)器健康監(jiān)控；異常檢測(cè)

DcvSccOps回接安全SDLC；API注冊(cè)中心；Swagger/YAMLAPI定義；AuthN和AuthX

控制

16

評(píng)估方法API性能趨勢(shì)分析；SIEM日志分析并與上游事件關(guān)聯(lián)；跨APT訪問端

口和協(xié)議的異常關(guān)聯(lián)

控制措施疊加的特性可從平臺(tái)繼承，而不是內(nèi)置于API規(guī)范或容器基礎(chǔ)設(shè)施。

復(fù)合狀態(tài)（獨(dú)有/通通用；其他模式也使用這一疊加。

用）

5.1.2路由（路由選擇）模式

當(dāng)一個(gè)端點(diǎn)需要暴露背后的多項(xiàng)服務(wù)時(shí).，可使用路由模式，根據(jù)入站請(qǐng)求路由請(qǐng)求和消息。

路由選擇策略和路由通信流管理被嵌入服務(wù)網(wǎng)格和/或使用sidecar服務(wù)。如果服務(wù)網(wǎng)格沒有嵌

入路由策略和通信流管理.則需要把API規(guī)范與有關(guān)消息隊(duì)列設(shè)計(jì)的路由邏輯結(jié)合到一起實(shí)現(xiàn)

API拓?fù)洌础罢l可以與誰交談，誰可以從誰那兒獲得消息”）。以往，大型分布式整體式傳

統(tǒng)應(yīng)用程序依靠消息隊(duì)列傳輸交易信息.以便應(yīng)用保持狀態(tài)。如果沒有服務(wù)網(wǎng)格可供使用，微

服務(wù)將可能不得不擁有路由選擇邏輯.以此執(zhí)行原本該由sidecar服務(wù)執(zhí)行的公用程序功能。

另外，路由選擇模式（或功能）可以設(shè)置在APT網(wǎng)關(guān)上。路由模式可以存在于硬件或軟件中。

17

路由模式

版本1.0

根據(jù)請(qǐng)求中的數(shù)據(jù)，如識(shí)別身份、來源、客戶端類型、請(qǐng)求主機(jī)

模式目的

值、請(qǐng)求URI路徑元素等的請(qǐng)求標(biāo)頭，將請(qǐng)求通信流路由給同服

務(wù)的不同版本或?qū)嵗８鶕?jù)通過源1P地址確定的請(qǐng)求源在有限時(shí)

間內(nèi)將請(qǐng)求路由給服務(wù)的一個(gè)新版本，便是路由選擇模式的一個(gè)

用例。

路由目的地也可以是消息隊(duì)列而不是同步服務(wù)端點(diǎn)。

層面位置企業(yè)（平臺(tái)）層面

結(jié)構(gòu)描述根據(jù)路由策略配置所定義的請(qǐng)求或消息數(shù)據(jù)，將請(qǐng)求路由到服務(wù)

的特定版本或?qū)嵗蛳㈥?duì)列。

行為描述根據(jù)請(qǐng)求數(shù)據(jù)和路由策略配置對(duì)入站請(qǐng)求進(jìn)行評(píng)估，確定目標(biāo)服

務(wù)實(shí)例的目的地或消息隊(duì)列。

數(shù)據(jù)特性使用中的數(shù)據(jù)/傳輸中的數(shù)據(jù)

主要依賴性API網(wǎng)關(guān)、經(jīng)過配置的服務(wù)網(wǎng)格功能、sidecar等路由組件必須可

用。

次要依賴性路由目的地或消息隊(duì)列必須可用。

內(nèi)部事件/消息傳遞目標(biāo)服務(wù)和消息隊(duì)列目的地的健康和可用

需要

外部事件/消息傳遞服務(wù)網(wǎng)格日志和遙測(cè)

鏈接

事件響應(yīng)行為響應(yīng)目標(biāo)服務(wù)不可用的自適應(yīng)或后備路由

18

共同的上游鏈接IAM平臺(tái)、網(wǎng)關(guān)平臺(tái)（API,負(fù)載平衡，基于策略的路由）

共同的下游鏈接隊(duì)列、數(shù)據(jù)存儲(chǔ)庫、其他內(nèi)部API

API網(wǎng)關(guān)可用性

Ops安全回接

DDOS預(yù)防

擴(kuò)展或節(jié)制通信流以確?？捎眯?/p>

SAST——服務(wù)網(wǎng)格配置審計(jì)

DevSecOps回接

DAST---服務(wù)端點(diǎn)的AuthN和AuthZ測(cè)試

IAST一一剔除假陽性結(jié)果

評(píng)估方法路由功能的可觀察性、遙測(cè)和U志記錄。U志記錄可提供實(shí)時(shí)可

見性和可觀察性。

控制措施疊加的特性預(yù)防性---DevSecOps控制、DDoS預(yù)防

檢測(cè)性和糾正性一一擴(kuò)容/收縮以確?？捎眯?/p>

復(fù)合狀態(tài)（獨(dú)有7通用）通用

5.1.3聚合模式

聚合模式接收并向多個(gè)微服務(wù)發(fā)出請(qǐng)求，然后把對(duì)后端服務(wù)發(fā)出的多個(gè)請(qǐng)求合并成一個(gè)請(qǐng)

求，用以響應(yīng)初始請(qǐng)求。當(dāng)許多設(shè)備向一個(gè)中心點(diǎn)發(fā)送交易消息和活動(dòng)日志時(shí)，往往會(huì)在云邊

緣發(fā)生軟件定義的聚合。其他模式可能會(huì)在網(wǎng)關(guān)聚合背后發(fā)揮作用，如Facade模式、代理模

式和斷路器模式，具體由應(yīng)用目標(biāo)和通信特點(diǎn)決定。這些設(shè)計(jì)模式有類似的結(jié)構(gòu)，但是使用它

們的意圖或目的各不相同。

19

版本l.o

模式目的聚合（網(wǎng)關(guān)）模式的目的是減少應(yīng)用程序?qū)蠖朔?wù)提出請(qǐng)求的

數(shù)量，并提高應(yīng)用程序在高時(shí)延網(wǎng)絡(luò)上的性能。

層面位置企業(yè)（平臺(tái)）層面

結(jié)構(gòu)描述聚合（網(wǎng)關(guān)）模式用于將多個(gè)單獨(dú)的請(qǐng)求聚合成一個(gè)請(qǐng)求或響應(yīng)。

行為描述當(dāng)一個(gè)客戶端需要向各種后端系統(tǒng)發(fā)出多個(gè)調(diào)用來執(zhí)行一項(xiàng)操作

時(shí)，聚合（網(wǎng)關(guān)）模式會(huì)很有用。

數(shù)據(jù)特性當(dāng)聚合器合并來自多個(gè)終端的數(shù)據(jù)集時(shí)，使用中的數(shù)據(jù)可能需要

得到安全保護(hù)。否則，聚合器可能只在請(qǐng)求者與響應(yīng)者之間傳輸

數(shù)據(jù)。

主要依賴性網(wǎng)絡(luò)（網(wǎng)絡(luò)可能會(huì)帶來嚴(yán)重時(shí)延）

次要依賴性可用性和接近性（將與這一模式通信的各種系統(tǒng)的可用性）

20

內(nèi)部事件/消息傳遞需聚合器模式可安全驗(yàn)證請(qǐng)求者的身份并傳遞一個(gè)訪問令牌。服務(wù)

要可驗(yàn)證請(qǐng)求者是否得到授權(quán)可以執(zhí)行所涉操作。

外部事件/消息傳遞網(wǎng)絡(luò)安全控制措施（網(wǎng)絡(luò)訪問控制——AuthN、AuthZ、通過加密

鏈接保護(hù)靜止數(shù)據(jù)等）

事件響應(yīng)行為確保聚合網(wǎng)關(guān)具有可滿足應(yīng)用程序可用性要求的彈性設(shè)計(jì)。

聚合網(wǎng)關(guān)可能是一個(gè)單點(diǎn)故障（SPOF）點(diǎn)，因此應(yīng)該具備處理負(fù)

載平衡的良好能力。

聚合網(wǎng)關(guān)應(yīng)該配備有適當(dāng)?shù)目刂?，可確保來自后端系統(tǒng)的任何響

應(yīng)延遲都不會(huì)造成性能問題。

共同的上游鏈接配置管理；API安全；策略管理和執(zhí)行

共同的下游鏈接維護(hù)、運(yùn)行時(shí)間/停機(jī)時(shí)間、集成、測(cè)試、漏洞掃描和打補(bǔ)丁

Ops安全回接Tie-backAPI性能監(jiān)控：系統(tǒng)日志監(jiān)控；健康監(jiān)控：異常檢測(cè)、事件管理、

反惡意軟件/病毒、漏洞抑制、補(bǔ)丁

DevSecOps回接安全SDLC：敏捷、更簡(jiǎn)單/更靈活的開發(fā)和測(cè)試周期、持續(xù)集成/持

續(xù)交付（CI/CD）管道

評(píng)估方法日志記錄/監(jiān)控；警報(bào)、基于授權(quán)失敗條件的計(jì)量警報(bào)、SIEM事故

和事件管理

控制措施疊加的特性網(wǎng)關(guān)可改善并直接影響應(yīng)用程序的性能和規(guī)模。

預(yù)防性：漏洞抑制、打補(bǔ)丁

糾正性：事件響應(yīng)

檢測(cè)性：性能監(jiān)控、健康監(jiān)控

復(fù)合狀態(tài)（獨(dú)有/通用）通用

21

5.1.4緩存模式

應(yīng)用設(shè)計(jì)中的緩存通常是用來滿足提高可用性、改善應(yīng)用性能和/或減少后端數(shù)據(jù)讀寫的

要求的。緩存可以是嵌入式的，也可以是分布式的。主要緩存模式有許多衍生。如果?項(xiàng)'也務(wù)

操作對(duì)于后續(xù)使用具有持續(xù)的價(jià)值，可以考慮把結(jié)果緩存起來。例子包括按交易定價(jià)的數(shù)據(jù)兀

素，如