论软件架构风格的选择

本文是参加系统架构师前写的一篇合格的文章。

摘要：

2018年5月我参与了某省电信智慧BSS系统的运营管理平台（NOSP）项目的开发。该项目为解决BSS系统的日常运营中提前发现故障、快速定位问题、保障服务稳定运行等方面提供全方位的软件支撑,我在该项目中担任系统架构师，主要负责系统的总体架构设计和技术选型。本文以该项目为例，主要论述了软件架构风格在该项目中的具体应用，通过采用微服务架构有效降低了系统耦合度；通过模型-视图-控制器架构解决自定义图表和报表展现问题，有效提升了可扩展性；通过采用管道与过滤器架构有效解决了分布式服务调用链的性能问题。事实证明，采用这些架构风格后，系统在在可扩展性、性能等的方面都达到了预期目标。系统自2019年2月上线后运行平稳，得到了领导和用户的一致好评。

正文：

随着2016年中国电信提出构造新一代运营商领先的智慧BSS3.0，以满足未来5年以上的市场营销与服务要求。2017年某省电信采用集团规定的平台+应用的方式重构了BSS核心系统，由于重构后的BSS系统涉及到PaaS平台的众多中间件和18个能力中心；同时采用容器化、集群的方式部署在超过140台物理主机、2000个容器中。整个BSS系统在性能和可扩展性等方面得到了极大的提升，但也增大了系统的运维难度，急需配套的运营系统来从整体上全方位的掌握BSS运行情况。由于我们不仅承建了该省的BSS核心系统，同时我们还深度参与了集团PaaS平台的开发，因此2018年5月我公司被该省电信委托建设新一代智慧运营管理平台(NOSP)，以下简称该系统。该系统包含资源管理中心、组件管理中心、数据运营中心、监控告警中心、运营日志中心、运营分析中心等子系统。我以系统架构师的身份负责系统的总体架构设计和技术选型，7月份完成架构设计工作和基础开发框架的搭建，整个项目历时9个月，2019年2月顺利上线并通过验收。

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。而惯用模式可以为我们的项目提供通用解决方案，能够极大提高软件设计的重用的方法，加快我们的建设进程。传统的软架构风格可以分为数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。例如数据流风格中的管道过滤器风格，其中每个组件都有对应的输入和输出数据，输入数据经过组件的转换、计算、过滤等处理后，形成输出流;在输入数据完全处理完之前，就可以形成输出数据;此时组件就是过滤器，而连接件则为管道。独立构件风格中的事件驱动的架构以事件消息为载体，通过注册事件，然后事件被触发时，发送消息的方式不同系统或模块之间的调用。

我们在该系统设计过程中，为了解决不同开发小组负责的子系统的集成，自定义图表和报表展现以及分布式性能数据的流式处理过程，我们在项目中主要采用了微服务风格、MVC风格、管道与过滤器风格，具体阐述如下:

1. 微服务架构风格

由于该系统涉及到多个不同的开发小组，每个开发小组使用的技术栈有所不同，为了实现各子系统之间的服务集成，我们评估了传统的SOA架构风格和微服务架构风格，传统的SOA架构风格更多地在于已有异构系统的集成，其采用的ESB、SOAP和WebService等技术，太过于笨重，不符合集团技术规范和互联网化的要求，所以我们最终决定采用基于Spring Cloud框架的微服务架构风格，我们在开发框架中二次封装了SPring Cloud的Eureka注册中心、Zuul的网关、携程的Apollo配置中心、Spring Boot的Acututor监控以及Hystrix的服务限流等功能。在实际开发过程中，各开发小组只要聚焦于自己所负责的微服务模块的功能API的实现，通过在springboot的bootstrap文件中配置相同的注册中心和配置中心，就可以实现服务间的互联互通，极大地提升了开发效率；同时提供了配套的管理控制台，降低了生产环境下的运维难度。

2. MVC架构风格

我们采用MVC架构风格解决运营分析子系统中自定义图表和报表展现的难题。由于整个系统涉及到业主方的多个科室的运营人员，他们对日常运营数据的关注点和展现方式有较大的差异，需要支持自定义图表和报表。我们采用MVC架构风格能够解决这一难题，并充分考量了现有主流和成熟的技术框架，例如后端采用了SpringMVC框架，将后端代码组织成Controller、service和dao以及model4层，前端采用Vue框架负责展现图表和报表。dao和model层主要负责获取数据；service负责到dao转换和过滤数据；controller层作为控制器实现具体的业务逻辑，例如调用不同的service封装成前端需要的实体数据，最后以API的形式暴露给前端调用。基于MVC的架构风格，可以让开发人员清晰的明白系统的组织结构，解耦交互；同时在可扩展性上比较容易满足二次开发需求。

3. 管道过滤器架构风格

在监控告警子系统中，我们采用管道过滤器架构风格，解决分布式性能数据的处理。由于BSS采用基于分布式服务框架Dubbo实现了各业务中心的服务能力，当BSS系统出现故障后，需要快速定位到服务调用链中具体某个服务出现问题，为了实现分布式服务的性能统计和链路跟踪展现，监控告警子系统需要实现从各容器中采集分布式服务的性能数据，然后再汇聚数据，加工处理数据，数据入库以及展现数据。首先由pinpoint采集的服务调用日志数据，然后通过Fluntd采集并推送到kafka集群，由kafka集群做中间缓冲区，然后采用Flink流式框架，从kafka集群中获取数据并计算，最后将计算后的结果写入MySQL数据库，同时将原始的源数据写入ElastricSearch集群。从实际效果看，管道过滤器风格的应用，高效地解决了大批量分布式服务跟踪数据的采集、计算、过滤、统计等过程的性能问题,可以实现5秒以内快速发现和定位故障。

总体来看，我们的软件开发工作是成功的，系统已于2019年2月底顺利完成验收，项目的系统架构和技术选型带来的性能、可扩展性和灵活性等方面的优势，在满足后续二次开发和数据接入方面，得到了开发人员、客户和领导的一致好评。目前已完成了所有存量资源数据的接入，可以满足CRM和计费系统的日常运营要求,在月底业务高峰期间，能定位和发现存在性能瓶颈的服务和故障节点，指导相应系统及时采取扩容和灾备方案。但系统开发过程中也面临两方面不足之处：第一在资源管理的数据建模阶段，没有完全识别出所有用户需求，导致集群模型在CRM系统和PaaS平台上理解有偏差，在做资源树的展现时无法串联；后期我们重新定义Mongodb文档的字段，修改相应功能的查询语句，就满足了要求。第二由于配置管理采用蓝鲸开源系统二次改造而来，在多模型关联查询时，性能有待改善;后期采用线程池和并发查询策略直接操作蓝鲸系统的数据库，使得查询性能控制在1s以内。

通过该项目的顺利实施，让我加深了对架构设计相关知识和技术的运用，同时也认识到在今后的工作和学习中，需要进一步梳理完善自身的知识结构，扩展知识的深度和广度，更好地参与到下一个项目中。