REVIEW： 「マイクロ・サービスの設計」可読性からカメオ専門書は、乾燥品の実際の技術的な側面が非常に優れている、とさえ読み取り後を思い出させているように、古典的な「UNIXプログラミングのアート」「コンピュータシステムの深い理解」良い本の感じ。ここでは、より多くの知識をタップし、本を読むことができることを非常に多くの希望が、私はいくつかの一般的な読書ノート何をすべきかです。
マイクロサービスが何であるかをまず、：小さなと自律性は、いくつかの作業サービスです。
- 小さなフォーカス一つのことを行う上では：境界に基づいて、ビジネス・サービスの境界を決定します。
- オートノミーは：マイクロサービスは、別々の実体です。私たちは、密結合を避けるため、それによって、サービス間のアイソレーションを高め、呼び出しサービス間のネットワークを介して通信しています。これらのサービスは、互いに独立して修正しなければならない、とサービスの展開は、サービス消費者の変化が発生することはありません。
第二に、マイクロサービスの主な利点
- 技術的な異質性：スタックは異なる技術、言語、データベースまたはフレームを使用してもよいです。
- 伸縮性：重要な概念は、弾性エンジニアリングバルクヘッドです。コンポーネントがシステムで使用できませんが、障害をカスケード接続させない場合は、システムの残りの部分は正常に機能し続けます。
- 拡張：小さな複数のサービス、あなただけのそれはやや少ないハードウェアのパフォーマンスに、小さなで実行する必要はありません人々にサービスを展開することができるように拡張するためにサービスを拡大する必要があるかもしれません。
- 簡素化の展開：マイクロサービスアーキテクチャ、各サービスの展開は、あなたがより迅速にコードの特定の部分を展開できるように、独立しています。
- 組織構造に一致する：マイクロサービスアーキテクチャがよく理想的なチームの大きさと生産性を得るために、過剰なコードベースを避けるために、アーキテクチャと組織構造に一致することがあります。
- 組み合わせ：異なる粒子サイズの組み合わせは、顧客のためのさまざまなサービスオブジェクト関数に基づくことができます。
第三に、マイクロサービスの原則
- ビジネスコンセプトの周りモデリング
の経験は、ビジネス・コンテキストの定義の周りインターフェースの境界は、概念の定義の周りのインターフェース技術よりも安定であることが示されています。システムはこの領域でどのように機能するかのモデルには、だけでなく、より安定した界面を形成するために、だけでなく、我々は、ビジネスプロセスの変化を反映しやすくなりますことを確認するために私たちを助けることができます。コンテキスト境界のフィールドの境界を定義するために使用することができます。 - 自動化された文化の受け入れ
複雑さの多くにマイクロサービスは、その要約の重要な部分は、私たちは多数のサービスを管理しなければならないということです。この問題を解決するための主要な方法は、オートメーション・文化を受け入れることです。初期の理にかなって、ビルドのサポートマイクロサービスツールにはいくつかのコストを費やしています。モノリシックシステムと比較して自動テストは、我々はサービスの多くは、より複雑なプロセスである仕事ができることを保証するために、必要不可欠です。各高速フィードバックの重要な一部であることにコミットした後、製品品質の継続的デリバリーの使用であり、それぞれの環境は非常に便利である実践にシステムを展開するのと同じ方法で、統一されたコマンドラインを呼び出します。
展開する統一された方法を使用する能力を維持しながら、あなたは明らかに異なる環境間の違いを定義するのに環境を使用することを検討してください。展開をスピードアップするためにカスタムイメージを作成することを検討し、完全に自動化されたサーバーの不変を作成し、それがシステム自体の容易な位置付けになります。 - 内部実装の詳細を隠す
、他のサービスのサービスの独立を作るために一人で進化の能力を最大化、実装の詳細を隠蔽することが不可欠です。それは私たちが共有する必要があるとその隠されるべきかのモデルに焦点を当てることができますので、有界コンテキストモデリングは、この点で助けることができます。サービスはまた、結合されたように、データベースに落ちないように、自分のデータベースを非表示にする、カップリングのこの種は、伝統的なサービス指向アーキテクチャーの中で最も一般的なタイプです。データ・ポンプ・データ・ポンプまたはレポートの機能を実現するために一緒に複数のサービス間でのデータを統合するイベント。
可能で、技術に依存しないAPIを選択してみてください。これは、あなたは異なるテクノロジー・スタックを使用することを選択する自由ができます。RESTを使用することを検討してください、それはRPCを使用した場合でも、あなたはまだ、これらのアイデアを使用することができ、実装の詳細を分離する内部および外部の標準的な方法になります。 - センターにすべてをしてみましょう
自律性をもたらすことができるマイクロサービスを最大化するために、我々は意思決定と制御を委任したチームに奉仕する機会を探し続けする必要があります。可能な限り、このプロセスの最初では、これらの事を行うには、人々は、ソフトウェア、開発、できるだけ単純にテストの導入を要求することを可能にするリソースのセルフサービスを使用して、別々のチームを避けるようにしてください。
このプロセスでは、チームはサービスの所有権は、理想的に、重要なステップである、あるいはチームがときに、ライン上でそれらの変更を行うことが決定できるように保つことを確認してください。内部で使用するオープンソースモデルは、人々がこのモデルを実現するために、以下のことを他のチームが持っているサービスを変更、しかし、注意してくださいできることを確保することが、多くの作業が必要です。チームや組織一貫したのでコンウェイの法則が働くことを、してみましょう、と助けチームは、彼らがそのビルド事業分野の専門家になるように、ビジネス指向のサービスを構築しています。一部のグローバルガイダンスが必要である、共有のガバナンスモデルを使用しようとするので、技術ビジョンシステムの共進化を担当するチームの各メンバー。
エンタープライズ・サービス・バスまたはサービス・デリバリー・システムのようなこのような方式は、あなたがそれらを使用しないでください、ビジネスサービスセンターのロジックとダムをリードします。代わりに、データを確実にするために、インテリジェントなエンドポイントと関連するロジックを使用して、相乗オーケストレーションまたはダミーミドルウェアを使用しての、サービス区切り内の結束は、サービスを維持します。 - 独立して展開することができ
、我々は常にサービスが独立して展開することができることを保証するために努力すべきです。あなたがする必要がある場合でも、互換性の変更はありませんが、我々はまた、消費者が徐々に新バージョンに移行することができ、新旧両方のバージョンを提供する必要があります。これは、新機能の放出速度を加速するために私たちを助けることができます。彼らは継続的な配分の展開プロセスを実行する必要はありませんので、我々は、これらのマイクロサービスチームを持っているだけでなく、より多くの自主性を持っています。JavaのRMIを使用しないようにのようなの統合RPCベースの種類を使用する場合は強固に結合技術クライアント/サーバー、生成されたスタブコードを使用して提供。
単一のサービスの単一ホストモードを使用することにより、あなたは、このような別の完全に無関係なサービスの影響として、サービスによって引き起こされる副作用を軽減するために展開することができます。青/緑またはカナリア展開技術の導入、展開、およびリリースは、エラーの解除の危険性を減らす区別使用することを検討してください。消費者主導契約テストの使用は、破壊的な変化の前にそれらをキャプチャします。
その後、他のサービスの展開へのリンクせずに本番環境にデプロイする、これが当たり前ではなく、例外である必要があり、あなたが単一のサービスを変更することができ、覚えておいてください。あなたの消費者は、更新に、あなたがそれらに適応する必要がある場合に決定する必要があります。 - 検疫は、失敗した
マイクロ・サービス・アーキテクチャは、我々は、システムの故障モードを理解し、それに応じて計画している場合にのみ、モノリシックアーキテクチャよりも柔軟であることができます。私たちは、下流の呼び出しが失敗する可能性があるという事実を考慮していない場合、システムは、システムがこれまで以上に脆弱になり、壊滅的なカスケード故障を被るだろう。
ときにネットワーク呼び出しは、それが別の故障モードを隠しているため、リモート呼び出しを扱うローカル呼び出しとして使うことが好きではありません。だから、オーバー抽象化なし長距離通話、クライアントライブラリを使用してください。
私たちの心は、抗脆弱な信条を持っている場合は、予想される障害は、我々は正しい軌道に乗っているかを示し、どこかの街で起こります。いつ、どのように障害のあるコンポーネントを制限するために、ノックオン効果隔壁と回路ブレーカを使用することを理解するために、あなたのタイムアウトを設定してください。システムの場合は一部だけで、ユーザーへの影響を理解するために、通常の動作ではありません。あなたは、ネットワークパーティションが特定のケースではと可用性や一貫性は正しい決断だったかどうかを犠牲を意味するかもしれないものを知っています。 - 高度観測
システムが適切に機能しているかどうかを確認するために、我々は、単一のサービスインスタンスの観察、またはサーバーの動作に依存することができません。代わりに、我々は全体として何が起こっているかを調べる必要があります。お使いのシステムに統合トランザクションを注入することにより、システムが正常に機能しているかどうかを確認するために、セマンティック監視を使用するために、実際のユーザーの行動をシミュレートします。あなたは問題が発生したときシンジケートあなたのログおよびデータは、そう、あなたはさらにその理由を分析することが可能となります。あなたは迷惑な問題を再現するために、あるいは単に本番環境でお使いのシステムが対話型であるかを確認する必要があるときに、あなたはあなたのコールトラッキングシステムとの間の関連性を特定するのに役立ちます。第四に、マイクロサービスの提案
- ときまず、分割後、安定化、単一のシステムの最初のビルディング・ブロックを考慮し、
より多くのあなたは、難しく、それをサービスのための右のコンテキストを見つける囲まれた領域を知りません。サービス間の連携につながる可能性が制限サービス部門のエラーが頻繁に変更する必要があり、この変更は高価です。あなたはフィールドには、1つのブロックシステムを理解していないのであれば、その後、サービスの分割前、最初にすることは、システムがやっていることを理解して、明確な境界モジュールを特定しようとするいくつかの時間を費やすことです。また、物事の既存の分類は、より存在していないものは、はるかに簡単に分類します。 - 進化アーキテクチャの概念
マイクロサービスアーキテクチャは、あなたはまた、より多くの意思決定を行う必要がある、あなたに多くの選択肢を提供します。シンプルなシングルピースシステムと比較すると、ミクロの世界のサービスでは、意思決定を行うことは、より一般的な活動です。あなたはので、各意思決定の範囲を狭めるためにしようと、いくつかの意思決定のミスになります。間違っていても、それだけでシステムの小さな部分に影響を与えます。進化のアーキテクチャの概念を受け入れることを学びなさい。あなたが何か新しいことを学ぶの後にこの概念では、システムは拡張し、変更します。これは、システムの柔軟性を保つことができ、徐々にシステムへの一連の変更を行って、ビッグバンの書き換えを考えると、時間をかけて、それを交換しないでください。 - また、非常に重要なポイント：マイクロサービスは特効薬ではありません。
ビューの建築家のための第五、
- 進化建築家：ちょうど都市プランナーとしては、（既存の住民に簡単にそれを作る、都市部のレイアウトを最適化するだけでなく、要因の将来を考える）、この枠組みの中で、合理的な枠組みを設計する必要があり、ゆっくりと正しい進化させることができこのシステムは、非常に限られた状況下での実装に非常に特異的に関与することが、一般的な方向に焦点を当てます。彼らは、システムは、現在のニーズを満たすことができないことを保証するだけでなく、将来の変化に対応できるようにする必要があります。そして、彼らはまた、開発者はちょうど幸せのようなシステムを使用するシステムとユーザに取り組んでいることを確認する必要があります。
- 進化建築家が責任を負うべき。
- ビジョン：必ずシステム・レベルでの技術ビジョンによる完全な通信があることを確認し、このビジョンは、あなたが顧客や組織のニーズに応えることができるはずです。
- 共感：あなたがクライアントや同僚を持って行った決定の影響を理解しています。
- 協力：より良いビジョン、改訂および実装を定義するために通信するために、同僚の多くとして。
- 適応性：顧客が技術的、組織的ビジョンを調整する必要がある場合ていることを確認してください。
- 自治：標準化とチームの自律性との適切なバランスを見つけます。
- ガバナンス：技術的なビジョンの要件に応じて、システムの実装を確保します。
