说起在某一领域起到重要引领和带动作用的因素，我们往往会想到一次词语，那就是三驾马车，今天，我有幸学习了一下架构的三驾马车。这里所说的三架马车是指微服务、消息队列和定时任务。如下图所示，这里是一个三驾马车共同驱动的一个立体的互联网项目的架构。不管项目是大是小，这个架构模板的形态一旦定型了之后就不太会变，区别只是我们有更多的服务有更复杂的调用，更复杂的消息流转，更多的Job，整个架构整体是可扩展的，而且不会变形，这个架构可以在很长的一段时间内无需有大的调整。
微服务并不是一个很新的概念，在10年前的时候我就开始实践这个架构风格，在四个公司的项目中全面实现了微服务，越来越坚信这是非常适合互联网项目的一个架构风格。不是说我们的服务一定要跨物理机器进行远程调用，而是我们通过进行有意的设计让我们的业务在一开始的时候就按照领域进行分割，这能让我们对业务有更充分的理解，能让我们在之后的迭代中轻易在不同的业务模块上进行耕耘，能让我们的项目开发越来越轻松，轻松来源于几个方面：
1. 如果我们能进行微服务化，那么我们一定事先经过比较完善的产品需求讨论和领域划分，每一个服务精心设计自己领域内的表结构，这是一个很重要的设计过程，也决定了整个技术架构和产品架构是匹配的，对于All-In-One的架构往往会省略这一过程，需求到哪里代码写到哪里。
2. 我们对服务的划分和职责的定位如果是清晰的，对于新的需求，我们就能知道需要在哪里改怎么样的代码，没有复制粘贴的存在少了很多坑。
3. 我们大多数的业务逻辑已经开发完毕，直接重用即可，我们的新业务只是现有逻辑的聚合。在PRD评审后，开发得到的结论是只需要组合分别调用ABC三个服务的XYZ方法，然后在C服务中修改一下Z方法增加一个分支逻辑，就可以构建起新的逻辑，这种爽快的感觉难以想象。
消息队列MQ的使用有下面几个好处，或者说我们往往处于这些目的来考虑引入MQ：
1. 异步处理：类似于订单这样的流程一般可以定义出一个核心流程，这个流程用于处理核心订单的状态机，需要尽快同步落库完成，然后围绕订单会衍生出一系列和用户相关的库存相关的后续的业务处理，这些处理完全不需要卡在用户点击提交订单的那刹那进行处理。下单只是一个确认合法受理订单的过程，后续的很多事情都可以慢慢在几十个模块中进行流转，这个流转过程哪怕是消耗5分钟，用户也无需感受到。
2. 流量洪峰：互联网项目的一个特点是有的时候会做一些toC的促销，免不了有一些流量洪峰，如果我们引入了消息队列在模块之间作为缓冲，那么backend的服务可以以自己既有的舒服的频次来被动消耗数据，不会被强压的流量击垮。当然，做好监控是必不可少的，下面再细说一下监控。
3. 模块解耦：随着项目复杂度的上升，我们会有各种来源于项目内部和外部的事件（用户注册登陆、投资、提现事件等），这些重要事件可能不断有各种各样的模块（营销模块、活动模块）需要关心，核心业务系统去调用这些外部体系的模块，让整个系统在内部纠缠在一起显然是不合适的，这个时候通过MQ进行解耦，让各种各样的事件在系统中进行松耦合流转，模块之间各司其职也相互没有感知，这是比较适合的做法。
定时任务的需求有那么几类：
1. 如之前所说，跨服务调用，MQ通知难免会有不可达的问题，我们需要有一定的机制进行补偿。
2. 有一些业务是基于任务表进行驱动的，有关任务表的设计下面会详细说明。
3. 有一些业务是定时定期来进行处理的，根本不需要实时进行处理（比如通知用户红包即将过期，和银行进行日终对账，给用户出账单等）。和2的区别在于，这里的任务的执行时间和频次是五花八门的，2的话一般而言是固定频次的。