软件架构风格

胸毛在燃烧

摘要：
本人于2020年9月参与了某省通信管理单位“传输网系运维可视化及工单管理系统”的项目建设，该系统建设目标是实现对辖区内光缆线路及承载传输系统的实时监控，呈现传输系统或光缆线路故障位置，并就近向维修分队自动下发作业工单，提升通信运维管理质量。在该项目组中我有幸担任该系统的架构师，主要负责系统整体架构设计。本文以该项目为例，主要讨论了软件架构风格在该项目中的具体应用。整个系统采用具有分层架构设计，分别是应用层、服务层、数据层。在应用层中的业务逻辑层的设计中，将整个业务系统划分为多个子系统。服务层使用Dubbo服务框架为核心，数据层采用Mybatis框架。整个系统开发工作历时11个月。目前，该系统已经稳定运行近一年半的时间。实践证明，这种架构设计有效地降低了维护成本，提高了系统的开放性、可拓展性、可复用性和可移植性。
正文：
“传输网系运维可视化及工单管理系统”项目是某省通信管理部门“通信网系综合网管平台”的一个子系统。“综合网管平台”是该省网信体系建设“十三五”规划中的示范应用项目，该项目聚焦运用自动化、智能化手段，有效整合光纤通信传送网、计算机网等多种网管系统，支撑通信值勤运维力量整合、抢修力量高效运用、节约运维成本，促进值勤质效提升。“传输网系运维可视化及工单管理系统”主要是整合光纤网的各类网管系统中的运行情况信息，实现对辖区内光缆线路及承载传输系统的一体化监控，保证故障处置工单的准确迅速下达，从而更加有效地调动人员力量。根据用户需求，该系统共包括运行态势呈现、巡检管理、工单管理、基础数据维护等4大功能模块。项目组成员共15人，我作为公司技术骨干之一，主持并参与了该系统的需求分析、设计、编码、设计、测试等阶段的工作。该项目架构工作于当年12月完成，整个项目耗时11个月。
由于通信管理系统对安全性、可靠性、可用性和扩展性要求很高。在架构工作的开始阶段，我们便意识到，架构风格定义了用于描述系统的术语表和一组指导构建系统的规则，是系统组织方式的惯用模式，可以为我们的项目提供架构级的通用解决方案。这种架构级的软件重用可以极大提高我们的系统建设进程。软件系统开发中常用的软件架构风格有数据流风格，调用/返回风格，独立构件风格，虚拟机风格，仓库风格。数据流风格包括批处理序列与管道-过滤器，其每一步处理都是独立，顺序执行的，适用于简单的线性流程。调用/返回风格包括主程序/子程序风格，面向对象风格，层次结构风格，其进一步降低系统耦合度，明确系统层次。独立构件风格包括进程通信，事件驱动系统（隐式调用），其构件特点为软件重用提供了支持。虚拟机风格包括解释器风格，基于规则的系统风格，其具有良好灵活性，可自定义规则。仓库风格包括数据库系统风格，超文本系统风格，黑板系统风格，其以数据为中心。除此之外，还有dssa，soa 等架构风格。
在与各级用户对接需求后，我们决定在公司技术顾问的建议下，采用层次架构风格。将系统分为应用层，服务层，数据层。应用层负责具体业务和视图展示，如运维态势和巡检情况展现等，其又分为视图层与业务逻辑层。服务层负责为应用层提供通用服务支持，并实现服务的分布式部署。数据层负责提供数据存储访问服务，如数据库服务，缓存服务，文件服务，搜索服务等。接下来，我将分层次详细介绍三层层次体系结构的设计过程。
首先是应用层。在应用层中，我们将系统根据应用进行水平划分，这有助于代码管理与维护。我们将系统分为运行情况监控、巡检任务管理、工单分派等十余个子系统。在视图层，针对用户提出的传输系统系统拓扑图能够自由定制的需求，我们综合考虑多种方案后选择了使用HTML5 Canvas技术来实现传输系统拓扑图的自由定制，并融合Vue前端框架实现用户页面。使用Canvas技术形成的拓扑图的非常轻巧，性能出色，能够支持上万图元，操作流畅，并且支持矢量图形，无极缩放等。Vue是一套用于构建用户界面的渐进式JavaScript框架，非常容易学习且方便与第三方库或既有项目整合。在业务逻辑层，我们采用SpringBoot实现相应业务功能开发，SpringBoot是一套javaweb开发框架，其核心思想是约定大于配置，能够简化开发。因为系统面向的用户职责各不相同，如线路巡护人员、工单处理人员、网络监控人员等，且区分市县级用户，不同用户拥有不同的权限，我们选用SpringSecurity框架实现用户认证和用户授权，并使用其中的oauth实现统一身份认证，该框架与SpringBoot能够无缝组合，SpringBoot能够自动装载Security中的组件，加快了开发速度。
服务层采用了Dubbo 服务框架等技术实现。随着服务器规模的扩大，开发人员的增多，每个应用都变得复杂，臃肿，存在大量代码重复。加之通信运维管理有一定的时效性，且该系统面向各市通信管理部门使用，需要更快的响应速度。为解决上述问题，实现系统的松耦合，便于后期应用拓展，我们使用了服务化方案，即应用层和数据层中增加一个服务层。首先从结构上来看，系统结构更为清晰明了，更为立体。稳定性上来看，许多散落的代码成为了通用服务，并交付专门的团队负责运维。出于对成本与技术成熟度的考虑，我们采用了阿里研发的Dubbo 服务框架，该框架是一个高性能的RPC分布式服务框架，使得应用可以通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成，实现了面向接口代理的RPC调用，服务注册和发现，负载均衡，容错，扩展性等功能。Zookeeper作为注册中心和Dubbo框架一并使用，把提供者和消费者通过Dubbo注册到Zookeeper中，存储服务的url列表，消费者需要服务时，会根据接口名称通过Dubbo到Zookeeper中查找相应服务的url列表，Zookeeper返回服务提供地址给消费者。消费者从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选一台调用。
最后是数据层。数据层涉及缓存，文件系统，数据库，数据通知服务，搜索系统等模块。由于用户对数据的访问具有集中性，所以我们基于Ehcache与Redis 实现了缓存机制。由于系统的业务特性，数据库往往是读操作远多于写操作，所以我们对数据库进行了读写分离。数据访问方面，我们使用了ORM 框架 Mybatis 框架，再将框架包装一层，用于实现数据层功能，对外暴露的仍然是Mybatis 的接口。该方法开发高效，敏捷，成本较低，而且兼容性不错。在读写分离方面，使用MySQL构建主从数据库，并使用了Mycat中间件保障了数据的高可靠性。此外，为整合多个网管系统的告警信息，并保证告警信息推送的及时性，我们使用Maxwell组件，实时监测下游各原有传输系统故障数据库的变化情况，发送至Kafka中，在服务层进行注册，相关的呈现应用对该消息进行消费，并将故障信息及时推送至Redis数据库服务器中，以满足页面呈现的需要。
由于软件三层架构设计得当，并采取了有效的措施去解决设计中遇到的问题，系统最后按计划完成并顺利投入运行，不但保证了系统的开放性、可用性和互用性，取得了良好的经济效益和管理效益，而且我的软件三层架构设计得到了管理单位领导和用户的一致认同与称赞，为系统的试运行打下了良好的基础。
在总结经验的同时，我也看到了我在软件三层架构设计中的不足之处：首先是分层结构的多层调用降低了系统的性能。其次是分层所带来的级联修改问题，上层逻辑的修改可能会导致下层逻辑随之修改。此外，我们采用的负载均衡算法是加权轮转算法，过于简单，常常出现资源分配不合理的现象，可以将算法改为加权最小连接数算法来解决。这些都是我在今后的系统设计和开发中需要注意与改进的地方，也是日后我应该努力的方向。