マイクロサービスにもデザインパターンがあるはずだと，この辺りを参考にまとめてみる．

• Pattern: Microservices Architecture
• Building Microservices, Sam Newman
• Microservices: Patterns and Applications, Lucas Krause

Circuit Breaker

• 分散されたサービスの呼び出しにおいて，提供サービスがfailしているに関わらず，サービス呼び出し側が，呼び出しを続けると計算リソースの枯竭を招き，システム全体の性能低下を招く．サービスと呼び出し側コードの間にCircuit Breakerを置くことで，failしたサービスへのコネクションを抑制し，サービスが復旧した際の迅速な全体回復を行う．

Bulkhead

• システム障害を局所化するために，同じシステムを複数用意し，それぞれを障壁を用いて孤立化しておく．障壁とは，データセンター単位，VM単位，コンテナ単位などが考えられる．

API Gateway / Orchestrated API

• サービス利用者にとって，サービスの粒度が小さすぎる場合など，それぞれと接続するのは効率が悪いときがある．また，オーケストレイトされたサービスを呼び出したい場合には，APIを直接呼び出すのではなく，API Gatewayを介して接続する．個人的には，Gatewayを介することで，ここにモニタリングや認証の仕組みを持ち込める反面，ここが単一故障点になる気もする．また，ここが重くなると，マイクロサービスが忌み嫌うESBに向かってしまう．

Service Registry / Service Discovery

• サービス同士が直接つながるのではなく，サービスをService Registryに登録し，Service Registryを用いた発見，結合を行う．UDDI再び?

Instantiation

• サービスをどのスタックレベルでinstantiateするか．以下の様な粒度がある．

• Multiple service instances per host
• Single service instance per host
• Service instance per VM
• Service instance per Container

Polyglot Persistence

• 一つのシステムの中で)複数のデータベース (SQLやNoSQL)を用途に応じて使い分けること
• Polyglot Programmingのデータベース版
• 特定のdata consistencyメカニズムを意味するのではなく，複数のデータベース実装を使い分けるという意味で用いられているようだ

Consumer-Driven Contracts

• 通常1対多となるサービスの提供者と消費者間でのサービス契約において，消費者が，提供者のサービス全体ではなく，必要な部分のみを「期待」 (expectation)として提供者側に提示することで，提供サービスの更新への耐性を向上させ，サービスやビジネスの価値を高めることができる．

Tolerant Reader

• サービスを疎結合しても，サービス間の通信はなくならない．コードの更新に対して耐性を持ったデータ読み込みのパターン
• “送信するものに関しては厳密に、受信するものに関しては寛容に.”　by Jon Postel