オリジナルリンクします。https：//mp.weixin.qq.com/s/oI3Py2PZY31mA5iOOOd73g
日ユンCCTC2017総会の演説からこの論文。
誰もがマイクロサービスアーキテクチャを言及し、マイクロサービスアーキテクチャ最後にされて何ですか？その機能とデザインパターンとは何ですか？我々は、これらのデザインパターンは、実際の戦闘で使用する方法、マイクロサービスアーキテクチャ・プロセスを作成しますか？どのようにデータの整合性を確保する必要がありますか？今日、私は考えてこれらの質問に対する私の回答を共有することになります。
マイクロサービスアーキテクチャの特長
マイクロサービスアーキテクチャとは何ですか？英語は、2014年にMartin Fowler氏によって提案され、このチャートを見て、マイクロサービスのアーキテクチャは、アーキテクチャモデルであることから、それは必然的に機能のいくつかを満たす必要があります、アーキテクチャ・モデルです。彼はマイクロサービスアーキテクチャを構成する小さなマイクロ一連のサービスの組み合わせであることを述べ、その後、「小さなマイクロサービス」とは何ですか？一人一人の可能性の理解は、我々はすべて、SOAのアーキテクチャは、我々は、マイクロサイズのサービスを分割すべきか最後に、比較的厚い粒度SOAアーキテクチャを知るべきで違うのですか？私は、マイクロアーキテクチャのサービス・アーキテクチャは、ビジネスのより深い理解、より多くのあなたの合理的なサービスマイクロスプリットそして、基本的なビジネスである上、だと思います。
たとえば、私たちは二次取引プラットフォーム（周り）を行い、プラットフォームは、ユーザシステム、商品システム、取引システムと検索推薦システムを含んでいます。各システムは比較的独立しているため、我々はマイクロサービスを分割するために様々なビジネスモジュールに従うことができます。お使いの製品は、多くの機能もありますが、大きなアイデアはさらに、特定の商品の内部ロジックに応じて分割することですので、もちろん、これは、行うことはありません。
第二に、特定のビジネスモデリングの周り。ビジネスシナリオからすべてがマイクロサービスアーキテクチャのいじめについて話をします。
2つの方法がありますまず、モデルは、独立した事業単位として特定の領域：商品、注文、及び他のユーザの例えば、二次取引;第二の別個のビジネス・ユニットなどのビジネスの挙動：電子メールの送信など、シングル・サインオン検証、プッシュサービス。
各マイクロサービスのプロセスが独立しているため第三に、全体のマイクロサービスは、独立して配置することができ、展開のように独立しても、各モジュールを理解することは非常に簡単です。
第四に、分散管理。何のマイクロサービスが存在しないことを分散管理の意味各モジュールを作成し、言語を開発し、関係のプラットフォームを実行するには、開発言語はC ++することができ、行くことが、世界最高の言語であってもよいし、プラットフォームを実行すると、Linuxでは、UnixのですWindowsとそうすることができます。
最後のポイントは、コミュニケーションと言語モジュールは、プラットフォームが重要ではありません理解することは非常に簡単です、軽量な通信です。限りこの事なので、クロスプラットフォーム、クロス言語の実装を行うには、軽量通信の可能な選択として、それは簡単であるとき。
これらの特性を終え、我々はどの要素によって最終的にミクロレベルのDEMO標準サービスアーキテクチャを見ることができますか？以下は、含めゲートウェイ、マイクロサービス、データストレージ、レジストリ、コンフィギュレーション・センター。
それはDEMO段階下にあり、かつので、確かにいくつかの違いは、実際の状況と比較します。だから、実際のケースでは、最終的に我々はこのことを行う必要がありますか？また、この例では、最近、私は2番目の手の取引プラットフォームをしていた - 周り。DEMOと多少異なる場所があることを。第一の層またはゲートウェイの前に、次のポリマー層のマイクロサービスの役割は、ビジネス・ロジックの処理のさまざまな操作を行うことであり、ポリマー層は、主にデータ・アクセス・エージェントに、我々のデータ原子層の下にあるが、別垂直ビジネスに依存しますA。、ゲートウェイ、データ層、レジストリ、コンフィギュレーション・センターに持って見ることができるが、サービス処理における2つの部分に分割される：1つの原子層、全体のデータ・アクセス・プロキシ層がユーザにインターフェースを提供する、すなわち、別の上位層のサービスは、ポリマー層です。
建築デザインパターンと実践例
私はおそらく私たちの実際の例の部分はアーキテクチャ設計パターンが含まれている設定だけでなく、マイクロマイクロサービスの下でサービスの上記の特徴とDEMOレベルのいくつかについて話しました。では、なぜ私たちが行うには、このモデルを採用すべきか？このアーキテクチャモデルは何他の建築のパターンに加えて？チェーンのデザインパターン、デザインパターンと集約非同期共有モード：ここでは、パターンは非常にまだある、私はこれらの点のいくつかを紹介します。
まず、私たちはこのモードでは、連鎖モードのために設計し、APPのフロントエンド要求は、2つの連続通話マイクロサービス、サービス後であっても2トーンのマイクロサービスマイクロチューンが続き、ゲートウェイ層を通過する最初のものです。なぜそれがチェーンと呼ばれていますか？コールは最初のマイクロ-1サービスの後に来たので、その後、2はマイクロサービス1にフィードバックされるマイクロサービスを処理した後、マイクロ、マイクロサービス2は、いくつかの処理を行います同期サービス2に呼び出し、再びゲートウェイに、そして最終的には1マイクロサービスバックAPPへ。実際のビジネス・シナリオでは、ビジネスシナリオの取引と注文への関連は、このモードで使用されます。
接下来是聚合器设计模式，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开发人员如何解决服务冲突和实例乱窜？
扫码关注有惊喜！
