如何做好架构设计
了解架构图
4R架构
4+1架构视图
常见架构图
业务架构
客户端架构、前端架构
系统架构
应用架构
部署架构
系统时序图
idea-PlantUML
时序图
@startuml title Oauth2令牌颁发之授权码模式 actor User as user participant "User Agent" as userAgent participant "Client" as client participant "Auth Login" as login participant "Auth Server" as server autonumber user->userAgent:访问客户端 activate userAgent userAgent->login:重定向到授权页面+clientId+redirectUrl activate login login->server:用户名+密码+clientId+redirectUrl activate server server-->login:返回授权码 login-->userAgent:重定向到redirectUrl+授权码code deactivate login userAgent->client:使用授权码code换取令牌 activate client client->server:授权码code+clientId+clientSecret server-->client:颁发访问令牌accessToken+refreshToken deactivate server client-->userAgent:返回访问和刷新令牌 deactivate client userAgent--> user:令牌颁发完成 deactivate userAgent @enduml
@startuml title Oauth2令牌颁发之授权码模式 actor User as user participant "User Agent" as userAgent participant "Client" as client participant "Auth Login" as login participant "Auth Server" as server autonumber user->userAgent:访问客户端 activate userAgent userAgent->login:重定向到授权页面+clientId+redirectUrl activate login login->server:用户名+密码+clientId+redirectUrl activate server server-->login:返回授权码 login-->userAgent:重定向到redirectUrl+授权码code deactivate login userAgent->client:使用授权码code换取令牌 activate client client->server:授权码code+clientId+clientSecret server-->client:颁发访问令牌accessToken+refreshToken deactivate server client-->userAgent:返回访问和刷新令牌 deactivate client userAgent--> user:令牌颁发完成 deactivate userAgent @enduml
本时序图关键说明如下:
title
可以用于指定UML图的标题;通过
actor
可以声明人形的参与者;通过
participant
可以声明普通类型的参与者;通过
as
可以给参与者取别名;通过
->
可以绘制参与者之间的关系,虚线箭头可以使用-->
;在每个参与者关系后面,可以使用
:
给关系添加说明;通过
autonumber
我们可以给参与者关系自动添加序号;通过
activate
和deactivate
可以指定参与者的生命线。右键时序图时,可以生成一个在线访问的链接;
直接访问这个链接,可以在线访问UML时序图,并进行编辑
活动图
@startuml title 生成确认单流程 start :获取购物车信息并计算好优惠; :从ums_member_receive_address表中\n获取会员收货地址列表; :获取该会员所有优惠券信息; switch(根据use_type判断每个优惠券是否可用) case(0) :全场通用; if (判断所有商品总金额是否\n满足使用起点金额) then (否) :得到用户不可用优惠券列表; stop endif case(-1) :指定分类; if (判断指定分类商品总金额\n是否满足使用起点金额) then (否) :得到用户不可用优惠券列表; stop endif case(-2) :判断指定商品总金额是否满足使用起点金额; if (判断指定分类商品总金额\n是否满足使用起点金额) then (否) :得到用户不可用优惠券列表; stop endif endswitch :得到用户可用优惠券列表; :获取用户积分; :获取积分使用规则; :计算总金额,活动优惠,应付金额; stop @enduml
@startuml title 生成确认单流程 start :获取购物车信息并计算好优惠; :从ums_member_receive_address表中\n获取会员收货地址列表; :获取该会员所有优惠券信息; switch(根据use_type判断每个优惠券是否可用) case(0) :全场通用; if (判断所有商品总金额是否\n满足使用起点金额) then (否) :得到用户不可用优惠券列表; stop endif case(-1) :指定分类; if (判断指定分类商品总金额\n是否满足使用起点金额) then (否) :得到用户不可用优惠券列表; stop endif case(-2) :判断指定商品总金额是否满足使用起点金额; if (判断指定分类商品总金额\n是否满足使用起点金额) then (否) :得到用户不可用优惠券列表; stop endif endswitch :得到用户可用优惠券列表; :获取用户积分; :获取积分使用规则; :计算总金额,活动优惠,应付金额; stop @enduml
本活动图关键说明如下:
- 通过
start
和stop
可以表示流程的开始和结束;通过
:
和;
中间添加文字来定义活动流程节点;通过
if
+then
+endif
定义条件判断;通过
switch
+case
+endswitch
定义switch判断。
高可用架构通用设计
大型互联网架构设计,需要考虑的点,
高并发
、高性能
、高可用
、高扩展
。
一、系统拆分
将一个复杂的业务域按DDD的思想拆分成若干子系统,每个子系统负责专属的业务功能,做好垂直化建设,各个子系统之间做好边界隔离,降低风险蔓延。
二、解耦
软件开发原则“高内聚、低耦合”。
小到接口抽象
、MVC 分层
,大到 SOLID 原则
、23种设计模式
。核心都是降低不同模块间的耦合度,避免一处错误改动影响到整个系统。
以开闭原则
为例,对扩展是开放的,对修改是关闭的。随着业务功能迭代,如何做到每次改动不对原来的旧代码产生影响。
Spring 框架给我们提供了一个很好的思路,里面有个重要设计 AOP
,全称(Aspect Oriented Programming),面向切面编程。
核心就是采用动态代理技术,通过对字节码进行增强,在方法调用的时候进行拦截,以便于在方法调用前后,增加我们需要的额外处理逻辑。
还有一个重要思路就是事件机制
,通过发布订阅模式
,新增的需求,只需要订阅对应的事件通知
,针对性消费即可。不会对原来的代码侵入性修改,是不是会好很多。
三、异步
同步指一个进程在执行请求的时候,若该请求需要一段时间才能返回信息,那么这个进程将会一直等待下去,直到收到返回信息才继续执行下去。
如果是非实时响应的动作可以采用异步来完成,线程不需要一直等待,而是继续执行后面的逻辑。
如:线程池(ThreadPoolExecutor)、消息队列 等都是这个原理
比如一个用户在淘宝下了一笔购物订单,关心的是订单是否创建成功,能否进行后续的付款流程
至于其他业务动作,如短信通知、邮件通知、生成订单快照、创建超时任务记录,这些非核心动作用户并不是特别关心。
我们可以采用消息队列的发布/订阅
机制,数据库插入订单记录后,发布一条消息到 MQ,然后就可以告知用户下单成功。
其他事情,由不同的 Task 任务订阅消息异步处理,彼此间互不干扰。
四、重试
重试主要是体现在远程的RPC调用,受 网络抖动
、线程资源阻塞
等因素影响,请求无法及时响应。
为了提升用户体验,调用方可以通过 重试
方式再次发送请求,尝试获取结果。比过:浏览器的 F5 刷新机制就是类似道理。
接口重试是一把双刃剑,虽然客户端收到了响应超时
结果,但是我们无法确定,服务端是否已经执行完成。如果盲目地重试,可能会带来严重后果。比如:银行转账。
重试
通常跟幂等
组合使用,如果一个接口支持了 幂等
,那你就可以随便重试
关于的 幂等
的解决方案
- 插入前先执行查询操作,看是否存在,再决定是否插入
- 增加唯一索引
- 建防重表
- 引入状态机,比如付款后,订单状态调整为
已付款
,SQL 更新记录前 增加条件判断 - 增加分布式锁
- 采用 Token 机制,服务端增加 token 校验,只有第一次请求是合法的
五、补偿
不是所有的请求都能收到成功响应。除了重试
机制外,还可以采用补偿玩法,实现数据最终一致性
。
业务补偿根据处理的方向分为两部分:
- 正向。多个操作构成一个分布式事务,如果部分成功、部分失败,我们会通过最大努力机制将
失败
的任务推进到成功状态 - 逆向。同上道理,我们也可以采用反向操作,将部分成功任务恢复到
初始状态
注意:补偿操作有个重要前提,业务能接受短时间内的数据不一致。
补偿有很多的实现方式:
1、本地建表方式,存储相关数据,然后通过定时任务扫描提取,并借助反射机制触发执行
2、也可以采用简单的消息中间件,构建业务消息体,由下游的的消费任务执行。如果失败,可以借助MQ的重试机制,多次重试
六、备份
任何服务器都有宕机的可能性,一旦存储了数据,带上状态,如果发生故障,数据丢失,后果是我们无法承受的。
所以,容灾备份
也就变成了互联网的基本能力。
如何备份,不同的框架有不用的玩法。以 Redis 为例:
Redis 借助 RDB
和 AOF
来实现两台服务器间的数据同步
- RDB,全量数据同步
- AOF,增量数据同步,回放日志
一旦主节点挂了怎么办?
这里引入哨兵机制。哨兵机制可以实现主从库的自动切换,有效解决了故障转移。整个过程分为三个阶段:监控、选主、通知。
除了 Redis 中间件外,其他常见的 MySQL、Kafka 消息中间件、HBase 、ES 等 ,凡是涉及到数据存储的介质,都有备份机制,一旦主节点挂了,会启用备份节点,保证数据不会丢失。
七、多活策略
在一些极端情况,如:机房断电、机房火灾、地震、山洪等不可抗力因素,所有的服务器都可能出现故障,无法对外提供服务,导致整体业务瘫痪。
为了降低风险,保证服务的24小时可用性,我们会采用 多活策略
。
常见的多活
方案有,同城双活
、两地三中心
、三地五中心
、异地双活
、异地多活
八、隔离
隔离属于物理层面的分割,将若干的系统低耦合设计,独立部署,从物理上隔开。
每个子系统有自己独立的代码库,独立开发,独立发布。一旦出现故障,也不会相互干扰。当然如果不同子系统间有相互依赖,这种情况比较特殊,需要有默认值或者异常特殊处理,这属于业务层面解决方案。
隔离属于分布式技术的衍生产物,我们最常见的微服务解决方案。
将一个大型的复杂系统拆分成若干个微服务系统,这些微服务子系统通常由不同的团队开发、维护,独立部署,服务之间通过 RPC
远程调用。
隔离使得系统间边界更加清晰,故障可以更加隔离开来,问题的发现与解决也更加快速,系统的可用性也更高。
九、限流
高并发系统,如果遇到流量洪峰,超过了当前系统的承载能力。CPU、内存、Load负载飚的很高,最后处理不过来,所有请求都超时无法正常响应。
解决方案-限流
限流定义:
限制到达系统的并发请求数量,保证系统能够正常响应部分用户请求,而对于超过限制的流量,则通过拒绝服务的方式保证整体系统的可用性。
根据作用范围:限流分为单机版限流、分布式限流
1、单机版限流
主要借助于本机内存来实现计数器,比如通过AtomicLong#incrementAndGet(),但是要注意之前不用的key定期做清理,释放内存。
纯内存实现,无需和其他节点统计汇总,性能最高。但是优点也是缺点,无法做到全局统一化的限流。
2、分布式限流
单机版限流仅能保护自身节点,但无法保护应用依赖的各种服务,并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。而分布式限流,以集群为维度,可以方便的控制这个集群的请求限制,从而保护下游依赖的各种服务资源。
限流支持多个维度:
- 整个系统一定时间内(比如每分钟)处理多少请求
- 单个接口一定时间内处理多少流量
- 单个IP、城市、渠道、设备id、用户id等在一定时间内发送的请求数
- 如果是开放平台,则为每个appkey设置独立的访问速率规则
常见的限流算法:
- 计数器限流
- 滑动窗口限流
- 漏桶限流
- 令牌桶限流
十、熔断
熔断,其实是对调用链路中某个资源出现不稳定状态时(如:调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。
熔断的主要方式是使用断路器阻断对故障服务器的调用
断路器有三种状态,关闭、打开、半打开。
1、关闭(Closed)状态:在这个状态下,请求都会被转发给后端服务。同时会记录请求失败的次数,当请求失败次数在一段时间超过一定次数就会进入打开状态。
2、打开(Open)状态:在这个状态下,熔断器会直接拒绝请求,返回错误,而不去调用后端服务。同时,会有一个定时器,时间到的时候会变成半打开状态。目的是假设服务会在一段时间内恢复正常。
3、半打开(Half Open)状态:在这个状态下,熔断器会尝试把部分请求转发给后端服务,目的是为了探测后端服务是否恢复。如果请求失败会进入打开状态,成功情况下会进入关闭状态,同时重置计数。
目前,市面流行的解决方案是阿里的开源框架 Sentinel
,提供了Dashboard控制台用于定义资源以及规则配置
十一、降级
降级是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性。
降级是系统保护的一种重要手段。使有限资源
发挥最大价值,临时关闭一些非核心功能,减轻系统压力,并将有限资源留给核心业务。
比如电商大促,业务在峰值时刻,系统抵挡不住全部的流量时,系统的负载、CPU 的使用率都超过了预警水位,可以对一些非核心的功能进行降级,降低系统压力,比如把商品评价
、成交记录
等功能临时关掉。弃车保帅,保证 创建订单
、订单支付
等核心功能的正常使用。