快速成为*架构师的内功修炼
查看直播——如何构建普适的企业级微服务架构
查看上篇文章
（二）同步架构->异步架构
从上图中我们可以看出图中所示的架构是一种同步架构，而同步架构显然是无法满足所有的业务场景的，那么我们怎么将同步架构变成异步架构呢？
如上图所示，在同步架构中，上游发送request给下游，下游再返回response给上游，而想将其变为异步架构也非常简单，就是在上游和下游之间加入一个MQ（Message Queue，消息队列）即可，这时虽然上游和MQ之间、下游和MQ之间仍然是同步架构，但是上游和下游已经变成了一个异步架构。
那么利于MQ，我们如何将上述商品发布服务的架构从同步架构转为异步架构呢？我们一共可以在APP与网关层、网关层与业务逻辑层、业务逻辑层与数据请求层、数据请求层与数据层四个地方加上MQ，使得其成为异步架构，且MQ对整个系统生命周期来说，加的越靠前越好，但是APP与网关层之间加一个MQ的意义不是很大，因为网关层一般不会成为架构的瓶颈。因此，最好的做法就是我们在网关层和业务逻辑层之间加一个MQ，相当于以此MQ为界将业务的生命周期分为了上游和下游，由同步架构转为了异步架构。
我们进一步思考，是不是所有的业务场景都可以用异步架构来做呢？当然不是。比如业务请求分为“读”请求和“写”请求，读请求就很难用异步架构来做，而写请求一般是可以的。但是，是否所有的写请求都可以用异步架构来做呢？大家在工作中需要进一步的思考。
二、微服务架构下分布式事务设计实践
根据上文我们了解了微服务架构的拆分方式，那么我们的DB该怎么去做呢？假如用户数据、商品数据、交易数据分布在不同的DB中，而我们有些操作既涉及到用户数据，又涉及到商品数据和交易数据，这种情况下显然我们是无法去做一些本地事务的，那么有什么解决方法呢？这时我们要进行分布式事务设计。
（一）分布式事务破局
分布式事务我们具体怎么去做呢？首先要进行分布式事务的破局，也就是实现长事务到短事务的转变。假设我们现在有一个事务，涉及到下单、减库存、支付三步，对应DB1、DB2、DB3三个数据库，那么我们想要设计一个分布式事务的第一步就是将长事务变成一个短事务，也就将下单、减库存、支付三步分开成三个事务，如果三个事务都成功了，那么分布式事务也就成功了，即便其中某一个事务N失败了，那么也只需要补偿关联的事务即可，也就是回滚N-1的事务。
（二）分布式事务设计实例
这里我们举一个异步场景的例子，如上图所示的商品交易场景，包括下单和支付两个业务，在用户下单之后，产生一个DB1，然后将消息传输给MQ，再由支付业务去消费MQ的消息，并操作自身的DB。
这种场景下，支付和下单是本地事务，但是MQ实际上不是一个本地事务，那么这时候我们如何去进行分布式事务设计呢？有人说可以将发送message和下单对DB1的操作放在一个本地事务里面，也就上图虚线框中部分。如果不细想，好像这样的操作也没有问题，但是在某些时候会出现问题，比如消费订单消息超时了，前面取消了订单，但是实际上后面的支付成功了，这样就会造成数据库的不一致，带来严重的业务影响。
那么这种情况下，我们怎么去设计分布式事务呢？一种比较好的方式是利用本地事务消息表来做。比如说刚才的下单业务，我们可以将下单和产生message都固化到本地数据中，下单对应一个表（本地事务操作表），产生message对应一个表（本地事务消息表），这样就转变成了一个本地事务，如果下单和产生message都成功，本地事务才成功，两者有一个失败，本地事务就失败了。如下图所示，本地操作和发送消息通过本地事务实现强一致性，再通过MQClient和MQ Server，就实现了分布式事务的设计。
三、要点总结
本次直播中主要讲解了：
（1）在构建普适的企业级微服务架构时如何进行架构的拆分，包括按照业务进行拆分的垂直拆分和按照功能（API）进行拆分的水平拆分两种方式。在拆分完成之后，要根据业务场景来具体地考虑是使用同步架构还是异步架构。
（2）在进行分布式事务设计的时候我们可以采取将长事务拆分成短事务的方式来完成架构设计，并列举了一个异步场景下用本地事务消息表来完成分布式事务设计的实例。
更多的详细文档大家可以扫描下面二维码关注孙玄老师的公众号《架构之美》和阿里云MVP技术圈来查看。
四、QA
下面是直播中的一些问答整理：
问1：现在微服务有什么难点没有解决或者说解决方式不够优雅呢？
答1：这个问题比较大，比如服务本身的设计和服务治理的分离就没有被很好的解决，类似的还有其他很多都没有被优雅的解决。
问2：使用MQ之后，订单状态更新不及时，怎么处理？
答2：首先，你要找到订单状态更新不及时的原因是什么，是因为消息量太大，还是因为下游消费的速度不够，然后针对性的解决。
问3：微服务治理主要有哪些方案？
答3：治理这个话题比较大，通常说的治理除了功能之外，也包括一些其他的治理，比如监控、熔断、限流等。最好的治理方式就是让你的业务同学不需要关注服务治理，比如Istio方案。
问4：微服务一般按照领域来进行设计吗？
答4：领域设计是一个比较好的思路，但是在实际中是比较复杂的，最好的方式还是刚才我们讲的方式，便于更好地去落地。
问5：请问亿级数据量用什么数据库？
答5：我个人认为亿级数据量并不大，用什么数据库都能扛得住，比如MySQL等，问题在于这个亿级的数据到底是怎么样的一个业务场景，需要提供什么样的特性，否则很难得到一个具体的回答。
问6：通常分库和分表的方案是什么呢？
答6：通常分库是按照业务来进行垂直拆分，往往是按照领域来进行拆分的，比如拆分成用户、商品、交易等；分表最好是按照查询维度来进行拆分，比如按照用户ID、商品ID等。另外，对于分库和分表，阿里云有比较好的解决方案，大家可以多多关注一下。
问7：gPRC多语言微服务需要部署在注册中心吗？可以直接使用K8s么？
答7：在我看来，k8s等docker的东西解决的是运维部署的问题，如果你的公司原来已经有了注册中心，那么没有必要为了使用k8s而把原来的注册中心推翻重来；如果原来没有的话，那就可以直接使用k8s service。
关键词：微服务，分布式事务，垂直拆分，水平拆分，MQ