マイクロサービス プロジェクト アーキテクチャの解釈
①マイクロサービスとは何ですか？
マイクロサービスとは、小規模ながらビジネス機能を備えた単一のサービスの開発を指します。各サービスは独自の処理と軽量の通信メカニズムを備えており、単一または複数のサーバーにデプロイできます。
マイクロサービスは、特定の限定されたコンテキストを持つ疎結合のサービス指向アーキテクチャも指します。言い換えれば、すべてのサービスを同時に変更する必要がある場合、それらは緊密に結合されているためマイクロサービスではありませんが、サービスのコンテキスト シナリオの使用条件を把握する必要が多すぎる場合、それはコンテキストのあるサービスになります。境界。この定義は DDD ドメイン駆動設計から来ています。
その主な特徴はコンポーネント化、疎結合、自律性、分散化であり、これらは次の側面に反映されています。
小さなサービスセット
サービスの粒度は小さくする必要があり、各サービスは 1 つの責任に対するビジネス機能をカプセル化したものであり、1 つのことをうまく実行することに重点を置いています。
独立してデプロイ、実行、スケールする
各サービスは個別にデプロイし、プロセス内で実行できます。この運用・導入方法により、システムに柔軟なコード編成方法とリリースリズムを与えることができ、迅速な納品と変更への対応が可能になります。
独自に開発・進化
従来のシステム テクノロジーの制約から解放され、柔軟なテクノロジーを選択できます。適切なビジネス上の問題に対して適切なテクノロジーを選択することは、独立して進化する可能性があります。サービスは言語に依存しない API を使用して統合されます。モノリシック アーキテクチャと比較して、マイクロサービス アーキテクチャはビジネス イノベーションをより指向したアーキテクチャ モデルです。
独立したチームと自律性
チームはサービスのライフサイクル全体に責任を負い、統一されたコマンドセンターを必要とせずに、独立したコンテキストで作業し、独自の決定を下して自らを管理します。チームは緩やかなコミュニティ部族を通じてつながります。
マイクロサービス全体の考え方は、私たちが現在直面している情報爆発や知識爆発と同じであることがわかります。私たちが行っていることを分離し、分割して征服することで不必要な損失を減らし、複雑なシステムと組織全体が変化に素早く対応します。
②マイクロサービスのメリット
各マイクロサービスは小さいため、特定のビジネス機能やビジネス ニーズに焦点を当てることができます。
マイクロサービスは、2 ～ 5 人の開発者からなる小規模チームによって個別に開発できます。
マイクロサービスは、開発フェーズであってもデプロイフェーズであっても独立した、疎結合された機能サービスです。
マイクロサービスはさまざまな言語を使用して開発できます。
マイクロサービスにより、Jenkins や Bamboo などの継続的統合ツールを通じて、自動化されたデプロイメントを簡単かつ柔軟に統合できます。
チームの新しいメンバーをより早く本番環境に導入できるようになります。
マイクロサービスは開発者にとって理解しやすく、変更し、保守しやすいため、小規模なチームは自分たちの作業の結果により集中できます。価値を提供するためにコラボレーションする必要はありません。
マイクロサービスを使用すると、最新のテクノロジーの統合を活用できます。
マイクロサービスは単なるビジネス ロジック コードであり、HTML、CSS、またはその他のインターフェイス コンポーネントと混合されていません。
マイクロサービスはオンデマンドで拡張できます。
マイクロサービスは、中程度からローエンドの構成のサーバーにデプロイできます。
サードパーティと簡単に統合できます。
各マイクロサービスには独自のストレージ機能があり、独自のデータベースを持つことができます。統合されたデータベースも存在する可能性があります
k8s クラスター アーキテクチャの解釈
①Kubernetesとは
Kubernetes (k8s) は、Google のオープンソース コンテナ クラスタ管理システム (Google 内部: Borg) です。Dockerテクノロジーに基づいて、コンテナ化されたアプリケーションの展開と運用、リソースのスケジューリング、サービス検出、動的スケーリングなどの一連の完全な機能を提供し、大規模なコンテナクラスタ管理の利便性を向上させます。Kubernetes の利点:
コンテナオーケストレーション
軽量
オープンソース
柔軟なスケーリング
負荷分散
② Kubernetes のアーキテクチャとコンポーネント
マスター/スレーブ分散アーキテクチャ、マスター/ノード
-
サービスのグループ化、小規模クラスター、マルチクラスター
-
サービスのグループ化、大規模クラスター、単一クラスター
Kubernetes マスター/ノード: Hadoop などの分散クラスターについてある程度の知識がある場合は、k8s の設計コンセプトが他の分散アーキテクチャと非常に似ていることがわかります。マスター ノードは、ユーザーの指示を受け取り、タスクを割り当て、各ノードを記録する責任があります。ノードノードはマスターから命令を受け取り、対応するポッドを開始する責任があります (k8s の最小実行単位はコンテナーの集合です)。
k8s のインストール時にマスター ノードとノード ノードが指定され、デプロイ後、k8s API を通じてマスター ノードと対話します。マスター ノードは指示 (新しいポッドの開始など) を受け取り、指示を完了するようにノード ノードをスケジュールします。もちろん、基礎となるスケジューリング戦略と具体的な実装の詳細は私たちユーザーには隠されており、理解する必要はありません。
マスターワークフロー図
Kubecfg は、ポッドの作成などの特定のリクエストを Kubernetes クライアントに送信します。
Kubernetes クライアントはリクエストを API サーバーに送信します。
API サーバーは、リクエストのタイプに基づいてリクエストを処理する REST ストレージ API を選択します。たとえば、ポッドを作成する場合、ストレージ タイプはポッドです。
REST ストレージ API は、それに応じてリクエストを処理します。
処理された結果は、高可用性のキー/値ストレージ システム Etcd に保存されます。
API サーバーが Kubecfg のリクエストに応答した後、スケジューラーは Kubernetes クライアントを通じてクラスター内で実行中のポッドとミニオン/ノードの情報を取得します。
Kubernetes クライアントから取得した情報に基づいて、スケジューラは未分散ポッドを利用可能なミニオン/ノード ノードに配布します。
Kubernetes Node はノードを実行し、次のコンポーネントを含むビジネス コンテナを実行および管理します。
1. Kubelet はコンテナの管理と制御を担当し、Kubernetes API Server から Pod 作成リクエストを受け取り、コンテナの起動と停止、コンテナの実行状況の監視、Kubernetes API Server への報告を行います。
2. Kubernetes Proxy は Pod のプロキシ サービスの作成を担当します。Kubernetes Proxy は、Kubernetes API サーバーからすべての Service 情報を取得し、Service 情報に基づいてプロキシ サービスを作成して、Service から Pod へのリクエストのルーティングと転送を実装し、それによって仮想転送を実現します。 Kubernetes レベルのネットワーク。
3. コンテナー サービスは DockerNode 上で実行されている必要があります。
Kubelet [ノード上のポッド スチュワード]
Node ノードでのポッドの作成、変更、監視、削除のライフサイクル全体の管理を担当し、このノードのステータス情報を API サーバーに定期的に報告します。
Kubelet はマスター API サーバーと Minion/ノード間のブリッジであり、マスター API サーバーによって割り当てられたコマンドと作業を受け取り、kube-apiserver を通じて間接的に Etcd クラスターと対話し、構成情報を読み取ります。
具体的な作業内容は以下の通りです。
コンテナの環境変数を設定し、ボリュームをコンテナにバインドし、ポートをコンテナにバインドし、指定されたポッドに基づいて単一のコンテナを実行し、指定されたポッドのネットワーク コンテナを作成します。
ポッドのステータスを同期し、ポッドのステータスを同期し、cAdvisor からコンテナ情報、ポッド情報、ルート情報、マシン情報を取得します。
コンテナ内でコマンドを実行し、コンテナを強制終了し、ポッドのすべてのコンテナを削除します。
③k8s共通コマンド
リソースを作成します。
kubectl create -f yaml文件リソースを表示します:
kubectl get <resource_type>
# 比如获取K8s集群下pod的信息
kubectl get pod
# 更加详细的信息
kubectl get pod -o wide
#获取pod更详尽的状态信息
kubectl describe pod pod名称
#查看所有的nodes
kubectl get nodes
#查看所有的namespace
kubectl get pod --all-namespaces
代替リソース:
kubectl replace -f yaml文件リソースを削除します。
kubectl replace -f yaml文件ログを確認します。
kubectl logs pod名称
#如果想动态查看日志加-f
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
この情報は、[ソフトウェア テスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。また、皆さんのお役に立てれば幸いです。
