关于架构的学习之三驾马车

提及在某一领域起到重要引领和带动做用的因素，咱们每每会想到一次词语，那就是三驾马车，今天，我有幸学习了一下架构的三驾马车。这里所说的三架马车是指微服务、消息队列和定时任务。以下图所示，这里是一个三驾马车共同驱动的一个立体的互联网项目的架构。无论项目是大是小，这个架构模板的形态一旦定型了以后就不太会变，区别只是咱们有更多的服务有更复杂的调用，更复杂的消息流转，更多的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的话通常而言是固定频次的。