《2023微服务架构模式.docx》由会员分享，可在线阅读，更多相关《2023微服务架构模式.docx（80页珍藏版）》请在三一办公上搜索。
1、微服务架构模式2024目录序言3致谢41 .引言72 .目的93 .读者104 .架构与解决方案104 .1模式和控制措施叠加115 .2微服务架构模式简介135 .微服务架构模式155.1 模式155. 1.1卸载（OffIoad）模式156. 1.2路由（路由选择）模式177. 1.3聚合模式198. 1.4缓存模式229. 1.5代理2410. .6AuthN（身份验证）模式2711. 1.7AuthZ（授权）模式2912. 1.8Facade模式3213. 1.9StranglerFig模式3414. 1.10断路器（CirCUitBreaker）模式3715. .11适配器（包装器/
2、转化/转换）模式406 .安全控制措施叠加426. 1叠加介绍446.1.1服务叠加456.1.2IAM叠加506.1.3网络叠加526.1.4监控叠加556.1.5密码叠加576.1.6微服务的弹性和可用性叠加61总结/结论67附录A：缩略语69附录B：词汇表Glossary70附录C：参考文献76附录D：作业练习指导801.0微服务架构模式模板801.1 模式作业练习指导801.2 模式模板802. 0安全叠加模板822.1 安全叠加作业练习指导822.1.1介绍822.1.2预备知识832.1.3作业练习的步骤851.引言以较弱方式构建微服务的影响始终存在I表现为不够安全和把应用编程接口
3、（APn过度暴露，构成了微服务应用程序风险的核心部分。一些业务和技术负责人跳过搭建架构的方法2,仅凭几条粗略的要求寻找软件解决方案。然而在开放市场上寻求解决方案的人们最终还是要用搭建架构的方式把采购的解决方案融入到现有控制环境中。即便是新建的微服务应用程序也要与企业旧有的其他部分集成没有哪家公司会年年淘汰现有架构。不采用架构方法而单纯购买解决方窠将不可避免地在日后引入各种制约和附加组件，修修补补的资金成本会随着时间的推移而不断增加。无论企业领导者倾向于购买现成解决方案还是支持“内部构建”，API消费和微服务集成都会是一种常见的系统集成预期。最好能有一种办法指导将架构的使用、架构模式和安全控制措
4、施叠加集成为一个整体，确保信息安全成为既定要求的集合。微服务架构模式和相应的安全控制措施的叠加为微服务的开发奠定了基础，形成一种完整的思路。模式和叠加可确保信息安全根植于产品之内。如果做得好，安全控制措施叠加会变得与用于创建微服务应用程序的架构和设计方法难以区分。有人称这种现象为DevSecOps”（开发-安全-运维）安全控制措施叠加的概念起源于美国联邦信息系统管理法案（FISMA）。根据FISMA的说法，“安全叠加是运用裁剪指南对控制基线裁剪后得出的一个全套特定控制措施、控制措施强化和补充指南集。美国国家标准和技术研究所（NIST）特别出版物SP800-53联邦信息系统和机构安全和隐私控制措
5、施第4版第3.3节对安全控制措施叠加作了进一步阐述。尽管叠加是NIST引入的概念，但是ISACACOBIT5、PCI-DSS3.2.1或CSACCMv3.0.1等其他控制框架也可使用。软件开发的展开离不开以软件设计模式为引导）安全控制措施叠加（OVerIay）是指由全套特定控制措施、控制措施强化和补充指南组成的离散集，可集成到架构设计流程中，充当嵌入和既定的管理、技术或物理要求。软件设计模式与安全控制措施叠加结合到一起会告诉我们，软件开发工作要把安全作为一个设计元素“内置”到软件产品之中，而不能只把安全当作最后才涂抹到软件产品上的一层外衣，而这一层外衣到了日后成为必须付出极高代价才能做出改变的
6、地方。本文后面的章节将为使软件架构形成一个完整思路打下基础。架构意义上的完整思路是指表现得像一个完美数学方程式的架构表达方式；把这个思路向前推进，可以得到它的预期产品，向后推演，则可以看到它的非功能和功能要求。开发人员一旦掌握软件设计模式和安全控制措施叠加，就可以在架构成熟度上更上一层楼，从特定的微服务视角揭示底层服务交付框架具体方面（如数据、集成和部署架构）所需要的控制状态。虽然这些还不是“微服务架构”，但可以支持对于那些要求保证系统行为可重复性、可靠性、准确性和完整性的架构和设计。微服务架构风格体现在分布式应用程序的处理足迹里，其中静态配置、动态适应和抽象化设想组合在一起所形成的能力，产生
7、人们所说的“应用功能”。在微服务和容器化转型出现之前，许多配置和抽象化设想存在于单个整体式应用程序边界之内。随着整体代码库变得越来越大,内部应用程序的状态和相互依赖变得越来越难以分辨，从而带来许多架构、开发和运维上的挑战。然而，让一名业务代表负责业务流程功能，同时让另一名产品负责人履行应用托管义务并在一个组织结构下管理联合开发人员的情况依然十分常见。微服务架构风格改变了组织结构，就像改变软件的构建和组装一样。架构的每个部分，无论是在平台、软件定义、应用编程接口（API）层面，还是在软件开发层面，都是在微服务应用程序交付的整体功能中执行具体和特定功能。机构把多个开发团队组织到一起应对技术变化，响
8、应计算、内存、存储和网络虚拟化成一种能力的趋势。存储、网络和服务器计算机团队的混合体由分散的团队组合而成。随着微服务软件开发深入人心，业界越来越重视DevSecOps（开发-安全-运维）软件组装和应用程序安全。例如，一个业务负责人可能拥有涵盖整个工作流程的应用程序，但是只负责处理涉及改进现有能力或建立新能力的前瞻性请求。业务负责人关心的是已交付或可交付成品的价值最大化；这个角色游离于软件构建团队之外。在微服务架构风格中，多个产品负责人服从于某一个业务负责人，与业务负责人保持一致的情况是可能存在的。产品负责人和相关软件开发团队（也就是敏捷用语中所说的“机组”crew）可能拥有特定功能的所有权，如
9、搜索功能（API使用、排序、算法、元数据编目），而第二个产品负责人则专注于前端客户的用户体验（风格、演示、流程和整体体验）o数据的集成可能会由服务于多个产品负责人数据需求的一个联合“机组”负责。整体应用程序把所有这些角色和行动捆绑进一个垂直的支持体系，这便是微服务架构风格的一个关键特点一一微服务软件的开发和生产部署行动使机构的传统垂直体系扁平化。不仅应用程序的功能是分散布局的，而且它的支撑结构也是分布式的，从而迫使我们更多地依靠自动化提供以前在垂直体系中相互隔离的各种基础设施、策略、安全、身份和网络功能。运维部门通常拥有一套部署和管理IT服务的流程，但是部署和测试的责任有时会左移给构建软件的开
10、发人员。架构师往往需要在实施软件工程的过程中掌握新的技能，才能更好地把习惯和传统的架构工作转换成微服务架构风格。附录B进一步定义业务负责人、产品负责人、开发人员、运维人员和架构师的角色。有关这五种角色的更多详细信息和具体定义，请参见词汇表。2 .目的CSA于2020年2月出版实现安全微服务架构的最佳实践8,为读者提供了可信安全系统设计指南，其中最后一章着重从开发人员、运维人员和架构师的视角阐述。本文旨在提出一种可重复的方法，用于按“MAP”（MiCroSerViCeSArchitecturePattern,微服务架构模式）构建、开发和部署微服务。我们提出的这个“MAP”包含微服务独立运行和与其
11、他微服务通信所需要的全部信息一一这些微服务聚合到一起，会形成转而又会成为应用程序成分的能力。本文描述了“MAP”的关键元素、应该怎样设计和部署，以及应该怎样通过一种合规即代码方法把安全和合规左移。本文的主要目的是开发一个厂商中性的参考架构基础，从这个基础分解出软件和平台（企业）平面体现的软件架构模式，以后还可以通过添加安全控制措施叠加重新构建。微服务架构模式的成功分解和重组就证明了这一点；其中的集成操作便是安全控制措施的叠加。3 .读者本文的目标读者是应用程序开发人员、应用程序架构师、系统和安全管理员、安全项目经理、信息系统安全官以及其他对应用程序容器和微服务的安全负有责任或感兴趣的人员。我们
12、假定读者具备一定程度的操作系统、网络和安全专业知识，同时还掌握了应用程序容器、微服务和敏捷应用程序方面的专业知识。由于应用程序容器技术具有不断变化的性质，因此我们鼓励读者借助其他资源（包括本文列出的参考文献）获得更新和更详细的信息。4 .架构与解决方案架构并不是解决方案。解决方案是指通过架构、模式和设计上的努力满足特定行业需要或解决具体业务问题的办法。解决方案旨在向客户和企业负责人提供持续的价值。以POS机系统为例，POS机系统是人员之间交互、技术支持的业务流程和后端支付平台运行的综合体现，用于创建一种只靠架构无法实现的特定业务能力。POS机解决方案的设计是概念、系统属性和模式为应对某一特定业
13、务挑战而组合到一起的结果。任何问题都会有化解挑战症结的解决方案。但是你若想搞清问题的来龙去脉，就必须回到源头去了解这个问题之所以会产生的条件和决定。架构与解决方案的区别在于：解决方案的根本在于设计。设计包含一组模式，而这些模式起源于最早的抽象形式个架构。架构构成了运行环境中系统的基本概念或属性，由系统的元素、关系以及系统的设计和进化原则体现出来。商业和技术草图和图纸依然是架构师向工程设计团队表述自己想法的主要手段。为了进一步消除开发过程中的可变性，架构师与工程师一起挑选商定的模式，共同奠定设计和框架设计活动的基础。架构、模式和设计不引用特别命名的技术，保持了厂商中性。设计完成后，业务负责人和技
14、术负责人决定是全部自行构建、全部对外采购还是结合这两种构建方法，从而针对具体问题创建一个符合业务需要的技术解决方案。有些业务和技术负责人选择跳过构建架构的过程并仅凭一组要求寻找现成的解决方案，而其他人则选择根据要求自己构建解决方案。那些到市场上寻求一站式、垂直集成、低代码或无代码解决方案的公司，最终也还是要用构建架构的方法把买来的解决方案融进现有的控制环境。而这将不可避免地导致权衡，其中有些对初始条件极为敏感，日后倒是能够引入约束或解决方案重构，但是到了那时，改造会带来经济成本的上升；而这无非是在偿还不断积累的技术负债。许多人认为微服务也是一种架构，但微服务其实只是一种架构风格。大肆使用水泥预
15、制板的粗野主义和依托精雕细刻的橡木承载使命感的工匠风格代表了能够渲染整栋建筑物的架构风格。每种风格都有自己的架构原则，应用得当时，这些原则会体现在蓝图中，引导产生特定设计,从而在物理上呈现出预期的风格。如果目标是构建高度模块化的分布式应用程序，则应用微服务原理、架构、模式和设计会导致出现一款微服务应用程序。4.1 模式和控制措施叠加模式是指以可预测方式发生的一组可重复动作和安排。模式是可以通过物理外观、直接或间接观察或分析看出的。设计应用系统时，软件模式是用于解决一类计算机编程问题的一种已知可重用方法。软件模式显示构建元素之间的关系，但不规定问题或要求的最终解决方案。我们可以把软件模式视为软件
16、代码与支持软件的系统之间的中间结构体现。以往的软件模式缺乏一个关键的宏观架构表述：安全控制措施指南。开发人员通常不会自行开发安全解决方案，而是选择依靠从平台或应用程序继承的功能，只有在迫不得已的情况下才会创建自己的安全控制措施。用加盐的散列函数给保存的口令单向加密是开发人员自己构建安全控制措施的一个例子。历史上软件模式都是指导软件开发，并不使用信息技术(IT)安全控制措施。IT安全控制措施提供了调节和管理应用系统行为的手段。IT安全控制措施是一种抽象说法,表述了与应对感知风险的预防、检测或纠正对策相应的底层技术、管理或物理能力。IT安全控制措施的目标是把潜在风险降低到可接受、无害或无关紧要的水
17、平。控制目标也是一种抽象说法,但不同之处在于它是对以特定方式实施控制措施所要达到的预期结果或目的的陈述。控制目标通过使用一个或通常的一组控制措施实现；后者便是所谓的深度防御一用不同类型的多个控制措施协同预防、检测和/或纠正次优运行状态。控制目标源自一个控制框架，后者是可用于帮助业务流程负责人履行防止信息丢失职责的一组基本控制措施。多层布局的控制措施可以在应用程序生命周期的不同阶段以及应用程序运行环境的不同层面发挥作用。IT安全控制措施从新软件创意诞生，到构建、部署，再到平台运行的所有阶段一直存在；这些阶段构成了所谓软件开发生命周期。安全专业人员确实在推动开发人员左移，但是应用程序安全领域要求的
18、专业水平与IT安全平台专业人员技术水平的差异越来越大，距离也越来越远。机构可以通过培养或雇用具有开拓精神的软件开发人员或者使用由不同领域专业人员组成的角色组合管理技能上的差距。在整体式应用程序下，管理技能差距是可以实现的，但是分布式应用程序设计的实体化会扩大竖井式组织结构部门的控制范围，从而进一步加剧技能差距和所有权之争。表现不同且论述或探索最少的是企业平台层面一一这里有多个竖井式组织结构部门使用IT控制措施（网络、安全、服务器、存储、消息传递）一一与软件开发层面（安全软件开发生命周期和安全测试自动化）之间的空间。安全控制措施叠加可以把企业平台层面与较低的软件开发层面联系到一起。安全叠加的使用
19、代表了一个适合可扩展安全架构角色的领域，其中保密性、完整性和可用性可扩展到把弹性和隐私问题也包括进来。随着世界转向使用以软件为中心的抽象化方法以及企业接受软件中心主义，依赖不仅要求服务具有弹性，而且还要求可通过整个人机交互过程中自我管理数据访问能力实现完整的隐私。安全架构作为一种完整思路涵盖了人、平台，外加软件。安全架构代表了企业架构中专门解决信息系统弹性问题并为满足安全要求的功能提供架构信息的部分。微服务语境下的安全架构不仅在现有平台和软件架构上引入了控制措施叠加的概念，而且安全架构师有责任和义务划出一条界线，把体现在平台层面的控制措施叠加与体现在软件本身的控制措施叠加区分开来。作为一种完整
20、的安全架构思路，安全叠加是用于降低风险的多项控制措施的集合体，是管理、技术和物理控制措施的组合。全面考虑问题的安全架构师往往会先构建威胁模型，然后才把控制措施运用到复杂的解决方案架构之中。威胁建模是把控局面的一种方式。红蓝对抗、STRIDE,攻击树、Trike.VASTPASTA和ISO-31010Delphi是风险识别方法的示例。威胁建模在很大程度上属于围绕着人展开的一种活动。最好的分析产生于各有侧重的多样化人群，这样的群体对攻击面各个方面的深入体验,远远超过一个人的单独认知。即便是分析受到的系统性冲击，群体分析也不太容易变得脆弱。强健的威胁模型来自于对当前状态、制度历史和想象力的深入的行业
21、纵向认识，以及选择一种适合问题的分析方法，而不是安全架构师的方便程度。让威胁模型契合战术实施范围并避免空幻、存在主义和黑天鹅场景至关重要。威胁模型得出的结果会使IT安全控制措施的落实合法化，从而形成一个可以抑制已知或假定风险的强大叠加。在这一点上，安全架构不同于解决方案架构，因为它可以减轻乃至消除在拟议的解决方案架构中发现的潜在技术、管理或物理风险。一个微服务应用程序不会把每个设计模式和每个安全控制措施叠加全部囊括其中，但是会包含那些被认为对于有效设计不可或缺，可以解决客户问题的软件架构模式和安全叠加。而这正是软件层面实现扁平化并融进平台层面的结合部。在微服务架构风格中，任何解决方窠除非在每个
22、所用模式都配备了相应的安全控制措施叠加，否则都谈不上概念完整。所有叠加都与模式配套，才算解决方案架构构建完成。模式与叠加组合到一起，构成了微服务应用程序的安全控制措施状态。4 .2微服务架构模式简介为了便于指导安全控制措施叠加对微服务的施用，通用微服务架构模式用两个分支形成了两个不同的视角。第一个视角着眼于企业层面。企业层面包含了可协助实现微服务架构治理的信息技术资产。企业期望减少控制措施状态的变数。自定义编码、生产状态变通方案和一次性修改都会增加开发成本。技术负债（如以增添安全设备形式出现的技术负债）、在设计中引入会限制灵活性的紧耦合等，可能会妨碍基础设施作为代码部署的能力，从而形成没有必要
23、的持久存在。企业环境期望软件开发尽可能多地继承安全控制措施，以防开发团队在编制应用程序安全指南的过程中出现可变性和不可靠性。安全叠加同时存在于企业层面和软件层面。API注册中心处理已完成开发的微服务的清单和版本以及主导服务供应商和第三方集成。服务存储库（存放API规范、模板、代码脚手架、用于构建过程的构件等）在微服务开发过程中建立统一性、自动进行静态和动态安全测试，并把微服务引入容器，最终通过公共管道交付合为一体的功能（例如会先触发安全检查，然后触发配置管理资源部署计划的JenkinS操作）。理想状态是，按企业层面的要求在执行引导进程的过程中交付平台层面的安全钩、调用和集成，这样可以避免在运行
24、期间不得不进行的修改。第二个视角着眼于软件层面。图1是分布式微服务应用的分解图，这种状况存在于软件层面,是最接近软件代码的表现方式。该图描述了合成的分布式微服务应用程序的-般性图景。它像是一张X光片，在上半部分显示主要的可继承的企业层面的系统集成，在下半部分显示微服务组件。各类机器客户端（浏览器、物联网、移动、API集成）和物理消费者通过企业层面访问分布式微服务应用程序提供的功能。API控制着客户端使用的表示逻辑，并提供一项且只有一项业务功能，同时包含用来控制客户端可以从暴露的API获取哪些内容的其他业务规则。API可以整理来自多个来源的数据，并且可以访问安放在托管微服务API的容器外面数据卷
25、上的数据。微服务利用企业层面的服务和软件层面的API网关服务在容器之间平衡负载，允许多个微服务实例在生产中同时运行。在软件层面的微服务环境下，由sidecar服务代表公用程序服务处理与微服务中存在业务逻辑无关的任务。每个微服务API都有一个sidecar与之配对，而在集群容器环境中，sidecar根据服务通信策略和安全策略交付服务的手段。通信流的主要组成机制是网络访问控制逻辑。控制会以虚拟局域网、基于策略的路由选择、基于上下文的ACL、特定网关逻辑和软件定义的网络的形式出现。这些企业层面执行方案中的每一个都自带安全叠加权衡。构成通信流和控制流的主要手段，是企业层面严格管理的授权，以及携带被加密
26、客户端权限（即OAUth）、外部管理的托管凭证（如平台层面机对机凭证托管和管理）和mTLS（企业层面相互传输层安全证书管理）的访问令牌。安全控制措施叠加可以在一个层面内以及跨企业和软件层面发挥作用一一从而实现深度防御。安全控制措施叠加同时存在于两个层面。客户端（客户、设第三方AH点,可信构半可信方）企业层面企业内8交付M（WS解务DfVoPS/安全 SOlCCI/C0IRQ集群/集群APlAPlite命同阳.m.tiwei)APl网关模式务(UI)SkSeorSAdecv软件层面模式KAB企业层面监控和遥测（SM.Sit.旃指标,VM.工作流，JSKHt）图4-1微服务参考架构一一企业层面和软
27、件层面5 .微服务架构模式5.1 模式以下架构模式适用于将微服务开发成业务应用。研究这些模式时一定会注意到，正是许多模式的共同作用，构成了一个安全的系统。尽管最初可能要从某一个模式(如身份验证)入手，但必须搞清，这些模式是怎样通过彼此交互支撑起一个安全而富有弹性的业务解决方案的。5.1.1 卸载(OffIoad)模式卸载是针对具体环境的一个通用数据流动作。卸载可以与API网关功能紧密耦合，例如通过内核软件或加速器硬件提供TLS密码终止功能，从而使后端设备不必管理TLS连接。卸载也可以与数据访问层紧密耦合，在这一层把数据写入分散到多个同时进行的数据提交动作中，从而提高数据写入或读取的速度。卸载还
28、可以应用于身份验证和授权。一般来说，被卸载的功能是常被许多其他服务作为共享服务使用的功能。如果选择卸载一项服务，就表明一个资源不必再被微服务API纳入它的代码库。版本LO模式目的展现巩固技术能力的机会层面位置企业(平台)层面结构描述APl网关是外部流量进入微服务应用的入口。行为描述卸载TLS证书托管；TLS终止；AUthN和AUthX请求中介服务数据特性传输中的数据主要依赖性平台层面与IAM平台、证书管理平台相互连接;上游入口堡垒防火墙；上游负载平衡平台次要依赖性容器集合体(containerfleet)；相邻的安全日志相互连接内部事件/消息传递需要HTTPSv2/3；AS2外部事件/消息传递
29、链接APl层面日志；网关层面系统日志；AUthN和AUthX消息交换事件响应行为发送，不接收。没有转换；原始机器输出共同的上游链接防火墙；全局和/或本地通信流负载平衡；网络间ACL共同的下游链接发证机构；配置管理；APl注册中心；集群管理APl安全环境；机器ID/服务ID凭证托管OPS安全回接APl性能监控；SySIog监控；机器健康监控；异常检测DeVSeCoPS回接安全SDLC；APl注册中心；Swagger/YAMLAPl定义；AUthN和AUthX控制评估方法API性能趋势分析；SIEM日志分析并与上游事件关联；跨APl访问端口和协议的异常关联控制措施叠加的特性可从平台继承，而不是内置
30、于APl规范或容器基础设施。复合状态（独有/通通用；其他模式也使用这一叠加。用）5.1.2 路由（路由选择）模式当一个端点需要暴露背后的多项服务时，可使用路由模式，根据入站请求路由请求和消息。路由选择策略和路由通信流管理被嵌入服务网格和/或使用SideCar服务。如果服务网格没有嵌入路由策略和通信流管理，则需要把API规范与有关消息队列设计的路由逻辑结合到一起实现API拓扑（即“谁可以与谁交谈，谁可以从谁那儿获得消息”）O以往，大型分布式整体式传统应用程序依靠消息队列传输交易信息，以便应用保持状态。如果没有服务网格可供使用，微服务将可能不得不拥有路由选择逻辑，以此执行原本该由SideCar服务
31、执行的公用程序功能。另外，路由选择模式（或功能）可以设置在APl网关上。路由模式可以存在于硬件或软件中。路由模式版本1.0模式目的根据请求中的数据，如识别身份、来源、客户端类型、请求主机值、请求URl路径元素等的请求标头，将请求通信流路由给同一服务的不同版本或实例。根据通过源IP地址确定的请求源在有限时间内将请求路由给服务的一个新版本，便是路由选择模式的一个用例。路由目的地也可以是消息队列而不是同步服务端点。层面位置企业（平台）层面结构描述根据路由策略配置所定义的请求或消息数据，将请求路由到服务的特定版本或实例或消息队列。行为描述根据请求数据和路由策略配置对入站请求进行评估，确定目标服务实例的
32、目的地或消息队列。数据特性使用中的数据/传输中的数据主要依赖性APl网关、经过配置的服务网格功能、SideCar等路由组件必须可用。次要依赖性路由目的地或消息队列必须可用。内部事件/消息传递需要目标服务和消息队列目的地的健康和可用外部事件/消息传递链接服务网格日志和遥测事件响应行为响应目标服务不可用的自适应或后备路由共同的上游链接IAM平台、网关平台（API,负载平衡，基于策略的路由）共同的下游链接队列、数据存储库、其他内部APlOPS安全回接APl网关可用性DDOS预防扩展或节制通信流以确保可用性DeVSeCoPS回接SAST服务网格配置审计DAST服务端点的AUthN和AUthZ测试IAS
33、T一一剔除假阳性结果评估方法路由功能的可观察性、遥测和日志记录。日志记录可提供实时可见性和可观察性。控制措施叠加的特性预防性DCVSeCoPS控制、DDOS预防检测性和纠正性一一扩容/收缩以确保可用性复合状态（独有/通用通用5.1.3聚合模式聚合模式接收并向多个微服务发出请求，然后把对后端服务发出的多个请求合并成一个请求，用以响应初始请求。当许多设备向一个中心点发送交易消息和活动日志时，往往会在云边缘发生软件定义的聚合。其他模式可能会在网关聚合背后发挥作用，如Facade模式、代理模式和断路器模式，具体由应用目标和通信特点决定。这些设计模式有类似的结构，但是使用它们的意图或目的各不相同。版本L
34、O模式目的聚合（网关）模式的目的是减少应用程序对后端服务提出请求的数量，并提高应用程序在高时延网络上的性能。层面位置企业（平台）层面结构描述聚合（网关）模式用于将多个单独的请求聚合成一个请求或响应。行为描述当一个客户端需要向各种后端系统发出多个调用来执行一项操作时，聚合（网关）模式会很有用。数据特性当聚合器合并来自多个终端的数据集时，使用中的数据可能需要得到安全保护。否则，聚合器可能只在请求者与响应者之间传输数据。主要依赖性网络（网络可能会带来严重时延）次要依赖性可用性和接近性（将与这一模式通信的各种系统的可用性）内部事件/消息传递需要聚合器模式可安全验证请求者的身份并传递一个访问令牌。服务可
35、验证请求者是否得到授权可以执行所涉操作。外部事件/消息传递链接网络安全控制措施（网络访问控制AuthNsAuthZs通过加密保护静止数据等）事件响应行为确保聚合网关具有可满足应用程序可用性要求的弹性设计。聚合网关可能是一个单点故障（SPOF）点，因此应该具备处理负载平衡的良好能力。聚合网关应该配备有适当的控制，可确保来自后端系统的任何响应延迟都不会造成性能问题。共同的上游链接配置管理；APl安全；策略管理和执行共同的下游链接维护、运行时间/停机时间、集成、测试、漏洞扫描和打补丁OPS安全回接Tie-backAPl性能监控；系统日志监控；健康监控；异常检测、事件管理、反恶意软件/病毒、漏洞抑制、
36、补丁DeVSeCOPS回接安全SDLC；敏捷、更简单/更灵活的开发和测试周期、持续集成/持续交付（CI/CD）管道评估方法日志记录/监控；警报、基于授权失败条件的计量警报、SIEM事故和事件管理控制措施叠加的特性网关可改善并直接影响应用程序的性能和规模。预防性：漏洞抑制、打补丁纠正性：事件响应检测性：性能监控、健康监控复合状态（独有/通用通用5.1.4缓存模式应用设计中的缓存通常是用来满足提高可用性、改善应用性能和/或减少后端数据读写的要求的。缓存可以是嵌入式的，也可以是分布式的。主要缓存模式有许多衍生。如果一项业务操作对于后续使用具有持续的价值，可以考虑把结果缓存起来。例子包括按交易定价的数
37、据元素,如可计量的外部接口等。第二个例子是消费者与现代分布式微服务应用中的许多外部API交互时的会话授权。把数据缓存在同一地点的同一层中可以简化调试，从而避免出现多个缓存实例彼此不同步的情况。版本LO模式目的提高性能、可扩展性和可用性层面位置软件层面结构描述把被频繁访问的数据临时复制到离应用更近的快速存储中。行为描述通过快速数据交付模式提高性能，以防I/O数据连接出现严重问题；利用缓存的凭证提高可用性，以防应用会话中断。缓存可以避免出现因快速检索数据而产生的时延情况，从而消除了频繁扩展的需要。数据特性使用中的数据（内存）主要依赖性最终一致性、缓存大小、基于缓存点击率或近来被用最少策略的回收策略
38、、冷启动、缓存集合体（CaChingfleet）停运、通信流模式的变化、扩散的下游停运、网络时延、请求合并次要依赖性通信协议的类型、缓存服务管理内部事件/消息传递需要内部API、SOAP、RPC、ICP、HTTP/S外部事件/消息传递链接APPDeV调试（基于合规要求的更严格调试）事件响应行为发送/接收/排队/消息传递、事件驱动、异步/同步共同的上游链接全局和/或局部通信流负载平衡共同的下游链接内部API；与记录的数据源或参考的数据源紧密耦合的端口和协议OPS安全回接APl监控；异常检测；安全监控流程DeVSeCoPS回接用于缓存大小/内存超限问题的SAST、DAST,缓存客户端库的漏洞打补丁
39、评估方法APl加固指南（如果使用了容器，则策略即代码形式的加固指南）、网络时延和性能、负载测试、测试缓存失效和欺骗的方法控制措施叠加的特性API跟踪/调试、密码叠加（传输、处理和使用中的数据）、加速新缓存实例（更短的TTL、动态扩展内存配置）以避免缓存丢失、缓存失效和负载平衡复合状态（独有/通用通用；其他模式也会使用这个叠加5.1. 5代理代理模式是一种靠硬件启用或靠软件定义的结构体，在机器之间充当可读数据流中介。代理的能力可体现在不同的设计取向上。代理代表另一个人“发声”或“行事”，要么隐藏请求者，要么承担请求者授予的责任。在机器对机器的数据传输中，代理可以是透明的，代理功能在请求者和内容提
40、供者之间起中介作用，或者在发起的API端点和响应的API端点之间起中介作用。透明代理功能拦截数据并执行缓存、卸载或重定向等操作，但是不改动数据流（修改数据流是适配器模式的责任）。反向代理功能代表提供者做出响应，从而隐蔽提供者的身份。此外还有其他几种类型的代理。分布式微服务应用程序通常使用透明和反向代理。代理模式版本1.0模式目的在服务消费者和服务提供者之间建立中介联系层面位置软件层面结构描述代理接收来自各种服务消费者的输入，充当APl或容器的安全检查点。然后根据安全策略处理来自服务消费者的输入，决定是接受、拒绝还是终止指向服务提供者的连接。行为描述代理模式可以扩展或变成专用，以纳入网络或访问控
41、制代理（即专注于网络第三或第四层的源、目标、端口和协议属性的代理）、身份代理（即执行身份验证和授权的代理），等等。代理也可以与其他模式协作（例如给入站请求添加元数据，以帮助促进适当路由）。收到的数据流输入会依照安全策略接受评估。假若没有违反策略，服务消费者提出的请求将被传递给服务提供者。数据特性代理应该把通信从服务消费者传递给服务提供者。它不应存储数据，评估暂时排队的请求的可能情况除外。如果需要，代理可以（但不是必须）用元数据充实数据流。主要依赖性代理要求网络连接、运行环境和应用程序端点能够正常运行并做出响应。次要依赖性代理应该持续执行安全策略，即便与策略定义组件断开连接也是如此。请注意，当无
42、法获得最新版安全策略时，所执行的策略可能会是一个过时或针对特定时间点的版本。内部事件/消息传递需要名义上运转正常的代理可以独立运行，但可能会从与以下模式的交互中受益：AuthN检查身份验证凭证是否仍然有效并且没有被撤销。卸载一一提取被解密的TLS流，检查策略合规。路由/路由选择一一确保服务消费者的元数据（如原始源IP地址）会被传达给路由/路由选择模式。外部事件/消息传递代理应该能够向安全分析解决方案（例如SIEM）提供事件的细节链接和决定，以便进行企业安全事件关联和事故调查。理想状态是，代理能够获取威胁情报或有关可疑或受损用户、设备和端点的高可信度清单，从而使安全策略合规决定做到有理有据。事件
43、响应行为代理的响应有以下三个选项：接受：允许从服务消费者到服务提供者的数据流或连接，并作为可选项对消费者做出回应。终止：阻止连接，不回应消费者。拒绝：阻止连接，同时必须回应消费者。共同的上游链接AuthNs卸载共同的下游链接路由/路由选择OPS安全回接基础设施即代码（IaC）、配置管理、安全信息事件管理（SIEM）.负载平衡器、防火墙DeVSeCoPS回接用于一致和可重复执行的持续集成/持续交付（CI/CD）管道、用于安全执行的静态应用安全测试（SAST）,用于策略执行的动态应用安全测试（DAST）评估方法分析被允许和被拒绝的通信，与企业数据关联，确认代理是按要求决定允许/拦截通信的，并主动尝
44、试破坏代理（例如通过红茶测试/渗透测试）。控制措施叠加的特性预防性/纠正性一一访问控制检测性一一给企业关联增加视角。可能有助于事件调查监管性一一可能必须满足审计员或企业客户的要求复合状态（独有/通用通用。具有独有的控制措施叠加。代理控制措施叠加可能是通用的，与其他模式类似。5.1.6 AuthN（身份验证）模式AUthN（身份验证）模式可确保访问微服务的服务和用户身份与其声称的一致。例如，OpenIDConnect扩展了OAUth2.0的身份验证规程。OAUth2.0是一个纳入了身份验证规程的授权框架。身份验证服务器把身份令牌提供给依赖方，内含有关身份验证和身份信息的声明（通常在通过门户登录之
45、后）。身份验证模式版本1.0模式目的建立信任并验证被声称的实体身份的过程层面位置软件层面和企业（平台）层面结构描述客户端一一无论是用户还是其他微服务一一在使用服务之前都需要识别身份行为描述在授权模式决定允许访问资源之前对用户或服务进行身份验证。身份验证由两个相关概念组成，“识别”用户或服务身份，以及“验证”用户或服务确实是他们（它们）自称的人或物。数据特性身份验证模式可以生成有关用户或服务是否已被核实身份的布尔回应。其他回应可能还包括一个令牌或断言，表明实体就是他们自称的身份。身份令牌或断言可供APl端点、API网关、MESH和ISTlO使用。主要依赖性身份验证依靠存储凭证的可信身份存储库（如
46、ACtiVeDirectoryLDAP等），也可能依靠公钥基础设施（PKl）给身份断言或令牌签名以及对这些令牌或断言验证。次要依赖性根据所用身份验证协议，可能要有一个客户端（依赖方）、用户（资源拥有者）和授权服务器签发访问令牌（IDP）。内部事件/消息传递OAUTH的令牌和客户端事件消息、触发警报（调查和控制）的OAUTH需要策略、来自ISTlO组件的日志、AUthN和AUthZ消息交换外部事件/消息传递APPDeV调试、SIEM链接事件响应行为在执行策略过程中做出“允许”或“拒绝”响应。准备用日志记录身份验证事件，供企业事件关联之用。如果某一特定用户的过多身份验证事件超过某个阈值（例如60秒
47、内超过三次身份验证失败），则可能必须生成警报。共同的上游链接防火墙；全局和/或本地通信流负载平衡；网络间AeL共同的下游链接发证机构；配置管理；APl注册中心；集群管理APl安全背景；机器ID/服务ID凭证托管、代理、授权（AUthZ）OPS安全回接APl性能监控；系统日志监控；机器健康监控；异常检测DeVSeCOPS回接安全SDLC；APl注册中心;Swagger/YAMLAPl定义;AUthN和AUthX控制评估方法APl性能趋势分析；用于异常检测和事故响应的SlEM日志分析和关联控制措施叠加的特性预防性一一访问控制复合状态（独有/通用通用；其他模式也使用这一叠加。5.1.7 AuthZ（授权）模式AuthZ（授权）确定经过身份验证的用户可以做什么或授予他们什么权限。把这些权限从授权服务器传递到资源服务器的标准方法之一，是将范围编码到
