2020年下半年试题三：论云原生架构及其应用
论文库链接：系统架构设计师论文
论文题目
近年来，随着数字化转型不断深入，科技创新与业务发展不断融合，各行各业正在从大工业时代的固化范式进化成面向创新型组织与灵活型业务的崭新模式。在这一背景下，以容器盒微服务架构为代表的云原生技术作为云计算服务的新模式，已经逐渐成为企业持续发展的主流选择。云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。云原生架构有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用，其代表技术包括容器、服务网络、微服务、不可变基础设施和声明API等。
请围绕“论云原生架构及其应用”论题，依次从以下三个方面进行论述.
1.概要叙述你参与管理和开发的软件项目以及承担的主要工作。
2.服务化、弹性、可观测性和自动化是云原生架构的四类设计原则，请简要对这四类设计原则的内涵进行阐述。
3.具体阐述你参与管理和开发的项目是如何采用云原生架构的，并且围绕上述四类设计原则，详细论述在项目设计与实现过程中遇到了哪些实际问题，是如何解决的。
写作要点
一、简要叙述所参与管理和开发的软件项目，并明确指出在其中承担的主要任务和开展
的主要工作。二、云原生架构的四类设计原则
1、服务化原则:
当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了,包括拆分为微服务架构、小服务(MiniService)架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务选代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程,服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等,本质上都是基于服务流量(而非网络流量)的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系,标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。
2、弹性原则:
大部分系统部署上线需要根据业务量的估算,准备一定规模的机器,从提出采购申请、到供应商治谈、机器部署上电、软件部署、性能压测，往往需要好几个月甚至一年的周期,而这期间如果业务发生变化了,重新调整也非常困难。弹性原则是指系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额外软硬件资源的成本支出(闲置成本)，降低了企业的 IT 成本,更关键的是当业务规模面临海量突发性扩张的时候,不再因为平时软硬件资源储备不足而“说不”， 保障了企业收益。
3、可观测原则:
今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的 SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、APM 等系统提供的能力不同，前者是在云计算这样的分布式系统中,主动通过日志、链路跟踪和度量等手段，让一次 APP 点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等,这样的能力可以使运维、开发和业务人员实时掌握软件运行情况,并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。4、自动化原则:
技术往往是把“双刃剑”,容器、微服务、DevOps、大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，因为整体增大了软件技术栈的复杂度和组件规模，所以不可避免地带来了软件交付的复杂性，如果这里控制不当，应用就无法体会到云原生技术的优势。通过laC(Infrastructure asCode)、GitOps、OAM(OpenApplication Model)、Kubemnetes operator和大量自动化交付工具在 CICD 流水线中的实践,一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。三、第三个问题要根据项目的实际情况来写自己是怎么做的，遇到什么样的问题，如何解决的。
论文参考
论云原生架构及其应用
摘要
为了响应国家政府新型无纸化办公的强烈要求，2023年6月我参与了单位OA系统的云原生架构开发与设计，包含的功能有公文签批流转、电子公文传输、工资查询等。我主要担任系统架构设计师，负责系统的需求分析、技术选型、质量属性效用树、概念架构、细化架构等具体业务。经过小组讨论后我们决定采用云原生架构技术，围绕服务化、弹性、可观察性和自动化等设计原则，利用容器、服务网络、微服务等技术将OA系统中的非业务代码部分进行最大化剥离，让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度）等。提高了系统的轻量度、敏捷度以及自动化程度等。经过大家半年的不懈努力，我们终于在2023年底顺利上线该产品，最终得到了领导和用户的一致好评。
正文
为了响应国家政府新型无纸化办公的强烈要求，2023年6月我参与了单位OA系统的云原生架构开发与设计，包含的功能有公文签批流转、电子公文传输、工资查询、物品申购、公车派送等。我主要担任系统架构设计师，负责系统的需求分析、技术选型、质量属性效用树、概念架构、细化架构等具体业务。经过小组讨论后我们决定采用云原生架构技术，围绕服务化、弹性、可观察性和自动化等设计原则，利用容器、服务网络、微服务等技术将OA系统中的非业务代码部分进行最大化剥离，让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度）等。提高了系统的轻量度、敏捷度以及自动化程度等。经过大家半年的不懈努力，我们终于在2023年底顺利上线该产品，最终得到了领导和用户的一致好评。
服务化、弹性、可观测性和自动化是云原生架构的四类设计原则。其中服务化指系统的设计要围绕服务展开，不可偏离这一主旨。比如在用户、管理员使用和开发人员对系统进行修改的时候，是否可以便捷高效地解决问题，让用户切身地感受到系统给大家带来的方便。弹性指在系统用户激增或因用户操作不当时是否仍能保持正常运行，而不至于因此宕机，造成数据丢失的情况，提高系统的鲁棒性。可观测性指系统的软硬件设备状态数据均可实时获取，比如正在使用系统的用户数量，CPU、服务器的负载率等数据，方便及时发现问题并予以解决。自动化指系统可以在无人操作的情况下24小时正常运转，出现一些小问题时也可以利用恢复操作将系统复原，继续正常运转，保证业务的持续可用性。
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，可以将云应用中的非业务代码部分进行最大化剥离，使业务不再有非功能性业务中断困扰，具备轻量、敏捷、高度自动化的特点。下文将围绕服务化、弹性、可观测性和自动化四类设计原则具体阐述OA系统是如何采用云原生架构进行开发的。
（一）围绕服务化设计原则进行云原生架构的开发。利用微服务架构将OA系统拆分为多个小的、自治的服务。每个服务都独立运行、独立部署和独立扩展，降低了系统的耦合度，提高了系统的灵活性和可维护性。为了提高用户和开发人员的工作效率，我们在概念架构设计阶段就采用需求矩阵从功能、质量、约束的角度对其进行全方面的分析，考虑用户使用环境、开发工作环境和上线时用户可能遇到的问题。比如：采用Spring Cloud微服务框架实现功能解耦，将公文流转、电子签批等核心业务封装为独立服务，通过API网关统一暴露接口；单位领导之前一直使用windows系统操作界面，那么我们在设计时就要考虑到这一约束，咨询领导是否可以换成其他界面，还是继续使用；由于单位资金有限，技术公司派出的开发人员技术参差不齐，前期的开发和后期的维护均需要他们牵头，所以后台管理界面也要尽可能方便操作，提高系统的可扩展性。利用鲁棒图找到系统对应的边界对象、控制对象、实体对象，有效地降低系统的复杂性，方便进一步开发。
（二）围绕弹性设计原则进行云原生架构的开发。利用弹性原则确保OA系统能够自动适应负载变化，根据负载情况动态地调整服务实例的数量和资源配置，实现了系统的高性能和可用性，利用自动扩展和负载均衡技术进一步优化系统的弹性。通过Hystrix实现服务熔断，当依赖服务响应超时自动降级返回缓存数据。为了提高其弹性程度，我们全面地梳理了涉及到系统应用的软硬件设备，排查单点故障，对某些关键基础设施还仍在串联的设备及时进行备份处理，一旦发生紧急情况就可以无缝切换热备/冷备，避免发生数据丢失的情况。我们将所有硬件设备均接入到堡垒机上，在堡垒机上即可对设备配置参数进行修改，减少进出机房的频率，避免造成不必要的麻烦。为了避免系统数据被一些不熟悉操作的开发人员误删，我们将root权限账号集中移交至管理人员；开发人员要对系统进行操作时需向管理人员申请使用账号，有效地降低了系统在开发过程中发生故障的可能性。
（三）围绕可观测性和自动化设计原则进行云原生架构的开发。自动化与可观测性通常紧密耦合，可观测性为自动化提供决策依据，自动化是可观测性的落地手段。在可观测性方面，在开发前期将涉及到系统的软硬件设备均接入到可观测系统中，方便实时地了解OA系统地开发情况，发现某些设计不合理的地方可以及时地进行调整，避免造成大面积地返工。我们实现了全面的监控和日志收集机制。通过分布式追踪和指标收集，我们可以实时地了解系统的运行状态、性能和潜在问题。同时，我们还利用日志分析技术来挖掘系统的运行规律和潜在优化点。在自动化方面，我们实现了持续集成/持续部署（CI/CD）流程，使得代码可以自动构建、测试和部署到生产环境。通过自动化测试和自动化监控技术，我们可以确保每次代码更改都经过充分的测试，并及时发现和解决潜在问题。同时，我们还利用自动化故障恢复技术来减少系统的停机时间和手动干预的需求。利用动态环境监测系统对机房的温度、湿度以及电路可承受的负载率进行实时监控，一旦发生紧急情况及时通过电话和短信的方式提醒工作人员。
经过大家半年的不懈努力，我们终于在2023年底顺利上线该产品，让云设施接管应用中原有的大量非功能特性（如弹性、韧性等），使业务不再有非功能性业务中断困扰，具备轻量、敏捷、高度自动化的特点，最终得到了领导和用户的一致好评。但是在运行过程中也暴露出了一些问题，比如：一些用户在OA系统经常使用的电子邮件传输功能因用户使用频率激增导致原有的存储已经不能满足用户的需要，所以要对系统的数据存储服务器进行扩容，避免因存储容量不足，造成系统崩溃。通过采用云原生架构对OA系统进行开发，使我们团队的系统架构设计能力也得到了充分地锻炼，非常感谢领导地栽培与信任，希望能够继续承接系统架构相关任务，继续为单位的信息化建设添砖加瓦。