DEC-应用架构设计
更偏向于技术架构的设计。
应用：应用软件的概念
应用架构：应用的技术架构
应用软件：按照不同领域、不同用户需求提供的软件包。
系统软件：偏向底层的用于支撑应用软件的软件。
应用软件的技术架构会如何影响软件交付和运维效能
为了支撑devops效能目标，对应用软件技术架构的关键需求是什么
为了满足这些需求，应用软件技术架构设计的常用原则和方法是什么
可扩展性被认为是对devops效能影响最大的因素
1. 架构设计模式
微服务架构的定义：微服务架构风格是一种开发应用的方法，应用由一系列的小服务构成，每个小服务都运行在各自独立的进程中，项目之间采取轻量级的机制通讯（通常是基于HTTP协议的API）。这些服务围绕业务能力进行构建，并且通过全自动化方式进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务仅做最低限度的集中管理。
不应过分追求超前设计、过度设计。在功能和非功能需求变化的驱动下，技术架构要保持不断进化。
2. 可扩展性设计
核心思想：通过模块分解和耦合，将系统拆分为低耦合的模块，提高模块的复用性，并通过低耦合的方式将模块聚合在一起。环境和外部依赖可配置、功能实现可配置。
模块分解
1. 模块分解的核心原则
- 高内聚松耦合：尽量在一处修改
- 复用性：模块复用，避免重复开发
- 稳定性：隔离易变因素，拆分出变化层、稳定层。
2. 常用方法
- 纵向分割：在垂直方向，按照不同的业务域拆分为不同的功能和服务，通常可以按业务域中不同的名词或动词拆分（如名词：用户管理、订单管理；动词：订单查询、订单生成等）
- 横向分层：在水平方向，按照外部请求处理过程拆分为不同层次、通常可以划分为展现层（前后端分离）、应用层（应用服务层）、领域层（领域服务层）、基础设施层（数据访问、数据缓存、持久化存储）
- 非功能需求的分解：基于伸缩性、可用性、高性能等需求，进行部分模块的拆分，比如读写服务分离等。
可参考《领域驱动设计——软件核心复杂性应对之道》
模块聚合
常用方法
异步：分布式消息队列
同步：分布式服务
环境和外部依赖可配置
- 不同环境下的运行参数、不同的外部依赖组件等可以通过配置方式控制，实现软件代码和配置分离，实现同一个软件制品包能适应不同环境、不同外部依赖组件的变化；
方法： - 引入服务配置中心组件（例如Appollo配置中心，spring cloud config server等），实现对配置项的实时控制；
- 基于配置文件实现，为配置文件建立单独的版本控制库，为配置文件变更建立独立的流水线
功能可配置
引入低代码平台，基于通用模板、基础组件的组合编排方式扩展功能；
通过自定义脚本等方式扩展功能
3. 可伸缩性设计
定义：指不需要改变软件系统的软硬件设计，仅仅通过改变部署的服务器资源数量，就可以扩大或缩小软件系统的服务处理能力。
衡量标准：当增加或减少部署的服务器资源数量，系统的处理能力能够接近线性的扩大或缩小
主要方法
服务无状态化、负载均衡
4. 可观测性
定义：指通过应用软件外部输出的信息分析系统内部状态的能力
价值：对软件运行中掌握软件运行状态、发现问题、定位问题的能力的度量。可观测性越好，表示越容易发现和定位内部问题。
日志、指标、追踪。
5. 可用性
定义：是指在某个考察的时间区间内，软件系统处于可执行规定功能状态的能力
衡量标准：一般通过系统服务不中断运行时间占实际运行时间的比例来度量，比例越高越好。
方法
- 服务无状态化
- 失效检测
- 服务降级
- 失效转移
6. 高性能设计
首要解决方案：缓存。
