2017年下半年试题三：论无服务器架构及其应用
论文库链接：系统架构设计师论文
论文题目
近年来，随着信息技术的迅猛发展和应用需求的快速更迭，传统的多层企业应用系统架构面临越来越多的挑战，已经难以适应这种变化。在这一背景下，无服务器架构逐渐流行，它强调业务逻辑由事件触发，具有短暂的生命周期，运行于无状态的轻量级容器中，并且由第三方代为管理。采用无服务器架构，业务逻辑以功能即服务的方式形成多个相互独立的功能组件，以标准接口的形式向外提供服务；同时，不同功能组件间的逻辑组织代码将存储在通用的基础设施管理平台中，业务代码仅在调用时才激活运行，当响应结束后占用的资源便会释放。
1.概要叙述你参与分析和设计的软件系统开发项目以及你所担任的主要工作。
2.与传统的企业应用系统相比较，基于无服务器架构的应用系统具有哪些特点，请列举至少3个特点，并进行解释。
3.结合你具体参与分析和设计的软件开发项目，描述该软件的架构，说明该架构是如何采用无服务器架构模式的，并说明在采用无服务器架构后软件开发过程中遇到的实际问题和解决方案。
写作要点
需要较为详细地说明目前各种常见的信息系统建模方法的核心思想，并对每种方法所创建的模型进行简要描述
(1)结构化建模方法。
结构化建模方法是以过程为中心的技术,可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图(DFD)。对于流程较为稳定的系统可考虑结构化建方法。(2)信息工程建模方法(或数据库建模方法)。
信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图(ERD)。主要用于数据建模。
(3)面向对象建模方法。
面向对象建模方法将“数据"和“过程"集成到被称为“对象”的结构中,消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML(统一建模语言)。UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统。是目前比较常用的建模方法。
(4)功能分解法
功能分解法以系统需要提供的功能为中心来组织系统。首先定义各种大的功能，然后把功能分解为子功能，同时定义功能间的接口。比较大的子功能还可以被进一步分解，直到我们可以对它进行明确的定义。总的思想就是将系统根据功能分而治之，然后根据功能的需求设计数据结构。
论文参考
论无服务器架构及其应用
摘要
2024年1月，我作为系统架构设计师参与了单位OA系统的设计与研发。该系统主要功能有公文流转、打卡签到、物品申购等。经技术小组研究讨论后，最终确定采用无服务器架构进行开发。本文以该项目为例，主要论述如何采用无服务器架构模式开发OA系统，通过将公文审批、用户认证、消息通知等模块拆分为独立的函数服务，依托云平台实现自动伸缩与按需执行，显著提升了资源利用率与系统稳定性。我主导了整体架构设计与核心接口定义，协调各开发小组完成服务间通信机制的搭建，并制定了异常处理与日志监控方案，确保系统在高并发场景下的可靠性。经过团队坚持不懈地努力，终于在2024年12月成功上线至今，领导和同事一致对该系统给予好评。
正文
2024年1月，我作为系统架构设计师参与了单位OA系统的设计与研发。该系统主要功能有公文流转、打卡签到、物品申购等。随着单位规模扩大，传统OA系统面临资源浪费严重的问题，但需预留服务器应对早高峰打卡，计算资源利用率不足15%。运维成本高，故障恢复耗时超30分钟。经技术小组研究讨论后，最终确定采用无服务器架构进行开发。我负责整体架构选型与设计，特别是主导了从初期考虑的虚拟机部署方案向无服务器优先架构的战略转型。因合规要求选择华为云混合云方案--敏感公文审批函数运行于本地机房集群。非敏感模块使用公有云。通过统一事件总线连通两地函数，实现安全与效率平衡。解决了技术难题后，经过编程工作人员的不懈努力，最终于2024年12月成功上线并获得了同事和用户的一致好评。
与传统的企业应用系统相比较，基于无服务器架构的应用系统具有如下特点。第三方平台管理：该架构业务逻辑由事件触发，具有短暂的生命周期，运行于无状态的轻量级容器中，由第三方代为管理，事件触发执行结束后即释放占用资源。高内聚低耦合：业务逻辑以功能即服务的方式形成多个相互独立的功能组件，以标准接口的形式向外提供服务，将组件独立部署便于其修改与完善。生命周期短暂：不同功能组件间的逻辑组织代码将存储在通用的基础设施管理平台中，业务代码仅在调用时才激活运行，当响应结束后占用的资源便会释放。快速适应市场需求：传统的多层企业应用系统架构很难适应信息技术的迅猛发展和应用需求的快速更迭，而基于无服务器架构的应用系统通过将服务器交由第三方代为管理，能够迅速响应。
作为系统架构设计师在参与OA系统的分析和设计过程中，下文将从基于通用基础设施管理平台、独立功能组件、无状态轻量级容器三个方面详细论述该架构是如何采用无服务器架构模式的。
基于通用基础设施管理平台的无服务器架构模式。编程人员先将OA系统各功能模块的代码写好，再由设计人员将OA系统的不同功能组件间的逻辑组织代码存储在通用的基础设施管理平台中，当用户需要使用该功能时再调用其业务代码并激活运行，响应结束后即可释放占用的资源。极大地减轻了公司服务器的负担，同时可以将通用基础设施管理平台的服务器进行扩容，避免在用户使用过程中由于平台资源有限出现卡顿的现象。对于系统开发人员而言，做好将各功能模块与通用基础设施管理平台接口的衔接即可，降低了开发难度。对于系统维护人员而言，除了必要的前端修改完善，降低了后端管理的难度，只需将通用基础设施管理平台管理好即可实现系统的正常运行，有效解决了传统多层企业应用系统架构面临的问题。
基于独立功能组件的无服务器架构模式。将公文流转、打卡签到、物品申购等功能模块采用无服务器架构，业务逻辑以功能即服务的方式形成多个相互独立的功能组件，以标准接口的形式向外提供服务。在开发前期，需要对功能组件的标准接口形式进行规范，避免在开发后期发生接口混乱接入的情况。在开发过程中，要将各个功能组件高内聚低耦合，提高各模块的内聚程度，降低耦合程度。在后期维护A模块时可以有效地避免引起B模块的变化，降低维护难度。同时，要在写代码的同时做好相应的注释工作，避免由于开发周期较长忘记之前代码含义的情况。根据各功能涉及的操作对象不同分别进行处理，比如打卡签到的对象是员工，而物品申购的对象是办公用品。将对象封装成不同的类，便于后期维护。
基于无状态轻量级容器的无服务器架构模式。对于服务器的选型，技术团队建议采用无状态的轻量级容器，因为OA系统本身承载业务量较少，如果采用重量级容器，反而会使系统不能充分利用资源而造成浪费；轻量级容器本身具有轻便、快捷的特性，对于系统性能的提升有很大帮助。当通用基础设施管理平台突然需要响应多个不同的工作任务时，无状态模式比有状态模式可以更加高效地将任务按照先来先服务的顺序进行排序，有效地避免了拥堵，从而有条不紊地按计划执行，防止系统发生死锁。轻量级容器也可以在一定程度上降低硬件成本，从而使资源得到更有效地分配。在后期维护过程中如果发生容器故障问题，在排除了软件问题后，也可以通过便捷地更换轻量级容器从而使系统正常运行，提高了系统的可用性。
OA系统通过采用无服务器架构模式，解决了传统的多层企业应用系统架构面临的挑战，积极适应了信息技术的迅猛发展和应用需求的快速更迭。虽然该系统整体上得到了领导和同事的认可，但在系统的分析与设计过程中也遇到了一些问题。比如在第三方管理方面，由于之前惯用传统架构，缺乏与第三方合作的经验，第一次接触相对比较陌生，在经过与第三方管理技术人员的多次沟通交流协商后逐步适应了工作方式。在各功能模块对外接口的确定方面，由于需要接入第三方管理平台，平时没有积累相关经验做法，比较生疏，之后通过在网上找寻相关接口胶水代码才将问题进行解决。最后于2024年12月成功上线该项目，通过这次项目的历练，使我们团队的整体分析与设计水平得到了提高，非常感谢领导给我们团队建设项目的机会，希望能够继续为单位的系统建设添砖加瓦，感谢领导的栽培与认可。