现在微服务有很多人用。我以前写项目都是用的单体架构，简单方便。但是前几天我和小伙伴参加一个比赛要求使用微服务架构，当时对微服务架构一点也不了解。后来在github上查找代码时发现许多人已经开始使用微服务架构开始搭建日常的一些项目了。在这篇文章中作者介绍了现在常用的三种架构：微服务、消息队列和定时任务。
用微服务、消息队列和定时任务搭建起来的项目架构时可扩展的，而且不会变形，这个架构可以在很长的一段时间内无需有大的调整。
如果项目使用微服务架构，会有这样几个好处：
（1）如果我们要进行·微服务架构，必须先要进行产品需求讨论和精心设计自己的表结构。早先做好这些的工作会让后来的工作容易很多。
（2）微服务能够让我们清晰对服务的划分和指责的定位，这写对于后来更改新需求是有利。
（3）当心得方案需求用到旧的代码时，只需要将以前的服务组合调用一下就好了。代码的复用性很高。
（4）在性能存在明显瓶颈的时候，我们可以针对性地对某些服务增加更多机器进行扩容，而且因为服务的划分，我们更清楚系统的瓶颈所在。
（5）如果业务有比较大的变动需要下线，那么我们可以肯定的是底层的公共服务是不会淘汰的，下线对应业务的聚合业务服务停掉流量入口，然后下线相关涉及到的基础服务进行部分接口即可。
服务是有三个层次：（1）聚合业务服务：高层次的串起来整个流程的具有完整业务形态的业务服务。和基础业务服务不同的是，这里是在完整描述一方面的业务，这个业务往往是由各种基础业务拼装组合起来的。和不同外部合作方的不同合作形式，给用户提供的产品的不同服务形态，都决定了聚合业务服务会有业务流程上的差异化。（2）基础业务服务：某一个领域业务相关的服务。此类服务之间是允许相互调用的，比如投资人交易服务和借款人交易服务免不了需要和用户服务、资产服务、账户账务服务进行通讯做相关的用户信息查询、标的信息查询、记账等业务操作。（3）公共基础服务：负责某一个方面的基础业务（没有什么领域业务逻辑在里面），可以是自治的处理某一个方面的基础业务，也可以和外部通讯实现某一个方面的功能，服务之间是不会相互调用的，但是会被聚合业务服务和基础业务服务调用。
每一个服务对接的底层数据表是独立的没有交叉关联的，也就是数据结构是不直接对外的，需要使用其他服务的数据一定通过访问接口进行。
消息队列MQ的使用有下面几个好处：异步处理、流量洪峰、模块解耦、消息群发。
定时任务的需求有几类：如之前所说，跨服务调用，MQ通知难免会有不可达的问题，我们需要有一定的机制进行补偿。有一些业务是基于任务表进行驱动的，有关任务表的设计下面会详细说明。有一些业务是定时定期来进行处理的，根本不需要实时进行处理。任务表可以设计下面的字段：自增ID；任务类型：表明具体的任务类型，当然也可以不同的任务类型直接做多个任务表；外部订单号：和外部业务逻辑的唯一单号关联起来；执行状态：未处理（等待处理），处理中（防止被其它Job抢占），成功（最终成功了），失败（暂时失败，会继续进行重试），人工介入（永远不会再变了，一定需要人工处理，需要报警通知）；重试次数：处理过太多次还是失败的可以归类为死信，由专门的死信队列任务单独再进行若干次的重试不行的话就报警人工干预；处理历史：每一次的处理结果，Json的List保存在这里供参考；上次处理时间：最近一次执行时间；上次处理结果：最近一次执行结果；创建时间：数据库维护；最后修改时间：数据库维护。
通过这篇文章，微服务、消息队列、定时任务的确可以解决很多我以前写项目时遇到的许多问题。希望我以后会把这些架构应用到我的项目。