Luxoft Trainingは、Sander Hugendornの記事「Microservices。 善、悪、悪。」



SANDER HUGENDORN（オランダ）



メンター、トレーナー、ソフトウェアアーキテクト、プログラマー、スピーカー、ライター。



サンダーはソフトウェア開発に30年以上携わっており、18歳でパスカルで最初の商用プログラムを書きました。



20年間、大規模なコンサルティングIT企業と協力しています。 現在、Capgeminiで働いています。 さまざまな国からの多数のクライアントが、彼をソフトウェア開発の革新の「アクティベーター」として評価しています。



彼は、世界的に有名なベストセラーの本This is Agileの著者であり、UMLとAgileの多くの本もあります。 彼は現在、ソフトウェアアーキテクチャ、パターンとコード、およびアジャイルアンチパターンに関する2冊の新しい本に取り組んでいます。



サンダーは、Microsoft Visual Studio諮問委員会のメンバーです。 @Portunity（MDAプロバイダー）の諮問委員会、Software Release MagazineおよびIT Managementの編集委員会、Computable雑誌の開発エキスパートのメンバー。 モスクワでのサンダーの訓練に関する情報。

マイクロサービス。 善、悪、悪

1988年、私が最初にソフトウェア会社で働き始めたとき、世界はとてもシンプルでした。 開発環境はテキストで、データベースは統合され、カーソルで表示され、可能なすべてをカバーする完全に新しい管理システムを作成しました。 プロジェクトを完了するのに5年かかりました。これは主に、クライアントが定期的に考えを変え、各変更がシステムの他の場所のコードに違反する可能性があるためです。 単体テストはまだ発明されておらず、テストはエンドユーザーによって行われています。 生産中。



今のところモノリスについては十分です。 1994年に、デスクトップアプリケーションを開発する会社に入社しました。WorldWide Webはほんの数年前のもので、Webアプリケーションはまだ発明されていません。 PowerBuilderと呼ばれる優れたツールを使用しましたが、心配する必要のある2つのコンポーネントがありました。デスクトップアプリケーションとサーバー上のデータベースです。 私たちが作成したアプリケーションは、会社の部門で使用され、時には会社全体でも使用されました。 それらはそれほど複雑ではありませんでしたが、スケーラブルでもありませんでした。 クライアントとサーバーのパラダイムが存在し続けている間、私たちは楽しみました。

コンポーネント指向開発

90年代半ばに世界はより複雑になりました。 企業は、デスクトップホスティングをなくすために、イントラネットで実行されるWebアプリケーションを探していました。 また、アプリケーションは複数の部門にサービスを提供する必要があり、場合によっては会社の境界を越えて行きました。 新しいパラダイムが確立されました- コンポーネント指向開発 、CBDとしても知られています。 彼女は、再利用、スケーラビリティ、柔軟性、およびコードを抽出する機能（通常はCOBOLで記述されている）を約束しました。 私たちはシステムを大きな機能部品に分解し始め、これらのコンポーネントが互いに通信を開始するように非常に懸命に努力しました。 Javaが発明され、誰もが突然Javaでコードを書きたいと思っていました（明らかに、一部の人はまだしたいと思っています）。 コンポーネントは、アプリケーションサーバーやCORBAなどの信じられないほどのテクノロジで機能しました（ウィキペディアで同僚に感銘を与えることの意味を見てください）。 古き良き時代のブローカーオブジェクトクエリ ！





不気味なこと-オブジェクトクエリブローカーのアーキテクチャ



当時、私は大手国際銀行で働いており、コンポーネント指向開発の方法論を作成しようとしていました。 Andersenの優秀なコンサルタントチームでさえ、この気の毒なことを書くのに3年かかりました。 その結果、パラダイムとテクノロジーの両方が複雑すぎて、きちんとした適切に機能するプログラムを書くことができませんでした。 うまくいきませんでした。

サービス指向アーキテクチャ

その瞬間、21世紀の初めに、分散ソフトウェア開発を取り除き、Webアプリケーションの作成を開始したと思いました。 オブジェクトを配布するのではなく、オブジェクトの配布に関するマーティン・ファウラーの最初の法則を誰もが勇敢に無視したようです。 徐々に、次の分散コンピューティングパラダイムに移行し、コンポーネント指向の開発の約束を最新のテクノロジーセットに再パッケージ化しました。 現在、ビジネスプロセスモデリング（BPM）を実行し、これらのプロセスをエンタープライズサービスバス（ESB）に実装し始め、コンポーネントがサービスを提供しました。 私たちは、SOAとして知られるサービス指向アーキテクチャの時代にいました。



CBDの後、SOAは簡単になりました。 コンポーネント（メーカー）がエンタープライズサービスバスに接続されている限り、スケーラブルで柔軟なシステムを成長させる方法を考え出しました。 これで、既存のシステム（COBOLだけでなく、PowerBuilder、.NET、およびJavaで記述された）から抽出できるはるかに小さなコンポーネントができました。 開発パターンに関する必要な本が書かれ、世界はビジネスに取りかかる準備ができていました。 今回は対処する必要があります！





エンタープライズサービスバス



今回は国際的な運送会社で働き、SAPミドルウェアを中心にソフトウェアを作成し、ESBとBPMの両方にツールを提供しました。 Javaと.NETの開発者だけでなく、ミドルウェア開発者とSAPコンサルタントも必要になりました。 そして、開発をスピードアップするためにアジャイルが提案されましたが（これは間違った議論です）、プロジェクトはまだ遅すぎました。午後にはすべてがより複雑になります。

最後に：マイクロサービス！

マイクロサービスのトピックについて、このように長く混乱を招く入門を許してくださることを願っています。 「マイクロサービスのトピックに関する別の記事が必要なのはなぜですか。このトピックに関する十分な文献がないのですか？」 一般に、はい、十分です。 しかし、インターネットで見つけられる記事の流れを注意深く見ると、それらのほとんどはマイクロサービスの利点と機能のみを記述し（「ハレルヤ」を歌います）、それらのいくつかはイノベーターのいくつかの有名な例を記述しています（Netflix、Amazon、Netflix、およびAmazon、およびNetflix ...）。 そして、実際に少し深く掘り下げた記事はほんのわずかであり、それらの記事でさえ、原則として、マイクロサービスの実装に使用されるテクノロジーを要約したものです。 すべてが始まったばかりです。



そして、ここで歴史への小旅行は害を与えません。 興味深いことに、マイクロサービスの前身の利点と機能はまだ残っています。 マイクロサービスは、独立して簡単に展開できる小さなコンポーネントに基づいたスケーラブルで柔軟なシステムを約束し、コンポーネントに最適なテクノロジーを選択するのに役立ちます。 つまり、過去にCBDとSOAで行ったのと同じ約束です。 ここに新しいものはありませんが、これはマイクロサービスが綿密な検討に値しないという意味ではありません。

今回は違いはありますか？

では、なぜ今回は違うのでしょうか？ 前任者が明らかにそうでなかった場合、マイクロサービスを勝利のパラダイムにするものは何でしょうか？ それらの何がそんなに特別なのですか？ 開発者として、私は間違いなくマイクロサービスに喜んでいますが、CBDとSOAが登場したときは（多かれ少なかれ）喜んでいました。



違いがあります。 初めて、このタイプのアーキテクチャを作成するために必要なすべてのテクノロジーを備えています。 複雑で複雑なミドルウェアはすべて姿を消しました。私たちは、非常にシンプルで長く存在するWebプロトコルとテクノロジーのみに依存しています。 RESTとCORBAを比較するだけです。 さらに、継続的インテグレーション、単体テスト、さらには継続的デリバリの実行方法を学習することで、展開をよりよく理解します。 これらの違いは、今回できることを示しています。



ただし、一部の懐疑論は避けられません。 10年前、サービス指向アーキテクチャは技術的に実現可能であり、すべての問題を解決し、信頼性の高い再利用可能なものを迅速に作成できると強く信じていました。 技術の準備ができていると私たちが信じるという事実は、あまり有効な議論ではありません。 同時に、世界もより複雑になっています。



過去1年間、私はメインフレーム（高価すぎる）と多くの古いJavaモノリス（大きすぎてサポートするには複雑すぎる）から離れる会社と仕事をしてきました。 実装のタイミングも重要な役割を果たします。 ITは、数か月間、新製品の導入をサポートする必要があります。 したがって、ファッショナブルであると決め、マイクロサービスを選択しました。 マイクロサービスアーキテクチャの「良い点、悪い点、悪い点」の側面をまとめたものです。

いいね

良い面から始めましょう。 小さなコンポーネントを作成し、それぞれが2〜6個のサービスを提供します。 このような小さなコンポーネントの良い例は、データテンプレートからPDFのみを生成するPDFコンポーネントや、ユーザーが既存の顧客を検索できるCustomerコンポーネントです。 これらのコンポーネントには適切なサイズがあります。コードの量、理解とドキュメント化、テストと展開に適したサイズです。



いいね



私たちのチームは、個々のコンポーネントを開発、実装、サポートする小さなグループのセットになり始めました。 私たちはこれを主張しませんでしたが、時間の経過とともに、小グループ自身が特定のコンポーネントの作業を開始し、その責任を感じ始めました。



マイクロサービスの基本アーキテクチャの一般的な図を作成した後、多くの原則を確立しました。 小さなコンポーネントだけでなく、小さな単一目的のWebアプリケーションも作成します。 アプリケーションは、他のアプリケーションやコンポーネントと通信できます。 コンポーネント自体が独自の復元力とストレージを管理し、他のコンポーネントと通信することもできます。 アプリケーションはリポジトリと直接対話しません。 コンポーネントはリポジトリと対話しません。 私たちにとって、これらの原則は機能します。



マイクロサービスはその約束の一部を守ります。 各コンポーネントに必要なテクノロジーと安定性メカニズムを選択できます。 一部のコンポーネントはリレーショナルデータベース（DB2またはSQLServer）に保存され、他のコンポーネントはドキュメントデータベース（この場合はMongoDB）に保存されます。 ファッショナブルな用語であるポリグロット持続性がここに当てはまります。



また、各アプリケーションとコンポーネントに独自のドメインモデルを持たせることも決定しました。 サブジェクト指向設計の原則とパターンを直接使用します。 ドメインオブジェクト、値オブジェクト、統合ルート、ストレージ、および工場があります。 コンポーネントが小さいため、ドメインモデルは非常にシンプルであり、したがってメンテナンスが容易です。



Fitnesseから手書きテストに至るまで、コンポーネントとサービスのテストに向けて長い道のりを歩んできましたが、SoapUIのテスターに​​よるテストの記述に移ります。 テストは、個別に、およびアセンブリ中に実施します。 RESTを理解することを学ぶべきでしたが、すでにこれに対処しました。 そして、テスターは何が起こったのか本当に気に入っています。



マイクロサービスを使用して旅を始めたとき、私がいたチームはリアクティブモードでした。プログラムの内容と方法を教えてください。 これがチームメンバーのモチベーションにどのように影響するかを説明する価値はないと思います。 ただし、マイクロサービスの場合、既製の「レシピブック」や特定のアーキテクチャはありません。 これらは単に存在しません。 これは、RESTインターフェースを使用する前に、マイクロサービスの設計方法（スマートな使用シナリオを使用）の発見、まったく新しい環境セットの操作方法、まったく新しいものの作成方法から、常にマイクロサービスのパズルを解決する必要があったことを意味しますコンポーネントを展開する方法。 このパズルは、このアーキテクチャでの作業を興味深いものにします。 毎日学びます。

悪い

しかし、いつものように、欠点があります。 マイクロサービスのパスを選択するとき-何らかの理由でそれが有用だと思う場合-これはすべて非常に新しいことを理解する必要があります。 考えてみてください：NetflixやAmazonで作業していない場合、フルロードで実稼働環境でマイクロサービスを積極的に展開している人を知っていますか？ 誰に頼むことができますか？





悪い



本当に深く掘り下げなければならないことを理解する必要があります。 あなたは自分で多くを学ぶ必要があります。 まだ標準はありません。 テクニック、プロトコル、フレームワーク、およびツールについて行う決定はすべて一時的なものである可能性が高いことに気付くでしょう。 毎日勉強するとき、新しい、より良いオプションが利用可能または必要になり、あなたはあなたの決断を変えなければなりません。 したがって、マイクロサービスを正しく実装するための既製のIKEAデザイナーを探している場合は、さらに5〜7年待たなければならない場合があります。 大企業を待ってください、彼らはビジネスが収益性があるので、彼らはかなりすぐに参加します。



設計の観点からは、異なる考え方を開始する必要があります。 小さなコンポーネントの設計は、思ったほど簡単ではありません。 どのコンポーネントサイズが正しいですか？ はい、彼にはもちろん1つのビジネス目標がありますが、コンポーネントの境界をどのように決定しますか？ どの時点で作業コンポーネントを2つ以上の個別のコンポーネントに分割することにしましたか？ 過去1年間で、このような問題に直面しました。 また、既存のコンポーネントを共有しましたが、これを実行する厳密なルールはありません。 通常、コンポーネントの構造を理解できなくなったとき、またはいくつかのビジネス機能を実行することに気付いたときに、直感に基づいて決定を下しました。 大規模なシステムからコンポーネントを「切り離す」場合、これはさらに複雑になります。 この場合、通常、多くの「配線」を削減する必要があり、同時にシステムの安定した動作を確保する必要があります。 さらに、既存のシステムのコンポーネント化を実行するには、サブジェクト領域に関する十分な知識が必要です。



一般に、コンポーネントは予想したほど安定していないことがわかりました。 コンポーネントを組み合わせることもありますが、再利用と市場投入までの時間を短縮するために、多くの場合、コンポーネントを小さなコンポーネントに分割しました。 たとえば、 Q＆Aコンポーネントを製品コンポーネントから分離しました。現在、 製品に関する調査フォームだけでなく、他の目的でもアンケートフォームを提供しています。 そして最近、完成したアンケートのチェックと保存のみを行う新しいコンポーネントを作成しました。



また、多くの技術的な質問に対する答えを見つける必要があります。 コンポーネントアーキテクチャとは アプリケーションもコンポーネントですか？ あるいは、それほど明白ではない質問ですが、通信プロトコルとしてRESTを使用することを考えている場合、おそらくRESTはどのように機能するのでしょうか？ 「サービスインターフェイスREST準拠」とはどういう意味ですか？ どのような完了コードをいつ使用しますか？ サービスのいずれかによって何かが適切に処理されない場合、コンシューマーエラー処理を実装する方法は？ RESTは見た目ほど単純ではありません。 サービスインターフェイスを操作する独自の方法を見つけるには、多くの時間と労力を費やす必要があります。 サービスを多かれ少なかれ統合するために、リクエストを行い、回答とエラーを処理する小さなフレームワークを作成する方がよいことがわかりました。 したがって、接続はすべてのリクエストで同じであり、メインプロトコル（この場合はJAX-RS）を変更する必要がある場合は、1か所でのみ変更する必要があります。



そして、それは次の問題に私を導きます。 はい、マイクロサービスは、各コンポーネントに最適なテクノロジーを選択できるという約束を果たします。 私たちはこれをプロジェクトで認識しています。 一部のコンポーネントは、Hibernate、MongoDBコネクタ、マッピング用のDozerなどの追加フレームワークに基づいたもの、または何らかのPDF生成フレームワークを使用したものを使用します。 しかし、追加のフレームワークでは、追加の知識が必要になります。 この会社では、約100個、さらにそれ以上の小さなコンポーネントを簡単に作成できます。 それらの4分の1が特定のフレームワークを使用している場合でも、25〜30の異なるフレームワークになります（Javaで作業していることを述べましたか？）。 それらすべてを知る必要があります。 さらに悪いことに、それらのすべてのバージョン（もちろん、「デッド」でない限り）もそうです。



さらに、作成するコードの一部を標準化する必要があります。 テクノロジーの自由は素晴らしいですが、各コンポーネントが文字通り異なる方法で実装されている場合、最終的にはほとんどサポートされていないコードベースになります。特に、書かれているすべてのコードをフォローしている人はほとんどいないからです。 コードベース内のコンポーネント間で、統合できる、または統合する必要がある一貫性があることを確認することを強くお勧めします。 ユーザーインターフェイスのコンポーネント（グリッド、ボタン、ポップアップ、エラーメッセージ）、検証（ドメインモデル）、データベースとの通信、およびサービスからのリクエストがどのように定式化されるかを考えてください。 さらに、ドメイン分割モデルには断固として反対しますが（このパスは選択しないでください）、ドメインモデルには分離する必要がある要素があります。 たとえば、 CustomerIdやIBANなど、いくつかの列挙と値オブジェクトを共有します。



あなたが私たちのようであれば、あなたのコードはあなたのコンポーネントによって再利用されるライブラリのセット（または必要に応じてフレームワーク）になります。 この自家製フレームワークの新しいリリースごとに、コンポーネントのコードの一部をリファクタリングすることになりました。 先週、検証フレームワークのインターフェースを書き直しました。これは、保存した状態を取り除くために必要でした（コンポーネントは、スケーラビリティの理由で状態を保存するべきではありません）。仕事に戻ったときに、システムにそれを埋め込みたくありません月曜日に。 ほとんどのコンポーネントはそれを使用しており、それらのコードはコンパイルできません。 独自のフレームワークを持つのは良いことだと言いたいです。 ある程度の規律では、コードをより理解しやすく、少し統一するのに役立ちますが、それに専念し、新しいバージョンをリリースする必要があることを確信する必要があります。

怒り

それでは、マイクロサービスの本当に不快な瞬間はどうでしょうか？ 展開パイプラインから始めましょう。 マイクロサービスの約束の1つは、マイクロサービスを個別に展開およびリリースできることです。 構築または拡張している1つのシステムに対して1つの開発および展開パイプラインを使用することに慣れている場合は、おそらくそれをお楽しみいただけます。 マイクロサービスを使用すると、個々のコンポーネントに個別のパイプラインを作成できます。



怒り



コンポーネントの最初のバージョンをリリースすることはそれほど難しくありません。 シンプルなJenkinsパイプラインから始めましたが、現在はTeamCityを検討しています。 4つの異なる環境があります。 1つは開発用、1つはテスト用、1つは採用用、さらにもちろん運用環境です。 ほとんどのコンポーネントが独自のデータベースを持っているコンポーネントを徐々にリリースし始めたので、運用チームのサポートと協力なしにはこれを実現できないことに気付きました。 運用活動をチームに統合して、継続的な配信体制に徐々に進化することを期待しています。 現在、運用チームからサポートを受けるのに十分な問題があります。 現時点では、これらはシステム全体の四半期ごとのリリースに使用されており、個々のコンポーネントの展開に切り替えることを望んでいません。



懸念の別の原因はバージョン管理です。 相互作用する複数のアプリケーションのバージョンを制御するのが既に十分に難しい場合、必要なサービスを提供するためにそれぞれが他の多くに依存している何百ものアプリケーションとコンポーネントについて何と言えますか？ もちろん、マイクロサービスのパラダイムで約束されているように、サービスはすべて独立しています。 しかし、一緒にいるだけで、サービスはシステムに変わります。 すべての美しいマイクロサービスアーキテクチャがバージョン化された地獄にならないようにするにはどうすればよいですか？これは、地獄DLLの直接の子孫であると思われますか？



正直なところ、現時点ではこのトピックについて良いアドバイスをすることはできませんが、誠実な警告も役立ちます。 簡単な3桁の番号付けスキーム（1.2.5など）から始めました。 軽微なエラーがなくなると、右の図が変わります。 コンポーネントに小さな新しい関数が追加されると平均値が変わり、インターフェースに大きな変更が加えられたコンポーネントの新しいバージョンをリリースすると左の図が変わります。 定期的なインターフェイスの変更を推奨しているわけではありませんが、実際に変更されています。



さらに、コード化されたテストとSoapUIで作成したテストの両方を使用して、アセンブリ中にサービスをテストします。 また、スマートユースケースの要件と、UMLを使用してアプリケーションとコンポーネントのドメインモデルを文書化します。 将来、システムを「健全な」状態に保つために、たとえばエンコードされたサービスにSwaggerを追加するなどの予防措置を講じる必要がありますが、判断するには時期尚早です。

ホッケースティックモデル

判断するには早すぎますか？ はい、約1年間マイクロサービスの道を歩んできました。 そして、私たちはまだ天国への階段を上っているか、地獄への道を進んでいるかを理解していません。 私は、このパラダイムを機能させる技術を持っていると本当に信じていますが、歴史的な前任者の場合のように、私たちはその中間のどこかにいると信じています。 そして、Netflix、Amazon、またはいくつかのファッショナブルなモバイル企業だけでなく、私たちがあなたと一緒に仕事をする普通の中規模企業も意味します。



しかし、それは適切でしょうか？ 実装時間は短縮されますか？ パラダイムが私たちが提供することを約束するすべての美しいものはありますか？ 正直なところ、まだわからない-にもかかわらず、またはマイクロサービスを取り巻くすべての誇大宣伝のためです。 マイクロサービスを取り巻く複雑さを考えると、最初のサービスを立ち上げるのに多くの時間がかかることに気づき、このラインを通過しました。 数週間前、Building Microservicesの著者であるSam Newmanとビールを飲みました。 サムは彼の例で私の観察を確認し、それをホッケースティックモデルと呼びました。







最初のサービスをリリースする準備が整う前に、多くのことを行う必要があります。 インフラストラクチャを検討するには、RESTを正しく適用し、展開パイプラインを構成し、まずソフトウェア開発の考え方を変更する方法を見つけます。 ただし、最初のサービスが開始されて機能するとすぐに、新しいサービスがより早く表示されます。

我慢して

去年何を学んだかは忍耐です-この言葉は以前私の辞書にはありませんでした。 組織の標準がまだ存在しない場合は、適用しないでください。 プロセスを理解する。 自分で学ぼう。 徐々にやる。 昨日より少しだけ良いことをしてください。 そしていつものように-楽しんでください！



Sander Hugendornのワークショップは9月25日にモスクワで開催され、マイクロサービスアーキテクチャの設計、開発、テスト、展開に専念します。