论 业务系统 架构 的 简化 （一） 不需要 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 个 请求，

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