2023微服务架构模式.docx

《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安全控制措施的目标是把潜在风险降低到可接受、无害或无关紧要的水