微服務架構模式t

應用容器和微服務工作組的網址：

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

序言

隨著數字化時代的到來，微服務應用進入飛速發展時代。微服務是一種新興的分布式系統

開發范式，在架構層面，安全性是必需認真考慮的重要工作。我國隨著《數據安全法》和《個

人信息保護法》的頒布，對安全和數據保護的重視程度日益提高，架構層的安全問題必將上升

到組織安全治理層面。

如何保證微服務架構的安全？本文檔給出了CSA的最佳實踐與總結，通過CSA微服務安

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

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

李雨航YaleLi

CSA大中華區主席兼研究院院長

3

致

謝

本文檔《微服務架構模式》(MicroservicesArchitecturePattern)由CSA應用容器和微服務工

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

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

組長：高卓

翻譯組：高卓賀進李巖廖武鋒馬琳琳

審校組：郭鵬程姚凱

感謝以下單位對本文檔的支持與貢獻：

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

北京北森云計算股份有限公司

英文版本

主編/工作組聯合主席：AnilKarine1AndrewWild

主要供稿者：GustavoNievesArreazaMarinaBregkouCraigEllrod

MichaelHoldenJohnJiangKevinKeane

NumrataKulkarniVaniMurthyPradeepNampiar

VinodBbuVanjarapuMarkYanaiitis

審稿者：AnkurGargiAlexReboMichaelRozaAnkitSharma

CSA分析師：HillaryBaronMarinaBregkou

CSA全球人員：ClaireLehnertAnnMarieUlskey

4

在此感謝以上專家。如譯文有不妥當之處，敬請讀者聯系CSAGCR秘書處給與雅正！聯系

郵箱：research@c-csa.cn；云安全聯盟CSA公眾號。

5

目錄

序言3

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

121=="7

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

2目的9

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

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

4.2微服務架構模式簡介...................................................................13

5.微服務架構模式..............................................................................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（授權；模式.............................................................29

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

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

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

5.1.11適配器（包裝器/轉化/轉換）模式...............................................40

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

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

6.1.2IAM”口50

*1?1I

6.1.6微服務的彈性和可用性疊加.......................................................61

於、件/結論67

附錄C：參考文獻...............................................................................76

1.0微服務架構模式模板........................................................................80

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

2.1安全疊加作.業練習指導.................................................................82

211介紹82

2.1.2V備知識.......................................................................83

6

1.引言

以較弱方式構建微服務的影響始終存在「表現為不夠安全和把應用編程接口（API）過度

暴露，構成了微服務應用程序風險的核心部分。一些業務和技術負責人跳過搭建架構的方法2,

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

搭建架構的方式把采購的解決方案融入到現有控制環境中。即便是新建的微服務應用程序也耍

與企業舊有的其他部分集成一一沒有哪家公司會年年淘汰現有架構。不采用架構方法而單純購

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

推移而不斷增加。

無論企業領導者傾向于購買現成解決方案還是支持“內部構建”，API消費和微服務集成

都會是一種常見的系統集成預期。最好能有一種辦法指導將架構的使用、架構模式和安全控制

措施疊加集成為一個整體，確保信息安全成為既定要求的集合。微服務架構模式和相應的安全

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

全根植于產品之內。如果做得好，安全控制措施疊加會變得與用于創建微服務應用程序的架構

和設計方法難以區分。有人稱這種現象為“DevSecOps”（開發-安全-運維）/安全控制措施

疊加的概念起源于美國《聯邦信息系統管理法案（FISMA）》。"根據卜'ISMA的說法，“安全疊

加是運用裁剪指南對控制基線裁剪后得出的一個全套特定控制措施、控制措施強化和補充指南

集。”美國國家標準和技術研究所（NIST）特別出版物SP800-53《聯邦信息系統和機構安全

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

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

軟件開發的展開離不開以軟件設計模式為引導工安全控制措施疊加（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

套特定控制措施、控制措施強化和補充指南組成的離散集，可集成到架構設計流程中，充當嵌

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

軟件開發工作要把安全作為一個設計元素“內置”到軟件產品之中，而不能只把安全當作最后

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

的地方。本文后面的章節將為使軟件架構形成一個完整思路打下基礎。架構意義上的完整思路

是指表現得像一個完美數學方程式的架構表達方式；把這個思路向前推進，可以得到它的預期

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

開發人員一旦掌握軟件設計模式和安全控制措施疊加.就可以在架構成熟度上更.上一層樓,

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

制狀態。雖然這些還不是“微服務架構”，但可以支持對于那些要求保證系統行為可重復性、

可靠性、準確性和完整性的架構和設計。

微服務架構風格體現在分布式應用程序的處理足跡里，其中靜態配置、動態適應和抽象化

設想組合在一起所形成的能力，產生人們所說的“應用功能”。在微服務和容器化轉型出現之

前，許多配置和抽象化設想存在于單個整體式應用程序邊界之內。隨著整體代碼庫變得越來越

大，內部應用程序的狀態和相互依賴變得越來越難以分辨，從而帶來許多架構、開發和運維上

的挑戰。然而，讓一名業務代表負責業務流程功能.同時讓另一名產品負責人履行應用托管義

務并在一個組織結構下管理聯合開發人員的情況依然十分常見。微服務架構風格改變了組織結

構，就像改變軟件的構建和組裝樣。架構的每個部分，無論是在平臺、軟件定義、應用編程

接口（API）層面，還是在軟件開發層面，都是在微服務應用程序交付的整體功能中執行具體

和特定功能。機構把多個開發團隊組織到一起應對技術變化，響應計算、內存、存儲和網絡虛

擬化成一種能力的趨勢。存儲、網絡和服務器計算機團隊的混合體由分散的團隊組合而成。

隨著微服務軟件開發深入人心，業界越來越重視DevSecOps（開發-安全-運維）、軟件組

7

裝和應用程序安全。例如，一個業務負責人可能擁有涵蓋整個工作流程的應用程序，但是只負

責處理涉及改進現有能力或建立新能力的前瞻性請求。業務負責人關心的是已交付或可交付成

品的價值最大化；這個角色游離于軟件構建團隊之外。在微服務架構風格中，多個產品負責人

服從于某一個業務負責人，與業務負責人保持一致的情況是可能存在的。產品負責人和相關軟

件開發團隊（也就是敏捷用語中所說的“機組”[crew]）可能擁有特定功能的所有權，如搜索

8

功能（API使用、排序、算法、元數據編目），而第二個產品負責人則專注于前端客戶的用戶

體驗（風格、演示、流程和整體體驗）。數據的集成可能會由服務于多個產品負責人數據需求

的一個聯合“機組”負責。整體應用程序把所有這些角色和行動捆綁進一個垂直的支持體系，

這便是微服務架構風格的一個關鍵特點一一微服務軟件的開發和生產部署行動使機構的傳統

垂直體系扁平化。不僅應用程序的功能是分散布局的，而且它的支撐結構也是分布式的，從而

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

份和網絡功能。運維部門通常擁有一套部署和管理IT服務的流程，但是部署和測試的責任有

時會左移給構建軟件的開發人員。架構師往往需要在實施軟件工程的過程中掌握新的技能，才

能更好地把習慣和傳統的架構工作轉換成微服務架構風格。

附錄B進一步定義業務負責人、產品負責人、開發人員、運維人員和架構師的角色。有關

這五種角色的更多詳細信息和具體定義，請參見詞匯表。

2.目的

CSA于2020年2月出版《實現安全微服務架構的最佳實踐》\為讀者提供了可信安全系

統設計指南，其中最后一章著重從開發人員、運維人員和架構師的視角闡述。

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

微服務架構模式）構建、開發和部署微服務。我們提出的這個“MAP”包含微服務獨立運行和

與其他微服務通信所需要的全部信息一一這些微服務聚合到一起，會形成轉而又會成為應用程

序成分的能力。本文描述了“MAP”的關鍵元素、應該怎樣設計和部署，以及應該怎樣通過一

種合規即代碼方法把安全和合規左移。

本文的主要目的是開發一個廠商中性的參考架構基礎，從這個基礎分解出軟件和平臺（企

業）平面體現的軟件架構模式，以后還可以通過添加安全控制措施疊加重新構建。微服務架構

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

8CloudSecurityAlliance(202QFebruary24).BestPracticesinImplemeritingaSecureMicrosendees

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

9

3.讀者

本文的目標讀者是應用程序開發人員、應用程序架構師、系統和安全管理員、安全項目經

理、信息系統安全官以及其他對應用程序容器和微服務的安全負有責任或感興趣的人員。

我們假定讀者具備一定程度的操作系統、網絡和安全專業知識，同時還掌握了應用程序容

器、微服務和敏捷應用程序方面的專業知識。由于應用程序容器技術具有不斷變化的性質，因

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

4.架構與解決方案

架構并不是解決方案。解決方案是指通過架構、模式和設計上的努力滿足特定行業需要或

解決具體業務問題的辦法。解決方案旨在向客戶和企業負責人提供持續的價值。以POS機系統

為例，POS機系統是人員之間交互、技術支持的業務流程和后端支付平臺運行的綜合體現，用

于創建一種只靠架構無法實現的特定業務能力。POS機解決方案的設計是概念、系統屬性和模

式為應對某一特定業務挑戰而組合到一起的結果。任何問題都會有化解挑戰癥結的解決方案。

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

架構與解決方案的區別在于：解決方案的根本在于設計。設計包含一組模式，而這些模式

起源于最早的抽象形式一一??個架構。架構構成了運行環境中系統的基本概念或屬性，由系統

的元素、關系以及系統的設計和進化原則體現出來。商業和技術草圖和圖紙依然是架構師向工

程設計團隊表述自己想法的主要手段。為了進一步消除開發過程中的可變性，架構師與工程師

一起挑選商定的模式，共同奠定設計和框架設計活動的基礎。架構、模式和設計不引用特別命

名的技術，保持了廠商中性。設計完成后，業務負責人和技術負責人決定是全部自行構建、全

部對外采購還是結合這兩種構建方法，從而針對具體問題創建一個符合業務需要的技術解決方

案。有些業務和技術負責人選擇跳過構建架構的過程并僅憑一組要求尋找現成的解決方案，而

其他人則選擇根據要求自己構建解決方案。

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

構建架構的方法把買來的解決方案融進現有的控制環境。而這將不可避免地導致權衡，其中有

些對初始條件極為敏感，日后倒是能夠引入約束或解決方案重構，但是到了那時，改造會帶來

10

經濟成本的上升；而這無非是在償還不斷積累的技術負債。

許多人認為微服務也是一種架構，但微服務其實只是一種架構風格。大肆使用水泥預制板

的粗野主義和依托精雕細刻的橡木承載使命感的工匠風格代表了能夠渲染整棟建筑物的架構

風格。每種風格都有自己的架構原則，應用得當時，這些原則會體現在藍圖中，引導產生特定

設計，從而在物理上呈現出預期的風格。如果目標是構建高度模塊化的分布式應用程序，則應

用微服務原理、架構、模式和設計會導致出現一款微服務應用程序。

4.1模式和控制措施疊加

模式是指以可預測方式發生的一組可重復動作和安排。模式是可以通過物理外觀、直接或

間接觀察或分析看出的。設計應用系統時，軟件模式是用于解決一類計算機編程問題的一種已

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

們可以把軟件模式視為軟件代碼與支持軟件的系統之間的中間結構體現。以往的軟件模式缺乏

一個關鍵的宏觀架構表述：安全控制措施指南。開發人員通常不會自行開發安全解決方案，而

是選擇依靠從平臺或應用程序繼承的功能，只有在迫不得已的情況下才會創建自己的安全控制

措施。用加鹽的散列函數給保存的口令單向加密是開發人員自己構建安全控制措施的一個例子。

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

IT安全控制措施提供了調節和管理應用系統行為的手段。IT安全控制措施是一種抽象說

法，表述了與應對感知風險的預防、檢測或糾正對策相應的底層技術、管理或物理能力。IT

安全控制措施的目標是把潛在風險降低到可接受、無害或無關緊要的水平。控制目標也是一種

抽象說法，但不同之處在于它是對以特定方式實施控制措施所要達到的預期結果或目的的陳述。

控制目標通過使用一個或通常的一組控制措施實現；后者便是所謂的深度防御一一用不同類型

的多個控制措施協同預防、檢測和/或糾正次優運行狀態。控制目標源自一個控制框架，后者

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

施可以在應用程序生命周期的不同階段以及應用程序運行環境的不同層面發揮作用。IT安全

控制措施從新軟件創意誕生，到構建、部署，再到平臺運行的所有階段一直存在；這些階段構

成了所謂軟件開發生命周期。

安全專業人員確實在推動開發人員左移，但是應用程序安全領域要求的專業水平與IT安

全平臺專業人員技術水平的差異越來越大，距離也越來越遠。機構可以通過培養或雇用具有開

11

拓精神的軟件開發人員或者使用由不同領域專業人員組成的角色組合管理技能上的差距。在整

體式應用程序下，管理技能差距是可以實現的，但是分布式應用程序設計的實體化會擴大豎井

式組織結構部門的控制范圍，從而進一步加劇技能差距和所有權之爭。

表現不同且論述或探索最少的是企業平臺層面一一這里有多個豎井式組織結構部門使用

IT控制措施（網絡、安全、服務器、存儲、消息傳遞）一一與軟件開發層面（安全軟件開發

生命周期和安全測試自動化）之間的空間。安全控制措施疊加可以把企業平臺層面與較低的軟

件開發層面聯系到一起。安全疊加的使用代表了一個適合可擴展安全架構角色的領域，其中保

密性、完整性和可用性可擴展到把彈性和隱私問題也包括進來。隨著世界轉向使用以軟件為中

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

整個人機交互過程中自我管理數據訪問能力實現完整的隱私。安全架構作為一種完整思路涵蓋

了人、平臺，外加軟件。

安全架構代表了企業架構中專門解決信息系統彈性問題并為滿足安全要求的功能提供架

構信息的部分。微服務語境F的安全架構不僅在現有平臺和軟件架構上引入了控制措施疊加的

概念，而且安全架構師有責任和義務劃出一條界線，把體現在平臺層面的控制措施疊加與體現

在軟件本身的控制措施疊加區分開來。作為一種完整的安全架構思路，安全疊加是用于降低風

險的多項控制措施的集合體，是管理、技術和物理控制措施的組合。

全面考慮問題的安全架構師往往會先構建威脅模型，然后才把控制措施運用到復雜的解決

方案架構之中。威脅建模是把控局面的一種方式。紅藍對抗、STRIDE,攻擊樹、Trike、VAST、

PASTA和ISO-31010Delphi是風險識別方法的示例。威脅建模在很大程度上屬于圍繞著人展

開的一種活動。最好的分析產生于各有側重的多樣化人群，這樣的群體對攻擊面各個方面的深

入體驗，遠遠超過一個人的單獨認知。即便是分析受到的系統性沖擊，群體分析也不太容易變

得脆弱。強健的威脅模型來自于對當前狀態、制度歷史和想象力的深入的行業縱向認識，以及

選擇一種適合問題的分析方法.而不是安全架構師的方便程度。讓威脅模型契合戰術實施范圍

并避免空幻、存在主義和黑天鵝場景至關重要。威脅模型得出的結果會使IT安全控制措施的

落實合法化，從而形成個可以抑制已知或假定風險的強大疊加。在這一點上，安全架構不同

于解決方案架構，因為它可以減輕乃至消除在擬議的解決方案架構中發現的潛在技術、管理或

物理風險。

一個微服務應用程序不會把每個設計模式和每個安全控制措施疊加全部囊括其中，但是會

12

包含那些被認為對于有效設計不可或缺，可以解決客戶問題的軟件架構模式和安全疊加。而這

正是軟件層面實現扁平化并融進平臺層面的結合部。在微服務架構風格中，任何解決方案除非

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

式配套，才算解決方案架構構建完成。模式與疊加組合到一起，構成了微服務應用程序的安全

控制措施狀態。

4.2微服務架構模式簡介

為了便于指導安全控制措施疊加對微服務的施用，通用微服務架構模式用兩個分支形成了

兩個不同的視角。第一個視角著眼于企業層面。企業層面包含了可協助實現微服務架構治理的

信息技術資產。企業期望減少控制措施狀態的變數。自定義編碼、生產狀態變通方案和一次性

修改都會增加開發成本。技術負債（如以增添安全設備形式出現的技術負債）、在設計中引入

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

久存在。企業環境期望軟件開發盡可能多地繼承安全控制措施，以防開發團隊在編制應用程序

安全指南的過程中出現可變性和不可靠性。安全疊加同時存在于企業層面和軟件層面。API注

冊中心處理已完成開發的微服務的清單和版本以及主導服務供應商和第三方集成。服務存儲庫

（存放API規范、模板、代碼腳手架、用于構建過程的構件等）在微服務開發過程中建立統一

性、自動進行靜態和動態安全測試，并把微服務引入容器，最終通過公共管道交付合為一體的

功能（例如會先觸發安全檢查，然后觸發配置管理資源部署計劃的Jenkins操作）。理想狀態

是，按企業層面的要求在執行引導進程的過程中交付平臺層面的安全鉤、調用和集成，這樣可

以避免在運行期間不得不進行的修改。

第二個視角著眼于軟件層面。圖1是分布式微服務應用的分解圖，這種狀況存在于軟件層

面，是最接近軟件代碼的表現方式。該圖描述了合成的分布式微服務應用程序的一般性圖景。

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

服務組件。各類機器客戶端（瀏覽器、物聯網、移動、API集成）和物理消費者通過企業層面

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

有一項業務功能，同時包含用來控制客戶端可以從暴露的API獲取哪些內容的其他業務規則。

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

的數據。微服務利用企業層面的服務和軟件層面的API網關服務在容器之間平衡負載，允許多

個微服務實例在生產中同時運行。在軟件層面的微服務環境下，由sidecar服務代表公用程序

13

服務處理與微服務中存在業務邏輯無關的任務。每個微服務API都有一個sidecar與之配對，

而在集群容器環境中，sidecar根據服務通信策略和安全策略交付服務的手段。通信流的主要

組成機制是網絡訪問控制邏輯。控制會以虛擬局域網、基于策略的路由選擇、基于上下文的

ACL、特定網關邏輯和軟件定義的網絡的形式出現。這些企業層面執行方案中的每一個都自帶

安全疊加權衡。構成通信流和控制流的主要手段，是企業層面嚴格管理的授權，以及攜帶被加

密客戶端權限（即OAuth）、外部管理的托管憑證（如平臺層面機對機憑證托管和管理）和mTLS

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

跨企業和軟件層面發揮作用一一從而實現深度防御。安全控制措施疊加同時存在于兩個層面。

客戶端

（客戶'設備、第三方APIJII點、可值和半可信方）

企業層面

企業內容交付和ONS圈務

企業路由和交換凰務

企業防火墻股務

企業代理冊務

身份供應裕KIK務雷碼程務DEVOPS/安全SMC容4注霸API注冊

（生命冏期、挑范、

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

運行時配

軟件層面

集群/集群API

:段式

容器容器

極式枚式：ifeKB

SDCKFacade/~^p\融凰務參考

珞由選擲

傲原務（UI）\/（業務邏輯）

震合

代理

SidecarSidecar

API網關記錄

數據源

段式

贛脫務

（包奘X）

極式

舊有應用程序

Sidecar

企業層面監控和遙測

OS.踩速、淵■指標，??.工作流、成擬化）

圖4T微服務參考架構一一企業層面和軟件層面

14

5.微服務架構模式

5.1模式

以下架構模式適用于將微服務開發成業務應用。研究這些模式時一定會注意到，正是許多

模式的共同作用，構成了一個安全的系統。盡管最初可能要從某一個模式(如身份驗證)入手,

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

5.1.1卸載(Offload)模式

卸載是針對具體環境的一個通用數據流動作。卸載可以與API網關功能緊密耦合，例如通

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

可以與數據訪問層緊密耦合，在這一層把數據寫入分散到多個同時進行的數據提交動作中，從

而提高數據寫入或讀取的速度。卸載還可以應用了身份驗證和授權。一般來說，被卸載的功能

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

再被微服務API納入它的代碼庫。

版本1.0

15

模式目的展現鞏固技術能力的機會

層面位置企業(平臺)層面

結構描述API網關是外部流量進入微服務應用的入口。

行為描述卸載TLS證書托管；TLS終止；AuthN和AuthX請求中介服務

數據特性傳輸中的數據

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

上游負載平衡平臺

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

內部事件/消息HTTPSv2/3；AS2

傳遞需要

外部事件/消息傳遞API層面日志；網關層面系統日志；AuthN和AuthX消息交換

鏈接

事件響應行為發送，不接收。沒有轉換；原始機器輸出

共同的上游鏈接防火墻：全局和/或本地通信流負載平衡；網絡間ACL

共同的下游鏈接發證機構；配置管理；API注冊中心；集群管理API安全環境；機器

ID/服務ID憑證托管

Ops安全回接API性能監控；syslog監控；機器健康監控；異常檢測

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

控制

16

評估方法API性能趨勢分析；SIEM日志分析并與上游事件關聯；跨APT訪問端

口和協議的異常關聯

控制措施疊加的特性可從平臺繼承，而不是內置于API規范或容器基礎設施。

復合狀態（獨有/通通用；其他模式也使用這一疊加。

用）

5.1.2路由（路由選擇）模式

當一個端點需要暴露背后的多項服務時.，可使用路由模式，根據入站請求路由請求和消息。

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

入路由策略和通信流管理.則需要把API規范與有關消息隊列設計的路由邏輯結合到一起實現

API拓撲（即“誰可以與誰交談，誰可以從誰那兒獲得消息”）。以往，大型分布式整體式傳

統應用程序依靠消息隊列傳輸交易信息.以便應用保持狀態。如果沒有服務網格可供使用，微

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

另外，路由選擇模式（或功能）可以設置在APT網關上。路由模式可以存在于硬件或軟件中。

17

路由模式

版本1.0

根據請求中的數據，如識別身份、來源、客戶端類型、請求主機

模式目的

值、請求URI路徑元素等的請求標頭，將請求通信流路由給同服

務的不同版本或實例。根據通過源1P地址確定的請求源在有限時

間內將請求路由給服務的一個新版本，便是路由選擇模式的一個

用例。

路由目的地也可以是消息隊列而不是同步服務端點。

層面位置企業（平臺）層面

結構描述根據路由策略配置所定義的請求或消息數據，將請求路由到服務

的特定版本或實例或消息隊列。

行為描述根據請求數據和路由策略配置對入站請求進行評估，確定目標服

務實例的目的地或消息隊列。

數據特性使用中的數據/傳輸中的數據

主要依賴性API網關、經過配置的服務網格功能、sidecar等路由組件必須可

用。

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

內部事件/消息傳遞目標服務和消息隊列目的地的健康和可用

需要

外部事件/消息傳遞服務網格日志和遙測

鏈接

事件響應行為響應目標服務不可用的自適應或后備路由

18

共同的上游鏈接IAM平臺、網關平臺（API,負載平衡，基于策略的路由）

共同的下游鏈接隊列、數據存儲庫、其他內部API

API網關可用性

Ops安全回接

DDOS預防

擴展或節制通信流以確保可用性

SAST——服務網格配置審計

DevSecOps回接

DAST---服務端點的AuthN和AuthZ測試

IAST一一剔除假陽性結果

評估方法路由功能的可觀察性、遙測和U志記錄。U志記錄可提供實時可

見性和可觀察性。

控制措施疊加的特性預防性---DevSecOps控制、DDoS預防

檢測性和糾正性一一擴容/收縮以確保可用性

復合狀態（獨有7通用）通用

5.1.3聚合模式

聚合模式接收并向多個微服務發出請求，然后把對后端服務發出的多個請求合并成一個請

求，用以響應初始請求。當許多設備向一個中心點發送交易消息和活動日志時，往往會在云邊

緣發生軟件定義的聚合。其他模式可能會在網關聚合背后發揮作用，如Facade模式、代理模

式和斷路器模式，具體由應用目標和通信特點決定。這些設計模式有類似的結構，但是使用它

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

19

版本l.o

模式目的聚合（網關）模式的目的是減少應用程序對后端服務提出請求的

數量，并提高應用程序在高時延網絡上的性能。

層面位置企業（平臺）層面

結構描述聚合（網關）模式用于將多個單獨的請求聚合成一個請求或響應。

行為描述當一個客戶端需要向各種后端系統發出多個調用來執行一項操作

時，聚合（網關）模式會很有用。

數據特性當聚合器合并來自多個終端的數據集時，使用中的數據可能需要

得到安全保護。否則，聚合器可能只在請求者與響應者之間傳輸

數據。

主要依賴性網絡（網絡可能會帶來嚴重時延）

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

20

內部事件/消息傳遞需聚合器模式可安全驗證請求者的身份并傳遞一個訪問令牌。服務

要可驗證請求者是否得到授權可以執行所涉操作。

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

鏈接保護靜止數據等）

事件響應行為確保聚合網關具有可滿足應用程序可用性要求的彈性設計。

聚合網關可能是一個單點故障（SPOF）點，因此應該具備處理負

載平衡的良好能力。

聚合網關應該配備有適當的控制，可確保來自后端系統的任何響

應延遲都不會造成性能問題。

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

共同的下游鏈接維護、運行時間/停機時間、集成、測試、漏洞掃描和打補丁

Ops安全回接Tie-backAPI性能監控：系統日志監控；健康監控：異常檢測、事件管理、

反惡意軟件/病毒、漏洞抑制、補丁

DevSecOps回接安全SDLC：敏捷、更簡單/更靈活的開發和測試周期、持續集成/持

續交付（CI/CD）管道

評估方法日志記錄/監控；警報、基于授權失敗條件的計量警報、SIEM事故

和事件管理

控制措施疊加的特性網關可改善并直接影響應用程序的性能和規模。

預防性：漏洞抑制、打補丁

糾正性：事件響應

檢測性：性能監控、健康監控

復合狀態（獨有/通用）通用

21

5.1.4緩存模式

應用設計中的緩存通常是用來滿足提高可用性、改善應用性能和/或減少后端數據讀寫的

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

操作對于后續使用具有持續的價值，可以考慮把結果緩存起來。例子包括按交易定價的數據兀

素，如