2020年8月14日から15日まで、GIAC2020グローバルインターネットアーキテクチャカンファレンスが先週の金曜日に深センで正式に開催されました。
GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）は、インターネット技術とアーキテクチャに長い間焦点を当ててきた、可用性の高いアーキテクチャ技術コミュニティとmsupによって立ち上げられた、建築家、技術リーダー、ハイエンド技術実務家のための年次技術アーキテクチャ会議です。これは中国で最大の技術です。会議の1つ。
第6回GIACは、インターネットアーキテクチャ、技術管理、システムアーキテクチャ、ビッグデータと人工知能、モバイル開発と言語、アーキテクチャ関連分野の最も人気のあるフロンティアテクノロジーからの技術革新とR＆Dプラクティスの典型的な例を共有します。
Go言語のトピックについて、TencentのシニアエンジニアであるLi Kaiyuanが、「TarsGoベースのマイクロサービステクノロジーアーキテクチャの実践」というタイトルの基調講演を行いました。
音声記録は次のとおりです。
今日共有したトピックは、TarsGoのマイクロサービステクノロジーアーキテクチャの実践に基づいています。まず、自己紹介をします。私の仕事の経験は非常に簡単です。卒業後、Tencentで働いています。過去5年間で3つの方向で働いてきました。
前編は2015年。当時はドッカーが大人気でK8Sを知っている人も多かったのですが、当時はまだおもちゃのようで、実稼働環境には向いていないと感じていました。私のチームは、主にドッキングコンテナでTarsやその他のサービスを実行するコンテナクラウドを独自に構築し、k8sよりもはるかに多くの自動スケジューリング機能を実現しました。過去数年間、このソリューションをオープンソースにしたいと考えていましたが、k8sは幸い、マイクロサービスのビジネス標準がなかったため、オープンソースのタールを作成しました。
第二部は2017年頃でした。その時、Goは私がその時に実装したTarsのGo言語バージョンの機能のいくつかに追いつき始めました。
第3部は2019年です。多くの人がサーバーレスとクラウドネイティブについて話し始めました。私もこの製品を開発するためにTencentCloudに切り替えました。私たちのバックエンドチームはTarsGoを使用して開発しています。
私がいくつかの方向性を示したことに気づきましたか？それらはすべてビジネストレンドに追いついているようですが、同じことがインフラストラクチャからアプリケーションプラットフォーム、プラットフォームのユーザーに至るまで、すべてTarsに関連しています。これらの経験のために、タールについて話すときは異なる角度があるかもしれません。プラットフォームや技術フレームワークを構築するときは、クールなテクノロジーを追求できますが、ユーザーになった後は、テクノロジーの素晴らしさを気にする必要はありません。特定のコンポーネントやプラットフォームが優れているかどうか、安定しているか不安定かによって異なります。 、ビジネス上の問題を解決できますか？
今日の共有セッションは、次の3つの部分に分かれています。
1）Tarsのコア機能、2）TarsGoの機能とパフォーマンス最適化の実践、3）TarsとK8Sの組み合わせ。
紹介する前に、基本的にすべてのソフトウェア開発チームが直面するビジネス規模の成長によって引き起こされる一般的な技術的課題を分析しましょう。
1日に数百のUVを使用する個人のブログサイトを作成している場合、この課題は大きくありません。ホストするサーバーを見つけるだけですが、1日のトラフィックが数百万または数十億に増加する場合、それがここで言及する最初の課題です。ユーザートラフィックが増加すると、元の単一サービスアーキテクチャはサポートできなくなります。現時点では、分散アーキテクチャを検討する必要があります。これには、読み取りと書き込みの分離が必要であり、高性能キャッシュが必要です。
2番目の課題は、より多くのビジネスニーズを満たすために、より多くのソフトウェア開発者を採用することです。より多くの人が新たな問題をもたらすでしょう。上司にとっては、より多くの賃金を支払うことに加えて、従業員の価値と余剰価値を最大化する方法を見つけることです。私たちの研究開発にとって、もちろん、優れた生産ツールがより良いことを願っています。上司のニーズを満たすため。プロジェクト開発に固有の、通信に共通のインターフェイスプロトコル、および複数の開発言語をサポートするフレームワークが必要です。これにより、異なる開発言語のチームメンバーも協力して同じプロジェクトを完了し、PHPに習熟し、Golangに習熟している学生も協力できます。学生の中で、どれが世界で最高の言語であるかについて議論することに時間を費やしません。
3番目の課題は、サーバーの数の増加です。多数のマシンを管理することは容易ではありません。1wのマシンを使用している場合、毎日複数のマシンがクラッシュしたり、複数のディスクが壊れたり、コンピューター室全体が壊れたりする可能性があります。それらはすべてハングアップしているため、これには、マシン障害またはマシンルーム障害の自動回復のためのソリューションが必要です。
4つ目は、ビジネスロジックの複雑化に対応するビジネスサービス数の増加です。また、多数のビジネスサービスを管理することは非常に困難です。開発中は非常にクールで、多くのマイクロサービスが開発されましたが、長い運用が遅れています。保守プロセスの処理方法、拡張と縮小、監視、問題のトラブルシューティング。これには、運用と保守の効率を向上させるための完全に機能するマイクロサービスガバナンスフレームワークが必要です。
上記の課題は、Tencentの多数のビジネス製品で発生しており、長年の沈殿の後、より多くの経験を積み重ねてきました。その中で、Tarsは、今日導入された最も代表的な外部オープンソースプロジェクトです。
では、タールの機能は何ですか？2つの部分があると思います。1つは開発に関連しています。TarsはIDLと自動コード生成の開発フレームワークを提供します。開発はビジネスロジックのみを気にする必要があります。tcpまたはucpプロトコルのどちらを使用するかを気にする必要はなく、依存サービスのIPを知る必要もありません。または移植、Tarsは現在cpp / golang / php / nodejs / java 5言語をサポートしており、さらに多くの言語もサポートされています。
他の部分は運用と保守に関連しています。サービスの視覚的管理と非破壊的な変更をサポートします。構成管理にはバージョン管理と構成参照機能があります。ログ、監視、およびコールチェーンは、Tarsがデフォルトでサポートする機能です。Tarsのセットモデルは、運用と保守を提供します。過負荷保護と耐災害性に加えて、便利なマルチクラスター管理機能。以前は、TARSのオープンソースバージョンには自動的に拡張および縮小する機能がありませんでしたが、最近、この機能を補完するためにtarとk8の統合をオープンソース化しました。これは、後で紹介するソリューションでもあります。
TARSに似たマイクロサービスフレームワークはたくさんあります。比較のために、さらに影響力のあるRPCフレームワークをいくつか紹介します。GPRCは最も人気のあるRPCフレームワークですが、サービスガバナンス機能はありません。一方、SpringCloudに似ています。または、Dobboは比較的完全なサービス管理機能を備えています。最近、dubboのgolang言語バージョンもオープンソース化しています。以前は、Java言語が依然として主要言語であると感じていました。サービスメッシュは現在非常に人気があり、次のマイクロサービスアーキテクチャと呼ばれています。ビジネスロジックを基盤となる通信から分離し、言語とは関係がないため、複数の言語をサポートしますが、産業用アプリケーションでは長くはなく、特に成熟していません。
本日発表されたTARSは、サービスマッシュと同様の考え方が多く、たとえば、負荷分散などの一般的な機能は、ビジネス層ではなく、パブリックインフラストラクチャ層で実装する必要があります。サービスマッシュと比較して、近年提案されたものです。 TARSの概念は、2008年以来、Tencentのコアビジネスの多くで使用されています。これは、複数の言語をサポートし、完全なサービスガバナンス機能を備えたマイクロサービスフレームワークです。
アプリケーションについて言及したばかりですが、TARSはオープンソースの後に多くの企業とも通信しています。時間の制約があるため、最初にいくつかのtar機能のみを選択してさらに紹介します。
最初に簡単なシナリオに戻りましょう。たとえば、サービスAはサービスBを呼び出す必要があります。サービスBには複数のノードがあります。Aはどのノードを呼び出すかをどのように選択しますか？TARSにはいくつかの負荷分散メソッドがあります。デフォルトはポーリングです。ハッシュメソッドを使用して呼び出す場合は、追加の開発なしで構成するだけで済みます。
さらに、サービスBのノードが異常な場合、TARSはデフォルトでヒューズアルゴリズムを提供します。これにより、異常なノードを自動的にシールドして、異常なノードによって引き起こされる要求の失敗の数を最小限に抑え、要求を再試行します。ノードが回復した場合、次に、異常なノードを追加し直します。
リクエストボリュームが大きすぎてサービスが過負荷になるという異常なシナリオもあります。タールは、過負荷保護を実現し、サービスのなだれを回避するために、同時処理の最大数を構成できます。
別のシナリオでは、サービスAがBに電話をかけたいので、AはサービスBのアドレスを知っている必要があります。最も簡単な方法は、サービスAにBのIPを書き込むことですが、サービスBのIPは、拡張と縮小によって変更される可能性があります。このように、サービスBの変更では、Aのコードを変更する必要がありますが、これは明らかに保守不可能です。最適化ソリューションは、IPを変更することです。構成ファイルに記述されているこのプランBは、サービスが変更されたときに変更する必要があります。したがって、基本的に誰もがサードネームサービススキームを使用し、サービスアドレスは自動的に登録され、呼び出されたサービスが変更されたときにクライアントを変更する必要はありません。ただし、ネームサービスには、マルチクラスターシナリオにはまだ欠点があります。マルチクラスターは非常に一般的なシナリオです。たとえば、toc製品には多数のユーザーがいます。クラスターを上海と北京の地域に分割して、さまざまな地域のユーザーにサービスを提供できます。これは優れています。上海などの隔離障害は、問題が発生しても北京のユーザーには影響しません。
クラスタリングには2つの従来の方法があります。1つは各クラスターが一連のネームサービスと共通サービスを使用する方法です。新しいクラスターごとに一定量の運用と保守のコストが増加します。もう1つは、複数のクラスターが一連のネームサービスを共有する方法です。クラスターの同じサービスは異なる名前を使用する必要があり、各クラスターサービスの名前を管理する必要があります。これにより、操作と保守が非常に複雑になります。
このジレンマに対応して、TARSはSET機能を提供します。
SETモデルはTARSの最も重要な機能の1つだと思います。これは、サービストラフィックを論理的に分離する機能を提供します。サービスでSETが有効になっている場合は、同じSETサービスのみを呼び出すことができ、サービスが有効になっていない場合は、 、およびすべてのセットサービスを呼び出すことができます。さらに、ワイルドカードを使用して、いくつかのクローズアップセットをセットコールすることができます。コードやビジネス構成を変更する必要はありません。運用および保守により、サービスコールを管理するためのセットを柔軟に構成できます。関係。
コンピュータルームの災害復旧も非常に一般的なビジネス要件です。Tencentでの個人的な経験から、基本的に毎年1つか2つのコンピュータルームの障害シナリオがあります。過去数年間、シャンウェイにあるTencentのコンピュータルームは洪水のために電源を切る必要があるかもしれません。もちろん最も一般的な理由は、ファイバーが切断されていることです。コンピュータルーム全体が利用できないという事故が発生した場合、製品のサービスが1つのコンピュータルームにのみ展開されていると、製品全体が利用できなくなり、上司は絶対にそれを受け入れることができなくなります。したがって、災害復旧を検討する際には、同じサービスを複数のコンピュータルームに展開する必要があります。コンピュータルームが利用できない場合でも、通常どおりサービスを外部に提供できます。
これはまた、新たな問題をもたらします。サービスはコンピュータルーム全体で呼び出される必要があるため、待ち時間が長くなります。
コンピュータルームで災害復旧を行いたいが、遅延を増やしたくない場合はどうすればよいですか？TARSは、自動エリア認識機能を提供します。クライアントは、複数のコンピュータールームが使用可能な場合にのみ、ローカルコンピュータールームのサーバーノードを呼び出します。ローカルコンピュータールームに使用可能なノードがない場合、コンピュータールーム全体で呼び出しが行われます。この機能は、コントロールプレーンでのみ有効になります。災害耐性機能を備えながらビジネスコードを変更しても、遅延は増加せず、操作と保守が簡単になります。
マイクロサービスの場合、監視、ロギング、およびコールチェーンが標準であると言えます。マイクロサービスの特性上、問題が発生した後にトラブルシューティングのためにマシンにログインする必要がある場合、低効率が現実的でない場合があります。通常、サービスの実行状態は監視によって監視され、状態が異常になるとアラームが発生します。複雑なシステムの呼び出し関係とサービスアーキテクチャを理解するための呼び出しチェーンを通じて、タイムアウトが発生したときに問題のあるモジュールをすばやく特定し、ログを使用して例外の原因を分析できます。次に、監視、ログ、およびコールチェーンは、使用中に互いにオーバーラップします。たとえば、メトリックを監視する機能は、ログを集約することによっても実現できますが、データ量が多いと効率が低下するため、成熟したマイクロサービスシステムには依然として必要です。これらの3つの完全な能力。
TARSは、デフォルトでtarslog / tarsstat / tarspropertyなどの基本サービスを提供します。また、監視用のPrometheus、ログ用のELK、コールチェーン用のzipkinとjaegerなどのより成熟したオープンソースソリューションを統合することもできます。
次に紹介したいのは、TARSのRPCフレームワークのGO言語バージョンで、主にパフォーマンスの最適化に関連するエクスペリエンスを紹介します。
TarsGoには、tarのサービス管理機能、goの利点、およびTARSGoのパフォーマンスの最適化という3つの利点があります。TARSGoは、tarsプロトコルに基づいて実装されたrpcフレームワークであり、負荷分散、耐災害性と障害耐性、tarsのネームサービスなど、デフォルトでtarsのサービスガバナンス機能を継承します。
2つ目は、go言語の利点です。Golangには豊富な標準ライブラリがあります。多くの場合、ホイールを作り直す必要はなく、初心者の方が高速です。python / Cまたは他の言語と比較して、開発効率とプログラム操作効率の間のバランスが優れています。静的コンパイルとクロスプラットフォームコンパイルを同時にサポートすると、研究開発に非常に便利です。たとえば、Macで開発およびコンパイルしてから、Linuxサーバーにアップロードして実行できます。go言語の最大の利点は、同時および非同期プログラミングだと思います。goルーチンとチャネルのデータ構造により、同時プログラミングの複雑さが大幅に簡素化されます。
TarsGoの3番目の利点はパフォーマンスです。これについては、後で詳しく説明します。
ユーザーリクエストは12以上のサービスを通過する可能性があるため、パフォーマンスはマイクロサービスにとって非常に重要です。高性能RPCフレームワークは、マイクロサービスによって引き起こされる時間のかかる成長の問題を軽減できます。これがTARSの機能です。悪くない。
以前は、一般的に使用されるPRCフレームワークとさまざまな開発言語のパフォーマンスプレッシャーテストの比較を行いました。テスト結果から、TARS C ++とTARSGOの全体的なパフォーマンスは最高であり、小さなパッケージのシナリオはgrpcの5倍以上です。
この目標を達成するために、tarsgoは多くの最適化を行いました。これらの最適化エクスペリエンスには、goを使用して開発する学生にとっても一定の参照値が必要です。
1つ目は、タイマーの最適化です。すべてのrpc呼び出しにはタイムアウト期間があり、タイムアウトを制限するという目標を達成するにはタイマーが必要です。同時実行量が多い場合は、多くのタイマーが必要になります。golangのpporfツールを使用してフレームグラフを生成すると、タイマー作成のパフォーマンスの問題を見つけることができます。そこで、タイムホイールアルゴリズムを実装しました。これにより、タイマーを作成する際の時間の複雑さをlog（n）からO（1）に減らすことができます。欠点は
さらに、ネットパッケージのdaedline設定のパフォーマンスの最適化、勝者のsync.Pool for bytes.Bufferの最適化のための頻繁なアプリケーション、多数のゴルーチン作成の問題に対するcoroutineプールの最適化の使用などの最適化ポイントもあります。上記の最適化の後、前述の効果が達成されます。
次に、TARSとK8Sの統合計画をご紹介します。
現在、TARSは、ネームサービス、負荷分散、過負荷保護、エリア認識などの包括的なサービス管理機能を提供していますが、オープンソースのTARSバージョンには自動スケジューリング機能がなく、オンラインサービスや容量拡張などの操作でIPとポートを入力する必要があります。
これは2つの問題をもたらします：
1つ目は、サービス容量の管理です。自動的に拡張または縮小できないサービスの場合、予約されたリソースが小さいと、トラフィックバーストが発生した場合にサービスが過負荷になり、より多くのリソースを予約すると無駄になります。
2つ目は、サービスの混合展開です。複数のサービスが混合して展開されると、相互に影響を与える可能性があります。展開が混合されていない場合、マイクロサービスが詳細になりすぎて、多くのマシンリソースが無駄になります。
上記の問題の最も自然な考え方は、K8Sのスケジューリング機能を使用して、TARSサービスの自動拡張および縮小を実現することです。しかし、問題は再び発生します。TARSの機能の多く（ネームサービスなど）はK8Sと重複しており、それらを統合するのは簡単ではありません。
K8Sエコシステムでは、Istioが最も人気のあるマイクロサービスソリューションです。TARSを放棄してIstioに変更する必要がありますか？これは、発生する問題の分析です。
1つ目は、サービスコードを変更することです。これは非常に現実的な問題ですが、iostioを使用しない理由は必ずしも適切ではありません。
istioを使用する場合の2番目の問題は、tcpへの長い接続は接続レベルでの負荷分散のみであり、tarは要求レベルであり、より優れた機能を備えていることです。
3つ目は、tarsクライアントがサービスをより堅牢にするためのヒューズ機能を備えていることです。
4つ目は、tarsにset / idcグループ化ネームサービスがあることです。これは、複数のクラスターや複数のコンピュータールームに展開すると、操作と保守が簡単になります。
5つ目は、自動ポート管理をサポートすることです。サービスが長い場合にポートを管理する手間を省くために、ビジネスコードのポートを気にする必要はありません。
6つ目は、ロギング、モニタリング、およびコールチェーンのサポートの向上です。たとえば、istioはコールチェーンもサポートしますが、コールチェーンのコンテキストを通過させるには、ビジネスコードでも使用する必要があります。共通のロジックを2か所に実装する必要があります。私はここで問題を起こしやすいです。
7つ目は、istioと比較して、まだ急速に繰り返されており、着陸にかかるコストが高いことです。TARSは、多数のビジネスサービスによって検証されており、比較的成熟していて安定しています。
したがって、K8Sでの自動スケジューリングをサポートするには、引き続きTARSを使用し、TARSを変換する必要があります。
実装の主な難しさは、重複する機能の統合です。Tarsにない機能は、自動リソーススケジューリング、ドッカーイメージ管理、およびネットワーク仮想化です。TARSにはあるが、K8Sにはない機能は、高性能RPCフレームワーク、ログ、監視、およびコールチェーンサービスです。機能、サービスの展開、バージョンのリリースと管理、ネームサービスと構成の管理は、tarとk8の両方が持つ機能です。
したがって、重複する機能から選択する必要があります。k8sはビジネスの主流標準である自動サービススケジューリングをサポートしているため、サービス展開ではk8sのみを選択でき、k8sはdocker imageを使用して基本的な環境依存関係を含めます。これは、より優れたバージョン管理ソリューションです。ネームサービス部分では、TARSはトラフィック制御、SET / IDCグループ化、クライアント障害許容度、およびk8sにはないその他の機能をサポートします。したがって、tarのネームサービスを保持する必要があり、tarの構成管理はバージョン管理、アプリケーション/セット/サービスレベルの構成参照をサポートします。合併により、k8sconfigmapソリューションよりも実稼働環境での使用に適したものになります。
K8SとTARSの重複する機能を分析した後、最近、そのようなソリューションを実装してオープンソース化しました。k8sを変更せずに、ネイティブk8s機能が使用され、自動サービス登録、ハートビートレポート、およびノードオフラインのためにいくつかのインターフェイスがTarsRegistryに追加されます。クラッシュシナリオの場合、ハートビートを長期間レポートしていないノードは自動的に削除されます。さらに、コンテナ内のサービスを管理し、起動構成の生成、サービス登録、ハートビートレポートなどの機能を実現するために、新しいコマンドラインツールが新たに実装されました。このソリューションの利点は、TARSのネイティブ開発フレームワークとサービス管理機能を保持し、K8Sをサービスの展開とスケジューリングに使用することです。
k8sポッドとtarsサービスのライフサイクルは強く関連しています。ポッドが開始されると、デフォルトでtarscliスーパーバイザープロセスが開始され、サービスの起動構成が生成され、サービスステータスがプルアップおよび監視され、サービスがk8sネームサービスに同期されます。hzcheckコマンドは、ポッドとサービスのステータスを確認するために使用されます。ポッドが終了すると、ノードはprestopサブコマンドによって自動的にシャットダウンされます。
TARSサービスをk8sにデプロイする方法は？まず、データベース、ネームサービス、Web管理ページ、サービス管理に関連する基本サービスなど、tarの基本サービスを展開する必要があります。オープンソースプロジェクトでは、これらのサービスをk8に直接すばやく展開するためのyamlを提供しています。次に、yamlファイルを使用してビジネスサービスを展開することもできます。2つの例を示します。具体的な使用法については、オープンソースホームページのドキュメントを参照してください。展開が完了すると、tarswebページからサービスノードのリストを確認できます。
管理ページには、デフォルトでサービス監視曲線があり、サービスコール量、時間消費、異常レート、タイムアウトレートを視覚的に確認できます。さらに、タールは損失のない変更をサポートします。監視の観点から、ミラーリングの変更中にビジネス監視曲線が変動しないことがわかります。
LiKaiyuan右
最後に、TARSとクラウドネイティブについて説明します。
上司はクラウドネイティブを好むと思います。インフラストラクチャの開発と保守に多くの人を雇う代わりに、オープンソースソリューションを直接使用して、クラウドベンダーでサービスをホストできるからです。
TARS自体には豊富なサービス管理機能があり、開発効率を向上させ、運用および保守コストを削減できます。TARSとK8Sの組み合わせにより、ビジネスコードを変更することなく、または低コストで、適切なクラウドベンダーにサービスを展開できます。インフラストラクチャの運用と保守のコストを削減すると同時に、クラウドベンダーとの拘束を回避することもできます。したがって、TARS + K8Sのクラウドネイティブソリューションを使用することをお勧めします。このソリューションは現在、githubでオープンソースです。すべての人に注意を払ってください。githubでk8starsを検索して見つけてください。
これは私の共有です、ありがとう！