大规模业务技术架构设计与战术（架构师必看）

战略层设计原则

战略层的设计原则就是：合适原则、简单原则、演化原则。

1.1 合适原则

那么现实是，如果在设计过程中一味追求新技术，往往失败的可能性很高。

1. 没有那么多人，却想干那么多活

1. 没有那么多积累，却想一步登天

1. 没有最新，只要最合适

总结一下，合适原则就是适合优于业界领先。

1.2 简单原则

（1）结构复杂性

图 1

 （2）逻辑复杂性

1.3 演化原则

2.1 高并发原则

（1）无状态

• 无状态应用，便于水平扩展。

• 有状态配置可通过配置中心实现无状

（2） 拆分

• 系统维度：按照系统功能、业务拆分，比如购物车、结算、订单等。
• 功能维度：对系统功能再做细粒度拆分。
• 读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表。
• AOP 维度：根据访问特征，按照 AOP 进行拆分.
• 模块维度：对整体代码结构划分 web、service、dao。

  （3）服务化

• 服务化演进：进程内服务 - 单机远程服务 - 集群手动注册服务 - 自动注册和发现服务 - 服务的分组、隔离、路由 - 服务治理。
• 考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等。

（4）消息队列

• 目的：服务解耦（一对多消费）、异步处理、流量削峰缓冲等。
• 大流量缓冲：牺牲强一致性，保障最终一致性。
• 数据校对：解决异步消息机制下消息丢失问题。

（5）数据异构

• 数据异构：通过消息队列机制接受数据变更，原子化存储。
• 数据闭环：屏蔽多重数据来源，将数据异构存储，形成闭环。

 （6）缓存

• 用户层：DNS 缓存、浏览器 DNS 缓存、操作系统 DNS 缓存、本地 DNS 服务商缓存、DNS 服务器缓存、客户端缓存、浏览器缓存、APP 客户端缓存。
• 代理层：CDN 缓存（一般基于 ATS、Varnish、Nginx、Squid 等构建，边缘节点 - 二级节点 - 中心节点 - 源站）
• 接入层：Nginx 的 Proxy_cache 代理缓存，或者 Nginx+Lua+Redis 做业务数据缓存。
• 应用层：页面静态化、业务数据缓存（Redis/Memcache/ 本地文件等）、消息队列
• 数据层：NoSQL（Redis、Memcache、SSDB 等）

2.2 高可用原则

1. 降级

• 降级开关集中化管理：将开关配置信息推送到各个应用。

• 可降级的多级读服务：如服务调用降级为只读本地缓存。

• 开关前置化：如 Nginx+Lua 配置降级策略，引流流量；可基于此做灰度策略。

• 业务降级：高并发下，保证核心功能，次要功能可由同步改为异步策略或屏蔽功能。

2. 限流

• 目的：防止恶意请求攻击或超过系统峰值

• 恶意请求流量只访问到 Cache

• 穿透后端应用的流量 Nginx 的 limit 处理

• 恶意 Ip 使用 Nginx Deny 策略或者 iptables 拒绝

3. 可回滚

• 发布版本失败时，可随时快速回退到上一个稳定版本。

• 防重设计

• 幂等设计

• 流程定义

• 状态与状态机

• 后台系统操作可反馈

• 后台系统审批化

• 文档注释

• 备份

3.1 逻辑架构图

功能需求技术架构图以产品架构图和应用架构图为基础。实现每个功能点需要使用什么技术、技术实现逻辑如何，就提现在技术架构图上。功能需要技术架构图绘制可以按照“整体 - 局部 - 整体”的思路实现。扩展：架构师必备技能：教你画出一张合格的技术架构图

 1. 整体

首先可以按照应用架构图的应用分布得到应用分布框架。如下：

图 2

2. 局部

图 3

图 4

图 5

图 6

看完本文有收获？请转发分享给更多人

往期资源：