论软件架构风格

2015

试题二论软件系统架构风格

系统架构风格(System Architecture Style)是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一个词汇表和一组约束，词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。软件系统架构风格反映了领域中众多软件系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。软件系统架构风格的共有部分可以使得不同系统共享同一个实现代码，系统能够按照常用的、规范化的方式来组织，便于不同设计者很容易地理解系统架构。

(请围绕“论软件系统架构风格”论题，依次从以下三个方面进行论述。)

1.概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。

2.分析软件系统开发中常用的软件系统架构风格有哪些?详细阐述每种风格的具体含义。

3.详细说明你所参与的软件系统开发项目中，采用了哪种软件系统架构风格，具体实施效果如何。

摘要：

2022年3月，我负责了某公司基于云原生理念的“自动化运维系统”的建设，并担任系统架构设计师，负责系统架构设计工作。该系统主要包括应用中心、发布中心、监控中心、成本中心、容器中心、权限管理和变更管理七大模块，整个系统采用了分层架构，主要分为表示层、应用层、数据层。在表示层，采用B/S架构风格，基于浏览器和https、websocket协议进行数据的获取、传递和显示；在应用层，采用微服务架构风格，每个模块我们设计为一个或多个微服务，所有的微服务部署在kubernets集群中，基于kubernets的service进行服务的注册和发现；在数据层，针对不同的功能，采用了不同的数据库，主要使用了关系型数据库mysql、缓存数据库redis、列存储数据库clickhouse、搜索引擎数据库elasticsearch。该项目总投入近450万，历时15个月，于2023年6月交付至今，不仅帮助运维人员高效、安全的管理云上应用和后端服务器资源，同时帮助开发和测试人员实现应用的快速迭代和测试，大大提升了团队之间的协作效率，消除了运维和开发之间的壁垒，得到了用户的一致好评。事实证明这种架构设计能够有效降低维护成本，提升系统的可扩展性，移植性和修改性。

正文：

随着云原生技术的发展，企业也逐渐引入相关技术，在基础设施层，越来越多的企业开始购买云上服务器，如应用服务器企业可选择阿里云的ECS服务器，数据库服务器企业可选择阿里云的RDS，DNS服务企业可选择阿里云的域名解析，云上资源购买十分方便，在页面中点击几下即可购买成功，但在实际工作中，不能随意购买，需要结合企业成本和服务器资源使用情况来综合考量，避免资源浪费，所以对云上资源的成本、资源使用情况的可视化管理就很重要。同时，随着容器技术和微服务架构的发展，企业应用也都选择微服务架构，采用容器的方式部署在kubernets集群中，在这种情况下，应用的快速发布、容器资源管理、监控告警就显得尤为重要。

为了实现云上资源的可视化管理和基于云原生应用的快速发布，我所在的公司决定开发一个“自动化运维”系统，我们称之为云平台，并在2022年3月正式启动该项目的建设工作，我被任命为系统架构设计师，负责系统架构设计工作。该项目总投入450万元人民币，建设周期从2022年3月至2023年6月截止，历时15个月。该系统主要包括应用中心、发布中心、监控中心、成本中心、容器中心、权限管理和变更管理七大模块，应用中心是整个系统的数据中心，其他模块的功能都围绕“应用”来进行资源的展示和操作；发布中心以“应用”为单位，向用户提供应用的快速发布功能；监控中心以“应用”为单位，向用户提供应用的监控告警功能；成本中心以“应用”为单位，向用户展示每个应用的成本；容器中心以“应用”为单位，展示应用的相关容器资源；权限管理是对用户分类，使得不同的用户可看到不同的模块；变更管理主要对云上资源的变更进行管控，避免对云上资源的误操作导致系统故障。

在架构开始阶段，我们便意识到，架构风格定义了构建系统的规则，可以为我们的项目提供架构级别的通用解决方案，这种通用的解决方案可以帮我们快速进行系统的设计。

软件系统开发中的常用软件架构风格有：数据流风格、调用/返回风格、独立构件风格、虚拟机风格、仓库风格、C2风格等。数据流风格包括管道/过滤器风格和批处理风格，每步处理都是独立的，顺序执行，前一步骤的输出数据是后一步骤的输入数据，适用于简单的线性流程。调用/返回风格包括主程序/子程序风格，面向对象风格，层次结构风格，降低系统耦合度。独立构件风格包括进程通信和事件驱动，其构件的特点是为软件的重用提供了支持。

虚拟机风格包括解释器和基于规则的系统风格，具有良好的灵活性，可自定义规则。仓库风格包括数据库系统风格、黑板系统风格，以数据为中心。

在了解需求后，我们决定整个系统架构采用层次架构风格，主要将系统分为表示层、应用层和数据层。表示层采用B/S架构，主要负责数据的展示，为用户提供数据查看和操作的入口。应用层采用微服务架构，主要负责业务逻辑，获取数据和资源操作。数据层存储数据，包含关系型数据库mysql、缓存数据库redis、列存储数据库clickhouse和搜索引擎数据库elasticsearch。下面分别介绍各层的详细架构设计。

首先是表示层，在架构方面，我们选择B/S架构，开发人员写好前端代码后，进行编译打包部署到nginx服务器中，用户在浏览器端通过网络进行访问系统，B/S架构交互性强，扩展容易。在技术方面，我们选择了Vue框架，vue是一个轻量级的框架，提供了mvvm风格的双向数据绑定，实现了view和model的解耦，我们选择vue框架还有一个很重要的原因，就是基于vue框架的代码的书写更容理解，更接近于html的代码。在前端页面设计方面，我们主要分成了应用中心、发布中心、监控中心、成本中心、容器中心、权限管理和变更管理七大主菜单，每个主菜单又包含多个子菜单，用户可根据菜单名称，找到系统中对应的位置进行操作。表示层的设计原则是操作简单、容易理解，提升系统的易操作性。

其次是应用层，我们选择了微服务架构，主要是因为微服务使得每个服务更轻量，降低了服务之间的耦合性，每个微服务独立开发和部署，提升了系统的可扩展性。由于服务部署在kubernets集群中，对于服务注册和发现我们使用kubernets的service资源来实现，为每个微服务创建一个service资源即可，在服务之间相互调用时，直接使用service的名称即可。对于服务的弹性扩缩容，我们使用kubernetes的hpa资源，为每个微服务创建一个hpa资源，可实现微服务的弹性伸缩，提升系统的性能。对于服务本身，我们使用了kubernets的deployment资源，当服务进行发布时，可实现当新的节点升级成功后才会删除旧的节点，大大提升了系统的可靠性。

在数据层，不同的微服务，基于不同的业务场景，我们采用了不同的数据库。在应用中心，应用元数据的采用关系型数据库mysql进行存储，主要负责插入、修改、删除等操作。针对应用检索功能，由于应用相关的信息众多，包含应用名、负责人、部门、实例名、实例ip等众多信息，用户在应用检索时，可能搜索任意维度，为了实现应用相关信息的快速检索，我们将相关信息存储在elasticsearch中，通过elasticsearch的sdk来进行信息检索十分方便。在成本中心，成本数据量很大，使用关系型数据库存储，查询效率较低，根据需求分析，成本数据的统计都是基于列查询的，为了提高查询效率，我们选择了clickhouse存储成本数据，大大提高了数据的查询效率。

经过近15个月的项目开发，“自动化运维系统”顺利投入使用，开发人员和测试人员可通过该系统实现应用发布的自动化，无需运维人员的协助，消除了运维和开发的固有壁垒；运维人员可通过该系统高效管理云上资源，实时查看云上资源的使用率和成本，减少资源浪费，提高资源使用率。当然，在本项目中还有一些不足之处，在进行云上资源成本统计时，最初我们通过阿里云的费用接口来拉取各个产品的成本，由于产品很多，写了很多逻辑，后来通过和阿里云的技术人员沟通，可以在阿里云平台上将所有产品的费用一键转储到oss中，直接通过oss的sdk即可快速查询所有产品的费用，后来我们开发人员快速修改下成本获取的逻辑，并没有对项目产生什么影响。由于架构合理且考虑周全，进展顺利，得到了公司技术人员的认可，大大提高了技术团队的协作效率。