论业务系统架构的简化（一）不需要 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 ^^），要怎么搞定？

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

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

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

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

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

因为现在高并发是常态，

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

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

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