編集者注| nginxの公式ブログからの記事では、第五の記事、「クリス・リチャードソンマイクロサービス」シリーズです。最初の記事は、マイクロサービスアーキテクチャモデルを説明し、そしてマイクロサービスを使用することの利点と欠点について説明し、モジュール間通信マイクロサービスアーキテクチャのさまざまな側面を説明する第二及び第三の、パートIVは、サービス発見の問題を研究します。Benpian研究マイクロサービスアーキテクチャは、分散データ管理の問題を提供します。
著者：クリス・リチャードソンは、書籍、世界有数のソフトウェアの第一人者、芸術の古典的な作品の作者「のPOJOでのアクション」ですが、また、などcloudfoundry.comオリジナルの創設者、クリス・リチャードソンとMartin Fowler氏、サム・ニューマン、エイドリアンコッククロフト、と呼ばれます世界のトップ10ソフトウェアアーキテクト。
クリス・リチャードソンシリーズ全体のマイクロサービス7：
2. マイクロ・サービス・アーキテクチャの構築：APIゲートウェイの使用
3. インター深マイクロサービスアーキテクチャプロセス間通信（この記事）
5.イベント駆動型マイクロデータ管理サービス
マイクロサービスと分散データ管理の問題
モノマーアプリケーションは通常、利益を結果するアプリケーションは、重要な動作特性を提供する、ACIDトランザクションを使用することができるということである、単一のリレーショナルデータベースを使用します。
- 微粒化：原子サイズの変更
- 一貫性：状態データベースは常に一貫しています
- アイソレーション：同時実行トランザクションはシリアル実行と表示
- 持続性：あなたが提出した後、トランザクションが取り消されることはありません
したがって、アプリケーションは、単純に複数の行をトランザクション、変更（挿入、更新、削除）を開始し、トランザクションをコミットすることができます。
リレーショナルデータベースを使用してのもう一つの利点は、SQLをサポートしていることです。SQLは、豊かな宣言型と標準化されたクエリの予定です。ユーザに問い合わせることによって缶容易RDBMSクエリスケジューラ次いで合わせたデータテーブルの複数のクエリを実行する最良の方法を決定します。ユーザーは、このようなデータベースにアクセスする方法として、基本的な詳細は、ありません。また、データベース内のすべてのアプリケーションデータので、クエリに簡単です。
しかし、ミクロデータサービスアーキテクチャへのアクセスが多く複雑になります。各サービスは、そのAPIを介してのみアクセスでき、特にマイクロサービスのためのミクロデータを、持っています。マイクロカプセル化されたデータは、緩やかにサービスを結合し、かつ独立して更新することができることをこれが保証されます。同じデータにアクセスするための複数のサービス場合は、スキーマの更新は時間がかかることが、また、すべてのサービスの更新を調整する必要があります。
さらに悪いことに、異なるマイクロサービスは、通常のデータベースの種類を使用します。ストレージと近代的なアプリケーションの各種データ、およびリレーショナルデータベースの処理は、常に良い選択ではありません。いくつかの使用シナリオでは、特定のデータベースには、より便利なのNoSQLデータモデル、優れたパフォーマンスとスケーラビリティを提供することができます。たとえば、このサービスは、ストアとクエリテキストにElasticsearchテキスト検索エンジンを使用して、同様に、ソーシャルグラフのデータ・ストレージ・サービスは、このようなAの地図データベースのNeo4jの使用を必要とするかもしれません。したがって、マイクロベースのサービスのアプリケーションは、多くの場合、多言語（ポリグロットの永続的なアプローチ）を保持SQLとNoSQLのデータベースを、混ぜます。
パーティションは、データ・ストレージのための多言語の保持アーキテクチャは、疎結合のサービス、優れたパフォーマンスとスケーラビリティなど、多くの利点があります。しかし、それはまた、分散データ管理の課題に忠実です。
最初の課題は、サービスの一貫性品種をビジネスロジックを実装する方法です。これが問題である理由、たとえば、オンラインB2Bストアを説明するために。カスタマーサービス（顧客サービスの以下使用）、クレジット情報など、ユーザーに関する情報を、維持するために。注文サービス（以下、利用順サービス）の受注を管理し、新しい秩序がユーザの与信限度を超えていないことを確認してください。単一のアプリケーションでは、サービスは、単に信用情報を確認し、ACIDトランザクションを使用してオーダーを作成するために注文することができます。
対照的に、注文テーブルと各顧客のプライベート・サービスに対応したテーブル、以下に示すように、マイクロサービスアーキテクチャです。
ご注文は、顧客テーブルに直接サービスにアクセスすることはできません、APIは、顧客サービスによって提供することができます。サブスクリプションサービスは、2相として知られている分散トランザクション、コミット（2PC）を使用する場合があります。しかし、2PCは、一般的に最新のアプリケーションのための実行可能な選択肢ではありません。CAP定理が第二の選挙でのスタイルと使いやすさのユーザーACIDの一貫性を必要とし、使い勝手は通常より良い選択です。また、このようなほとんどのNoSQLデータベースとして、多くの近代的な技術は、2PCをサポートしていません。サービス全体でデータの一貫性を維持し、データベースは非常に重要ですので、我々は別のソリューションが必要です。
第二の課題は、複数のサービスのデータを照会する方法です。アプリケーションは、顧客と彼の最も最近の順序を表示する必要があることを前提としています。注文サービスは、顧客の注文を取得するためのAPIを提供している場合は、データを取得するためにアプリケーション側を使用することができます。顧客サービスを介したアプリケーションは、顧客の注文を取得するためのサービスを通じて、顧客を取得します。注文サービスのみ（キー検索のNoSQLデータベースをサポートするだけで使用できます）主キー、クエリの注文の受注によってサポートされている場合しかし、この場合には、必要なデータを取得するためのいかなる適切な方法はありません。
イベント駆動型アーキテクチャ
多くのアプリケーションでは、解決策は、イベント駆動型アーキテクチャです。このフレームワーク、重要なイベントは、このような更新事業体、マイクロサービスポストイベントとして、発生した時点では、他のサービスは、マイクロは、これらのイベントをサブスクライブしています。サービスが受信すると、マイクロイベントがリリースされるより多くのイベントを達成するために彼らのビジネスエンティティを更新することができます。
ユーザーが複数のサービス間でのビジネス・ロジックを実装するためにイベントを使用することができます。トランザクションは、次のトリガ・イベントを発表し、その後、一連のステップで構成され、各ステップは、マイクロ更新サービスのビジネスエンティティを持っています。次の図は、オーダーを作成する際に利用可能なクレジットチェックを使用する方法のイベントドリブン方式のシリーズを示しています。マイクロサービスは、プロキシのイベントを介してメッセージを交換します。
- オーダサービスが状態NEWオーダーを作成して発行するイベントを「注文が作成しました」。
- 客户服务获取“订单已创建”事件，为此订单保留信用，发布“信用保留”事件。
- 订单服务获取“信用保留”事件，把订单状态修改为 OPEN。
更为复杂的场景可能涉及更多的步骤，比如在核对客户信用的同时预留库存。
基于（a）每个服务自动更新数据库和发布事件，以及（b）消息代理确保事件传递至少一次，用户能够跨多个服务完成业务逻辑。注意它们并非 ACID 业务。这种模式提供弱确定性，比如最终一致性。这种事务模型也被称作 BASE 模型。
用户也可以使用事件来维护不同微服务拥有的预连接数据的物化视图。维护此视图的服务订阅相关事件，并更新视图。例如，维护客户订单视图的客户订单视图更新服务会订阅由客户服务和订单服务发布的事件。
当客户订单查看更新服务收到客户或者订单事件，就会更新客户订单查看的数据存储。用户能够使用类似 MongoDB 的文档数据库查看用户订单，并为每位客户存储一个文档。用户订单预览查询服务通过客户订单预览数据存储，处理来自客户和最近订单的请求。
事件驱动的架构有优点也有缺点。它使得事务跨多个服务并提供最终一致性，也可以让应用维护物化视图。缺点之一在于，它的编程模型要比使用 ACID 事务的更加复杂。为了从应用级别的失效中恢复，还需要完成补偿性事务，例如，如果信用检查不成功则必须取消订单。此外，由于临时事务造成的改变显而易见，因而应用必须处理不一致的数据。此外，如果应用从物化视图中读取的数据没有更新时，也会遇到不一致的问题。此架构的另一缺点就是用户必须检测并忽略重复事件。
实现原子化
事件驱动的架构还存在以原子粒度更新数据库并发布事件的问题。例如，订单服务必须在订单表中插入一行，然后发布“订单已创建”事件。这两个操作需要原子化实现。如果服务在更新数据库之后、发布事件之前崩溃，系统变得不一致。确保原子化的标准做法是使用包含数据库和消息代理的分布式事务。然而，基于以上描述的 CAP 理论，这并非我们所想。
使用本地事务发布事件
实现原子化的方法是使用多步骤进程来发布事件，该进程只包含本地事务。诀窍就是在存储业务实体状态的数据库中，有一个事件表来充当消息队列。应用启动一个（本地）数据库事务，更新业务实体的状态，在事件表中插入一个事件，并提交该事务。独立的应用线程或进程查询事件表，将事件发不到消息代理，然后使用本地事务标注事件并发布。下图展示了这一设计。
订单服务在订单表中插入一行，然后在事件表中插入“订单已创建”的事件。时间发布线程或进程在事件表中查询未发布的事件并发布，然后更新事件表，将该事件标记为已发布。
这种方法优缺点兼具。优点之一是保证每个更新都有对应的事件发布，并且无需依赖 2PC。此外，应用发布业务级别的事件，消除了推断事件的需要。这种方法也有缺点。由于开发者必须牢记发布事件，因此有很大可能出错。此外这一方法对于某些使用 NoSQL 数据库的应用是个挑战，因为 NoSQL 本身交易和查询能力有限。
通过此方法，应用使用本地事务来更新状态和发布事件，排除了对 2PC 的需要。接下来，我们了解使用应用更新状态实现原子化的方法。
挖掘数据库事务日志
无需 2PC 实现原子化的另一种方式是由线程或者进程通过挖掘数据库事务或提交日志来发布事件。应用更新数据库，数据库的事务日志记录这些变更。事务日志挖掘线程或进程读取这些日志，并把事件发布到消息代理。如下图所示：
这一方法的范例是开源的 LinkedIn Databus 项目。Databus 挖掘 Oracle 事务日志并发布与之对应的事件。LinkedIn 使用 Databus 维持各种来源的数据存储与记录系统一致。
另一个范例则是 AWS DynamoDB 采用的流机制，AWS DynamoDB 是一个可管理的 NoSQL 数据库。每个 DynamoDB 流包括 DynamoDB 表在过去 24 小时之内的时序变化，包括创建、更新和删除操作。应用能够读取这些变更，将其作为事件发布。
事务日志挖掘具有多个优点。首先，它能保证无需使用 2PC 就能针对每个更新发布事件。其次，通过将日志发布于应用的业务逻辑分离，事务日志挖掘能够简化应用。事务日志挖掘也有缺点，主要缺点就是事务日志的格式与每个数据库对应，甚至随着数据库版本而变化。此外，很难从底层事务日志更新记录中逆向工程这些业务事件。
通过让应用更新数据库，事务日志挖掘消除了对 2PC 的需要。接下来我们会讨论另一种方法——消除更新，只依赖事件。
使用事件源
通过采用一种截然不同的、以事件为中心的方法来留存业务实体，事件源无需 2PC 实现了原子化。不同于存储实体的当前状态，应用存储状态改变的事件序列。应用通过重播事件来重构实体的当前状态。每当业务实体的状态改变，新事件就被附加到事件列表。鉴于保存事件是一个单一的操作，本质上也是原子化的。
要了解事件源如何运行，可以以订单实体为例。在传统的方法中，每个订单映射为订单表的一行，例如一个 ORDERLINEITEM 表。使用事件源的时候，订单服务以状态更改事件的方式存储订单，包括已创建、已批准、已发货、已取消等。每个事件都包含足够的数据去重建订单状态。
事件长期保存在事件数据库，使用 API 添加和检索实体的事件。事件存储类似上文提及的消息代理，通过 API 让服务订阅事件，将所有事件传达到所有感兴趣的订阅者。事件存储是事件驱动的微服务架构的支柱。
事件源有不少优点。它解决了实施事件驱动的微服务架构时的一个关键问题，能够只要状态改变就可靠地发布事件。另外，它也解决了微服务架构中的数据一致性问题。由于储存事件而不是域对象，它也避免了对象关系抗阻不匹配的问题（object‑relational impedance mismatch problem）。事件源提供了 100% 可靠的业务实体变化的审计日志，使得获取任何时间点的实体状态成为可能。事件源的另一大优势在于业务逻辑由松耦合的、事件交换的业务实体构成，便于从单体应用向微服务架构迁移。
イベントソースの欠点。プログラミングの異なるまたは不慣れなスタイルの結果、学習曲線があるでしょう。イベントストアに直接ビジネスエンティティによってサポートされている唯一の主キーのクエリは、あなたはまた、クエリを完了するために、コマンドクエリの責任分掌（CQRS）を使用する必要があります。したがって、アプリケーションは、最終的には一貫性のあるデータを扱わなければなりません。
概要
マイクロサービスアーキテクチャでは、各サービスは、独自のプライベートミクロデータストレージを持つ、異なるマイクロサービスが異なるSQLとNoSQLのデータベースを使用することができます。データベーススキーマは、利便性をもたらすだけでなく、分散データ管理の課題をもたらしました。最初の課題は、より一貫性のあるサービスを業務執行を実現する方法です。第二の課題は、問い合わせを達成するために、複数のサービスからデータを取得する方法です。
多くのアプリケーションでは、解決策は、イベント駆動型アーキテクチャを使用することです。イベント駆動型アーキテクチャの課題は、アトミック更新を持参し、イベント状態を発行する方法です。メッセージキュー、トランザクションログ、鉱業、イベント・ソースとして使用するデータベースを含め、これを行うには、いくつかの方法があります。
記事からの転載：http://blog.daocloud.io/microservices-5/