应用架构设计原则

软件系统架构设计原则就是把我们在各种场景下的架构设计进行抽选化提取公共特征形成过一定的方法论，这些方法论是经过严格推敲并具备移植性的，我们在设计系统时遵从这些设计规则可以为我们的体统提供更高的扩展性、稳定性。

抽象原则

各平台(含基础设施、中间件技术服务、各层业务服务等)需要通过合理地抽象，将内部信息、处理与扩展能力聚合成标准的服务于扩展接口，并通过统一的形式提供给使用者，屏蔽内部的实现与运行细节。

以下是一些符合抽象原则的架构规范或模式： 架构分层(layer)/级(tier)，层、级间提供标准服务与数据接口 根据业务模型，统一服务标准与数据标准 使用服务目录屏蔽服务位置等实现细节 使用“逻辑库”屏蔽数据库物理细节 通过SLA，标准化服务的质量水平 提供标准插件架构支持扩展 使用标准数据库特性，保持厂商无关性 使用逻辑的网络与系统名称 使用商品化硬件单元。

共享原则

最大化重用数据、计算资源、业务组件等资产，防止数据、逻辑与技术实现不一致性带来的管理复杂性，避免重复建设成本与管理成本，通过安全机制保证共享资产的合法使用，通过业务分级保障共享资源效益最大化。 以下是一些符合共享原则的架构规范或模式：

同一业务服务有唯一提供者

同一技术服务有唯一提供者

同一数据有唯一可信源

控制技术多样性 (但需要同时防止厂商绑定)

服务具备互操作性

服务具备易用性

统一的身份、访问控制与加解密机制

为共享服务提供多租户能力 (Multi-tenancy)

提供访问计量与控制能力

提供业务分级能力，对不同级别的业务提供区分服务

自治原则

每一个组件（计算资源、业务组件、信息实体等）具备最大可能的自我完备性，可独立运行、监控、部署、配置与禁用，具备确定的SLA，并与其它组件之间以松散耦合的方式进行协作。当依赖的组件不存在或者无法正常提供服务时，能够以良好的方式降级，且在故障解除后自动恢复。 以下是一些符合自治原则的架构规范或模式：

基于开-闭原则(OCP)设计组件

应用无启动依赖

最小化运行依赖集

根据运行依赖关系合理安排组件物理colocation

能够隔离依赖组件的故障

异步调用 (提升异常流量的承载能力，简化故障隔离的实现)

具备自我健康检查能力

具备自我恢复能力

无状态设计

冗余原则

各组件（计算资源、业务组件、数据等）都必须有充分、合理的冗余实例，保证单一组件实例失效不影响业务正常运行（多活/热备），或可以通过切换备份实例快速恢复（温备/冷备），不会丢失不可恢复的数据。针对不同类型的组件，需要明确定义冗余量与冗余类型。 以下是一些符合冗余原则的架构规范或模式：

高可用水平扩展服务器集群（负载均衡、健康检查与自动切换）

无单点设计 (含逻辑单点)

采用“随机写”策略的数据库水平拆分

Failover数据库

N+1或N+x设计

“多活”数据中心

数据复制

灾难备份

分布原则

整个系统拆分成职责清晰、粒度恰当、便于管理的组件，各组件（计算资源、业务组件、数据等）可分布部署运行。组件的拆分与分布可以采取复制、根据功能垂直拆分、或根据用户与访问模式水平拆分等形式。 以下是一些符合分布原则的架构规范或模式：

读写分离设计

垂直分拆

水平分拆

柔性的分布事务

自动原则

系统设计了具备自监控、自管理、自适应与自优化能力，可以随着业务量与访问模式的变化、以及其它内、外部因素的改变，自动地对资源进行调度、调整服务策略，保障自身的稳定与服务的质量。 以下是一些符合自动原则的架构规范或模式：

监控每一个服务的质量与资源的状态与报警

从客户视角监控最终服务的质量

统一、自动的错误报告、管理与响应

提供完备的配置能力

自动化系统安装

自动化应用部署

自动化资源分配

可以mark up/mark down服务

支持优雅降级

自动拒绝超出SLA之外异常流量

-END-