背景時は経つのは早いもので、もう2024年です。2015年に就職したばかりの頃は、SSM/H(Spring/Struts2/Mybatis/Hibernate)フレームワークをマスターすれば、ほとんどの面接に合格できたことを今でも覚えています。
たまたま、私は働き始めた頃のモバイルインターネットブームから、eコマース→シェアリングエコノミー→toBの普及→今に至るまで、あらゆることを経験してきました。テクノロジー スタックも、当初の単一アプリケーション + 物理マシンから現在の Kubernetes クラウド ネイティブ アーキテクチャへと進化しました。 もちろん、SOA サービス指向 -> マイクロサービス -> クラウド ネイティブ -> サービス メッシュ -> サーバーレスなど、その過程でいくつかの主要な段階を経てきました。 私の最近の仕事は主にインフラに重点を置いたもので、インフラに関しては比較的包括的な理解を持っていると思います。そこでこの記事では、2024 年にどのようなクラウド ネイティブ テクノロジー スタックを使用すべきかを私の観点から共有します。多くの技術的要素が関係するため、あまり詳細には触れません。 ただし、ここで紹介するテクノロジー スタックはすべて私が実際に使用したものであり、実際の経験に焦点を当てて、その長所と短所について述べることを保証できます。 オペレーティング·システム1 つ目はオペレーティング システムです。これは、従来のオペレーティング システム (Linux/Windows Server/MacOS) とは異なります。主に選択の余地があまりないクラウドネイティブなオペレーティングシステム、つまりKubernetesを指します。 しかし、Kubernetes をどのように保守するかは難しい問題です。昨年後半にDidiで事故が起き、Kubernetesのバージョンアップによる問題ではないかとネット上で噂されたことを今でも覚えています。 私たちの経験に基づいて、小規模なチームにはクラウドベンダーでコンテンツを直接ホストすることをお勧めします。 Kubernetes のメンテナンスは非常に複雑な作業です。小規模なチームには通常、複数の責任があり、自己メンテナンスによって問題が発生する可能性が高くなります。 もちろん、大規模なチームの場合は、リスクをカバーできる限り、問題が発生しても迅速に対応できる専任のメンテナンス担当者を配置することが最善です。
マルチクラウドの利点とメリットクラウドベンダーのコンテナサービスを利用しているため、昨年の Alibaba Cloud の障害など、クラウドベンダーの障害によって発生する可能性のある問題も考慮する必要があります。 そのため、中規模企業や大規模企業の中には、マルチクラウド ソリューションを選択し、複数のクラウド サービス プロバイダーに同じコードを展開して、いずれかのプロバイダーで問題が発生した場合にすばやく切り替えられるようにしているところもあります。 しかし、具体的な実装プロセスには、データの一貫性をどのように確保するかという最も困難かつ最も重要な問題など、多くの課題があります。 もちろん、分散展開をサポートし、それ自体がデータ同期をサポートするデータベースやミドルウェアを使用することもできます。たとえば、メッセージ キュー内の Pulsar はグループのレベル全体に展開され、メッセージを同期できます。 同時に、マルチクラウド展開のコストも増加するため、「コスト削減と効率化」の観点から慎重に検討する必要があります。そこで、これに対する妥協案があります:
一般的に、クラウド サービスを切り替える必要があるのは常に極端な状況であるため、操作中にある程度のデータ損失を許容することは許容されます。最も重要なデータが失われず、ビジネスに影響が及ばないようにすることだけが必要です。 言うのは簡単ですが、シミュレーション演習に時間を費やす必要もあります。実施されるかどうかは、クラウドサービスの停止によって生じる損失と訓練のコストを企業が受け入れられるかどうかによって決まります。
デブオプスクラウドネイティブ オペレーティング システムとして Kubernetes を選択したため、継続的インテグレーションとリリースも Kubernetes に基づく必要があります。 上の図は、gitlab+ArgoCD で Git を使用するフローチャートです。私たちはソースコードの管理に GitLab を使用し、継続的インテグレーションに Pipline を使用し、最後に Kubernetes プロセスを開くために Argo を使用します。
同時に、履歴バージョンのロールバックや容量の拡張と縮小はすべて Kubernetes によって提供され、DevOps プラットフォームでは Kubernetes API を呼び出すだけで済みます。 もちろん、FinOps は今人気があります。私の理解では、主にクラウドコストの管理と最適化が関係していると思います。私の仕事は、ビジネスに影響を与えることなく、未使用のリソースをリサイクルし、構成を適切に削減することです。 サービスメッシュ次は、Service Mesh の最も重要な部分だと考えています。これについては多くの背景話があります。本質的には、これはすべて RPC (リモート プロセス コール) によって引き起こされ、配布によってもたらされると思います。 最初の単一マシンのローカル関数呼び出しから始めます。 主に、RPC フレームワーク、マイクロサービス、そして現在のサービス メッシュという、上記の 3 つの重要な段階を経てきました。
ただし、Istio の使用には高い技術的ハードルもあります。以下の条件を満たす場合は、Istio を使用することをお勧めします。
さらに、SpringCloud、Dubbo、kratos、go-zeroなどのマイクロサービスフレームワークを使用することも可能です。 可観測性今日では、可観測性システムはますます重要になっています。個人的には、技術チームを評価するための重要な指標は、そのチームの可観測性システムがどれだけうまく機能しているかであると考えています。 優れた可観測性システムは、システムの動作状態を明確に把握し、問題を効率的にトラブルシューティングし、タイムリーな障害アラームを提供できます。 上記の基準を達成するには、観測可能なシステムの 3 つのコア指標が必要です。
私たち自身の観測システムは反復を経てきました。以前のテクノロジー スタックは次のとおりです。
昨年末、私たちは比較的大きな変革を行い、主に SkyWalking を、よりオープンなコミュニティであり、徐々にクラウドネイティブの可観測性の標準になりつつある OpenTelemetry に置き換えました。 これを使用することで柔軟性が高まり、特定のテクノロジー スタックに縛られる必要がなくなります。現在、ログは切り替えられておらず、コミュニティはまだベータテスト中です。成熟した後は、OpenTelemetry を直接使用してログを収集することもできます。 メッセージキューここでメッセージ キューを特に取り上げる理由は、現在主に社内のメッセージ キューを管理しているからです。同時に、ビジネス規模が大きくなるにつれて、メッセージ キューが非常に重要になります。通常、さまざまなビジネス ラインを接続するためのブリッジとして、またはデータベースを MySQL と同期するためのチャネルとして機能します。つまり、用途は多岐にわたります。 ここでは、クラウド ネイティブにより適したメッセージ キューである Pulsar を引き続き推奨します。ストレージとコンピューティングを分離したアーキテクチャのため、Kubernetesの特性と合わせて迅速な容量拡張・削減を実現でき、Kafkaよりもメンテナンスが容易です。同時に、コミュニティも非常に活発で、バグ修正や新機能のサポートにも比較的積極的に取り組んでいます。 Pulsar は幅広いクライアントを公式にサポートしています:
もう 1 つの質問は、Pulsar クラスターをどのように展開するか、プライベートで展開するか、クラウド サービスを購入するか (現在、Pulsar の商用会社である streamnative と国内の Tencent Cloud が同様のサービスを提供しています) です。 価格については以前相談させていただいたのですが、比較的自社で導入する方がコストパフォーマンスは高いです。前述のとおり、当社ではクラウドベンダーの Kubernetes サービスのみを使用し、これに基づいて独自のサービスを展開しています。 活発な Pulsar コミュニティのおかげで、メンテナンスに問題があっても、タイムリーなフィードバックを得ることができます。同時に、遭遇した落とし穴を通じてコミュニティに貢献することもできます。 ビジネスフレームワーク最後のステップは、ビジネス フレームワークを選択することです。この決定の前提は、まず主要なビジネス言語としてどの言語を選択するかを決定する必要があるということです。 これはKubernetesにとって重要ではありませんが、私がよりよく知っているJavaとGolangで紹介します。 ジャワJava には多くの技術的なオプションがあります。 Kubernetesのみを使用し、サービスグリッドを使用しない場合は、 ただし、これには一部のサービス ガバナンス機能が欠けており、小規模および中規模のチームに適しています。 チームの人数が多く、サービス メッシュを使用していない場合は、前回の記事で紹介したマイクロサービス フレームワーク (Dubbo、SpringCloud など) を使用することをお勧めします。 専用のクラウド ネイティブ チームがある場合は、サービス メッシュ ソリューションを使用することをお勧めします。これにより、上記の 2 つのソリューションの利点を組み合わせることができます。
Go言語Golang は実際には Java に似ています。小規模および中規模のチームの場合、開発には Gin などの http フレームワークを使用できます。 中規模および大規模のチームには、kratos や go-zero など、Dubbo や SpringCloud に匹敵する Golang エコシステムのフレームワークもあります。 Golang のシンプルさのおかげで、ビジネス開発には Java を使用するよりもはるかにシンプルで「頭を使わない」方法だと感じています。 同様に、将来的にはサービス メッシュに切り替えることもできます。 gRPC と Golang を直接使用することも非常に適応性があります。この時点で、チームは比較的成熟しており、gRPC に基づく開発スキャフォールディングを完全に作成したり、Kratos または go-zero を使用してサービス呼び出しモジュールを削除したりできるはずです。 要約する上記は、現在普及している技術的ソリューションについての私の個人的な理解であり、さまざまなチーム規模に応じた推奨事項も示しています。確かに完璧な技術的解決策は存在せず、最も適切な解決策があるだけです。トレンドに従って、自分では制御できないテクノロジー スタックを選択しないでください。そうしないと、最終的に苦しむのは自分自身になる可能性があります。 参考リンク:
|
<<: Kubernetes の helm とは何ですか?使い方は?
>>: DevOpsのボトルネックを克服するための4つのステップについてお話ししましょう
産業界はデジタル化へと向かっており、業務の最適化に役立つツールやテクノロジーを求める企業が増えていま...
販売者は、Taobao プラットフォーム上のマーケティング リソースが多すぎて複雑すぎるため、どれが...
4月24日、Googleの優秀なエンジニアであるマット・カッツ氏は、Googleウェブマスターブログ...
テンセントクラウドは6月3日、タイのバンコク、ドイツのフランクフルト、日本の東京、中国の香港の4つの...
高品質の外部リンクですか? 低品質の外部リンクですか? いいえ、そのようなあいまいな答えは必要ありま...
1994年、中国は64K国際専用回線を通じてインターネットへの完全なアクセスを獲得しました。それ以来...
VMware (NYSE: VMW) は、VMware Workspace ONE、VMware N...
301リダイレクトの実態を分析してみよう! 1. ケース 1: 以前のドメイン名は、画像や記事などの...
実際の開発では、定期的にバッチを実行し、1 日に 1 回調整操作を実行する必要があるシナリオに遭遇す...
読者の皆さん、この動きについてどう思いますか?Weiboを閲覧していたときにこれを見ました。Baid...
百度の不正行為判定基準Web ページのソース コードの任意の場所に、Web ページの内容とは無関係な...
インターネット全体のゴシップの中心地として、 Weiboはますます注目を集めています。データによると...
海外メディアCNBCが入手した内部文書によると、プライムデーのプロモーションが麻痺した主な原因は、ア...
IBM Research Labs は最近、クラウドおよびコンテナ環境の脆弱性を見つけるためのオープ...
最近、業界観察記事を書いています。Weiboの友人から、私の記事は内容が薄すぎるというメッセージが届...