【超赞】技术架构的战略和战术原则
共 5118字,需浏览 11分钟
·
2021-12-17 12:03
战略层的设计原则就是:合适原则、简单原则、演化原则。
我们总是希望能将我们的软件设计的精美、宏大,这样才能彰显我们系统的复杂度和难度。我们是不是会遇到这样的场景,在做设计方案的时候,如果一个解决方案很简单,而且能很快的满足需求。在评审方案时,就会有人觉得这个方案是不是太简单了,没有什么技术含量,是不是需要再设计的复杂一点。
系统是不是一定要设计的复杂?在回答这个问题前,我们先看下软件领域的结构复杂性和逻辑复杂性。
(1)结构复杂性
(2)逻辑复杂性
意识到结构复杂性的问题后,只要减少组件就能让系统结构变简单?这样做还是行不通,原因在于除了结构的复杂性,还有逻辑的复杂性,如果一个组件的逻辑太复杂,通用会带来问题。
设计高并发的系统,需要考虑以下几个方面的设计:无状态、拆分、服务化、消息队列、数据异构、缓存。
(1)无状态
无状态应用,便于水平扩展。
有状态配置可通过配置中心实现无状
(2) 拆分
服务化演进:进程内服务 - 单机远程服务 - 集群手动注册服务 - 自动注册和发现服务 - 服务的分组、隔离、路由 - 服务治理。 考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等。
(4)消息队列
目的:服务解耦(一对多消费)、异步处理、流量削峰缓冲等。
大流量缓冲:牺牲强一致性,保障最终一致性。
数据校对:解决异步消息机制下消息丢失问题。
数据异构:通过消息队列机制接受数据变更,原子化存储。
数据闭环:屏蔽多重数据来源,将数据异构存储,形成闭环。
用户层:DNS 缓存、浏览器 DNS 缓存、操作系统 DNS 缓存、本地 DNS 服务商缓存、DNS 服务器缓存、客户端缓存、浏览器缓存、APP 客户端缓存。 代理层:CDN 缓存(一般基于 ATS、Varnish、Nginx、Squid 等构建,边缘节点 - 二级节点 - 中心节点 - 源站) 接入层:Nginx 的 Proxy_cache 代理缓存,或者 Nginx+Lua+Redis 做业务数据缓存。 应用层:页面静态化、业务数据缓存(Redis/Memcache/ 本地文件等)、消息队列 数据层:NoSQL(Redis、Memcache、SSDB 等)
1. 降级
降级开关集中化管理:将开关配置信息推送到各个应用。
可降级的多级读服务:如服务调用降级为只读本地缓存。
开关前置化:如 Nginx+Lua 配置降级策略,引流流量;可基于此做灰度策略。
业务降级:高并发下,保证核心功能,次要功能可由同步改为异步策略或屏蔽功能。
搜索公众号互联网架构师回复“面试”,送你一份惊喜礼包。
2. 限流
目的:防止恶意请求攻击或超过系统峰值
恶意请求流量只访问到 Cache
穿透后端应用的流量 Nginx 的 limit 处理
恶意 Ip 使用 Nginx Deny 策略或者 iptables 拒绝
3. 可回滚
发布版本失败时,可随时快速回退到上一个稳定版本。
防重设计
幂等设计
流程定义
状态与状态机
后台系统操作可反馈
后台系统审批化
文档注释
备份
1. 整体
图 2
在整体框架的基础上,对每一个局部的子系统进行详细的技术实现的表达。子系统的技术架构图中需要展示每个子系统使用的技术组件,比如(缓存技术、消息中间件、流程引擎、流式计算框架等等)。同时,这些技术组件是如何实现业务功能,需要清晰的展示技术实现逻辑。
图 3
图 4
3.2 物理架构图
图 5
图 6
演化是一个过程,这个过程或长或短,所以演化需要考虑系统的生命周期。如果演化的过程非常漫长,超出了软件的生命周期,即使架构越来越优化,对于产品或者项目的帮助也将有限,所以时间这个约束条件是非常苛刻的。
在现有规划的基础上进行演化,我们无法得到普适的架构,但可以得到确定领域的通用架构,可以在特定领域通过演化使架构逐步优化,帮助业务快速的发展。
作者简介
胡斌,菜鸟网络技术专家,目前负责菜鸟风控系统的建设。曾在淘宝技术部先后负责卖家平台、商家运营等领域。在大规模分布式应用、大数据、架构领域有多年的开发和管理经验。