序文
分散サービスフレームワークには、コアランタイムクラスライブラリだけでなく、サービス部門の原則、サービス指向のベストプラクティス、サービスガバナンス、サービスモニタリング、サービス開発フレームワークなども含まれます。これは、アプリケーションを支援するための完全なソリューションセットですサービス指向の変換を行い、サービス指向の価値を最大化するために、ビジネスシナリオに適したサービス指向システムを構築する方法をユーザーに案内します。
分散サービスフレームワークに基づいて、ビジネスは最終的にすべてのエネルギーをアプリケーションレイヤーのロジック開発に充てることができ、研究開発の効率とシステムの信頼性が大幅に向上しました。現在、Huawei Telecom Softwareの主なソリューションのほとんどすべてのJavaシステムは分散サービスフレームワークに基づいており、基盤となる基本的なフレームワークは統合されています。
近年、DevOpsとDockerが主導するコンテナテクノロジーの開発に伴い、マイクロサービスアーキテクチャは次第に人気を博しています。マイクロサービスアーキテクチャの人気は、その不可避の歴史的理由にあります。これは、アジャイル開発、インフラストラクチャのサービス、DevOps、高速インターネット業界です。開発の統合製品。Amazon AWS、Netflixなどはすべてマイクロサービスの成功者であり、中国ではますます大規模なアプリケーションがマイクロサービスアーキテクチャに進化すると考えられています。
Huawei SoftwareのJavaアーキテクチャは、従来のMVC垂直アーキテクチャ-RPCフレームワーク-分散サービスフレームワークを経験しており、現在Docker + microservicesの方向に進化しています。サービス指向アーキテクチャ全体の進化は、業界の技術変化の縮図でもあります。
したがって、分散サービスフレームワークとマイクロサービスはどちらも、建築家にとって重要な基盤であり、不可欠な技術でもあります。友人は、このコンテンツの学習に注意を払う必要があります。
ちょうど今日、私はこれらの2つの技術的な知識を皆のために準備しました。それを転送して、より多くの人々に利益を与えたいと思います！
目次、目次、特定の章から、これらの2つの知識の部分を1つずつ紹介します。
まず最初に紹介するコンテンツは、分散サービスフレームワークの原則と実践です。
1.ディレクトリ
2.主な内容
第1章、アプリケーションアーキテクチャの進化
ビジネスの発展に伴い、アプリケーションの規模は拡大し続け、システム内にBig Macアプリケーションがますます増えています。従来の垂直型アプリケーションアーキテクチャでは、複雑なサービスがもたらすさまざまな課題に対処できなくなりました。ビジネスの共通機能をアトミックサービスに抽象化することで、複雑なアプリケーションは水平方向に分割され、サービス指向になり、サービスのコンシューマーとプロバイダーは分離されます。パブリック機能の抽出と再利用により、パブリックモジュールの繰り返し開発と構築のコストを効果的に削減できます。
従来の垂直アーキテクチャー変換の中核は、アプリケーションをサービスに変換することであり、サービス変換で使用されるコア技術アーキテクチャーは、分散サービスフレームワークです。
この章では、アプリケーションアーキテクチャの進化の歴史を分析します。これにより、読者は、アプリケーションアーキテクチャの歴史的な進化プロセスと将来のアーキテクチャの開発方向をより明確かつ包括的に理解できるようになります。
第2章、分散サービスフレームワークの概要
進化し続ける大規模アプリケーションでは、新しいビジネス要件と機能が増加し続け、テクノロジーは常に進化しています。さまざまなチームによって構築された機能サブシステムは、さまざまな技術アーキテクチャを使用しており、サブシステム間の開発、展開、運用および保守モードも大きな違いがあります。企業に技術統合のための統一されたサービスフレームワークがない場合、開発および運用と保守の効率は大幅に制限されます。
従来の垂直アーキテクチャー変換の中核はサービスアプリケーションであり、サービス変換で使用されるコアテクノロジーは分散サービスフレームワークです。
第3章、コミュニケーションフレームワーク
スタンドアロンバージョンのローカルメソッド呼び出しがリモートサービス呼び出しになった後、高性能の一般的な通信フレームワークが分散サービスフレームワークの重要な部分になります。
通信フレームワークには、ソケット通信、マルチスレッドプログラミング、プロトコルスタック、およびJavaテクノロジスタックで習得するのが難しいその他の関連知識が含まれます。この章では、コミュニケーションフレームワークの原則と設計のポイントを詳しく説明し、コミュニケーションフレームワークの設計のポイントを誰もができるだけ早く理解し、実際の作業で柔軟に使用できるようにします。
第4章、シリアライゼーションとデシリアライゼーション
サービスプロバイダーとコンシューマーはネットワークを介して通信します。オブジェクトはシリアル化および逆シリアル化する必要があります。一般的なシリアル化および逆シリアル化の方法は多数あります。選択方法が重要で難しい点です。
第5章、プロトコルスタック
異なるサービスは、パフォーマンスの伝送に異なるプロトコルを使用します。たとえば、異種のサードパーティサービスを接続する場合、通常、HTTP / Restfulなどのパブリックプロトコルが選択されます。異なる内部モジュール間のサービスコールでは、多くの場合、パフォーマンスの高いバイナリプライベートプロトコルが選択されます。
第6章、サービスルーティング
分散サービスフレームワーク。オンラインで実行されているときは、クラスターネットワーキングです。つまり、クラスター内にサービスの複数インスタンスがデプロイされます。コンシューマーがサービスリストから適切なサービスプロバイダーを選択して呼び出す方法は、サービスを含みます。ルーティング。分散サービスフレームワークは、ユーザーの柔軟なルーティングニーズに対応できる必要があります。
第7章、クラスターのフォールトトレランス
クラスタサービスの呼び出しが失敗した後、サービスフレームワークは最下層で自動的にフォールトトレランスを実行できる必要があります。さまざまなシナリオに適した多くのフォールトトレランス戦略があります。この章では、クラスタのフォールトトレランスの機能と設計について詳しく説明します。
第8章、サービスの呼び出し
一般的に使用される同期サービス呼び出しに加えて、分散サービスフレームワークは他のいくつかの形式のサービス呼び出しもサポートする必要があります。この章では、これらの呼び出し方法について詳しく説明します。
第9章、サービスレジストリ
サービスプロバイダーにとっては、サービスを公開する必要があります。アプリケーションシステムは複雑であるため、サービスの数と種類は増え続けていますが、サービスユーザーにとっては、必要なサービスを取得する方法が最も重要です。サービスプロバイダーとサービスコンシューマーの場合は、サービスを提供し、サービスを利用する必要があるため、両方の役割を持つ場合もあります。
サービスのサブスクリプション/リリースを効果的に管理し、アドレス情報をハードコーディングしないようにする方法は、分散サービスフレームワークが解決する必要がある問題です。サービスの統合管理により、内部アプリケーションによるサービスの公開/使用のプロセスと管理を効果的に最適化できます。サービスレジストリは、サービスのサブスクリプション/公開の管理に特に使用される構成管理ノードです。
第10章、サービスの公開と参照
サービスプロバイダーは、構成、注釈、API呼び出しなどを通じて、ローカルサービスの公開をリモートサービスとしてサポートする必要があります。コンシューマーの場合、リモートサービスプロバイダーをピアツーピアで参照して、サービスの公開と見積もりを行うことができます。
第11章、サービスグレースケールパブリッシング
グレーリリースとは、黒と白の間をスムーズに移行できるリリース方法を指します。
ABテストはグレーリリース方式です。一部のユーザーがAを使い続け、一部のユーザーがBを使い始めます。ユーザーがBに異論がない場合は、範囲を徐々に拡大し、すべてのユーザーをBに移行します。グレーリリースはシステム全体の安定性を確保でき、問題を発見して初期グレーレベルで調整してその影響を確実にすることができます。
第12章、パラメーターの受け渡し
サービスコンシューマーとプロバイダーの間で通信する場合、インターフェイスで定義されたリクエストパラメーターに加えて、メッセージプロバイダーのIPアドレス、メッセージコールチェーンのトラッキングIDなど、いくつかの追加パラメーターを運ぶ必要があることがよくあります。これらのパラメーターをビジネスインターフェイス経由で渡すことはできません。合格するには、
このパラメータ転送方法をサポートするには、基盤となる分散サービスフレームワークが必要です。
第13章、複数バージョンのサービス
サービスがオンラインになった後、ビジネスの発展に伴い、機能を変更するか、オンラインBUGを修正する必要があります。サービスがアップグレードされた後、多くの場合、サービスにマルチバージョン管理を採用する必要があります。
サービスのマルチバージョン管理は分散サービスフレームワークの重要な機能であり、サービスの開発、展開、オンラインアップグレード、サービスガバナンスが含まれます。
第14章、フロー制御
リソースがボトルネックになると、サービスフレームワークはコンシューマのフローを制限し、フロー制御保護メカニズムをアクティブにする必要があります。フロー制御には多くの戦略があり、より一般的に使用されるものは、アクセスレートの静的フロー制御、リソース占有の動的フロー制御、コンシューマーの同時接続数の接続制御、同時アクセス数の同時実行制御です。
実際には、より良い結果を得るには、さまざまなフロー制御戦略を包括的に使用する必要があります。この章では、分散サービスフレームワークのフロー制御設計の原則と実践について説明します。
第15章、サービスの低下
大きなプロモーションやビジネスのピーク時には、コアサービスのSLAを確保するために、製品のレビュー、フォーラム、ファンポイントなど、それほど重要ではないビジネスを停止する必要があることがよくあります。
別のシナリオでは、何らかの理由で一部のサービスが利用できないが、プロセスが直接失敗することはありません。プロセスを明確にするために、ローカルのMockサーバーで実装する必要があります。本の読書を例にとると、ユーザーのログイン残高認証サービスが正常に機能しない場合、ビジネスをクリアする必要があり、消費請求書が記録され、ユーザーは失敗を返す代わりに読書を続けることができます。
上記の2つのシナリオでは、分散サービスフレームワークの重要なサービスガバナンス機能であるサービスの低下が使用されます。サービスの劣化には主に2つのモードが含まれます：フォールトトレラントな劣化とシールドされた劣化以下では、2つのサービスの劣化戦略と設計について説明します。
第16章、サービス優先順位スケジューリング
システムの現在のリソースが非常に限られている場合、優先度の高いサービスの正常な動作を保証し、サービスのSLAを保証するには、一部の非コアサービスのスケジューリング頻度を減らし、リソースの占有を解放し、システム全体のスムーズな動作を保証する必要があります。
サービスの優先順位には多くのスケジューリング戦略があります。分散サービスフレームワークでは、サービスが解放されたときに優先順位戦略の設定をサポートできる必要があり、リソースがボトルネックになったときに、ユーザーが構成した優先順位戦略に従ってサービスが実行されるようにスケジュールされます。
第17章、サービスガバナンス
ビジネスの発展に伴い、サービスはますます増えており、オンラインで実行されているさまざまなサービスを調整してサービスのSLAを保証する方法は、サービスアーキテクチャと運用および保守担当者にとって大きな課題です。
事業規模の拡大に伴い、小さなサービスリソースの浪費などの問題が徐々に出てきています。サービス呼び出しのパフォーマンスKPIデータに基づいて容量管理を行い、各サービスのリソース占有率を合理的に割り当て、マシンの稼働率を向上させる必要があります。
オンラインビジネスが失敗した場合、ビジネスを迅速に回復するには、失敗したビジネスのサービスの低下、フロー制御、およびフローの移行を実行する必要があります。
開発チームの継続的な拡大に伴い、サービスの開始はますますランダムになり、同じ機能と異なるサービス名を持つサービスでさえ同時に開始されます。オンラインにするのは簡単で、オフラインにするのは難しいです。サービスのオンラインとオフラインを標準化するには、サービスのリリース前にサービスのプレリリースプロセスに従う必要があります。アーキテクトまたはプロジェクトマネージャーは、オンラインにする必要のあるサービスのリリースをレビューし、レビューに合格した人だけがオンラインにできます。
サービスのオフライン管理と制御に対応し、効率的なオンライン運用を確保するには、サービスを効率的かつ正常に運用するためにサービスを均一かつ効果的に管理するための統合サービスガバナンスフレームワークが必要です。
第18章、分散メッセージのトレース
ビジネス分散アーキテクチャーの開発に伴い、システム間のシステムコールはますます複雑になっています。eコマースからの商品の購入を例にとると、フロントエンドインターフェースの購入操作には、何百ものサービスコールが含まれ、関連するミドルウェアには次のものが含まれます。
◎分散サービス体制
◎メッセージキュー。
◎分散キャッシュ
◎分散データアクセスミドルウェア
◎分散ファイルストレージシステム
◎分散ログ収集
◎その…
バックエンドの分散呼び出しと依存関係を効果的にクリーンアップできない場合、障害の境界設定は非常に困難になります。分散メッセージ追跡システムを使用すると、サービス後にシステムが直面する運用と保守の課題を効果的に解決し、運用と保守の効率を向上させることができます。
第19章、信頼性設計
従来のローカルJava API呼び出しと比較して、プロセスにまたがる分散サービス呼び出しは、失敗のリスクが高くなります。
1）ネットワーク障害：リンクの点滅、読み取りと書き込みのタイムアウトなど
2）シリアライゼーションとデシリアライゼーションが失敗しました。
3）不正なストリーム。
4）サーバーのフロー制御と輻輳保護によって引き起こされるサービス呼び出しの失敗。
5）その他の異常.....
アプリケーションの場合、分散サービスフレームワークは、プラットフォームの下部で障害をインターセプトおよびシールドするのに十分な堅牢性を備えている必要があります。
第20章、マイクロサービスのアーキテクチャ
過去10年間、SOA（Service-Oriented Architecture）アーキテクチャが広く使用されてきましたが、現在、クラウドコンピューティング、モバイルインターネット、Dockerコンテナ、およびその他のテクノロジーの急速な開発と応用により、「マイクロサービスアーキテクチャ」新しいアーキテクチャスタイルは誰からもますます注目されており、特定のビジネス上の問題を実際に解決するために、多くの企業やプラットフォームサービスプロバイダーがこのアーキテクチャスタイルを使用しようとしています。マイクロサービスアーキテクチャの人気は、将来の技術開発トレンドの1つになっています。 。
第21章「サービスのベストプラクティス」
サービスを提供する前は、ビジネスは通常ローカルAPI呼び出しであり、ローカルメソッド呼び出しのパフォーマンスの低下はわずかです。サービス後、サービスプロバイダーとコンシューマー間のリモートネットワーク通信を使用すると、パフォーマンスがさらに低下し、ビジネスコールの遅延が増加すると同時に、ネットワークフラッシュなどの理由により、分散型のコール障害のリスクが高まります。 。サービスフレームワークに十分なフォールトトレランスがない場合、ビジネスの失敗率は大幅に増加します。
パフォーマンスと信頼性の問題に加えて、ノード間のトランザクションの一貫性の問題、分散された呼び出しによって引き起こされる障害の区切りの難しさ、および大規模なマイクロサービスの運用と保守のコストの増加も、分散されたサービスフレームワークによって解決する必要がある問題です。この章では、サービス後に直面する課題を分析し、ソリューションとビジネスのベストプラクティスを示します。
次に、コンテンツマイクロサービス設計の2番目のピースを紹介します
1.ディレクトリ
2.主な内容
第1章マイクロサービス
ドメイン主導の設計、継続的デリバリー、オンデマンド仮想化、インフラストラクチャの自動化、小規模な自律チーム、および大規模なクラスターシステムの人気により、マイクロサービスも登場しています。それは発明されたのではなく、現実の世界から要約された傾向またはパターンです。しかし、前述のこれらの概念がなければ、マイクロサービスの登場は困難です。この本の残りの部分では、これらの概念を統合して、マイクロサービスを構築、管理、および進化させる方法のパノラマビューを提供することを試みます。
多くの組織は、きめの細かいマイクロサービスアーキテクチャが、ソフトウェアをより迅速に提供し、新しいテクノロジーを試す機会を増やすのに役立つと考えています。マイクロサービスにより、技術的な決定に大きな自由が与えられ、不可避の変更により迅速に対応できるようになります。
第2章進化論者
これまで見てきたように、マイクロサービスには多くの選択肢があるため、多くの決定を行う必要があります。たとえば、チームが複数のサービスをマージしたり、1つのサービスを複数に分割したりする場合に、異なるチームが異なるプログラミング仕様を使用する必要があるかどうかなど、使用する異なるテクノロジーの数。これらのアーキテクチャは、頻繁に変化する環境でより速いペースで変更をサポートするため、それに応じてアーキテクトの役割を変更する必要があります。この章での建築家の責任に関する見解は私の個人的な意見であり、歯の塔の定義に対する最後の攻撃を開始したいと思います。
第3章サービスをモデル化する方法
マイクロサービスとは何かがわかったところで、その主な利点を理解していただければ幸いです。あなたはすでにそれを実装したいと思っているかもしれませんよね？しかし、どこから始めますか？この章では、マイクロサービスの利点を最大化し、その欠点を回避するためにサービス間の境界を決定する方法について説明します。しかし、最初に、議論の手段としての製品が必要です。
第4章統合
私の意見では、統合はマイクロサービスに関連する最も重要なテクノロジーの1つです。うまくやれば、マイクロサービスは自律性を維持でき、独立して修正および公開できます。しかし、うまくやらないと、災害が発生します。この章が、マイクロサービスの移動中にSOAで発生した問題を回避するのに役立つことを願っています。
第5章モノリシックシステムの分解
前の章では、優れたサービスとは何か、小規模なサービスでより良い結果が得られる理由、およびシステムの進化可能性の重要性について説明しました。しかし実際には、すでに多くのコードベースを手にしている可能性があり、それらはすべて例外なく上記のパターンに従っていません。モノリシックシステムを段階的に分解するにはどうすればよいですか？
モノリシックシステムの形成は、1日の作業ではありません。開発者は毎日、システムに新しい機能と新しいコードを追加します。しばらくして、それは組織内で恐ろしく巨大な存在になり、誰もそれを変更したくありませんでした。しかし、心配しないでください、それは絶望的ではありません。適切なツールを使用している限り、このモンスターを斬ることができます。
第6章部署
モノリシックシステムを展開するプロセスは非常に簡単です。ただし、多くの相互依存するマイクロサービスでは、展開は完全に異なります。導入方法が不適切な場合、導入方法が複雑になるため、苦痛を伴います。この章では、きめの細かいアーキテクチャでマイクロサービスをより適切に展開するのに役立ついくつかのテクニックとテクニックについて説明します。
継続的インテグレーションと継続的デリバリーから始めます。これらの概念は、以下で説明するトピックとは異なりますが、関連しているため、これらを理解することで、何をビルドするか、どのようにビルドするか、およびどのようにデプロイするかを検討するときに、より良い意思決定を行うことができます。
第7章テスト
プログラミングを始めて以来、自動テストの世界は日々変化しており、新しいツールやテクノロジーがほぼ毎月登場し、常に世界を前進させています。ただし、分散システムの機能を効率的かつ効果的にテストする方法は依然として課題です。この章では、きめの細かいシステムが直面する問題と課題を分析し、新しい機能をより自信を持ってリリースするのに役立ついくつかのソリューションを提案します。
テストの対象範囲は非常に広く、自動テストだけが議論されている場合でも、多くの考慮事項があります。マイクロサービスアーキテクチャを使用した後、テストの複雑さが増しています。このような課題に直面した場合、さまざまな種類のテストを理解することが非常に重要です。魚とクマの足には互換性がない場合があるため、ソフトウェアをできるだけ早く提供することと高品質のソフトウェアを維持することのバランスをとるのに役立ちます。
第8章モニタリング
以前に示したように、システムをより細かい粒度のマイクロサービスに分割すると、多くの利点があります。ただし、本番システムの監視が複雑になります。この章では、システムの監視と位置決めの問題において、きめ細かいシステムが直面する課題について説明すると同時に、両方を実現するためのいくつかの対策を紹介します。
次のようなシナリオを想像してみてください。金曜日の静かな午後に、チームは早めにバーに忍び込み、週末を仕事から離れることを楽しみにしています。しかし、突然メールが届きました：ウェブサイトが正常に機能していません！Twitterはあなたの会社のウェブサイトの問題についてのニュースでいっぱいで、上司が脇でおしゃべりをしていて、静かな週末が去っています。
最初に知っておくべきことは何ですか？問題はどこにありますか？
モノリシックアプリケーションの世界では、調査を開始する場所について少なくとも非常に明確にする必要があります。ウェブサイトが遅い？それは一体型のアプリケーション問題です。Webサイトに何か問題がありますか？これは一体型のアプリケーションです。CPU使用率は100％ですか？それでもシングルブロックアプリケーションの問題です。焦げ臭いですか？単一障害点は問題の調査を大幅に簡略化できます！
さて、マイクロサービスベースのシステムに戻りましょう。ユーザーに提供する機能は複数の小さなサービスで構成されており、その一部は機能を完了するためにより多くのサービスを統合する必要があります。この方法には多くの利点があります（これは良いですが、そうでなければこの本は時間の無駄ですか？）しかし、監視の世界では、より複雑な問題に直面しています。
これで、監視する複数のサービス、フィルタリングする複数のログがあり、ネットワークの遅延が原因で複数の場所で問題が発生する可能性があります。対処方法？整理する必要があります。そうしないと、混乱につながり、混乱する可能性があります。これが、金曜日の午後に（またはいつでも！）直面する最後の状況です。
ここでの答えは簡単です。小さなサービスを監視し、それらを集約して全体を確認します。その方法を示すために、最も単純なシステムである1つのノードから始めます。
第9章セキュリティ
さまざまな危険な個人にデータを公開した大規模システムでのセキュリティ違反については、あまりにも多くの話を聞きました。最近のエドワードスノーデンリークにより、会社が保持するユーザー情報の価値と、顧客向けに構築されたシステムに保存されているデータの価値をより意識するようになりました。この章では、システムを設計するときに安全性の観点から考慮すべきいくつかの問題について簡単に説明します。セキュリティのすべての側面をカバーすることは不可能ですが、さらなる調査のための良い出発点を提供するために、いくつかの主要なオプションがリストされます。
あるポイントから別のポイントへの転送中にデータを保護する方法と、他の状況でデータを保護する方法を考慮する必要があります。基盤となるオペレーティングシステムとネットワークのセキュリティを考慮する必要があります。考慮すべき点が多すぎ、実行できることが多すぎます！どのくらい安全ですか？何が十分に安全かをどうやって知るのですか？
人的要因も考慮する必要があります。誰が私たちのシステムを使用しており、彼は何をしますか？これは私たちのサーバーとの相互作用とどのような関係がありますか？ここから始めましょう。
第10章コンウェイの法則とシステム設計
これまでのところ、この本の内容のほとんどは、きめの細かいアーキテクチャに移行するときに直面する技術的な課題に焦点を当てています。しかし、それに加えて、組織的な問題も考慮する必要があります。この章では、会社の組織構造を無視することの危険性について学びます。
私たちの業界はまだ若く、絶えず自分自身を改革しているようです。しかし、いくつかの主要な法律は時の試練に耐えてきました。たとえば、ムーアの法則では、集積回路に収容できるトランジスタの数は2年ごとに2倍になるとされています。法律は驚くほど正確であることが証明されています（この傾向が鈍化したと予測されている人もいますが）。私の日常業務でほぼ普遍的に適用され、より有用であると私が思う別の法律があり、それはコンウェイの法律です。
第11章スケーリングされたマイクロサービス
本の小さな例を扱うと、すべてがシンプルに見えますが、現実の世界ははるかに複雑です。マイクロサービスアーキテクチャが単純なものからより複雑になるとどうなりますか？失敗したり、何百ものサービスを管理したりする複数の独立したサービスに対処する必要がある場合、どうすればよいですか？人よりもマイクロサービスの方が多い場合、レスポンスモードはありますか？一緒に答えを見つけましょう！
第12章まとめ
前の章では、マイクロサービスの定義から、境界を分割する方法まで、統合テクノロジーからセキュリティやモニタリングまで、多くのコンテンツについて説明しました。マイクロサービスアーキテクチャでのアーキテクトの役割についても説明しました。各マイクロサービス自体は小さいですが、アーキテクチャへの影響は非常に広く素晴らしいため、まだ学ぶべきことがたくさんあります。この章では、本全体を通していくつかの重要なポイントを要約してみます。
総括する
記事の内容の制限のため、エディターはここではあまり紹介しません。これら2つの部分の実際の技術ドキュメントの完全版が必要な場合は、次のエディターを転送し、下の画像を直接表示し、コードをスキャンしてエディターに追加またはプライベートメッセージを送信できます。 [テクノロジー]是非入手してください！！
私はあなたの過去に参加する時間はありませんが、私はあなたの将来にあなたと一緒にいます！
引き続き技術的な知識を共有してください。気に入っていただければ幸いです。！