浅谈APP架构设计

Posted 2021-04-10 码农基础

1、架构设计概要

架构设计是从业务需求到系统实现的一个转换，是对需求进一步深入分析的一个过程，用于确定系统中实体与实体的关系，以及实体的形式与功能，架构课根据从业务需要到系统实现的不同需要 主要分为：业务架构、应用架构、数据架构、技术架构。

 

2、业务架构

业务架构是对业务需求的提炼和抽象，使用一套方法论对产品所涉及需求的业务进行业务边界划分，简单的来说就是根据一套逻辑思路进行业务的拆分，开发软件必须满足的业务需求，否则就是空中阁楼，软件系统在业务上的复杂度问题，可以从业务架构的角度切分工作交界面来解决。

1）、第一步基础业务下沉、可复用，比如说:用户服务、积分服务、通知服务。

2）、第二步业务平台化，比如说社交平台、商城平台。

3）、第三步核心非核心业务分离化、核心独立化，比如说通讯服务、支付服务、订单服务，将核心业务精简（利于稳定），而并非核心业务多样化。

4）、区分主流程和辅助流程。要清楚哪些是电商系统的主流程，在运行时优先保证主流程的顺利完成；对辅助流程可以采用后台异步的方式，避免辅助流程的失败影响主流程的失败回流。

3、应用架构

应用架构介于业务技术之间，是对整个系统实现的整体架构，需要指出系统的层次，系统开发的原则，系统各个层次的应用服务。

可大致将系统分为:表现层、服务层、通用服务层、数据层、第三方集成层

应用架构的设计原则如下：

1）、稳定 - 一切以稳定为中心、架构尽可能简单、清晰、追求小而美。

2）、解耦 - 稳定部分与易变部分分离、核心非核心业务分离、将服务于实现细节分离。

3）、抽象

应用抽象化： 应用只依赖于服务抽象、不依赖服务实现的细节和位置。

数据库抽象： 应用只依赖逻辑数据库、不依赖于物理库的位置和分片。

服务抽象化： 应用虚拟化部署、不需要换新实体机的配置，动态调整资源。

4）、松耦合

跨域调用异步化：在不同的业务域之间尽量异步解耦。

非核心业务尽量异步化：在核心业务与非核心业务之间尽量异步化。

在必须同步调用时，需要设置超时时间和任务队列的长度。

5）、容错设计

服务自治：服务能彼此独立修改、部署、发布和管理，避免引起连锁反应。

集群容错：应用系统集群部署，避免单点服务。

多机房容灾：多机房部署、灵活部署。

4、技术架构

技术架构就是对业务架构中提出的功能进行技术方案的实现，包括软件系统的实现。

技术架构的设计原则如下。

1）无状态，即尽量不要把状态数据保存在本机上。

2）可复用。

2.1 复用粒度是有业务逻辑的抽象服务，不是服务的实现细节。

2.2 服务引用只依赖服务抽象。

3）松耦合

4）可治理

4.1 服务可降级。

4.2 服务可限流。

4.3 服务可开关。

4.4 服务可监控。

4.5 白名单机制。

5）基础服务

5.1 基础服务下沉、可复用，例如账单、通知和价格计算。

5.2 基础服务自治、相对独立。

5.3 对基础服务的实现要精简，并可水平扩展。

5.4 对基础服务的实现要进行物理隔离，包括基础服务相关的数据。

 示例图：客服子系统

5、数据架构

数据架构是对存储数据的架构，其设计原则和应用架构设计大同小异，在设计时要考虑系统的业务场景、根据不同的业务场景对数据进行异构设计、数据库读写分离、热点数据存储、分布式存储策略等。

数据架构包括两部分内容：静态部分的内容和动态部分的内容。

1）、静态部分：

重点就是数据元模型、数据模型、包括主数据、共享动态数据和所有业务相关的业务对象数据的分析和建模。

2) 、动态部分：

重点则是对数据的生命周期的管控和治理，因此，不能单纯地将数据架构理解为纯静态的数据模型，业务架构中数据模型的分析重点是主数据和核心业务对象，应用架构中数据模型的分析重点则进一步转换为逻辑模型和物理模型，直到最终的数据存储和分布。

 

设计原则：

1、统一数据视图，保证数据的及时性、一致性、准确性和完整性

2、对访问量大的数据库做读写分离，将数据量大的做分库分表。

3、对不同的业务域的数据库进行分区隔离，对重要的数据库配置备份库。

== 剧终 ==