こんにちは、Habr。この記事では、簡単な概念実証アプリケーションの例を使用して、Spring Cloudが提供するツールを使用してマイクロサービスアーキテクチャを実装する詳細について簡単に説明します。

コードはgithubで確認できます。画像はドックで公開され、動物園全体は1つのチームから始まります。

基礎として、私は古い忘れられたプロジェクトを取りました。そのプロジェクトのバックエンドはモノリスでした。このアプリケーションを使用すると、個人の財政を整理することができます。通常の収入と支出を行い、貯蓄を監視し、統計と予測を読み取ります。

機能サービス

モノリスをいくつかの主要なマイクロサービスに分解してみましょう。それぞれが特定のビジネスタスクを担当します。

アカウントサービス

収入、経費、貯蓄、アカウント設定を節約するためのロジックと検証を実装しています。

方法	方法	説明	ユーザーは許可されています	UIから利用可能
ゲット	/アカウント/ {アカウント}	指定されたアカウントの詳細を取得する
ゲット	/アカウント/現在	現在のアカウントの詳細を取得する	×	×
ゲット	/アカウント/デモ	デモアカウントの詳細を取得する		×
置く	/アカウント/現在	現在のアカウントデータを保存する	×	×
投稿	/アカウント/	新しいアカウントを登録する		×

統計サービス

アカウントの主要な統計パラメータを計算し、その値を基本通貨と期間に持ち込み、その後の分析に便利な形式でデータを保存します。結果の時系列を使用して、過去の時間の統計とインジケータをユーザーに表示し、将来の最も単純な予測の外挿を表示します。

方法	方法	説明	ユーザーは許可されています	UIから利用可能
ゲット	/統計/ {アカウント}	指定されたアカウントの統計を取得する
ゲット	/統計/現在	現在のアカウントの統計を取得する	×	×
ゲット	/統計/デモ	デモアカウントの統計情報を取得する		×
置く	/統計/ {アカウント}	の日付ポイントを作成/更新指定されたアカウント

通知サービス

通知設定（リマインダー頻度、バックアップ頻度）を保存します。必要に応じて、最初の2つのサービスから必要なデータを事前に収集および集約して、電子メールメッセージを送信するようにスケジュールされています。

方法	方法	説明	ユーザーは許可されています	UIから利用可能
ゲット	/通知/設定/現在	通知設定を取得する現在のアカウント用	×	×
置く	/通知/設定/現在	通知設定を保存する現在のアカウント用	×	×

注釈

すべてのマイクロサービスには独自のデータベースがあるため、すべてのデータアクセスはアプリケーションAPIを介してのみ取得できます。
このプロジェクトでは、簡単にするために、MongoDBのみを各サービスのメインデータベースとして使用しました。実際には、 Polyglotパーシステンスと呼ばれるアプローチが役立つ場合があります-特定のサービスのタスクに最適なストレージを選択します。
サービス間の通信も大幅に簡素化されます。同期の残りの要求のみが使用されます。一般的な方法は、さまざまな対話方法を組み合わせることです。たとえば、情報の同期GET要求と、作成/更新操作にキューサーバーを使用する非同期要求。ちなみに、これは結果整合性の世界に私たちを連れて行きます-私たちが一緒に暮らさなければならない分散システムの重要な側面の1つ。

インフラサービス

上記のサービスのコラボレーションを確保するために、Microserviceアーキテクチャの一連の基本パターンとプラクティスを使用します。それらの多くは、 Spring Cloudに実装されています（特に、 Netflix OSS製品との統合により）-実際、これらはSpring Bootの機能を何らかの方向に拡張する依存関係です。各コンポーネントについて以下に簡単に説明します。

構成サーバー

Spring Cloud Configは、分散システム向けの水平方向にスケーラブルな構成リポジトリです。データソースとして、Git、Subversion、およびローカルに保存されたシンプルなファイルが現在サポートされています。デフォルトでは、Spring Cloud Configは、Spring要求アプリケーションの名前に対応するファイルを提供します（ただし、バージョン管理システムの特定のブランチから特定のSpringプロファイルのファイルを選択できます）。

実際には、バージョン管理システムから構成をロードすることが最も重要ですが、ここでは簡単にするためにローカルファイルを使用します。 shared

ディレクトリをアプリケーションクラスに配置します。このクラスには、クラスター内のすべてのアプリケーションの構成ファイルが格納されます。たとえば、通知サービスが構成を要求する場合、構成サーバーはshared/application.yml

（すべてに共通）で染色されたshared/notification-service.yml

ファイルの内容でそれに応答します。

クライアント側では、アプリケーション名と構成サーバーのアドレスを持つbootstrap.yml

を除き、構成ファイルは不要になりました。

 spring: application: name: notification-service cloud: config: uri: http://config:8888 fail-fast: true

Spring Cloud Configを使用すると、構成を動的に変更できます。たとえば、 @RefreshScope

アノテーションでマークされたEmailService Beanは、再構築せずに電子メールメッセージの変更されたテキストの送信を開始できます。

これを行うには、構成サーバー構成ファイルに変更を加えてから、 Notification service

に対して次のリクエストを実行します。

 `curl -H "Authorization: Bearer #token#" -XPOST http://127.0.0.1:8000/notifications/refresh`

Github、Gitlub、またはBitbucketからWebhookをセットアップすることにより、バージョン管理システムからの構成ダウンロードを使用して、このプロセスを自動化できます。

注釈

残念ながら、動的な構成の更新には大きな制限があります。 @RefreshScope

アノテーションが付けられた@Configuration

クラスおよびメソッドに対して@RefreshScope

が機能しない
bootstrap.yml

記載されているfail-fast

プロパティは、Config Serverへの接続がない場合、アプリケーションがすぐにロードを停止することを意味します。これは、インフラストラクチャ全体を開始する際に役立ちます。
高度なセキュリティ設定は、この概念に耐えるアプリケーションの範囲を超えています。 Spring Securityは、セキュリティメカニズムを実装する十分な機会を提供します。 JCEキーストアを使用して構成ファイル内のマイクロサービスパスワードと情報を暗号化する方法については、ドキュメントで詳しく説明しています。

認証サーバー

承認義務は、バックエンドリソースにアクセスするためのOAuth2トークンを発行する別のアプリケーションに完全に転送されます。認証サーバーは、ユーザー認証と境界内の安全な通信サービスサービスの両方に使用されます。

実際、ここでは可能なアプローチの1つのみを説明しています。 Spring CloudとSpring Securityを使用すると、ニーズに合わせて構成を柔軟に構成できます（たとえば、ゲートウェイAPIの側で承認し、インフラストラクチャに既に入力されているユーザーデータで要求を転送するのが理にかなっています）。

このプロジェクトでは、 Password credential

付与タイプを使用してユーザーを認証し、 Client credentials

付与タイプを使用してサービス間で認証します。

Spring Cloud Securityは便利な注釈と自動構成を提供するため、クライアント側と認可サーバー側の両方で説明された機能を簡単に実装できます。

クライアント側では、これは従来のセッション認証と変わりません。リクエストから、 Principal

オブジェクトを取得し、 @PreAuthorize

アノテーションを使用してロールやその他のパラメーターを確認できます。

さらに、各OAuth2アプリケーションにはscope

がありscope

。バックエンドサービス- server

、ブラウザ-ui。そのため、外部から一部のエンドポイントへのアクセスを制限できます。

 @PreAuthorize("#oauth2.hasScope('server')") @RequestMapping(value = "accounts/{name}", method = RequestMethod.GET) public List<DataPoint> getStatisticsByAccountName(@PathVariable String name) { return statisticsService.findByAccountName(name); }

API Gateway

上記で説明した3つの主要なサービスはすべて、外部ユーザーにAPIを提供します。 Microserviceアーキテクチャ上に構築された産業システムでは、コンポーネントの数が急速に増加しています- 彼らは、Amazonでは約150のサービスがページレンダリングに関与していると言っています。

仮想的に、クライアントアプリケーションは各サービスを個別に要求できます。しかし、このアプローチにはすぐに多くの制限があります。各エンドポイントのアドレスを知る必要があり、各情報を個別に要求し、結果を個別にマージします。さらに、すべての非バックエンドアプリケーションがWeb対応プロトコルなどをサポートできるわけではありません。

この種の問題を解決するために、単一のエントリポイントであるAPI Gatewayが使用されます。外部要求を受信し、内部インフラストラクチャの必要なサービスにルーティングし、静的コンテンツ、認証、ストレステスト、カナリア展開、サービス移行、動的トラフィック管理を返すために使用されます。 Netflixには、さまざまなマイクロサービスからのコンテンツの非同期集約によるAPIの最適化に関するブログ投稿があります。

Netflixは、API Gateway- Zuulの実装を補償しました。 Spring Cloudはネイティブに統合されており、Spring Bootアプリケーションに1つの依存関係と@EnableZuulProxy

アノテーションを追加することで有効になります。このプロジェクトでは、Zuulが最も基本的なタスク（静的（Webアプリケーション）を返し、リクエストをルーティングする）に使用されます。

通知サービスのプレフィックスルーティングの例：

 zuul: routes: notification-service: path: /notifications/** serviceId: notification-service stripPrefix: false

これで、uriが/notifications

始まるすべてのリクエストが、対応するサービスに送信されます。

サービス発見

分散システムの別の広く知られているパターン。サービス検出により、使用可能なアプリケーションインスタンスのネットワークアドレスを自動的に決定できます。これは、スケーリング、クラッシュ、更新により動的に変化する可能性があります。

ここでの主要なリンクはレジストリサービスです。このプロジェクトでは、Netflix Eurekaを使用します（ただし、Consul、Zookeeper、Etcdなどもあります）。 Eurekaは、クライアント側の検出パターンの例です。つまり、クライアントは、使用可能なインスタンスのアドレスを要求し、それらを個別にバランスさせる必要があります。

Spring Bootアプリケーションをレジストリサーバーにするには、 spring-cloud-starter-eureka-server

と@EnableEurekaServer

アノテーションへの依存関係を追加するだけです。クライアント側で、 spring-cloud-starter-eureka

、 @EnableDiscoveryClient

アノテーション@EnableDiscoveryClient

およびbootstrap.yml

アプリケーション名（serviceId）：

 spring: application: name: notification-service

これで、起動時のアプリケーションインスタンスがEurekaに登録され、メタデータ（ホスト、ポートなど）が提供されます。 Eurekaはハートビートメッセージを受信し、設定された時間内にメッセージが存在しない場合、インスタンスはレジストリから削除されます。さらに、Eurekaは、登録されたアプリケーションとインスタンスの数およびその他の技術情報を表示するダッシュボードを提供しますhttp://localhost:8761

クライアントバランサー、ヒューズ、およびHTTPクライアント

次のツールキットもNetflixで開発され、Spring Cloudにネイティブに統合されています。それらはすべて連携して動作し、外部の世界または内部のインフラストラクチャと通信する必要があるマイクロサービスで使用されます。

リボン

リボンはクライアント側のバランサーです。従来のものと比較すると、ここでは要求は目的のアドレスに直接送信されるため、呼び出し中に余分なノードが削除されます。すぐに使用できるインスタンスは、サービスディスカバリメカニズムと統合されており、利用可能なインスタンスの動的なリストを提供して、インスタンス間のバランスを取ります。

ヒステリック

Hystrixは、サーキットブレーカーパターンの実装であり、ネットワーク経由で通話を行う際の遅延とエラーを制御するヒューズです。基本的な考え方は、多数のコンポーネントで構成される分散システムでのカスケード障害を停止することです。これにより、ハングしたサービスを要求する（回復させる）際に遅延することなく、できるだけ早くエラーを与えることができます。

開回路の制御に加えて、Hystrixでは、失敗した呼び出しが行われたときに呼び出されるフォールバックメソッドを定義できます。したがって、デフォルトの回答、エラーメッセージなどを指定できます。

Hystrixは、クエリごとに一連のメトリック（速度、結果など）を生成します。これにより、システムの全体的な状態を分析できます。以下では、これらのメトリックに基づいた監視を検討します。

偽物

Feignは、リボンおよびHystrixとネイティブに統合されたシンプルで柔軟なhttpクライアントです。簡単に言えばspring-cloud-starter-feign

持ち、 @EnableFeignClients

アノテーションでクライアントをアクティブ化すると、バランサー、ヒューズ、クライアントの完全なセットが得られ、妥当なデフォルト構成での戦いの準備が整います。

アカウントサービスの例を次に示します。

 @FeignClient(name = "statistics-service") public interface StatisticsServiceClient { @RequestMapping(method = RequestMethod.PUT, value = "/statistics/{accountName}", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE) void updateStatistics(@PathVariable("accountName") String accountName, Account account); }

あなたがする必要があるのはインターフェイスを宣言することだけです
通常どおり、サービスの名前を指定するだけです（Service Discoveryメカニズムのおかげです）が、もちろん任意のURLにアクセスすることもできます
@RequestMapping

とコンテンツは、Spring MVCの@FeignClient

と@Controller

に統一されたままにすることができます。

ダッシュボード

Hystrixによって生成されたメトリックは、クラスにspring-boot-starter-actuator

依存関係を含めることで提供できます。他の興味深いものの中で、特別なエンドポイントが公開されます- /hystrix.stream

。このストリームは、Hystrixダッシュボードを使用して視覚化できます。これについては、後で詳しく説明します。 Hystrixダッシュボードを有効にするには、 spring-cloud-starter-hystrix-dashboard

@EnableHystrixDashboard

と@EnableHystrixDashboard

アノテーションが必要です。 Hystrixダッシュボードを任意のマイクロサービスのストリームに対して設定して、この特定のサービスで発生していることのライブ画像を観察できます。

ただし、この場合、いくつかのサービスがあり、それらのすべてのメトリックを1か所で確認できると便利です。これには特別な解決策があります。各サービスはそのストリームをAMQPブローカー（RabbitMQ）にプッシュし、そこからストリームアグリゲーターのTurbineが変換して、Hystrixダッシュボードの単一のエンドポイントを公開します。

負荷時のシステムの動作を考慮してください。アカウントサービスは統計サービスを呼び出し、さまざまなシミュレーション遅延で応答します。要求時間のしきい値は1秒に設定されます。


`0`	`500`	`800`	`1100`
システムはエラーなしで動作します。スループットは約22秒/秒です。統計サービスの少数のアクティブスレッド。平均応答時間- 50ミリ秒	アクティブなスレッドの数は増加しています。紫色の数字は拒否されたリクエストの数を示し、それぞれエラーの約30〜40％ですが、回線はまだ閉じています。	半開状態：エラーの割合が50％を超えると、ヒューズが回路を開きます。一定のタイムアウト後、回線は閉じられますが、再び短くなります。	エラーのあるリクエストの100％。回線は常に開いており、タイムアウト後にリクエストをスキップしようとしても何も変更されません。個々のリクエストは遅すぎます。

ログ分析

多数の可動部分（それぞれが複数のコピーを持つことができる）で構成されるインフラストラクチャでは、ログの集中収集、処理、分析のシステムを使用することが非常に重要です。 Elasticsearch、Logstash、およびKibanaは、このような問題を効果的に解決できるスタックを構成します。

出荷準備が整ったELK Docker設定は、キュレーターと配送業者用のテンプレートとともにgithubで利用できます。ログ、ネットワークアクティビティの分析、およびサーバーパフォーマンスの監視のために、現在のプロジェクトで本番環境で正常に機能するのは、わずかなカスタマイズとスケーリングを備えたこの構成です。

単なる例として、Elasticの公式Webサイトからの写真

インフラストラクチャの自動化

多数の可動部分と相互接続性を備えたマイクロサービスシステムの展開は、モノリシックアプリケーションの展開よりも明らかに複雑なタスクです。自動化されたインフラストラクチャがなければ、ストーリー全体が無限の痛みと時間の無駄に変わります。これは完全に独立した会話のトピックです。無料バージョンのサービスでこのプロジェクトに実装されている最も単純な継続的配信ワークフローのみを示します。

最後の段階は比fig的であり、プロジェクトの生産は想定されていません。

リポジトリのルートには、CIサーバーの指示を含む.travis.ymlファイルがあります-ビルドが成功した後の処理。この構成では、Githubでのプッシュが成功するたびに、Travis CIがdockerイメージを収集してタグ付けし、Docker Hubにプッシュします。これで、 latest

タグでマークされた展開の準備ができたコンテナと、古いバージョン、任意のブランチのバージョンのコンテナが常にあることがわかりました。

打ち上げ

この場所まで読んだことがあるなら、自分ですべてを始めるのは面白いかもしれません。インフラストラクチャは、8つのSpring Bootアプリケーション、4つのMongoDBインスタンス、および1つのRabbitMQで構成されています。システムで3〜4 GBのメモリが使用可能であることを確認してください。統計サービス、通知サービス、監視の放棄など、最も必要な機能に自分自身を制限することからいつでも開始できます。

始める前に

DockerおよびDocker Composeをインストールする
環境変数のエクスポート： CONFIG_SERVICE_PASSWORD

、 NOTIFICATION_SERVICE_PASSWORD

、 STATISTICS_SERVICE_PASSWORD

、 ACCOUNT_SERVICE_PASSWORD

、 MONGODB_PASSWORD

生産モード

このモードでは、事前に組み立てられたすべてのイメージが中央リポジトリ（この場合はDockerハブ）からダウンロードされ、ポートはGateway、Service Discovery、Monitoring、およびRabbitMQ管理APIのみのdockerの外部に転送されます。必要なのは、docker-composeファイルとdocker-compose up -d

です。

docker-compose.yml

 version: '2' services: rabbitmq: image: rabbitmq:3-management restart: always ports: - 15672:15672 logging: options: max-size: "10m" max-file: "10" config: environment: CONFIG_SERVICE_PASSWORD: $CONFIG_SERVICE_PASSWORD image: sqshq/piggymetrics-config restart: always logging: options: max-size: "10m" max-file: "10" registry: environment: CONFIG_SERVICE_PASSWORD: $CONFIG_SERVICE_PASSWORD image: sqshq/piggymetrics-registry restart: always ports: - 8761:8761 logging: options: max-size: "10m" max-file: "10" gateway: environment: CONFIG_SERVICE_PASSWORD: $CONFIG_SERVICE_PASSWORD image: sqshq/piggymetrics-gateway restart: always ports: - 80:4000 logging: options: max-size: "10m" max-file: "10" auth-service: environment: CONFIG_SERVICE_PASSWORD: $CONFIG_SERVICE_PASSWORD NOTIFICATION_SERVICE_PASSWORD: $NOTIFICATION_SERVICE_PASSWORD STATISTICS_SERVICE_PASSWORD: $STATISTICS_SERVICE_PASSWORD ACCOUNT_SERVICE_PASSWORD: $ACCOUNT_SERVICE_PASSWORD MONGODB_PASSWORD: $MONGODB_PASSWORD image: sqshq/piggymetrics-auth-service restart: always logging: options: max-size: "10m" max-file: "10" auth-mongodb: environment: MONGODB_PASSWORD: $MONGODB_PASSWORD image: sqshq/piggymetrics-mongodb restart: always logging: options: max-size: "10m" max-file: "10" account-service: environment: CONFIG_SERVICE_PASSWORD: $CONFIG_SERVICE_PASSWORD ACCOUNT_SERVICE_PASSWORD: $ACCOUNT_SERVICE_PASSWORD MONGODB_PASSWORD: $MONGODB_PASSWORD image: sqshq/piggymetrics-account-service restart: always logging: options: max-size: "10m" max-file: "10" account-mongodb: environment: INIT_DUMP: account-service-dump.js MONGODB_PASSWORD: $MONGODB_PASSWORD image: sqshq/piggymetrics-mongodb restart: always logging: options: max-size: "10m" max-file: "10" statistics-service: environment: CONFIG_SERVICE_PASSWORD: $CONFIG_SERVICE_PASSWORD MONGODB_PASSWORD: $MONGODB_PASSWORD STATISTICS_SERVICE_PASSWORD: $STATISTICS_SERVICE_PASSWORD image: sqshq/piggymetrics-statistics-service restart: always logging: options: max-size: "10m" max-file: "10" statistics-mongodb: environment: MONGODB_PASSWORD: $MONGODB_PASSWORD image: sqshq/piggymetrics-mongodb restart: always logging: options: max-size: "10m" max-file: "10" notification-service: environment: CONFIG_SERVICE_PASSWORD: $CONFIG_SERVICE_PASSWORD MONGODB_PASSWORD: $MONGODB_PASSWORD NOTIFICATION_SERVICE_PASSWORD: $NOTIFICATION_SERVICE_PASSWORD image: sqshq/piggymetrics-notification-service restart: always logging: options: max-size: "10m" max-file: "10" notification-mongodb: image: sqshq/piggymetrics-mongodb restart: always environment: MONGODB_PASSWORD: $MONGODB_PASSWORD logging: options: max-size: "10m" max-file: "10" monitoring: environment: CONFIG_SERVICE_PASSWORD: $CONFIG_SERVICE_PASSWORD image: sqshq/piggymetrics-monitoring restart: always ports: - 9000:8080 - 8989:8989 logging: options: max-size: "10m" max-file: "10"

開発モード

開発モードでは、リポジトリからイメージを取得するのではなく、イメージをビルドすることになっています。すべてのコンテナは、便利なデバッグのために外向きになっています。この構成は上記を継承し、これらのポイントを上書きおよび拡張します。コマンドdocker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

docker-compose.dev.yml

 version: '2' services: rabbitmq: ports: - 5672:5672 config: build: config ports: - 8888:8888 registry: build: registry gateway: build: gateway auth-service: build: auth-service ports: - 5000:5000 auth-mongodb: build: mongodb ports: - 25000:27017 account-service: build: account-service ports: - 6000:6000 account-mongodb: build: mongodb ports: - 26000:27017 statistics-service: build: statistics-service ports: - 7000:7000 statistics-mongodb: build: mongodb ports: - 27000:27017 notification-service: build: notification-service ports: - 8000:8000 notification-mongodb: build: mongodb ports: - 28000:27017 monitoring: build: monitoring

注釈

このプロジェクトのすべてのSpring Bootアプリケーションを起動するには、アクセス可能な構成サーバーが必要です。各アプリケーションのbootstrap.yml

fail-fast

オプションと、Dockerのrestart：alwaysオプションのおかげで、コンテナは同時に起動できます（これらは、Config Serverが起動するまで自動的に試行を開始します）。

また、サービスディスカバリを開始するには時間がかかります。このサービスは、彼自身、ユーレカとクライアントがローカルに同じメタ情報を持たない限り、呼び出しに利用できません。これには3つのハートビットが必要です。ハートビート間のデフォルトの期間は30秒です。

マイクロサービスアーキテクチャ、Spring CloudおよびDocker