マイクロサービスの開発の過去数年間で、新しいテクノロジーとコンセプトが際限なく出現しました。これらのテクノロジーの導入は、基本的にサービスの安定性とビジネス開発効率の向上に重点を置いています。過去2年間、サービスグリッドはマイクロサービスユーザーの大多数によってますます使用されています。認知。
Kubernetesがクラウドネイティブ時代のオペレーティングシステムになった今日、Kubernetesエコシステムをより適切に採用し、クラウドへの迅速なビジネス移行を実現し、クラウドコンピューティングによってもたらされる機能を享受する方法。その中でも、サービスメッシュは重要なテクノロジーです。サービスグリッドの使用中に、既存のアプリケーションをサービスグリッドに移行する方法、複数の言語とフレームワークの相互運用性とガバナンスをサポートする方法、使用方法など、多くの問題が発生します。問題をトラブルシューティングするための監視可能な製品。サービスグリッドへのアクセス方法、異種サービスフレームワーク、言語の相互運用性、監視可能性の3つの側面からこの質問に答えます。
アプリケーションをサービスグリッドに移行する
サービスメッシュ
サービスメッシュは、サービス間の通信を処理するために使用される専用のインフラストラクチャレイヤーであり、最新のクラウドネイティブアプリケーションを含む複雑なサービストポロジを介したリクエストの信頼性の高い配信を担当します。実際、サービスグリッドは通常、軽量ネットワークエージェントのセットを介して実装されます。これらのエージェントは、アプリケーション自体を意識する必要なしに、アプリケーションコードと一緒にデプロイされます。
現在の主流のサービスグリッドオープンソースソフトウェアはIstioであり、その全体的なアーキテクチャは次のとおりです。
この図から、サービスグリッドとビジネスコンテナは同じポッド内の異なるコンテナであることがわかります。これには、次の3つの利点があります。
1.マイクロサービスガバナンスとビジネスロジックの分離。サービスグリッドは、SDKのほとんどの機能をアプリケーションから取り除き、それを独立したプロセスに分解し、サイドカーモードで展開します。サービスグリッドは、サービス通信と関連する管理および制御機能をビジネスプログラムから分離し、基盤ファシリティレイヤーは、それをビジネスシステムから完全に切り離し、開発者がビジネス自体により集中できるようにします。
2.異種言語/フレームワークの統一されたガバナンス。新しいテクノロジーの開発と、異なる言語の人員、アプリケーション、サービスの置き換え、および異なるフレームワークが同じ会社に現れることがよくあります。これらのサービスを統一された方法で管理および制御できるようにするために、過去の慣行は完全なSDKは、維持に非常にコストがかかり、企業のミドルウェアチームに大きな課題をもたらします。サービスグリッドを使用すると、本体のサービスガバナンス機能がインフラストラクチャと多言語に組み込まれます。サポートが提供されます。はるかに簡単です。
3.サービスグリッドは、トラフィックプロキシを想定できるだけでなく、ビジネスの一般的および一般的なシナリオと要件のサービスグリッドの一部になることもできます。これにより、ビジネス開発の効率を効果的に向上させることができます。
アプリケーションアクセスサービスグリッド
現在、サービスグリッドは最も完全なKubernetesをサポートし、VMアプリケーションアクセスもサポートしていますが、より多くの構成が必要です。VM上のサービスをコンテナ化してからグリッドに接続し、既存のサービスを徐々に移行することをお勧めします。アプリケーション。ゲートウェイを介して、サービスグリッド内のアプリケーションとサービスグリッドに接続されていないVMを開きます。
サービスグリッドにアクセスするには、最初にIstiodをインストールしてから、名前空間をマークしてSidecarの自動挿入を完了する必要があります。主に遅延を減らすために、MySQLやRedisなどのミドルウェアアプリケーションなどの一部のサービスにSidecarを選択的に挿入することはできません。 Envoyが原因で、EDASのアプリケーションごとにマーキングを実行でき、サイドカーインジェクションはサービスグリッドに参加する必要があるアプリケーションに対してのみ実行できます。
異種マイクロサービスの相互運用性とガバナンス
ビジネスの発展とビジネス製品の選択により、ビジネス開発言語はますます多様化しています。これらの言語間の相互通信は、すべての人にとって懸念事項になっています。現在、相互通信などの一般的なシナリオJava言語と非Java言語が最も一般的です。重要な問題は、サービス検出と通信プロトコルのサポートです。
サービスディスカバリ
通常、Kubernetesを使用してサービスをデプロイするには、次のようにします。これにより、サービス間リクエストのKubernetesサービスのドメイン名が定義されます。
apiVersion: apps/v1
kind: Deployment
metadata:
name: details-v1
labels:
app: details
version: v1
spec:
replicas: 1
selector:
matchLabels:
app: details
version: v1
template:
metadata:
labels:
app: details
version: v1
spec:
containers:
- name: details
image: docker.io/istio/examples-bookinfo-details-v1:1.16.2
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
apiVersion: v1
kind: Service
metadata:
name: details
labels:
app: details
service: details
spec:
ports:
- port: 9080
name: http
selector:
app: detailsIstioはKubernetesApiサーバーを監視し、サービス、ポッド、およびサービスの他のデータを取得し、XDSを介してEnvoyに提供します。Envoyは取得したデータを介して負荷分散を実行します。
多くのマイクロサービスフレームワークは、Nacos、Consul、Zookeeperなどのレジストリを使用しています。これらのマイクロサービスは、大規模な変換なしでサービスグリッドをどのように使用できますか？これには、Istiodとレジストラ間の接続が含まれます。現在、コミュニティは次の方法を提供しています。登録センターのデータ接続：
1.MCPサーバー
カスタムMCPサーバーを作成して、サードパーティのレジストリからサービスデータを取得し、それをServiceEntryおよびWorkloadEntryリソースに変換し、MCPプロトコルを介してIstioのMCP構成コントローラーに提供します。IstiodはMCPサーバーアドレスを構成する必要があります。現在、オープンソースプロジェクトにはMCPサーバーが含まれています。多くのレジストリセンターがあります。AlibabaCloudMSEは、MCPサーバー機能を直接提供するホスト型Nacosレジストリを提供します。
2.ServiceEntry和WorkloadEntry
レジストリからサービスデータを取得し、それをIstioでServiceEntryおよびWorkloadEntry CRDに変換して、KubernetesAPIサーバーに書き込む独立したサードパーティコンポーネントを記述します。PilotのKubeControllerは、Kubernetes APIサーバーのIstio関連リソースの変更を監視し、ServiceEntryとWorkloadEntryを内部サービスモデルに変換し、Xdsプロトコルを介してSidecarに同期します。
3.カスタムアダプター
サードパーティのレジストリを統合するカスタムアダプタを作成します。アダプタは、レジストリからサービスとサービスインスタンスを取得し、パイロット内のサービスモデルに変換して、既存のConsul ServiceRegistry適応方法と同様にServiceControllerに統合します。 。この方法の利点は、サードパーティによる変換の必要がないことですが、Istioと結合されています。Istioバージョンをすばやくアップグレードする場合は、対応する新しいバージョンに継続的に適応する必要があります。
MSEレジストリ
最初の方法はレジストリのサポートを必要とし、2番目の方法は同期するために独立したサードパーティコンポーネントを必要とし、可用性とメンテナンスは負担です、3番目の方法はIstioに精通している必要があり、メンテナンスとアップグレードのコストは非常に高く、現在MSEレジストリですMCPをサポートしていますOverXDSは、高可用性とメンテナンスフリーでIstioに接続されています。
Javaエージェントを使用してXdsプロトコルをサポートし、Istioに接続します。同時に、IstioはMCP Over XDSを介してNacosレジストリにも接続するため、サービスによって検出されたデータをJavaエージェントとサイドカーで取得できます。 Javaサービスと非Javaサービスはお互いを発見できます。お互いに電話してください。
サービスグリッドのサービスガバナンス
サービスメッシュSidecarは、コンテナを介してビジネスコンテナとネットワークを共有し、Iptablesを介してSidecarへのインバウンドトラフィックとアウトバウンドトラフィックの両方をハイジャックします。Sidecarはデータパケットを解析し、リクエストを取得して、一致するサービス検出データから対応するサーバーを見つけ、対応するルーティングを照合します。ルールは、リクエストを送信するための条件を満たすサーバーを見つけます。
サービスグリッドのサービスガバナンスにおけるIstioのルーティングルールの2つの最も重要なCRDは、VirtualServiceとDestinationRuleです。これらは、以下に示すように、要求の照合とルーティングのプロセスを説明します。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1DestinationRuleには、レビューサービスの3つのバージョンが含まれています。VirtualServiceは、レビューサービスのリクエストがサブセットv1のバージョンに送信されることを記述しています。その他のサービスガバナンス機能には、フォールトインジェクション、サービス認証、サービスタイムアウト、ヒューズなどがあり、対応するルールを作成することで完了できます。現在、Istioは非常に使いやすいホワイトスクリーンサービス管理インターフェイスを提供していません。 EDAS / MSEは、サービス認証、サービスクエリ、外れ値の削除、カナリアリリースなどのホワイトスクリーンインターフェイス操作を提供して、操作中にトラフィックが失われないようにします。ルーティングルールの操作は、次の原則に従う必要があります。
1.一般に、サービスグリッドサービスガバナンスを使用するベストプラクティスの方法は、最初から各サービスのデフォルトルートを使用してVirtualServiceを作成することです。つまり、バージョンが1つしかない場合は、そのバージョンのVirtualServiceルールを記述します。 2番目のバージョンを展開すると、トラフィックは2番目のバージョンに到達しません。新しいバージョンの検証中に新しいバージョン自体の問題によって引き起こされる大規模なエラーが発生しないように、ルーティングルールを構成する必要があります。
2. VirtualServiceとDestinationRuleを使用するプロセスでは、Envoyは最初にVirtualServiceのルーティングルールをチェックして、特定のサブセットにルーティングするかどうかを決定します。対応するサブセットへのルーティングのみが、融合、外れ値の削除など、DestinationRuleの対応するサブセット構成をアクティブにします。およびその他のルールでは、VirtualServiceとDestinationRuleの構成も順番に行われていることがわかります。最初に、DestinationRuleを構成し、次にVirtualServiceを構成します。そうしないと、対応するサブセットが見つからず、エラーが報告されます。
3. DestinationRuleを更新する新しいサブセットを追加した後、DestinationRuleがEnvoy Sidecarに伝播するのを待ってから、対応するVirtualServiceを更新する必要があります。
デュアルモードマイクロサービスガバナンス
相互通信の問題は、レジストリとドッキングすることで解決されます。異種フレームワークのサービスガバナンスはMSEによってサポートされます。MSEのサービス管理センターはJavaサービスとドッキングでき、サービスグリッドのサービスもサポートできます。
MSEは、コントロールサーフェスでデュアルモードマイクロサービスガバナンス、つまりJavaサービスガバナンスと非Javaサービスガバナンスをサポートします。コントロールサーフェスは統合ガバナンスモデルを提供します。Istioのルーティングルール設計モデルを参照して、統合サービスガバナンスルールモデルを提案します。モデルの設計では、主にDubbo、Spring Cloud、およびサービスグリッドガバナンスの多様性を考慮しています。
{
"RegisterConfig":Object{...},
"protocol":"springcloud",
"rule_type":"fault_inject",
"rule":{
"hosts":Array[1],
"rule_policy":[
{
"match":Array[1],
"fault":Object{...},
"route":Array[1],
"Timeout":"10s",
"retries":Object{...},
"mirror":Object{...},
"mirror_percent":100,
"headers":Object{...},
"tls":Object{...}
},
{
"route":[
{
"destination":Object{...},
"weight":"100",
"headers":Object{...}
}
]
}
]
}
}上記のモデルには、レジストリ、プロトコル、ルールタイプ、ルーティングルールが含まれ、ルーティングルールにはマッチングルールとルーティング宛先が含まれ、MSEは対応するCRDを生成することでさまざまなタイプのルーティングルールを定義し、JavaエージェントとサービスグリッドはそのようなCRDを監視することで独自のトラフィックを管理できます。また、将来的には、この一連のマイクロサービスガバナンスルールをOAMで開始して、サービスガバナンスモデルを統合します。
MSEマイクロサービスガバナンス
サービスクエリ：
ラベルルーティング：
外れ値の削除：
観察可能
コミュニティオープンソースソリューション
可観測性はマイクロサービス機能の重要な部分です。サービスグリッドは現在のオープンソースの可観測製品と組み合わせることができます。可観測性は主にメトリクス、トレース、ログを中心に展開します。データはPrometheusが収集するメトリクスで提供され、トレースではIstioがリンクをサポートします。 Apache SKyWalking、Zipkin、およびJaegerの追跡。これら3つのミドルウェアはすべてOpenTracingプロトコルをサポートします。ロギングでは、ログ収集コンポーネントの要件がますます高くなっています。現在、より一般的なソリューションはFluentdまたはFilebeatを使用することです。Logstashを置き換えます。 。
Alibaba CloudEDASソリューション
次の図に示すように、Alibaba Cloud Xtraceは、リンクトラッキング、アプリケーションの概要、トポロジ、メトリック統計など、サービスグリッドに監視可能な機能を提供します。アプリケーションがリリースされた後、アプリケーションの詳細から直接表示できます。
トポロジー図は次のとおりです。
リンクトラッキングを介して各リクエストプロセスの問題を表示し、問題の特定を支援します。同時に、Xtraceはさまざまな言語のSDKも提供します。SDKにアクセスした後、より詳細なデータを表示できます。
この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。