摘要
2021年，我公司研发了《企业资源计划管理系统》，用于企业的日常活动的计划与管理，主要功能模块有成员管理模块，权限模块，计划管理模块，物料管理模块，外部集成模块等。笔者在该项目中担任系统架构师一职，主要负责架构设计的工作。
以本项目为例，讨论了软件架构建模技术与应用的具体应用，重点从4+1视图模型的场景视图、逻辑视图、物理视图进行介绍。场景视图是系统的重要活动的抽象，以用例图对系统主要角色与用例进行分析，逻辑视图描述了系统中的功能需求，以包图对系统的不同层次进行建模。物理视图描述了部署图将软件映射到硬件，系统安装，通信，解决系统的拓补结构等。最终系统按计划如期交付并通过验收，获得了使用用户的一致好评。
正文
2021年，笔者所在公司的原企业资源计划管理系统由于企业自身的业务转变，人员的变动，维护文档的缺失，由于其系统对于目前的企业来说业务价值较低，技术水平较低，于是决定采用淘汰策略，借鉴遗留系统的功能与设计，重新开发企业资源计划管理系统。
该系统以管理企业的日常活动为中心，主要模块有：成员模块，物料管理模块，外部继承模块，计划管理模块等，并开放了外部接口允许其他与系统相关的应用与其集成，对企业的内外信息流进行管理，提升运行效率，降低流程成本。并提供了数据集成与转化工具，以及二次开放工具，帮助其他开发者以及外部系统可以基于原有的系统结构只需要拓展出结构即可与企业资源计划管理系统进行数据通信，并通过数据集成工具根据规则系统实现在数据通信的过程中自动进行数据转换。实现用户可以从单一入口完成跨应用协作的任务，帮助或完成用户任务。
4+1模型从五个视角来描述架构，分别为逻辑视图、进程视图、开发视图、部署视图、场景视图，逻辑视图描述了系统的功能需求，将系统分解为一系列的功能抽象，并用对象模型来代表逻辑视图，使用类图来描述逻辑视图。开发视图描述了模块之间的组织与管理，侧重于系统内部的系统。进程视图侧重于系统的运行特性，关注非功能需求，如容错，可用，设计约束，性能等，以及逻辑视图的功能抽象如何适应进程结构。定义了具体线程的执行，物理视图考虑的是将软件向硬件的映射，解决系统的拖补结构，系统安桩，通信等问题，场景是系统重要活动的抽象，将四个视图有机的联系起来。
系统最终采用微服务的形式开发，UML模型建模，这里着重从场景视图，逻辑视图，物理视图进行介绍
场景视图
场景视图使用用例图来进行建模，我们经过分析和调查，企业资源计划管理系统的参与者可以划分为员工，运维人员，系统管理员，审批人员及外部设备或系统，员工具有基本的物料上报与审批、计划的提交等，运维人员具有外部集成系统权限控制，外部系统集成，数据维护等用例，审批人员具有物料的审批，人员审批，权限管理等用例。外部设备或系统具有成员管理，物料的上报与审批，数据的通信规则设置，计划的管理等权限。系统管理员则具备其他所有参与者所具有的用例，同时具有生成报表，统计物料，统计审批计划等用例。
逻辑视图
逻辑视图采用包图进行建模，根据开发团队的调查和分析，最终决定采用微服务的服务架构，将系统的功能拆分为小且独立的服务，每个服务由2-3个人的小型团队进行开发，根据服务的需求与特性选取适合的语言以及相关工具，由于微服务的去中心化，，每个独立部署的微服务既可以使用中央存储结构也可以使用独立存储结构。当用户访问系统时，首先通过微服务网管将HTTP协议的用户请求转化为微服务的Protobuf协议的请求，再通过负载均衡算法选择对应的微服务，当微服务响应数据后，再将数据转化为HTTP协议对用户进行响应，同时微服务网关也可以对服务的健康度进行监控，提供用户授权认证，服务熔断，服务降级等功能。微服务之间通过同步，异步，工作流等方式进行相互通信，为了防止异步调用出错，涉及到金融相关的业务的通信决定使用成熟的消息通信队列进行实现，一旦调用失败则留存到队列中直至成功响应，同时会持久化消息数据，以防止出现异常崩溃等情况造成的数据丢失，保证了关键业务的高可靠性。
物理视图
物理视图采用部署图进行建模，在开发完成后，每个微服务都可以进行独立部署，将微服务打包并封装到Docker容器中，微服务与其他的相关系统容器通信通过Docker容器中的Bridge进行虚拟组网互相通信，而与其他容器进行通信通过服务器网络系统内的服务发现中心进行查找，同时为了解决微服务的相互查找问题，建立了服务发现中心，在微服务启动时，在服务发现中心中进行注册，服务关闭时则进行相应的注销，通信只需在服务发现中心获取目标服务在分布式网络的地址即可进行相互通信，服务发现中心可以对微服务进行心跳监测，资源检测等，保障了系统的可用性，以及性能，结合集群技术的管理可以动态的实现伸缩，拓展，以及敏捷性，解决了系统的单点故障、性能瓶颈、服务雪崩等问题。
总结
该系统目前已经上线一年，并在企业当中通过获取一致好评，在使用的过程中也出现了一些问题，例如微服务的实现过程中存在跨微服务的数据一致性问题及分布式锁问题，我们采用了两阶段提交保证了系统的数据一致性，跨应用的分布式锁问题则采用Redis锁方案解决，通过使用4+1视图对架构进行建模，对系统进行详细分析，为后续开发提供了强有力的支持。
根据个人实践说明，系统能够如期上线并且正常运行，与选择软件架构建模技术与应用密切相关，在架构设计的过程也发现了我个人的不足，在今后的日子里，会继续认真学习相关的知识及积累经验，完善本架构，使日后的架构设计过程中更加完善。
置顶卡
沉默卡
照妖镜
