应用架构总结

妖狐艹你老母 2024-03-22 17:51 60阅读 0赞

### 架构目标 ###

1.  高可用性

整体系统可用性最低99.9%，目标99.99%。全年故障时间整个系统不超过500分钟，单个系统故障不超过50分钟。

1.  高可扩展性 系统架构简单清晰，应用系统间耦合低，容易水平扩展，业务功能增改方便快捷。
2.  低成本 增加服务的重用性，提高开发效率，降低人力成本；
3.  最终一致性

服务设计能满足数据最终一致性，能方便、快捷的满足三方、或者对方对账需求。

1.  质量要求

我们要求在系统设计时候要兼顾下面的各个质量要求

![alt][]

### 架构总体原则 ###

![alt][alt 1]

**DID原则解释**

> **Design(D)设计20倍的容量；Implement(I)实施3倍的容量；Deploy（D）部署1.5倍的容量**
> 
> **原因**：DID为产品扩展提供了经济，有效，及时的方法
> 
> **要点**：在早期考虑可扩展性可以帮助团队节省时间和金钱。在需求发生大约一个月前实施（写代码），在客户蜂拥而至的几天前部署。
> 
> **例子**：“什么时候该在可扩展性上投入”有些轻率的回答是，最好在需要的前一天投入和部署。如果你能够多做到达需要改善可扩展性方案的前一天部署，那么 这笔投资的时机最佳，而且有助于实现公司财务和股东利益的最大化。 让我们面对现实，及时投入和部署根本就不可能，即使可能，也无法确定具体的时间，而且会带来很多风险。
> 
> DID（设计-实施-部署）：思考问题和设计方案，为方案构建系统和编写代码；实际安装或者部署方案。
> 
> **设计**（Design）:DID方法的设计（D）阶段聚集在扩展到20倍和无限大之间，通过如今可扩展性大会，把领导者和工程师团队聚集在一起，共同讨论产品的扩展瓶颈，这是在DID设计阶段发现和确定需要扩展部分的一个好办法。
> 
> **实施**（I，Implement）:我们把规模需求的范围缩小到更接近现实，例如当前规模的3~20倍。
> 
> 部署（D，Deploy）:在部署阶段资产的成本较高，如果是一家适度高增长的公司，也许我们可以把最大产能提高到1.5倍；如果是一家超高增长的公司，也许我们可以把最大产能提高到5倍。扩展具有弹性，它既可以扩张也可以收缩，因此灵活性是关键，因为你需要响应客户的请求，随着规模的收缩和扩张，在系统之间调整容量

### 架构设计原则 ###

1.  业务平台化

*  业务平台化，相互独立。 如交易平台、仓储平台、物流平台、支付平台、广告平台等
 *  基础业务下沉，可复用。如用户、商品、类目、促销、订单等 （参考目前核心系统）。

1.  核心业务、非核心业务分离

核心业务与非核心业务分离，核心业务精简（利于稳定），非核心业务多样化。

1.  隔离不同类型的业务

*  交易业务是签订买家和卖家之间的交易合同，需要优先保证高可用性，让用户能快速下单
 *  闪购业务对高并发要求很高，应该跟普通业务隔离

1.  区分主流程、辅流程

分清哪些是电商的主流程。运行时，优先保证主流程的顺利完成，辅流程可以采用后台异步的方式。避免辅流程的失败导致主流程的回滚。

### 应用架构设计要点 ###

1.  稳定性原则

*  一切以稳定为中心
 *  架构尽可能简单、清晰
 *  不过度设计

1.  解耦、拆分

*  稳定部分与易变部分分离
 *  核心业务与非核心业务分离
 *  主业务与辅业务分离
 *  应用与数据分离
 *  服务与实现细节分离

1.  抽象化

*  应用抽象化：应用只依赖服务抽象，不依赖服务实现细节、位置
 *  数据库抽象化：应用只依赖逻辑数据库，不需要关心物理库的位置和分片
 *  服务器抽象化：应用虚拟化部署，不需要关心实体机配置，动态调配资源

1.  松耦合

*  同步调用时，需要设置超时时间、对调用异常时候的failover处理。
 *  非核心业务尽量异步化：核心、非核心业务之间，尽量异步解耦。
 *  跨业务线（比如分期乐、桔子、鼎盛间）调用需要采用HTTP接口方式，避免底层业务逻辑耦合和依赖。

1.  容错设计

*  服务自治：服务能彼此独立修改、部署、发布和管理，避免一个服务发生灾害引发连锁反应(一定要对mq、rpc、db、redis的异常容错处理、异常包括超时、业务异常、系统异常等)。
 *  集群容错：应用系统集群，避免单点。
 *  多机房容灾：多机房部署，多活。

6 数据的一致性原则

*  小规模分布或不分布的业务确保可用、数据可靠、一致，即A & C兼顾；
 *  中型分布系统需要考虑【BASE-最终一致性】，如果涉及到订单、交易、清结算等数据敏感场景，保持数据最终一致性是最基本原则；
 *  大规模分布式系统在不涉及订单、交易、清结算等数据敏感场景上可以考虑【有损服务】；。

### 架构分解原则 ###

![alt][alt 2]

### 架构依赖原则 ###

1.  依赖稳定部分

*  稳定部分不依赖易变部分
 *  易变部分可以依赖稳定部分
 *  要求：避免循环依赖

1.  跨域弱依赖

跨业务域调用时，尽可能异步弱依赖

1.  基本服务依赖

*  基本服务不能向上依赖流程服务
 *  组合服务、流程服务可以向下依赖基本服务
 *  条件：基本服务稳定

1.  平台服务依赖

*  平台服务不依赖上层应用
 *  上层应用可依赖平台服务
 *  条件：平台服务稳定

1.  核心服务依赖

*  核心服务不依赖非核心服务
 *  非核心服务可依赖核心服务
 *  条件：核心服务稳定

\- END -

本文由[ mdnice ][mdnice]多平台发布

[alt]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/fc4f32a288e245828265881036f43b81.png
[alt 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/4e58247106284e15a7cead82a1076d81.png
[alt 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/7eece4f2282044aa88873edc2466c7f6.png
[mdnice]: https://mdnice.com/?platform=4