《实施微服务架构的关键技术》由会员分享，可在线阅读，更多相关《实施微服务架构的关键技术（15页珍藏版）》请在金锄头文库上搜索。
1、实施微效劳架构的关键技术大家都在提微效劳架构，微效劳架构到底是什么？它有哪些特点和设计模式？我们在打造微效劳架构过程中，这些设计模式在实战当中如何应用？数据的全都性应当如何保证？本文将针对上述疑问开放共享。15微效劳架构特点什么是微效劳架构？看以下图的这段英文，这是 Martin Fowler 在 2021 年提出来的，微效劳架构是一种架构模式，既然是架构模式，那么，它就必定需要满足一些特点。他提到，微效劳架构是一系列小的微效劳 构成的组合，那么，什么是“小的微效劳”？可能每个人的理解都不一样，大家都应当都知道 SOA 架构， SOA 架构的粒度是比较粗的，到底我们应当以什么样的粒度拆分微效劳
2、？我认为，微效劳架构本质上一个业务架构，那么对业务了解的越深刻，你的微效劳拆分就越合理。比方我们做二手交易平台转转，该平台包括用户体系、商品体系、交易体系以及搜寻推举体系。由于 各个体系比较独立，那么我们就可以依据各个业务模块来拆分微效劳。固然，这样做还不够，由于你的商 品里面还有很多功能，但是大的思路是依据具体商品内部的规律来进一步拆分。其次，围绕具体业务建模。一切脱离业务场景谈微效劳架构都是耍流氓。方法有二：首先将某一领域的模型作为独立的业务单元：比方二手交易中的商品、订单、用户等；其次将 业务的行为作为独立的业务单元：比方发送邮件、单点登录验证、push 效劳。第三，整个微效劳都可以独立
3、地部署，由于每一个维效劳Process 都是独立的，所以依据每个模块进展独立的部署也是很简洁理解的。第四，去中心化治理。打造去中心化治理意思就是微效劳的每个模块和开发语言、运行平台没有关系，开 发语言可以是 C+，可以是 go，也可以是世界上最好的语言，运行的平台是Linux，Unix、Windows 等都可以。最终一点就是轻量级通信，这点很简洁理解，通信和模块语言、平台没有关系。尽可能选用轻量级的通信 来做这个事情，这样实施跨平台、跨语言的时候就很简洁。讲完这些特点，我们可以看一看一个标准DEMO 级的微效劳架构到底是由哪些元素组成的？如以下图，主要包括网关、微效劳、数据存储、注册中心、配置
4、中心。既然是 DEMO 级的，和实际状况下相比确定有所差异。那么，实际案例中，我们到底应当如何做这件事情？这个例子也是最近我在做的二手交易平台转转。这里和DEMO 有些不一样的地方。前面的第一层还是网关，下面有微效劳的聚合层，作用是做各种业务规律的处理；聚合层下面是我们的数据原子层， 主要做数据访问代理，只不过依据业务的不同垂直分开了。可以看到，网关、数据层，注册中心、配置中 心都有，只不过在业务处理局部分成两层：一层是原子层，也就是整个数据访问的代理层，供给了用户的 接口；另外一层就是上层的业务聚合层。架构设计模式及实践案例了解了微效劳的一些特点以及 DEMO 级的微效劳包括哪些局部以及实际
5、案例中我们的设架构设计模式。那么，我们为什么要承受这种模式去做？除了这种架构模式之外还有哪些其它的架构模式？这里，模式还 是格外多的，我会重点讲这几点：链式设计模式、聚合器设计模式和异步共享模式。首先我们来说下链式设计模式，在这种模式下，APP 前端恳求首先要经过网关层，接下来连续调用两个微效劳，调了微效劳 1 之后还要调微效劳 2。为什么叫做链式呢？由于在调用过来以后先到微效劳1，然后再同步地调用微效劳 2，微效劳 2 会做一些处理，处理以后微效劳2 才会反响给微效劳 1，微效劳 1 再反响给 Gateway，最终反响到 APP。在实际业务场景中，涉及到交易和订单的业务场景都会用到这种模式。
6、接下来是聚合器设计模式，APP 前端一个调用恳求经过 Gateway，到达聚合层，需要调用三个微效劳， 聚合层将三个微效劳的返回结果做一些聚合处理，比方可以进展一些排序或者去重，聚合之后再反响到Gateway 和 APP 前端，这是一个典型的聚合器设计模式。第三种模式是数据共享模式，这种模式相比照较简洁，比方APP 经过微效劳网关，接下来调用微效劳1 和微效劳 2，抱负状况下微效劳 1 和微效劳 2 都有自己独立的 DB，但是有些状况下由于微效劳 1 和微效劳 2 的恳求量和存储量较小，从资源利用率的角度来讲，这两个微效劳的DB 是共享的，因此这种就是数据的共享模式。最终一种是异步消息设计模式
7、，不管是链式设计、聚合器模式还是共享数据模式，架构模式都是同步模式。 也就是说我的一个恳求发出去必需等到每个环节都处理完才会给客户端。假设恳求不需要关注处理结果， 这时候可以异步来实施。APP 更新恳求经过微效劳网关，长久化到 MQ，写入 MQ 成功后马上 Response 给 APP 客户端，之后微效劳依据需要从MQ 里面订阅更新消息进展异步处理，我们为了提高吞吐量也会承受这种模式。我从百度到转转这几年经受了很多业务场景，使用的无非就是聚合器、异步和数据共享的数据模式，特别 是前面两个用得特别多，下面我们来看一些例子。接下来我们看个例子，这是我们在 2021 年做的一个二手交易平台转转，这个
8、二手交易平台包括商品、分类搜寻、关键词搜寻、商品推举等功能。一个用户恳求过来，先经过网关，网关下面就是我们的聚合层， 聚合层再去调用商品、交易、推举以及搜寻相关的，最终在聚合层把各个微效劳原子层的结果汇总起来Response 给到客户端。具体如以下图所示：异步消息模式的这个案例比较早了，当时我们做了Feed 流，类似现在的微信朋友圈，这是我在百度做的事情。当时，我们承受的架构模式是异步架构模式。前面是我们的APP，经过了网关，到达异步提交层， 可以认为是长久化功能的 MQ。用户恳求经过网关到消息异步提交层后就返回了，业务处理局部从 MQ 里面读取数据再进展异步处理。这个时候吞吐量会增加，但是会
9、带来肯定的困惑。比方这个时候我发了一条Feed，用户再一查就直接到数据库里面查，可能异步提交消息队列有延迟，查不到，用户就困惑了，这个 问题怎么解决？我们就想能不能在前端帮我们做一些事情？比方提交了MQ 返回 Response 200 以后，前段协作插入这条 Feed。用户再次刷新时候我信任已经是好几秒以后的事情了，即使有延迟，这个消息早就被你的业务处理完了。固然，我们这里是有特定场景的，社区时候可以这样去做，但是涉及到和金融 相关的场景确定不会这么去做。数据全都性实践微效劳模块比较分散、数据也比较分散，整个系统简单性格外高，如何进展数据全都性实践？在一个单体 模块里面可以做 Local Tr
10、ansaction，但是在微效劳体系里面就不奏效。虽然难解决，但是不能不解决，不解决的话微效劳架构就很难实施。我们知道微效劳中做强全都性性的事情是格外难的，今日共享的更多 的是解决最终全都性。由于在微效劳下基于不同的数据库，Local Transaction 是不行用的。大家在在分 布式事务里面肯定听说过两阶段提交和三阶段提交，这种场景其实在微效劳架构里面也行不通，缘由是因 为它本质上是同步的模式，同步的模式之下做数据全都性吞吐量降低的格外多。我们的业务场景无非是两种：第一种是异步调用，就是一个恳求过来就写到消息队列里面就行，这种模式 相对简洁。今日主要讲下同步调用的场景之下怎么打造数据的最终
11、全都性。既然是同步调用场景，并且不 能降低业务系统的吞吐量，那么应当怎么做呢？建立一个异步的分布式事务，业务调用失败后，通过异步 方式来补偿业务。我们的想法是能不能在整个业务规律层实现分布式事务语义策略？如何实现，无非有两 种，第一是在调正常恳求的时候要记录业务调用链调用正常接口的完整参数，其次是特别时沿调用链 反向补偿。基于这个思路，我们架构设计上的关键点有三，第一是基于补偿机制，其次是记录调用链，第三是供给幂 等补偿接口。架构层面，看以下图，右边是聚合器架构设计模式，左边是异步补偿效劳。首先需要在聚合层引入一个 Proxy。首先基于方法，在方法名加注解标注补偿方法名，比方：- Compen
12、sable(cancelMethod=“cancelRecord”)另外，聚合层在调用原子层之前，通过代理记录当前调用恳求参数。假设业务正常，调用完毕后，当前方 法的调用记录存档或删除，假设业务特别，查询调用链回滚。原子层我们做了哪些事情呢？主要是两方面，第一是供给正常的原子接口，其次是供给补偿幂等接口。分布式事务关键是两个表如上图，第一是事务组表，假设A-B-C 三个恳求是一个事务，首先针对ABC 生成一个事务的 ID，写在这个表里面，并且会记录这个事务的状态，默认的状况下正常的，执行失败以后我们再把状态由 1正常变成 2特别；其次个表是事务调用组表，主要记录事务组内的每一次调用以及相关参数
13、，所以调用原子层之前需要记录一下恳求参数。假设失败的话我们需要把这个事务的 状态由 1 变成 2；第三，一旦状态从1 变成 2 就执行补偿效劳。这是我们的补偿规律，就是不断地扫描这个事务所处的表，比方一秒钟扫一次事务组表，看一看这个表里面有没有状态为2 的，需要执行补偿的效劳。这个思路对业务的侵入比较小。具体看下我们实际的例子，比方二手交易平台里面创立订单事务组的正常流程，从锁库存到减红包再到创 建订单，创立事务组完毕之后开头调用业务，首先Proxy 记录锁库存调用的参数，之后开头锁库存效劳调用，成功后之后又开头减红包和创立订单过程，假设都成功了直接返回。再看一下特别的流程，前面几步都是一样的，只是在调红包效劳、Proxy 创立红包的时候假设失败了就会抛出特别，业务正常返回，聚合层Proxy 需要把事务组的状态由 1 改成 2，这个时候由左边的补偿效劳异步地补偿调用。
