30种架构设计模式

架构设计模式

管理和监控

• 大使模式： 创建代表消费者服务或应用程序发送网络请求的帮助服务
• 反腐模式：在现代应用程序和遗留系统之间实现装饰或适配器层
• 外部配置存储： 将应用程序部署包中的配置信息移动到中心化的位置
• 网关聚合模式： 使用网关将多个单独的请求聚合到一个请求中
• 网关卸压模式： 把共享或特定的服务功能放到网关代理
• 网关路由模式： 使用单个端点将请求路由到多个服务
• 健康端点监控模式： 在应用程序中执行功能检查，外部工具可以定期通过暴露的端点访问
• 绞杀者模式： 通过新的应用程序和服务逐渐替代特定功能部件来逐步迁移老系统

性能和可扩展性

• 缓存辅助模式： 按需将数据从数据存储中加载到缓存中
  • 查缓存,不命中查库
  • 维护大片“全量”数据,尽量和数据库同步
• 命令和查询责任分离模式： 通过使用单独的接口来分离读取数据和更新数据的操作
• 事件溯源模式： 使用仅追加存储去记录描述对域中的数据采取的操作的完整系列事件
  • 特点：
    • 事件不可变，只是追加新的事件，没有冲突，性能高
    • 以事件驱动做外部处理，耦合低
    • 保留第一手原始资料，信息没有损耗
  • 业务场景
    • 业务更看重数据的意图和目的而不是当前的状态，注重审计、回滚、历史方面的功能
    • 希望避免数据更新冲突，数据的产生有较高的性能，能接受数据状态的最终一致性
    • 整个系统中本身就是以事件为驱动
• 物化视图模式： 针对所需的查询操作，当数据没有理想地格式化时，在一个或多个数据存储中的数据上生成预填充视图
  • 业务场景
    • 经过复杂的计算才能查询出数据
    • 背后存储可能会有不稳定的情况
    • 需要连接多个不同类型的存储才能查询到结果
    • 因为要考虑物化视图计算保存的开销，不太适合数据变化太频繁的情况
    • 因为数据加工需要时间，所以不适合需要强一致性的场景
• 基于队列的负载均衡模式： 使用一个队列作为任务和服务之间的缓冲区，平滑间歇性重负载
  • 引入消息队列不会提高处理能力，而是降低了性能，只是把耦合解开后允许每个部件有单独的弹性， 对不能负荷的部分在队列中进行缓冲，缓冲不是存储不意味着无限制
  • 队列看的是入队速度和处理速度，一般而言，我们需要预先做评估确保处理TPS超过2倍的最高峰的 入队TPS，确保能留出一半的富裕，这样在业务逻辑有修改的时候处理TPS哪怕下降30%，也能抗压
• 优先级队列模式： 确定发送到服务器的请求的优先级，使得具有较高优先级的请求更快被接收和处理
• 限流模式： 控制应用程序，个人租户或整个服务器的实例消耗的资源
  • 限流算法：
    • 计数器算法： 最简单的算法，资源使用+1，释放-1，达到一定计数拒绝服务
    • 令牌桶算法： 按照固定数率往桶中添加令牌，桶里最多存放n个令牌，填满丢弃。处理时候获取，无法获取拒绝服务
    • 漏桶算法： 一个固定容量的漏桶，按照一定速度流出任务，可以以任意速度流入任务，满了则丢弃任务
  • 注意事项：
    • 限流需要快速执行，任何一个超出流量的请求不允许放过，否则没有意义
    • 限流需要提前执行，最好是系统能力达到80%的时候进行限流，越晚风险越大
    • 可以返回特定的限流控制错误代码，让用户知道这不是错误而是限流，可以稍后重试
    • 在监控图上最好对这类限流的曲线有敏感
    • 限流可以在边缘节点上做，如秒杀100w的请求，可以直接随机放弃99.9%，留下1000的请求，TPS为1000没什么问题

数据、安全、消息、弹性

• 分片模式： 将数据存储区划分为一组水平分区或分片

  • 分片前：
    • 需要根据数据分布、压力情况、业务逻辑确定分片的方式，按照条件还是范围还是哈希等
    • 需要进行业务代码的改造，改掉所有不允许的SQL
    • 需要确定用HashCode方式还是框架方式还是中间件方式做数据路由
  • 分片后：
    • 需要有运维工具可以对这么多套分片的数据进行统一的加索引等操作
    • 最好有数据仓库可以汇总所有数据
    • 最好有辅助工具可以用来帮助定位数据会出现在哪个分区中

• 静态内容托管模式： 将静态内容部署到基于云的存储服务，可以将它们直接传递到客户端

• 索引表模式： 为查询经常引用的数据存储区中的字段创建索引

设计与实现模式

• 前端专用的后端模式： 通过单独的接口来分离读取数据和更新数据的操作
• 计算资源整合模式： 将多个任务或操作整合到单个计算单元中
• 选举模式： 通过选举一个实例作为负责管理其他实例的负责人，来协调分布式应用程序中的协作任务实例集合执行的操作
• 管理和过滤器模式： 将需要执行复杂处理的任务分解成可以重复使用的一系列单独的元素

消息模式

• 竞争消息模式： 使用多个消费者来处理同一个消息通道上接受的消息
• 重试模式： 在应用程序尝试在连接服务或网络资源时遇到预期的临时故障，让程序通过透明地重试以前失败的操作来处理
• 调度、代理、主管模式：在一组分布式服务和其他远程资源之间协调一组操作
  • 调度： 负责安排任务，在执行每个步骤的时候维护任务的状态，具体业务逻辑由代理负责
  • 代理： 负责和远程的服务和资源进行通讯，实现错误处理和重试
  • 管理者： 负责监视任务的执行状态，作为调度的补充，在合适的时候要求调度进行补偿

弹性模式

• 舱壁模式： 将应用程序的元素隔离到池中，如果其中一个失败，其他的将继续运行
• 断路器模式： 连接到远程服务或资源时，处理可以需要花费时间来修复的故障
  • 关闭： 出现错误的时候进行增加计数
  • 打开： 计数器达到阈值打开断路器，直接返回错误
  • 半开： 超时后允许一定量的请求通过，成功率达到阈值关闭断路器，操作还是失败进入打开状态
• 事务补偿模式： 撤销通过一系列步骤执行的工作，它们一起定义最终一致的操作
• 代客密钥模式： 使用向客户端提供特定资源或服务的有限直接访问权限的令牌
• 联合身份模式： 将认证委托给外部身份提供者