この問題は、アーキテクトが決定する必要があります。 かどうか？

マイクロサービスアーキテクチャに基づいてシステムを実装した経験があり、そのようなプロジェクトの実装中に発生する質問（および回答）を共有したいと思います。 残念ながら、私は自分が参加したプロジェクトについて広める権利を持っていないので、私は自分の球体プロジェクトを真空中で思いつきました。 このプロジェクトでは、多くの標準的な問題に対処します。

私はすぐに、実装が初歩的であり、質問を提起するための基礎としてのみ機能することに注意してください。 いずれにせよ、この記事で興味深い考えやリンクをいくつか見つけていただければ幸いです。

3つのクラスのみを記述するときにどれだけ興味深い瞬間が生じるかを確認し、この場合、アーキテクトが決定するべきか、開発者がこの問題を自分で解決できるかを自問します。

プロジェクトの主なアイデア

それで、より明るい未来が来て、自動操縦車が都市と村を活発に走ると想像してください。 質問が発生します：そのような状況で個人的な車が必要ですか？

別のアプローチを提供します。 見て、あなたは私のサイトに行き、登録し、フォームに記入してください。 アンケートは次のようになります。月曜日から金曜日の8時15分（ポイントA）に毎日家を出て、メルセデスに入り、仕事に取り掛かります（ポイントB）。 次に、夜の18:00にオフィスを出て（ポイントB）、アウディに座って家に着きます（ポイントA）。 ここで、ポイントをオフにすることができます。仕事を早く終わらせたい、8分以内に待つ準備ができています。

また、都合の良い時間に車に電話をかけることができます。入場時間は5分以内です。 このような場合の唯一の注意点は、週に5時間以内に使用する車です。 これは、計画が不十分な場合や、たとえば、店舗への旅行の場合です。

すべての喜びのために、彼らはあなたに150 cuを尋ねます 月あたり。 いいですね。

当然、このサービスには多くのロジックがあります。なぜなら、 考慮すべきことがたくさんあります。 たとえば、競争力がなければなりません。 人々に安価なオプションを提供する必要があります。 このために、共同旅行を提供できます。 クライアントの隣人も同じ方向に進んでいることがわかりますが、5分後です。 彼らに一緒に乗車を提供できますか？

私たちのサービスは、多くの興味深い情報を取得できる多くのデータを提供します。

• 誰が、どこで、いつ、誰と行くのか。
• 誰が、どこで、どのくらいの時間を費やすか
• どの車種が故障するか
• 誰がどの車を好むか
• ... ..

この情報に基づいて、有用な結論を導き出すことができます。 たとえば、 お客様がどこに、いつ行くかを知っているので、渋滞を予測し、それに落ちないようにルートを調整できます。

これを可能にするために、情報の収集と分析の可能性を提供する必要があります。

一般的に、モノのインターネットの世界の要素を備えたビジネス向けの「認知ソリューション」という流行語と呼ばれる大規模で複雑なプロジェクトについて話します。

開発方法論と要件分析

当然、まずプロジェクトのすべての要件を分析し、適用する方法（ウォーターフォール、ループ、スクラムなど）を決定する必要があります。 ただし、この場合、これらの手順はすべてスキップします。 この記事で提起されたほとんどすべての質問は、選択された方法に関係なく、いずれの場合にも発生します。

言語、フレームワーク、アーキテクチャ

最初はJava開発者であるため、実装はJavaで行われます。 私を責めないでください。

ところで、プログラミング言語の選択はアーキテクトの仕事ですか、それとも「これ以上」ですか？

プログラミング言語は二次的であり、一般的にはチームだけが重要であると思わない人のために、私は小さな思考実験を行うことを提案します。 そのようなプロジェクトを絶対にしない言語を考えてください。 これは明らかに間違った決定だと思います。 ここで、建築家がこの言語でプロジェクトを作成することを決定したと想像してください。 そして、怒ってあなたが怒るとき、彼はあなたに言うでしょう：これは二次的な質問です、主なものはチームです！

冒頭で述べたように、マイクロサービスアーキテクチャに基づいて行います。 モノリスから始める方が正確だと誰かが言うだろうし、彼に同意するだろうが、マイクロサービスからすぐに始める。

そして、どのフレームワークを採用しますか？ 少しグーグルで検索すると、選択肢があまりないことが明らかになります。SpringFrameworkで行います。 その理由は簡単です。SpringCloudには必要なものがすべて揃っています。

また、あらゆる種類のAPIゲートウェイ、構成サービス、メッセージブローカー、Docker、ワークフロー、ルールエンジン、その他多くのささいな単語を用意します。


必要なサービスを決めましょう。 これを行うには、必ず必要なドメインオブジェクトを確認してから、それらのサービスをプッシュするサービスを調べます。

トランスポートから始めましょう。 たとえば、 Carの場合 。 ただ車は動作しませんが。 説明します。 たとえば、突然、人が車で駅に行き、電車に乗り換え、街に行き、最後の2キロメートル自転車に乗るのが便利になりますか？ 結局のところ、私たちもこのいい人にこの自転車のお金を請求したいのですか？ 誰かがモノホイールでこの最後のマイルを運転したい場合はどうなりますか？ 特にお金を持っている人を怒らせないでください。 彼に一輪車を貸しましょう！ したがって、将来的には、さまざまなビークルを記述する多くのクラスが必要になる可能性があります。

出発点として、いくつかの抽象クラスVehicle

public abstract class Vehicle { …. protected String model; protected int wheelNumber; protected Date manufactureYear; protected EngineType engineType; protected Producer producer; } 

わかったように、異なるVehicleがありますので、いくつか作りましょう。

 public class Car extends Vehicle { public Car() { wheelNumber = 4; } } 

そしてもう一つは貧しいが運動選手のためです：

 public class Bicycle extends Vehicle { public Bicycle() { wheelNumber = 2; } } 

いいね 今、私たち全員がこれを行う人が必要です。私たちのクライアント、彼は私たちの収入源です。 このエンティティをCustomerと呼びましょう。

 public class Customer { private String firstName; private String lastName; private Date birthDay; } 

また、クライアントとの契約が必要です。これは、彼が私たちから受け取る車両と、そのために受け取る金額を示します。

 public class Contract { private long customerId; private long vehicleId; } 

そのため、最上位にVehicleを持つCustomerとContractという1つのクラス階層があります。 VehicleService 、 ContractServiceおよびCustomerServiceをそれらから作成することを提案します。


ここでサービスの基本的な実装を見ることができます。

次に、すべてをdockerに入れましょう。 ちなみに、私は最近Dockerの4歳の誕生日の際にミートアップでここにいました。 面白いリンクがそこに私たちに提示されました、それは非常に悪くない場所で、私は見ることをお勧めします

サービスをdockerに配置するには、maven（pom.xml docker-maven-pluginを参照）とdockerfileのプラグインが必要です。

docker-compose.ymlはプロジェクトのルートにあるため、docker-composeを介してすべてのサービスを起動します。

.envファイルとその内容にも注意してください。 このファイルの詳細については、 ドキュメントを参照してください 。 このファイルがないと、Windows 7マシンでMySQLを初期化できませんでした。

私は何をしましたか？

長所から始めましょう：

• このことは機能します。

これで、プロは残念なことに終了しました

短所：

残念ながら、それらの多くがありますので、私たちはいくつかの部分のみを選択的に検討します。

欠点の分析を開始する前に、小さな、しかし非常に重要なポイントに言及したいと思います。マイクロサービスアーキテクチャでは、最初に各サービスの少なくとも2つのインスタンスがシステムで動作し、負荷を共有することを前提としています。 このルールが守られていない場合、私の意見では、マイクロサービスアーキテクチャの話をすぐにやめることができます。 はい、私は知っています、これは議論の余地がありますが、私の意見はそれだけです。

残念ながら、冗長性はサービスの100％の可用性を保証するものではないため、システムのパフォーマンスを維持するための別の合理的な方法がある場合は、それを使用する必要があります。

新しいタイプのトランスポートをシステムに追加する

ですから、まず最初に、採用した車両を運転するという決定に対する正しいアプローチはありますか？ 質問を説明します。 たとえば、スクーターのレンタルをお客様に提供したいと考えています。

これで、 VehicleServiceは次のようになります。



システムに新しいスクーターエンティティを追加する必要があります。 すべては継承に基づいているため、最終結果は次のようになります。



VehicleServiceで新しいScooterクラスを作成し 、 protest 、コンパイル、およびデプロイします。 そして、数十種類の乗り物がある場合はどうでしょうか？ 新しいクラスを作成するたびに、テスト、コンパイルなどを行いますか？ 他の方法はありますか？

たとえば、そうすることができます。 VehicleTypeクラスを作成しましょう。

 public class VehicleType { private String name; private List<VehicleProperty> properties; …. } 

ご覧のとおり、 VehicleTypeにはVehiclePropertyがあります 。

 public class VehicleProperty<T> { private String name; private T value; private String description; ….. } 

Vehicleクラスを作りましょう：

 public class Vehicle { private VehicleType vehicleType ; private List<VehicleProperty> customProperties; …... } 

ここで、システムにスクーターを追加する場合、 まずVehicleType “ Scooter”を作成します。

 VehicleProperty wheelNumberProperty = new VehicleProperty<Integer>("wheelNumber", 2, "number of wheels"); ……. VehicleType scooterType = new VehicleType("Scooter"); scooterType.addProperty( wheelNumberProperty); …….. 

そして、スクーターのインスタンスを作成する必要がある場合：

 Vehicle scooter1 = new Vehicle(scooterType); ….. 

したがって、 VehicleServiceで新しいクラスを作成せずに、できるだけ多くの新しいタイプをシステムに追加できます。



クラス図に関する最後の叙情的な余談を今でも覚えていますか？質問は、それが建築の主題であるかどうかです。 以下は、サービスの実装に対する2つの根本的に異なるアプローチを説明する2つのクラス図です。 それらはアーキテクチャソリューションの一部ですか？ 私の意見では、非常に、 この場合、実装方法はクラスレベルでも広範囲に影響を及ぼし、プロジェクトの将来の生活を地獄に変える可能性があります。


次の瞬間。 VehicleServiceがクラッシュした場合、システムで自転車の新しいインスタンスを作成することはできません（たとえば、自転車の新しいバッチを購入してシステムに追加したい場合）。または、自転車をレンタルすることもできません。 つまり クライアントもオフィスの従業員も何もできません。 オフィスで問題が発生した場合でも、お客様が注文してお金をもたらすことができれば、はるかに良いでしょう。 これをどのように行うことができますか？ VehicleServiceを顧客用と従業員用の2つに分割する必要があるようです。

サービスを設計するためのドメインおよび機能的アプローチについて話していたことを思い出してください。 顧客と従業員に対するサービスの可用性に関する問題は、ドメインアプローチを開始し、問題にぶつかり、機能的アプローチに移行したときの優れた例です。 2つのサービスが必要です。ドメインオブジェクトは基本的に同じですが、機能は異なります。

もう一度、 VehicleServiceがクラッシュするとします。 これは、車も自転車もレンタルできないことを意味します。 車のサービスが利用できない場合、それは悪いことではありません。その後、自転車のサービスはさらに機能します。 これをどのように行うことができますか？ VehicleServiceを複数のサービスに分割します。各タイプの車両に1つですか？

実際、考えられる問題の最後の2つの例は完全に正しいわけではありません。 それらは冗長性、すなわち サービスのいくつかのインスタンスが機能するはずです。 ただし、冒頭で述べたように、冗長性がないと100％の可用性は得られません。 そのため、他の合理的な代替方法でサービスの可用性の問題を解決する必要があります。

私たちの路上で休日が起こり、私たちから車を借りたいと思っているたくさんの顧客が私たちのところに駆けつけてきました。 サービスは対処しませんが、これは問題ではありません。別のインスタンスを起動すると、すべてが再び正常になります。 しかし、今では車用だけでなく自転車用のサービスのコピーが2つあります。 悪いですか？ 分かりませんが、確かに良くありません。 それと一緒に暮らすことができる可能性が非常に高いので、見なければなりません。

これらの問題を考慮した後、サービスの実装に別のオプションを提供できます。 輸送の種類ごとに個別のサービスを提供します。 しかし、そのような疑問が生じます。
あなたがクライアントで、サイトに行き、可能なすべてのタイプのトランスポートのリストを見たいと仮定します。 あなたは次のようなものを見たいです：

• 車
• 自転車
• スコーター
• トラクタ
• ... ...

このリストはどこから来たのですか？ おそらく、 VehicleTypesServiceサービスも必要になります。このサービスは、システムにどのタイプの車両が存在するかを知っています。 彼はどこからこの情報を入手しますか？ 最初に頭に浮かぶのは、ペンでデータベースに書き込むことです。 サービスに別のタイプのトランスポートを提供する場合、そのサービスを作成し、 VehicleTypesServiceに移動してデータベースにもう1行追加することを忘れないでください。

しかし、別の方法でも可能です。 起動時に、各サービスはVehicleTypesServiceをノックして、その存在を通知する必要があります。 このソリューションは見栄えが良いように見えますが、追加する必要がない場合の対処方法の質問には答えず、車両のタイプを削除します。 たとえば、6か月後、誰もモノホイールを使用していないことに気付きました。モノホイールをシステムから削除したいのです。 これをどうやってやるの？

そして、もう一つ興味深い質問があります。 ご覧のとおり、 VehicleにはEngineTypeフィールドがあります。

 public abstract class Vehicle { …... protected EngineType engineType; 

私の初歩的な実装では、EngineTypeには列挙型があります。

• ガス
• ディーゼル
• エレクトロ

そして今、質問そのもの：ハイブリッド発電所を備えた車をどのように作成するのでしょうか？

EngineTypeの代わりに、 EngineTypeのリストを作成してみましょう （そして、マシンの99％が突然1つの要素を持つリストを持つことになります）？

 public abstract class Vehicle { …... protected List<EngineType> engineTypes; 

または、列挙型にGibridのような新しい型を追加しますか？

この場合、誰が決定を下し、それに応じて責任を負いますか？

ここで建築について話していると言ってもいいですか、これはあまりに「小さな」質問ですか？

EngineTypeフィールドの例を使用して、もう1つの質問をしたいと思います。車に搭載されているエンジンを本当に知る必要があるのでしょうか。 実際、お客様がディーゼル燃料またはガソリンをタンクに注ぐ可能性が非常に高いことは、お客様にとって絶対に重要ではありません。 しかし、たとえば、自転車を持ち歩く能力（つまり、大きなトランクがあるか、特別な自転車マウントがあるか）は非常に重要です。

実際、エンジンの種類はもちろん重要ですが、クライアントにとってではなく、私たちにとって、このサービスを提供する会社にとっては重要です。 その理由の1つは、統計（たとえば、燃料費や必要な修理に関する）です。 エンジンの種類ごとに大きく異なります。 これは別の質問を招きます：ドメインオブジェクト（またはその表現）は、バックエンドとフロントエンドで異なる必要がありますか？

この種の質問に答える方法は？ 私は1つの方法しか知りません。ビジネスの人々ともっと頻繁に話し合い、何をどこで見たいかを尋ねるべきでしょうか？ 残念ながら、彼ら自身はしばしばこれらの質問に対する答えを知りません。

複雑なクエリ

輝かしいベルリンの街、オレンジストリートに住んでいる契約のあるすべての顧客に会いたいとします。 つまり このプレートのようなものを見たい：

姓、名	契約番号	契約に署名した日付	車
パプキン、ヴァシャ	12345	2017年1月1日	アウディQ4
......	......	......	......

ご覧のとおり、テーブルには3つのマイクロサービスからのデータが含まれています： CustomerService 、 VehicleServiceおよびContractService 。 それらをどのように組み立てますか？ モノリスの場合、データベースへの1つのリクエストで問題は解決されますが、3つのベースがある場合はどうすればよいでしょうか？



この小さな問題を解決するためのさまざまなオプションがあり、次回はそれらについて説明します。

変更履歴

ある日、スマートな誰かが、顧客が契約を終了するか、契約を更新せずに競合他社に行く理由を知りたいでしょうか？ おそらく車が好きではなかった/遅れたのでしょうか？ それとも、同僚と一緒に以前に旅行した男性が、競合他社に切り替えて仲間を引き付けたのかもしれません。

このような質問に答えるには、システムで何が起こったのかを知る必要があります。 変更履歴が必要です。

これを行う方法については、次の記事で説明します。

インフラストラクチャの問題

マイクロサービスアーキテクチャは、アプリケーション全体のインフラストラクチャに非常に具体的な要件を課しています。つまり、

• 単一のエントリポイント、別名Gateway API
• サービスの検索、別名サービスディスカバリー
• 構成の1つのポイント、別名構成サービス
• ログの収集と分析の中心点
• 監視
• ... ...

次のパートでこれらの質問と他の質問。