1.はじめに
誰もがマイクロサービスアーキテクチャについて話しています。庭にはマイクロサービスに関する記事もたくさんあります。数日前、庭の友達からマイクロサービスアーキテクチャのいくつかのテクノロジーについて尋ねられました。マイクロサービスアーキテクチャのテクノロジースタックのロードマップを整理しました。ここで私はあなたと共有して議論し、初心者がマイクロサービス関連のテクノロジーをより深く理解できるようにします。
第二に、技術スタック
2.1労働者が自分の仕事をうまくやりたい場合は、まず彼の武器を研がなければなりません
インターネットの時代になると、インターネット製品も次々と登場していますが、人気のあるインターネット製品には比較的技術的なチームがあります。
ことわざにあるように、労働者が自分の仕事をうまくやりたいのなら、彼は最初に彼の武器を研がなければなりません。優れたエンジニアは、フレームワークとツールの使用に優れている必要があります。マイクロサービスでのテクノロジーの選択は簡単ではありません。長期にわたる困難なプロジェクトの後で完成させる必要があります。
以下では、テクノロジースタックのメインフレームワークとツールの使用シナリオを1つずつ共有します。この記事では、実際の例を1つずつ共有しません。
2.2マイクロサービス
マイクロサービスを「マイクロ」にする方法は？
マイクロサービスはもちろん、コアは「マイクロ」がテーマですが、どのようにマイクロするのですか？それはどのように減らすべきですか？私が初めて杭州に来たとき、私は電子商取引システムと連絡を取りました单体架构。このシステムは比較的大きく、電子商取引が持つべきさまざまなビジネスロジックとシナリオを組み合わせています。
コードの維持も困難です。結合度が高すぎ、ビジネスロジックの変更は基本的には動きです。先月共有
したAsp.Net CoreのIdentityServer4承認センターの実用的なアプリケーションに関する記事のeコマースシステムの元のアーキテクチャ図も同様です。 、次のように：
次に、このアーキテクチャについての「マイクロ」トークがあります。
ここでは单体架构、原則として次の「マイクロ」サービスを実行できます。
- ビジネス、1つのビジネス、1つのサービスの原則に従って分割し、ユニバーサルビジネスサービスモジュールを実現して、ビジネスが高い凝集度と低い結合度を実現できるようにします。後で必要なビジネスを変更できます。このビジネスのビジネスマイクロサービスを変更するだけでよく、他のビジネスには影響しません。
- ビジネスモジュールと独立したデータベースが原則であり、相互に並行するサービスが相互に呼び出す必要はありません。
- 外部APIゲートウェイはビジネスロジックを統合します。
- ビジネスデータベースとマイクロサービスが原則です。
- 分散サービスと組み合わせることで、迅速なイテレーションとスムーズなリリースが可能です。時間の影響を受けず、瞬時にリリースでき、深夜12時までリリースする必要がありません。（より痛みを伴うリリースは、3日間のボレーのようなものです。ある期間、毎週いくつかの痛みを伴うリリースがありました。1つのリリースは、午前中に4または5になる可能性があります。リリース後、何度もリリースされます。テストの結果、最終的にオンラインで問題を修正する必要があることがわかりました。戻ったとき、他の同僚がすでに仕事に来ていました。当時、私たちの技術責任者は次のように述べています。「彼は1週間息子に会っていません。戻ってください。彼の息子がずっと前に眠りについたとき、彼が仕事に起きたとき、彼の息子はすでに学校に行っていました」、誰もがそのような解放経験を持っていたに違いありません。
上記の原則によると、元のeコマースモノリシックアーキテクチャマイクロサービスのアーキテクチャ図は次のとおりです：
アーキテクチャ図は、意味を示すために大まかに描かれていますDocker。k8sマイクロサービスとその一部は簡単に要約されており、具体的な詳細は描かれていません。図。
マイクロサービスクラスター
マイクロサービスは既に「マイクロ」であり、Consulここで使用する必要があるサービスディスカバリ用のデータセンターが必要です。これはConsul主にサービスの登録、サービスディスカバリ、およびサービスのヘルスチェックに使用されます。必要に応じて特定のビジネスサービスを対象とすることができます自動容量拡張、サーバーの追加、サービスクラスターの拡張サービスがハングした場合、Consulは接続と使用に利用可能なサービスノードを自動的に選択するため、電子商取引システム全体の安定性が大幅に向上します。
詳細Consulな機能と構成については、マイクロサービスアーキテクチャの記事「執務の機能と構成」を5分で読むことができます。
マイクロサービスがデータの一貫性を確保する方法
以前のモノリシックアーキテクチャアプリケーションでは、ビジネス間の結合はトランザクションを通じてデータの一貫性を保証することでしたが、マイクロサービスはどのようにしてデータの一貫性を実現できますか ドアツードアはまた、マイクロサービスはサービス間に依存性がないことを保証する必要があり、各ビジネスは独立したサービスであることを述べています。次に、ビジネスとデータの一貫性を確保する方法も大きな問題であり、これも業界ですマイクロサービスについて論争の的となっているトピック、データの一貫性を確保する方法は？
分散システムアーキテクチャには1つありますCAP理论。どの分散システムでも、一貫性、可用性、およびパーティションの許容範囲という2つのポイントしか満たすことができません。分散システムの場合、パーティションのフォールトトレランスは基本的な要件です。それ以外の場合は、価値が失われます。したがって、選択できるのは可用性と一貫性のどちらかだけです。一貫性を提供することを選択した場合、一貫性が満たされる前に、他の同時アクセスをブロックする代価を支払う必要があります。これは無期限に継続する可能性があり、特にシステムがすでに長い待機時間を示している場合、またはネットワーク障害によって接続が失われた場合は特にそうです。現在の成功体験によれば、ユーザビリティは一般により良い選択ですが、サービスとデータベース間のデータの一貫性を維持することは非常に基本的な要件です。最終的な一貫性を満たすためにマイクロサービスアーキテクチャが選択されます。
最終的な整合性とは、システム内のすべてのデータコピーが、しばらくすると最終的に整合性のある状態になることを意味します。
ここで言及する期間は、ユーザーが許容できる期間でもある必要があります。
一貫性の本質から、ビジネスロジックに含まれるすべてのサービスは成功または失敗します。では、成功または失敗を保証する方向をどのように選択するのでしょうか。ビジネスモデルに応じた選択が必要です。最終的な整合性を達成するための3つのモードがあります。信頼できるイベントモード、ビジネス補償モード、およびTCCモードです。ここでは拡張されません。後で共有して学ぶ機会があります。
2.3マイクロサービスのオープンソースフレームワーク
Iオープンソースのマイクロサービスフレームワーク使用してマイクロサービスアーキテクチャにここにいるcore-grpcオープンソースのフレームワークアドレスします。https：//github.com/overtly/core-grpc
についての物語を共有するために私の目の前にマイクロサービスのアップグレードを[] .NETコアビジネスプラットフォームcore-grpcのコアアプリケーションでは
、マイクロサービスの基本的な概念と長所と短所について簡単に説明しているため、ここでは説明しません。特定のアプリケーションについては、[。net core]をクリックしてください。eコマースプラットフォームアップグレードのマイクロサービスアーキテクチャアプリケーション（core-grpc） ）読書
2.4 ORMフレームワーク
マイクロサービスで使用されているORM Dapper、および使用されているサードパーティのオープンソースコンポーネントはcore-data、オープンソースの作成者がdapperを一度パッケージ化したものであり、オープンソースフレームワークのソースコードアドレスはhttps://github.com/overtly/core-dataです。
core-data主な利点：
- 公式の推奨事項は、DDDドメイン主導の設計アイデアを開発に使用することです
- 複数のデータベースをサポートし、リンク構成に簡単な構成を追加できます
- マルチデータベースのサポート
- サブテーブル操作のサポート、カスタムサブテーブル戦略のサポート
- 式の記述をサポートし、SQLステートメントの記述の機械的作業を削減
- Dapperは拡張できます
- パフォーマンスはDapper自体のパフォーマンスに依存します。Dapper自体は軽量のORMであり、公式のテストパフォーマンスは他のORMよりも強力です
2.5分散追跡システム
マイクロサービスアーキテクチャの人気により、マイクロサービスアーキテクチャでのいくつかの問題はますます顕著になります。たとえば、リクエストには複数のサービスが含まれ、サービス自体は他のサービスにも依存する場合があり、リクエストパス全体がメッシュを構成しますコールチェーン、およびコールチェーン全体の特定のノードが異常になると、コールチェーン全体の安定性が影響を受けるため、「銀の弾丸」という単語が存在しないこと、およびすべてのアーキテクチャに深く感じる利点と欠点があります。
上記の状況では、システム動作の理解とパフォーマンスの問題の分析に役立つツールが必要です。これにより、障害が発生したときに問題をすばやく特定して解決できます。現時点では、APM（アプリケーションパフォーマンス管理）ツールがデビューします。 。
現在、主要なAPMツールのいくつかは、Cat、Zipkin、Pinpoint、SkyWalkingです。ここでは、分散追跡、パフォーマンスインデックス分析、アプリケーションおよびサービスの依存関係分析を含む、優れた国内APMツールであるSkyWalkingを主に紹介します。
2.6システムログの統合
大規模なシステムでは、問題をトラブルシューティングし、関連する機密情報を記録するためにログシステムが必要です。ここではログシステムが必要です。ここではExceptionLessログシステムを選択します。ログはESに書き込まれ、ログ管理、クエリ、および一般的な遭遇のためのビジュアルUIをサポートします問題が発生した場合は、ログ管理のバックグラウンドを直接確認してください。
2.7メッセージキュー
メッセージキューイングミドルウェアは分散システムの重要なコンポーネントであり、主にアプリケーションの結合、非同期メッセージング、およびトラフィックシェービングの問題を解決します。高性能、高可用性、スケーラブル、そして最終的に一貫したアーキテクチャを実現します。最も使用されるメッセージキューは、ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQです。
2.8タスクのスケジューリング
ここでは、Quartz.Netは主にジョブタスクのスケジューリングに使用されます。タスク呼び出しの使用法は何ですか？たとえば、データの一部をカウントする必要がありますが、リアルタイムの統計には多くの連続テーブルクエリが必要であり、データベースのパフォーマンスは比較的低下しているため、夜の特定の時点でデータ統計操作にタスクスケジューリングスキームを使用して前日をカウントできます。データ。
2.9 NoSql
Nosqlは主にMongDB、Redis、Memcacheなどの非リレーショナルデータベースであり、APIゲートウェイとデータベースレベルでデータキャッシュのレイヤーを作成し、頻繁に更新されない一部のデータにアクセスしてキャッシュし、ネットワークリクエストが発生するたびに使用できます。まず、分散キャッシュからデータを読み取り、データベースへのクエリの負荷を軽減し、システムのスループットを向上させます。
2.10視覚的なデータ管理と分析（Kibana）
Kibanaは、Elasticsearch用に設計されたオープンソースの分析および可視化プラットフォームです。Kibanaを使用して、Elasticsearchインデックスに格納されているデータを検索、表示、操作できます。アイコン形式で表示される高度なデータ分析と視覚化を簡単に実装できます。
Kibanaの使用シナリオは、次の2つの側面に焦点を当てる必要があります。
リアルタイムの監視
ヒストグラムパネルを使用すると、さまざまな条件の複数のキューがイベントの複数の次元を取り、さまざまな時系列傾向を組み合わせることができます。時系列データは、最も一般的な監視アラームです。
問題分析
elkの目的のために、対応する商用製品のsplunkシーンを参照できます。Splunkを使用することの重要性は、情報の収集と処理をインテリジェントにすることです。その操作のインテリジェンスは、
データのドリルダウンによる問題の検索、トラブルシューティング、根本原因の分析による問題の解決
、システムの検出とアラームを組み合わせてSLAとパフォーマンスの問題の追跡を容易にするリアルタイムの可視性、
履歴分析です。、傾向と履歴パターン、行動のベースラインとしきい値を見つけ、整合性レポートを生成できます。
2.11プロメテウス
Prometheusは、オープンソースのシステム監視および警告フレームワークです。新世代のクラウドネイティブモニタリングシステムとしてのPrometheusには、従来のモニタリングおよびモニタリングシステム（NagiosまたはZabbix）よりも次のような利点があります。
アドバンテージ
- 管理が簡単
- 内部サービスのステータスに簡単にアクセス
- 効率的で柔軟なクエリステートメント
- ローカルおよびリモートストレージをサポート
- httpプロトコルを採用、デフォルトのプルモードでデータをプル、または中間ゲートウェイ経由でデータをプッシュ
- 自動検出をサポート
- スケーラブル
- 統合が簡単
さて、ここでは、それらのほとんどが紹介されており、誰もが一般的に使用する他のいくつかの技術は、1つずつ紹介されていません。
2.12 .Net Core仮想化
.Net Core新世代の.Net Coreクロスプラットフォーム開発フレームワークは、Windows環境がなくてもLinuxやその他のプラットフォームで構築できます。もちろん、現在人気のあるDockerコンテナを使用して、Dockerコンテナで.netコアプロジェクト仮想化を構築して実行できます。これは、プラットフォームや環境に依存しません。コマンドを使用してイメージを作成するだけで、K8s複数のコンテナを実行することもできます。アプリケーションの展開、オーケストレーション、更新など
k8sとは何ですか？
Kubernetesはオープンソースであり、クラウドプラットフォームの複数のホストでコンテナ化されたアプリケーションを管理するために使用されます。Kubernetesの目標は、コンテナ化されたアプリケーションのデプロイをシンプルかつ効率的（強力）にすることです。Kubernetesは、アプリケーションのデプロイ、計画、更新、メンテナンスを提供します。メカニズム。
Kubernetesのコア機能は、コンテナーを自律的に管理して、クラウドプラットフォーム内のコンテナーがユーザーの希望する状態に従って実行されるようにする機能です（ユーザーがApacheを実行し続けたい、ユーザーがその方法を気にする必要がないなど、Kubernetesは自動的に監視してから実行します）再起動、新しい、つまり、Apacheが常にサービスを提供できるようにする）、管理者はマイクロサービスをロードし、プランナーに適切な場所を見つけさせることができます。同時に、Kubernetesはシステムアップグレードツールとユーザーフレンドリーな側面も備えているため、ユーザーは独自のサービスを簡単にデプロイできますアプリケーション（カナリアデプロイメントと同様）。
現在、Kubernetesは中断のないサービスステータス（Webサーバーやキャッシュサーバーなど）とネイティブクラウドプラットフォームアプリケーション（Nosql）に焦点を当てており、近い将来、バッチ、ワークフローなど、さまざまな本番クラウドプラットフォームのさまざまなサービスをサポートします、および従来のデータベース。
Kubenetesでは、すべてのコンテナがポッドで実行されています。ポッドは1つ以上の関連するコンテナを運ぶことができます。次の場合、同じポッド内のコンテナが同じ物理マシンにデプロイされ、リソースを共有できます。ポッドにはO以上のディスクボリュームグループ（ボリューム）を含めることもできます。これらのボリュームグループは、ユーザーが作成したポッドごとに、コンテナーへのディレクトリの形式で提供されるか、ポッド内のすべてのコンテナーで共有されます。正常で十分な容量があるマシンを自動的に選択し、コンテナのようなコンテナを作成します。コンテナの作成に失敗すると、コンテナはノードエージェントによって自動的に再起動されます。このノードエージェントはkubeletと呼ばれますが、ポッド障害またはマシンの場合、ユーザーがレプリケーションコントローラを定義しない限り、自動的に転送および開始されることはありません。
ユーザーはポッドを自分で作成して管理できます。Kubernetesはこれらの操作を2つの操作に簡略化します。同じポッド構成ファイルに基づいて複数のポッドレプリカをデプロイすること、ポッドがハングしたとき、またはマシンがハングしたときに代替ポッドを作成することです。再起動、移行、その他の動作を担当するKubernetes APIの一部は「レプリケーションコントローラー」と呼ばれます。テンプレートに基づいてポッドを生成し、システムはユーザーのニーズに応じて多くの冗長性を作成します。これらの冗長なポッドは、アプリケーション全体、サービス、またはサービス内のレイヤー。ポッドが作成されると、システムはポッドの正常性と、ポッドが配置されているホストの正常性を継続的に監視します。ポッドがソフトウェアの理由またはハングしたマシンでハングした場合、レプリケーションコントローラは自動的に正常になりますマシン上に同一のポッドを作成して、元のポッドの冗長状態を維持します。アプリケーションの複数のポッドがマシンを共有できます。
多くの場合、ポッドのグループを選択する必要があります。たとえば、ポッドのグループの特定の操作を制限したり、ポッドのグループのステータスを照会したりします。Kubernetesの基本的なメカニズムとして、ユーザーは一連のキーをKubernetes Apiの任意のオブジェクトに貼り付けることができます。値タグの場合、タグを使用して関連するKubernetes Apiオブジェクトのセットを選択し、特定の操作を実行できます。各リソースには追加の（多数の）キーと値のセットがあり、外部ツールはこれらを使用できますキーと値の値はオブジェクトの取得に使用されます。これらのマップは注釈と呼ばれます。
Kubernetesは特別なネットワークモデルをサポートしています。Kubernetesはアドレス空間を作成し、ポートを動的に割り当てません。これにより、ユーザーは使用する任意のポートを選択できます。この機能を実現するために、各ポッドにIPアドレスを割り当てます。
最近のインターネットアプリケーションには、通常、Webフロントエンドスペースや、キーと値のペアおよび対応するストレージサービスを格納するために使用されるメモリサーバーなど、複数のサービスレイヤーが含まれています。固定IPアドレスとDNS名。これらは一連のポッドに動的に関連付けられます。これらは前述のラベルを介して関連付けられるため、ポッド内のコンテナーがこのアドレスにアクセスすると、関連付けるポッドを関連付けることができますこの時点で、このリクエストはローカルプロキシ（kubeプロキシ）に転送されます。各マシンにはローカルプロキシがあり、対応するバックエンドコンテナに転送されます。Kubernetesは、ローテーショントレーニングメカニズムを介して対応するバックエンドコンテナを選択します。これらの動的ポッドが置き換えられると、Kubeプロキシが追跡を続けるため、サービスのIPアドレス（dns名）が変更されることはありません。
ポッドなど、Kubernetesのすべてのリソースは、URIと呼ばれるもので区別されます。このURIにはUIDがあります。URIの重要なコンポーネントは、オブジェクトタイプ（ポッドなど）、オブジェクト名、オブジェクトネームスペース、特別なオブジェクトタイプの場合、同じ名前空間ではすべての名前が異なります。オブジェクトが名前のみを提供し、名前空間を提供しない場合、この状況がデフォルトの名前空間であると想定されます。UIDは時間と空間で一意です。
2.13自動統合デプロイメント
自動統合導入が必要なのはなぜですか？
自動統合展開が必要な理由を次の点から分析します。
- 手動での展開、リリース、および更新はすべて信頼性が低く、自動化されたインテリジェントな展開で事故率を減らすことができると信じなければなりません。
- 更新の人工的なバックアップとリリースは非常に非効率的です。
- プロジェクトを更新する必要があるが、このマイクロサービスに数十程度の負荷がある場合、1つずつサーバーを更新して公開するのは非常に面倒で、事故を引き起こす可能性が高くなりますか？
自動統合デプロイメントとは何ですか？
することでjenkins、gitlab、dockerおよびその他のスクリプトツールは、ミラープッシュ倉庫にコード、および事前のダイナミックで書かれた提出への依存、自動化された建設プロジェクトミラー、ミラーを監視、ドッカーはミラー、スタートアップ項目および他の自動スクリプトの処理を引き上げ、スムーズな1サービスすることができ停止して更新します。すべての操作に人間の介入は必要ありません。ワンクリックで問題をロールバックすることもできます。
自動統合デプロイメントの利点は何ですか
- 人間の介入なしにすべてが自動化され、効率が向上します。専門家は、専門的なことを実行し、開発と開発を適切に行い、維持と管理を適切に行うことができます。
- リリース追跡可能性
- 人間の介入により、いつでもロールバックできます（スクリプトを使用して、以前の自動バックアップのプロジェクトイメージを確認します）
- ユーザーエクスペリエンスに影響を与えることなくスムーズにリリースされ、各サーバーが切断され、更新がリリースされます。
3.まとめ
今日はたくさん書いて、絵を描いても止まりません。この記事では、.netコアマイクロサービスアーキテクチャで使用されている一連のテクノロジーの使用シナリオと使用法を分析します。実用的なことはありません。Xiaobaiにマイクロサービスアーキテクチャに関連するテクノロジーをさらに習得するための明確な技術的方向性。以前の経験を整理して要約できるため、より大きな目標に向かって進むことができます。今後もドライグッズや実用的なものをお届けします。[Dr。dotNET] WeChat公開番号に注目してください。
