zoukankan      html  css  js  c++  java
  • 论 业务系统 架构 的 简化 (一) 不需要 MQ

    MQ , 就是 消息队列(Message Queue),

     

    不知从什么时候起, MQ 被用来 搭建 分布式 业务系统 架构, 一个重要作用 就是用来  “削峰”   。

     

    我们 这里 就来 讨论 如何 设计 业务系统 来 应对 高并发,  不需要 MQ  。

     

    应对 高并发,  很简单,    水平扩展 就可以 。   增加 服务器 数量 就可以 。

     

    MQ 通常用来 分解 一个 用户 请求 中的 各项 子任务, 尤其 是 异步任务,  尤其是 需要 和 第三方 平台 交互 的 任务 。

    比如  支付  业务 就是 一个  典型 的 场景 。

    假设 我们 做一个 支付 相关 的 业务,  用户 的 一次 支付,  我们的 系统 可能 需要 和 微信(支付宝)  交互,  等待 回调 ,  等等  。

    同时 还需要 处理 我们自己的 各种 业务 逻辑, 如果 业务逻辑 比较 庞大, 也可能 拆分 为 异步任务 进行 。

     

    但 不管 是 削峰 还是 分解业务,  都不需要使用  MQ 。

    我们 只 需要 用    进程内的 队列 (Queue) 和  多线程  就可以 很好 的 实现这些  。

     

    削峰, 可以使用   进程内的 队列(Queue),  简单的说, 比如 C# 的  System.Collection.Generics.Queue<T>  ,

    分解业务, 多个异步任务, 用 多线程 就可以 。

     

    大家可能会问, 在 水平扩展(负载均衡) 和 情况下, Server 之间怎么通信, 怎么共享数据 ?

    答案 是 一般情况 下 水平扩展 的 Server 之间 不需要 通信,

    一个 用户 的 一个 请求, 在 一台 Server 内 就可以 完成, 不需要 和 其它 水平 Server 通信 。

    这个 请求  如果分解为 多个 子任务, 在 一台 Server 内 开 多个线程 执行 就可以 。

    同理, 对于 削峰, 我们使用 进程内的 队列(Queue)  就可以 ,  比如 :

     

    private static Queue<T>  payQueue;

     

    这行么  ?

     

    水平 Server  之间的 通信 , 或者说  共享数据, 可以通过  分布式缓存 (比如  Redis   什么的)  来实现,

    我之前也说过, 分布式缓存 实际上是 Web 集群 的 共享内存 。

    但从 简化 的 角度 来看,  一个 请求, 或者说 一个 业务, 通常 在 一台 Server 内 就可以 完成 。 如果需要 多任务, 就使用 多线程 。

    如果 一个 业务 需要 多个 请求 才能 完成 ,

    这种情况 就可能 跨 Server,  

    因为 负载均衡 的 话, 第一次 请求 在 Server 1, 第二次 请求 在 Server 2,

    此时, 可以通过 分布式缓存 来 在 Server 之间 共享数据,  比如 保存 状态信息 。

     

    第三点 是, 对于一个 庞大的业务, 可能采用了 削峰 多任务 等 复杂的架构, 那么, 如何 保证 这个架构 的 稳定性 和 透明性 ?

    所谓 透明性 就是  开发人员 和  运维人员  对 这个 系统 里 发生了 什么 看的 很清楚, 出现问题 可以 清楚 的 知道 定位 追溯 解决 问题  。

    要实现 透明性 , 需要 在 代码 中 规范 和 适当 的 加入 Log 。

    这样 可以 记录下来 每个 子任务 的 创建 执行 报错 结束 状况 。

    在 分布式架构 下, 传统的 文件 Log 已经不能 适应, 需要 升级 为 数据库 Log(DB Log) 。

    DB Log 的 优点 是 :

    1  支持 分布式架构, 各台 Server 的 Log 可以汇总到一起(数据库 ,  表)

    2  便于 分析查询,  用 Sql 很容易 查询追溯,  以及 产出 报表 。

    那 这个 DB Log (或者叫 分布式 Log   ^^) , 要怎么搞定 ?

    其实 很简单, 我自己就写了一个, 可以看一下 :

    《SOALog》     https://www.cnblogs.com/KSongKing/p/9455309.html

    今天说的这个 架构, 就是我之前说过的   “1 Binary   n Deploy”   架构,

    也是我之前说过的    “3.5 层架构”  (在 传统 的 三层架构 上 加上 缓存层 叫做 3.5 层架构) 。

    还有一点就是, 将 业务 分解 为 子任务 不一定能 提高效率 。

    除了 要等待 第三方平台 回调, 或者 响应时间不确定 的 这类情况, 一般情况 分解为 子任务 效率 不一定高 。

    因为 现在 高并发 是 常态,

    在 高并发 下,  CPU 实际上没有 多余的 资源(核) 来 执行 分解出来的 子任务 ,  反而还会 增加 线程间 通信 的 性能消耗 。

    比如,  我们 的 CPU 假设 有 16 个 核,  要处理 每秒 1600 个 请求,   每个 核 要处理 每秒 100 个 请求,

    把 请求 分解成 子任务 实际上 并不能 起到   “并行执行, 利用多核, 提升效率”  的 作用 。

     

  • 相关阅读:
    Python老男孩 day18 文件处理模式b模式
    Python老男孩 day17 文件操作
    Python老男孩 day17 函数(十一) 其他函数
    Python老男孩 day17 函数(十) max、min函数
    Python老男孩 day17 函数(九) zip函数
    Python老男孩 day16 函数(八) map函数、filter函数、reduce函数
    Python老男孩 day16 函数(七) 函数式编程
    sqlzoo答案--more join
    sqlzoo答案--join
    sqlzoo答案--sum and count
  • 原文地址:https://www.cnblogs.com/KSongKing/p/9922146.html
Copyright © 2011-2022 走看看