AI编程的软件架构和质量
·
架构风格和质量属性是软件架构的重要结构
质量属性则是系统的非功能性要求，如性能，可用性，安全性等等，质量属性往往决定了软件的架构，细微的区别在随着如今对系统的可用性，高性能，可修改性，扩展性等高要求。
如可伸缩性，高可用，高性能，可修改性，故障恢复，以及具备团队解耦，技术解耦等优势。微服务架构风格
常见软件架构风格
| 架构风格 | 描述 | 单体 | 分布式 | 出现时间线 |
|---|---|---|---|---|
| 无风格架构 | 又成混沌架构，指随意架构，庞大的，草率的，布满了胶带和线路 | ✔ | 原始 | |
| 代理 | 此模式用于构造具有解耦组件的分布式系统。这些组件可以通过远程服务调用彼此交互。代理组件负责组件之间的通信协调。 | ✔ | ✔ | 古代 |
| 分层 | 将系统分为多层，每层完成部分系统功能，并传递到下一层完成剩下的功能。每个层只关注划分到自己层的功能 | ✔ | ✔ | 古代 |
| 流水线 | 将数据流的处理的每个步骤分装在过滤器里，数据通过相邻管道传输。 | ✔ | ✔ | |
| 微内核 | 统分解为 核心组件和插件。核心组件提供系统基本功能，具备管理插件功能，通过插件来增强和扩展系统功能 | ✔ | ||
| 事件驱动 | 事件驱动架构风格是一种分布式异步架构风格，经常被用与构建高可伸缩性的应用程序。这种架构风格由一系列高度解耦的、异步接收和处理事件的单一职责的组件所组成 | ✔ | ✔ | |
| 面向服务 | 按照 应用架构拆分系统为多个服务，服务之间的接口，调用方式遵循规范，比如基于WSDL描述服务调用方式，使用SOAP协议调用. | ✔ | 最近30年 | |
| 微服务 | 把应用架构拆分系统为多个细粒度服务，这些服务拥有自己的技术栈，数据库。 | ✔ | 最近10年 | |
| 无服务 | 函数即服务，自动扩容，不需要部署和运维。 | ✔ | 最近10年 | |
| 云原生 | 在微服务或者无服务基础上，增加了基础设施运维，CI/CD等内容 | ✔ | 最近10年 |
物联网应用架构
系统的质量
| 属性名称 | 描述 | 覆盖 |
|---|---|---|
| 性能 | 系统的响应时间.，常见衡量性能的指标TP95 ，TP99 和 吞吐量。本书涉及单机，分布式性能优化的战术实现 | 是 |
| 可用性 | 是系统能够正常运行的时间比例。可用性999，即99.9% ,一年出故障时间为8.76小时。本书涉及到高可用的战术实现。 | 是 |
| 可伸缩性 | 随着用户，请求量增长，系统能扩容适应流量增加。微服务架构，云原生，无服务架构均能支持可伸缩性。事件驱动架构风格也支持订阅端的可伸缩性。 | 是 |
| 可观测性 | 类似机械传感器，可观测性是收集关于程序执行、模块内部状态及组件间通信的数据的能力。为了提高可观测性，可以使用各种测试跟踪技术和工具。可观测性不同于传统监控，前者属于微观，后者属于宏观 | 是 |
| 故障恢复 | 指系统自身或者依赖的系统出现故障的情况下，系统能快速恢复。比如主库宕机下可以切换到从库 | |
| 安全性 | 是指系统拒绝非法用户使用，无安全漏洞 . 用户操作可审计。限于篇幅，本书不会介绍安全。 | 否 |
| 跨平台 | 指系统可以在不同平台运行，比如不同的操作系统或者云服务，或者前端页面可以使用不同的浏览器。本书不会介绍 | 否 |
| 可修改 | 指系统容易修改且容易部署。比如使用微内核架构，事件驱动架构都能让模块容易修改。使用脚本完成经常调整的业务逻辑以避免编写代码和部署系统 | 是 |
| 可扩展性 | 系统易于扩展新的功能，比如接入网关可以扩展接入不同的设备协议，支持不同的证书。微内核架构，事件驱动架构有良好的可扩展性。 | 是 |
| 灵活性 | 指系统的特性易于修改，尤其被非程序员修改，通过配置文件，配置业务规则，或者轻量级脚本实现 | 是 |
| 国际化和本地化 | 系统可以国际化部署，根据不同的使用者具备本地化的功能，如日期，钱币的计算和现实 | 否 |
| 可测试性 | 系统在开发，部署都是易于测试的。比如通过Junit+Mock+Cucumber来实现微服务单体测试，测试人员通过JMeter脚本验收测试。运维人员可能还会录制生产系统的流量用于验收系统的测试 | 是 |
| 易用性 | 用户能容易得掌握系统功能，用户使用出错的情况下能给出明确的指示。比如Web系统的基础协议是HTTP，它就是一个非常易用的协议，它构建出Web系统的易用性。本书不涉及这部分内容，但会在REST API 规范里涉及此内容 | 否 |
物联网网关架构，提出如下问题：
- 当证书文件需要更换的时候，是否不需要重启系统，以提高系统的可用性，灵活性
- 如果网关下游系统出现故障导致调用延时，如何避免影响网关的性能或者可用性。
- 设备的上下线业务是最为重要的业务，即使其他业务繁忙，也需要保证设备上下线功能正常
- 系统是否灵活，当新增业务的时候，是否可以不用开发和重新部署系统，以增强可用性和可修改性
- 协议处理是否灵活，当协议增减内容时候，是否不需要频繁修改编解码和部署系统。
每个问题都涉及到网关系统的质量属性，需要调整其架构，如下是针对上述问题的一个新的架构图。总体上改成事件驱动架构风格，其内部也采用了此架构模式。架构还综合应用了许多质量特性实现战术。黄色部分为调整内容
| 改进 | 描述 | 提高 |
|---|---|---|
| Kafka | 对外调用一律采用发送到Kafka。实现与其他系统解耦，以及调用量削峰功能。即使其他业务故障，也不会对网关系统造成影响 | 可用性，可靠性，高性能 |
| 增加多个线程池 | 上线状态和命令下行使用单独线程池，如果线程池满，则进入延迟重发线程池。其他类型对应的线程池采用丢弃策略，如属性上报如果线程次满，则直接丢弃 | 可用性，高性能 |
| 限流 | Netty 增加设备接入限流以及设备报文限流，此限流阈值配置在apollo中并能实时修改生效 | 可用性，可靠性 |
| 证书管理 | 网关不再重本地加载证书而是通过证书管理组件完成证书的加载和更新。证书统一存放在证书服务器上 | 可用性，灵活性 |
| 编解码自动化工具 | 对于二进制协议，可以配置其规范，并自动解析为JSON或者Java对象，不需要手工编码和部署。 | 可用性，可修改性，灵活性 |
| 热部署Bean容器 | 对于Task的修改可以自动部署生效而不需要重启网关，新增的Task也可以通过此部署 | 可修改性，可用性 |
| 脚本引擎 | 允许Task以脚本方式执行，以快速实现业务功能。比如，对于新的协议，可以在协议配置库配置解析规范，并使用JS来执行解析后的JSON内容 | 可修改性，灵活性 |
| Tracer | 使用可观测性客户端组件，记录设备链接，设备上报等业务信息，也记录线程池使用，任务处理时长等运行信息。 | 可观测性 |
参考：
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
3
0- 0
已为社区贡献3条内容
所有评论(0)