世界中で今、人気のマイクロ指向アーキテクチャサービス。速いペースで低コストの展開は、基本的なコミットメント指向アーキテクチャのマイクロサービスであるためです。
しかし、水をテストするための多くの企業のために、より多くの開発活動は、ソースが多くのレベルと紛争に妨げるかもしれサービス指向アーキテクチャのマイクロ、に既存のモノリシックアプリケーションを変換することです。
がグリーンフィールド設計原則- （未開発）マイクロサービス指向アーキテクチャの実装は、現在のマイクロサービスの厳密な解釈に付着することができます。予算と時間の制約を満たすが、他に理由がない場合でも、マイクロサービス指向アーキテクチャーでは、グレーのレガシーアプリケーションの色合いのブレークダウンは、そこにあります。
どこかで企業経営のチェーンで、企業幹部がマイクロ指向サービスのアーキテクチャでは、これらのレガシーアプリケーションに関連するコストの分解であり、レガシーコードが既に提供の値と比較表示します。開発コストが期待される利益を超えたら、企業幹部は撤回し、プロジェクトを中止する可能性があります。
このような事がしばしば起こります。
そのため、開発マネージャは、できるだけ早く出力にコードをそれらを求める、途方もない圧力に直面しています。理想的なターゲット変換される「十分に良いです」。
さて、これは必ずしも悪いことではありません。夢の到着を待っていると比べると、出力コードを動作させる能力は常により良いです。しかし、「グレーの色合いは、」管理することが困難な、問題は「十分に良い」の境界を定義する方法です。
そのため、競合が始まりました。他の多くの改善を望んでいる間党は、彼らが望むものを出力したいです。
あなたのために、挑戦はこれらせることではない別の学校を決して終わることのないけんかを製造するビューの信仰ポイントをサポートするために、自然の中で。そうした場合、それは任意のコードを提供していない状況を作成します。さて、競合が多くの競合のアイデアから最高のアイデアを合成することができます。談話は、無限の紛争に退化する場合しかし、それは致命的なことができます。
私はこのような競合を避けるために、次の問題の3つの焦点を通じてこの種の状況を処理します。
- 設計のための理由は何ですか？
- どのくらいのリスク？
- どのようなリスク削減計画？
私は手の込んだすることを許可します。
1.デザインが理由ではありませんか？
あなたはマイクロ指向アーキテクチャサービスの設計を評価すると、課題は、基本的な理論の最後のポイントに転送することです。これは、単一のアプリケーションの分解から主に作成されます。任意のデザインは、限り、あなたはその利点と価値を証明することができるよう、「十分に良い」ことも可能です。
例えば、サービス指向アーキテクチャのマイクロ設計の好ましい様式の一つは、サービス間の通信のイベントドリブン方式を使用することです。具体的には、これはあなたがメッセージのノードを使用することを意味し、非同期マイクロサービス間でメッセージを転送します。しかし、長期的には、非同期より柔軟で拡張性の高い通信が、メッセージ・システムは、同期設計はマイクロサービス「を」はるかに複雑なAPIの間でHTTP呼び出しを使用してよりも実装するのに。したがって、市場が関係している時間が、示されているマイクロHTTP APIへの別のサービスとして再構成されたモノリシックなアプリケーションの特徴であるとすべての理由があります。
与异步服务相比，同步微服务的实现通常不那么复杂。
長い目で見れば、同期通信は、必ずしも最良の選択ではありませんが、アカウントへのアプリケーションの単一のブロックから独立したマイクロサービスを抽出するために必要なすべての他の仕事を取って、最初のバージョンの同期は、「十分」です。だから、これは正当な理由です。
しかし、これはリスクなし同期方法を意味するものではありません。実際には、多くのリスクがあります。それはマイクロのための建築設計審査サービス、唯一の理由ではない唯一の要因になると。リスクについても説明しなければなりません。
2.どのくらいのリスク？
すべてのデザインは、固有のリスクを持っています。上記設計例において、同期化、によりHTTP通信と他の通信との非同期の性質のために、サービスタイプとの間の結合のリスクを引き起こす可能性がサービス間の通信方法遅延増加増加遅延。
あなたが意図した設計の合理性に応じてそれらを量ることができるように、これらのリスクの人々に認識させることが重要です。リスクが巨大である場合は、理由のない量が十分ではありません。一方、現在の需要を考えると、いくつかのリスクが許容可能です。トリックはリスクが明確にレビュープロセスに伝達されることを確実にするためです。既知のリスクの議論は常に隠されたリスクに好ましく、このリスクは、道路に影響を与える可能性があります。また、あなたはリスクを事前に認識して、その後、成熟したサービスのためのマイクロアーキテクチャでは、将来のリリースで前進するために最善の方法を計画することができます。これは、なぜリスクの低減です。
3.リスク削減計画とは何ですか？
賢明なアプリケーション設計の兆候は、かつて彼がこれらのリスクを軽減するための先見の明の方法を明確にします確定、その設計上のリスクを識別するための機能です。適切なリスク軽減技術がないと認識が不完全なフラグを考えています。
マージナル重大なリスクと計画のためのマイクロアーキテクチャ設計サービスはこれらの問題を解決する場合は、設計チームは真剣にその実現可能性を検討する必要があります。また、緩和計画は非現実的な場合-を越えた専門知識と予算のプロジェクト -デザインの可能性も疑問視する必要があります。これはバランスの問題です。
それはその固有のデザインの条件を満たすように望んでいるので、マイクロ指向サービスの良いバランスが正当化されるアーキテクチャの設計はトレードオフで、これらのリスクとリスク軽減計画に対処することを目指しています。
4.それらを一緒に入れて
紛争は、創造的なプロセスの重要な部分です。自分のアイデアの多くの場合、砂のような創造的な人々。あなたが部屋に入れ、それらを単一の設計のマイクロ志向の建築デザインとして機能させたときにそう、それは確かに緊張を悪化させるだろう。それは方法です。しかし、心を取ります！紛争は良いことです。
幸いなことに、合理的なアプローチで、私はマイクロサービスのためのアーキテクチャ設計を検討するために、前述の三つの問題では、ソフトウェアで、その結果、客観的な議論を促進することができますし、あなたのニーズを満たすためにする場合。いいえデザインは、単一のアプリケーションを打破するために設計された特に、完璧ではありません。ただし、サービスの提供のためのマイクロアーキテクチャは、このアーキテクチャの大きな利点は十分ですしている効果的に機能短期および長期の柔軟性を十分に継続的な改善に。
著者：ボブReselman
翻訳：ロスト夜明け