マイクロサービス 101: 良い点、悪い点、そして醜い点

マイクロサービスが人気の波に乗っているため、記憶が浅い人は見落としているかもしれません。 このアプローチは、20 年前に初めて登場したサービス指向アーキテクチャと驚くほど似ています。 前。

しかし、Red Hat のエンジニアリングミドルウェア担当副社長である Mark Little 博士は、マイクロサービスをマイクロサービスの良い部分と見なすことを好みます。 より洗練されたエンジニアリングおよび運用テクノロジーの登場によって強化されたサービス指向アーキテクチャ そしてテクニック。

「違いは、これがソフトウェアと分散ソフトウェアの開発に対する新しいアプローチによって大きく推進されていることです。 Linux コンテナのようなもの - Docker がその代表的な例です。 これで、不変のサービスが手に入り、それらのサービスを調整するための Kubernetes なども手に入ります。そして明らかに、アジャイルの影響を強く受けた DevOps も手に入ります」とリトル氏は語った。

「これらのことは、人々が過去に分散システムを行った方法を真剣に振り返るきっかけとなっています。 - サービス指向アーキテクチャはその例です - そして、それらに一致する最適なビットを選択します テクノロジー。 またはその逆、サービス指向アーキテクチャの優れた部分の一部に一致するテクノロジーを見つけます。 おそらくそれが違いです。 アーキテクチャのアプローチは変わりませんが、その背後にあるテクノロジーは実際には異なります。」

マイクロサービス アーキテクチャでは、アプリは特定のタスクを実行し、API を使用して相互に通信する小さな半自律プロセスのスイートとして構築されます。 マイクロサービスは使いやすく、スケーラブルであることを目的としており、Web、モバイル、IoT アプリでの利用が増えています。

サービス指向アーキテクチャの歴史的な欠点の中で、リトル氏は、サービス間で適切なコントラクト定義を提供できなかったことを挙げています。 クライアントとサービス、および疎結合と分散に弱い WSDL (Web サービス記述言語) の欠点 システム。

ただし、多くの要素とテクノロジーが集まってマイクロサービスが現在のアーキテクチャになったからといって、それが順風満帆になるわけではありません。

「マイクロサービスが世界平和への答えではないことを認識することが重要です。 それはいくつかのことに適しています。 それは何でもそうです。 マイクロサービスを採用したからといって、不適切に設計された泥団子が突然非常に適切に設計され、泥団子でなくなるわけではありません。 それはただ大量の泥の塊が散らばっているだけかもしれない」とリトル氏は語った。

「それはちょっと心配です。 私はサービス指向アーキテクチャに長い間携わっており、良い点も悪い点も知っています。 私はマイクロサービスが好きです。なぜなら、マイクロサービスによって良い点に集中できるからです。しかし、マイクロサービスが決して答えにはならない多くの問題の答えであると人々がみなしているのが心配です。」

マイクロサービスを検討している場合、適切なソフトウェア エンジニアリングの実践から始めるのが最善です。

「基本的に、それがサービス指向アーキテクチャの背後にあるものでした。 そこから始めなければ、Docker を使用しているか、仮想化や Java を使用しているかは関係ありません。 仮想マシンであろうと何であろうと、適切なツールではアーキテクチャの問題は解決されません。」 言った。

マイクロサービス、さらにはサービス指向アーキテクチャが真価を発揮するのは、ロジック サービスです。 相互に独立して展開でき、他のサービスとは独立して拡張でき、独立したフェールオーバーが可能です。

「マイクロサービスに関して私が懸念していることの 1 つは、モノリスがあり、それをサービスに分解し始めるとします。 それを恣意的に行うと、分解しすぎて、10 個、さらには 100 個、あるいは 1,000 個のマイクロサービスができてしまう可能性があります。」 言った。

「しかし、それらはすべて互いに依存し合っているため、そのうちの1つがダウンした場合、残りも同様にダウンしたも同然です。 その場合、あなたは自分自身に何も買ったことになりません。 999 個のサービスが残り、他のサービスが復旧するのを待っています。」

Little 氏によると、これからマイクロサービスを始める人は、古いという理由だけでソフトウェアを選ぶのではなく、その機能を発揮できていないソフトウェアを特定する必要があります。

「実際に自分にとってうまくいっていないものを取り上げてください。私が強調したいのは、自分にとってうまくいかないのは、一枚岩になってしまう可能性があるからです」 現在、それは過去 30 年間うまく機能しており、1 年 365 日、投げかけられる負荷に非常に喜んで対処しています。」 言った。

「その場合、それをマイクロサービスに分割しても、おそらくあまり利益は得られません。 しかし、まったく逆の一枚岩が存在する場合もあります。つまり、何年にもわたって、さまざまなチームが行き来して何かが構築され、継続的にパッチを適用する必要がある場合です。

「これはかなり信頼性が低く、さまざまな言語で実装されているため、とにかく再実装することを考えているかもしれません。 それはマイクロサービスの良い候補になる可能性があります。」

アプリケーションの機能と、アプリケーションが提供できない箇所を十分に把握するとともに、 その中のどのコンポーネントがマイクロサービスに分解できるかを理解する必要がありますが、 さらに遠く。

「あまりにも小さなマイクロサービスに分割することは望ましくありません。 ナノサービスについて話している人もいますが、これは少し行き過ぎです。 あまり遠くに行かないでください。 成功をどのように測定するかを理解します。 これは一般的に重要ですが、マイクロサービスではさらに重要です」とリトル氏は語った。

ソフトウェアが動作しない場合でも、保持される要素がある可能性があるため、すべてを最初から再実装することは避けてください。

「うまくいかないものがある場合でも、切り取って保存できるものがないかどうかを検討する必要があります。特に次のような場合は、 20 年または 30 年にわたって導入されており、多くの人が導入しており、特に COBOL で実装されている場合は、十分なテストが行​​われています。」 言った。

「たとえば、クリスマスの日のリクエストの規模は 30 年前に比べて桁違いに増加しているため、今日はすべてがうまく機能しているわけではないかもしれません。 しかし、それは、その COBOL コードに、取得して再利用できる基本的な部分がないという意味ではありません。 新しいシステムにバグを入れるつもりなら、それを新しいバグにする必要があるため、そうすべきです。 修正した古いバグを再実装する必要はありません。」

したがって、他のものとは別にデプロイできる作業単位を特定すると、失敗しても残りの部分に問題が発生することはありません。 アプリケーションが停止するまで停止し、他のすべてから独立して拡張することもできる場合、次のステップは、どのような契約を行うかを検討することです。 それを使って定義します。

「そのコントラクトには、そのインターフェイスが含まれます。リモートでどのように呼び出すのか、何を使ってリモートで呼び出すのか? 多くの人がマイクロサービスと REST (Representational State Transfer) について話していますが、間違いなく、REST はマイクロサービスの基本的なアプローチです。 しかし、それがサービスと会話する唯一の方法であるとは限りません」とリトル氏は語った。

「バイナリ プロトコルを使用して通信するとよいでしょう。 いくつかの従来のプロトコルを使用して通信する以外に選択肢がない場合があります。 COBOL では、マイクロサービスに移行しているにもかかわらず、アーキテクチャのかなりの部分が依然として CORBA [Common Object Request Broker Architecture] に関連付けられている可能性があります。 これはマイクロサービスと通信する唯一の方法ではないかもしれませんが、どこかに CORBA アダプターが必要になる場合があります。」

次に、スケーリングするマイクロサービスを作成し始めると、典型的な分散システムの問題が発生します。 独立して、HTTP またはバイナリ プロトコルを介したリモート インタラクションは、メモリ内手順よりも遅くなります。 呼び出します。

「したがって、特に応答時間に関して厳しい要件がある場合には、リモート サービスを呼び出すことが何を意味するのかを考慮する必要があります。 マクロサービス、マイクロサービス、ナノサービスなど、これらのものをサービスに分割すればするほど、分散環境で実行しているのではないかという心配がさらに大きくなります。 それは私にとって何を意味するのでしょうか? 実際、私のアプリケーションはそれを許容できるでしょうか?」とリトルは言った。

「私が本当にマイクロサービスを望んでいるのかもしれないが、残念ながらマイクロサービスがそれを使用するネットワークを発明するまでは タキオンを使ってメッセージを送信しても、契約を履行できないため、実際には何も呼び出すことができません 義務。 すべてを大きな泥の中に入れなければなりません。」

マイクロサービスの詳細

• 香港の企業 Mashape が API とマイクロサービスのリアルタイム分析を発表
• MicrosoftのAzureマイクロサービスプラットフォームでLinux、Java、コンテナのサポートが開始される
• Kong がオープンソース化: Mashape はこれを最初のマイクロサービス管理レイヤーと呼ぶ
• Microsoft、新しいマイクロサービス Service Fabric の最初の開発者プレビューを準備
• Microsoft、モバイル、クラウド中心の新しい「PowerApps」を準備
• マイクロサービス アーキテクチャを推進する 3 つの力
• サービスは新たなモノリスになったのでしょうか? マイクロサービスの事例
• マイクロサービスは本当にあるのでしょうか、それとも単なる最新のバズワードなのでしょうか?
• Microsoft の Azure 向けマイクロサービス ビジョンが具体化し始める
• マイクロサービスを通じて、シンプルさと IT ミニマリズムを新たに推進
• クラウドを実行するためのより良い方法として提案されたマイクロサービス