Original link: https: //mp.weixin.qq.com/s/oI3Py2PZY31mA5iOOOd73g
This paper from Sun Yuen CCTC2017 General Assembly speech.
Everyone is mentioning the micro-service architecture, micro-service architecture in the end is what? What are its features and design patterns? We create micro-service architecture process, how these design patterns used in actual combat? How should ensure data consistency? Today I will share my response to these questions thinking.
Micro Services Architecture Features
What is a micro-service architecture? English look at this chart, which is proposed by Martin Fowler in 2014, micro Services Architecture is an architectural model, since it is the architecture model, then it will inevitably need to meet some of the features. He mentioned that the micro-services architecture is a combination of a series of small micro-services constituted, then, what is "small micro-service"? Possible understanding of each person is different, we all should know granularity SOA architecture, SOA architecture is relatively thick, in the end what we should split the micro-size service? I think, on the micro-architecture service architecture is essentially a business, then the more profound understanding of the business, the more your reasonable service micro split.
For example, we do the secondary trading platform (around), the platform includes a user system, commodity system, trading system and search recommendation system. Because each system is relatively independent, then we can follow the various business modules to split micro services. Of course, this will not do, because your product there is also a lot of features, but the big idea is to further split according to the internal logic of specific commodities.
Second, around specific business modeling. Everything from business scenarios to talk about micro-service architecture bullying.
There are two ways: First, model a particular area as an independent business units: for example, secondary trading of goods, orders, and other users; secondly the behavior of the business as a separate business unit: such as sending e-mail, single sign-on verification, push service.
Third, the whole micro-services can be deployed independently, because each micro-service Process is independent, so independent of deployment is also very easy to understand each module.
Fourth, decentralized management. To create a decentralized management meaning that there is no micro-services each module and develop language, running relationship platform, development language can be C ++, may go, may be the world's best language, running platform is Linux, Unix, Windows and so can.
The last point is lightweight communication, it is very easy to understand, communication and language module, the platform does not matter. As far as possible selection of lightweight communications to do this thing, so the implementation of cross-platform, cross-language, when it is easy.
Finished these characteristics, we can look at a micro level DEMO standard service architecture in the end by which elements of? Below, including gateways, micro-services, data storage, registry, configuration center .
Since it is under the DEMO stage, and certainly some differences compared to the actual situation. So, the actual case, in the end we should do this thing? This example also recently I was doing second-hand trading platform - around. DEMO and somewhat different place to be. In front of the first layer or gateway, the following polymeric layer micro service role is to do a variety of business logic processing; polymeric layer underlying our data atomic layer, mainly to the data access agent, but depending separate vertical business a. Can be seen, a gateway, a data layer, a registry, configuration centers have, but is divided into two portions in the service processing: one atomic layer, i.e. the entire data access proxy layer provides the interface to the user; another the upper layer service is polymeric layer.
Architectural design patterns and practice cases
I probably talked about some of the above characteristics and DEMO level of service under the micro-micro services as well as which parts of our actual cases set architecture design patterns included. So, why should we adopt this model to do? In addition to this architecture model What other architectural pattern? Here, the pattern is still very much, I will highlight some of these points: chain design patterns, design patterns and aggregation asynchronous shared mode.
First, we design for the chained mode, in this mode, APP front-end request is first to go through the gateway layer, followed by two successive calls micro-service, micro-tune the service even after a 2 tone micro service. Why is it called the chain? Because the call came after the first-micro-1 service, then call in synchronization service 2 Micro, Micro Services 2 will do some processing, after processing micro-services 2 will be fed back to the micro-services 1, 1 micro-service again back to Gateway, and finally back to APP. In the real business scenarios, related to the transactions and orders of business scenarios will be used in this mode.
接下来是聚合器设计模式，APP前端一个调用请求经过Gateway，到达聚合层，需要调用三个微服务，聚合层将三个微服务的返回结果做一些聚合处理，比如可以进行一些排序或者去重，聚合之后再反馈到Gateway和APP前端，这是一个典型的聚合器设计模式。
第三种模式是数据共享模式，这种模式相对比较简单，比如APP经过微服务网关，接下来调用微服务1和微服务2，理想情况下微服务1和微服务2都有自己独立的DB，但是有些情况下由于微服务1和微服务2的请求量和存储量较小，从资源利用率的角度来讲，这两个微服务的DB是共享的，因此这种就是数据的共享模式。
最后一种是异步消息设计模式，不管是链式设计、聚合器模式还是共享数据模式，架构模式都是同步模式。也就是说我的一个请求发出去必须等到每个环节都处理完才会给客户端。如果请求不需要关注处理结果，这时候可以异步来实施。APP更新请求经过微服务网关，持久化到MQ，写入MQ成功后马上Response给APP客户端，之后微服务根据需要从MQ里面订阅更新消息进行异步处理，我们为了提高吞吐量也会采用这种模式。
我从百度到转转这几年经历了很多业务场景，使用的无非就是聚合器、异步和数据共享的数据模式，特别是前面两个用得特别多，下面我们来看一些例子。
接下来我们看个例子，这是我们在2015年做的一个二手交易平台（转转），这个二手交易平台包括商品、分类搜索、关键词搜索、商品推荐等功能。一个用户请求过来，先经过网关，网关下面就是我们的聚合层，聚合层再去调用商品、交易、推荐以及搜索相关的，最终在聚合层把各个微服务原子层的结果汇总起来Response给到客户端。具体如下图所示：
异步消息模式的这个案例比较早了，当时我们做了Feed 流，类似现在的微信朋友圈，这是我在百度做的事情。当时，我们采用的架构模式是异步架构模式。前面是我们的APP，经过了网关，到达异步提交层，可以认为是持久化功能的MQ。用户请求经过网关到消息异步提交层后就返回了，业务处理部分从MQ里面读取数据再进行异步处理。这个时候吞吐量会增加，但是会带来一定的困惑。比如这个时候我发了一条Feed，用户再一查就直接到数据库里面查，可能异步提交消息队列有延迟，查不到，用户就困惑了，这个问题怎么解决？我们就想能不能在前端帮我们做一些事情？比如提交了MQ返回Response 200以后，前段配合插入这条Feed。用户再次刷新时候我相信已经是好几秒以后的事情了，即使有延迟，这个消息早就被你的业务处理完了。当然，我们这里是有特定场景的，社区时候可以这样去做，但是涉及到和金融相关的场景肯定不会这么去做。
数据一致性实践
微服务模块比较分散、数据也比较分散，整个系统复杂性非常高，如何进行数据一致性实践？在一个单体模块里面可以做Local Transaction，但是在微服务体系里面就不奏效。虽然难解决，但是不能不解决，不解决的话微服务架构就很难实施。我们知道微服务中做强一致性性的事情是非常难的，今天分享的更多的是解决最终一致性。因为在微服务下基于不同的数据库，Local Transaction是不可用的。大家在在分布式事务里面一定听说过两阶段提交和三阶段提交，这种场景其实在微服务架构里面也行不通，原因是因为它本质上是同步的模式，同步的模式之下做数据一致性吞吐量降低的非常多。
我们的业务场景无非是两种：第一种是异步调用，就是一个请求过来就写到消息队列里面就行，这种模式相对简单。今天主要讲下同步调用的场景之下怎么打造数据的最终一致性。既然是同步调用场景，并且不能降低业务系统的吞吐量，那么应该怎么做呢？建立一个异步的分布式事务，业务调用失败后，通过异步方式来补偿业务。我们的想法是能不能在整个业务逻辑层实现分布式事务语义策略？如何实现，无非有两种，第一是在调正常请求的时候要记录业务调用链（调用正常接口的完整参数），第二是异常时沿调用链反向补偿。
基于这个思路，我们架构设计上的关键点有三，第一是基于补偿机制，第二是记录调用链，第三是提供幂等补偿接口。架构层面，看下图，右边是聚合器架构设计模式，左边是异步补偿服务。
首先需要在聚合层引入一个Proxy。首先基于方法，在方法名加注解标注补偿方法名，比如：- @Compensable(cancelMethod=“cancelRecord”)
另外，聚合层在调用原子层之前，通过代理记录当前调用请求参数。如果业务正常，调用结束后，当前方法的调用记录存档或删除，如果业务异常，查询调用链回滚。
原子层我们做了哪些事情呢？主要是两方面，第一是提供正常的原子接口，其次是提供补偿幂等接口。
分布式事务关键是两个表（如上图），第一是事务组表，假设A->B->C三个请求是一个事务，首先针对ABC生成一个事务的ID，写在这个表里面，并且会记录这个事务的状态，默认的情况下正常的，执行失败以后我们再把状态由1（正常）变成2（异常）；第二个表是事务调用组表，主要记录事务组内的每一次调用以及相关参数，所以调用原子层之前需要记录一下请求参数。如果失败的话我们需要把这个事务的状态由1变成2；第三，一旦状态从1变成2就执行补偿服务。这是我们的补偿逻辑，就是不断地扫描这个事务所处的表，比如一秒钟扫一次事务组表，看一看这个表里面有没有状态为2的，需要执行补偿的服务。这个思路对业务的侵入比较小。
具体看下我们实际的例子，比如二手交易平台里面创建订单事务组的正常流程，从锁库存到减红包再到创建订单，创建事务组完毕之后开始调用业务，首先Proxy记录锁库存调用的参数，之后开始锁库存服务调用，成功后之后又开始减红包和创建订单过程，如果都成功了直接返回。
再看一下异常的流程，前面几步都是一样的，只是在调红包服务、Proxy创建红包的时候如果失败了就会抛出异常，业务正常返回，聚合层Proxy需要把事务组的状态由1改成2，这个时候由左边的补偿服务异步地补偿调用。
推荐阅读
- 日志排查问题困难？分布式日志链路跟踪来帮你
- zuul集成Sentinel最新的网关流控组件
- 阿里注册中心Nacos生产部署方案
- Spring Boot自定义配置项在IDE里面实现自动提示
- Spring Cloud Zuul的动态路由怎样做？集成Nacos实现很简单
- Spring Cloud开发人员如何解决服务冲突和实例乱窜？
扫码关注有惊喜！
