序文
アーキテクチャの発展に伴い、マイクロアーキテクチャのサービス・アーキテクチャは、デザインコンセプトの最も熱いエリアがあると言うことができます。同社では、我々は、システムの設計・開発作業を担当して提供されています。
今日のマイクロサービスの練習を着陸の問題のいくつかについて話をします。私が参照して、いくつかの役割を果たし、マイクロサービス設計の友人を開始していない願っています。ほかにも、欠陥を認識することができ、我々は為替で仕事を楽しみにして、彼らの視点を共有することを願っています。
サービススプリット
マイクロサービスを着陸する前に、私たちが遭遇した最初の問題は、次のとおりです。サービスを分割する方法？
あなたが知っているように、サービスではなく、完全に一般的なルールを分割する方法について。しかし、以下の要素であり、我々はを参照することができます。
1、業務の独立性
通常の状況下では、最初の時間は、私たちは、このことを考慮してます。システムサービスモジュールは、各個々のモジュールのうち、識別機能に応じて別のサービスに分割されます。
高凝集、低カップリング：この分割した後、私たちのサービスは、基本的にお応えしています。
たとえば、私たちは、商品やサービス、オーダーサービス、物流サービスにシステム分割を持っています。通常の状況下で、我々は物流サービスの時間を変更し、低カップリングに反映されている商品やサービスを、影響しません;、機能およびロジック内で、このコアビジネスプロセスの受注を中心に展開するサービスの受注、あなたはそれがあると言うことができます非常に粘着性。
2、ビジネスの安定性
我々は、安定性に基づいてシステムのトラフィックを区別することができます。例えば、ユーザ登録、ログインセクションでは、我々のシステムでは、限り、コードのこの作品が書かれたように、基本的には変化はその後、私は顧客サービスにそれらを引き裂くだろう、起こりません。
同様に、ログインサービスがあり、サービスを監視し、これらのモジュールは基本的に非常に安定したビジネスです、別途分割考慮することができます。
3、サービスの信頼性
ここで強調コアサービスと非コアサービスの信頼性が低いの高い信頼性要件にあるが、オープン分割し、その後、コアサービスの可用性を確保するために集中します。
コアサービスに影響を与え、非コアサービスの障害を避けます。
4、ビジネスパフォーマンス
サービスのパフォーマンスに基づいてスプリット、それは圧力モジュールの分割性能が企図。このために、私は2つのアイデアを持っています：
- 回避性能の圧力サービスは他のサービスに影響を与えます。
- 高トラフィックのビジネスの独立した、ケースは、水平方向に拡張するのは容易で、持ち運びができませんでした。
たとえば、システムに私は、参加していたRocketMQ複数のベンダーからのデータのドッキング大量。
その時、それはメッセージを消費するために設計された独立したニュースサービス、です。その後、いくつかは、いくつかによって、局所的に処理RPCインターフェース、直接いくつかの処理の他のサービスに転送WebSocketショーの前端にプッシュします。
この場合、トラフィックの急増は、メッセージサービスにマシンを増やすことを検討しても、うまく力を費やし増やします。
スプリットのこれらのタイプは、上記の方法であることを学んだとき、私たちは自分自身のビジネスおよび技術チームのサイズに応じて、分割独自のシステムのサービスを検討することができます。
しかし、ここで、それは特にことは注目に値する、マイクロ細心のサービスは、ビジネスと技術チームのサイズスケールと組み合わせる必要があり、分割してはなりません。
その後、Genghen、および各ビジネス・サービス、私はサービス、10ヶ月のサービスの解体の結果を分割して運用独立性に基づいて、その後のテクニカルディレクターでサービスを行う過程で、以前のプロジェクトに遭遇しましたService層とController層がオフに分割し、各ビジネスメソッドが長距離通話が必要です。それは説明の当事者によると、ポストスケーラビリティを強化容易にするためにそうします。
しかし、正直に言うと、いくつかのシステムとはあまりいないトラフィックは、盲目的にマイクロマイクロワードサービスに応えるため、間違いなく、自分自身の難易度を高め、全体的なシステムの安定性を弱体化させます。だから、ビジネスプロセスの再ソートした後、このシステムの著者は、サービスの数を減らし、再構築されています。
ここでは、私が指摘したいと思います。Service層とController層が複数のモジュールに分割することができ、これは問題ではありません。しかし、それだけではなく、スプリットより独立したモジュールのサービスでなければなりません。例えば、我々は複数のモジュールに開発フェーズ分割でそれらを置くことができ、その後、通過Maven modulesに重合、オペレーションの展開段階では、彼らがサービスされています。
第二に、技術選択
分割されたサービスが完了した後、それを開発するどのようなフレームワークの選択は、あなたが選択する必要があります Dubbo 还是 SpringCloud ？
私は単にどこが下に著者の考え方を共有する問題についてすることができ、自分の強みと弱みに議論する必要はありません。
最初の選択は、私が選んだ場合はSpringCloud、すべての後に、それはマイクロサービスのワンストップソリューションとして知られています。そして、フレームワークを構築し、さまざまなコンポーネントの統合は、開発とテストのいくつかのデモを完了しました。
しかし、仕事のこの部分が完了した後、私たちが見る、システム全体を再検討しSpringCloud、関係するEureka、Ribbon、Feign、Hystrix、Zuul、Configコンポーネントを。
この時点で、私は2つの質問があります。
- これらのコンポーネントは非使用できなくはないのですか？より多くのポータブルシステムの解決策はありますか？
- だから、多くのものが、問題の一部のいずれか、私たちは生きて保持することができますか？
著者について一站式単語の理解の2つの層があります。まず、それは、開発の容易性、分散システム・インフラストラクチャの開発を簡素化し、第二は、同じ時間を簡素化、それは複雑な構成と実装原理をシールドする必要があり、それは深さ原理的に理解することは容易ではありません。
建築家やチームのテクニカルディレクターとして、我々はシステムを所有している必要があり技術的なポイントあまり知っていますか、あるいは少なくともその原則を知っている、ということを必要とします。このように、でも問題で、Baidu / Google結果が出ていないとき、慌てる必要はありません。
このような考え方に基づいて、彼がルックアップするためになりましたDubbo。著者の場合は、のためにDubbo、より身近な、そしてそれは、そのフレーム自体からある方法もインターフェイスをベースに呼び出し、ロードバランシングとフォールトトレラントクラスタを実現しました。比較するとSpringCloudの用語は、追加の導入のようにする必要はありませんRibbon/Feignそのような成分。
もう一つのポイントは、Dubbo強力なおかげSPIメカニズムは、我々は非常に簡単にそれを拡張することができます。あなたがビジネスニーズを持っている場合は、多くの場所で、そのようなRPCプロトコル、クラスタレジストリ、シリアライズ、スレッド・プールとして、拡張することができます。
しかし、それを言ったDubboだけで、高性能のRPCフレームワークは、それが運ぶSpringCloudよりかなり比較しましたREST和RPC。しかし、この時点で、唯一の一般的なプロジェクトでは、このパフォーマンスの違いは、ケーキの上だけでアイシングまで十分に最後の言葉ではありません。
などの他のコンポーネント、についてはHystrix/Zuul/Config/zipkin、このようなビューの著者のポイントとして、あるいはビジネスの規模を参照してください。マイクロサービスは、単にデザイン、建築のコンセプトではなく、マイクロと呼ばれる多数の分散サービスフレームワークで使用されるということです。これらのフレームワークは生産が、マイクロサービス・システムの問題点を解決するためにされています。
、技術選択を行うことで、太った男を食べるアリ、Jingdongはのような直接的なベンチマークを覚えて、メーカーはこのグループ、1、ビジネスシナリオの多分私達は決してかなりその種類の美しさを体験するために一口を知っています。また、一般的な企業そのようには人材プールの人々はありません。ラインに問題がある場合は、すべての後に、あなたと損失を共有する誰もありません。
一般的な、または彼らの実際の状況と組み合わせてでは、最も安全な技術ソリューションは、ビジネス上の要件を満たすことができます。
第三に、合併症
サービスを分割し、また技術的なソリューションの選択を完了し、その後、すべてが順調で、まだラインとコードを開始？もしそれだけで開発者として、それは確かにオープンラインとラインの上にあります。あなたは関係なく、細部の戦略的に有利な位置にコンテンツシステムの担当者、している場合、問題を複雑にバインドされています。
1、残業とフォールトトレランス
異なるサービス間のコールのサービスは、リモート呼び出し後。リモートコール最も基本的な設定、つまりタイムアウトがあります。
例えば、中にDubbo1秒のデフォルトのタイムアウト。私たちは、単にするために、別の値にデフォルト値や統一セットを使用することはできませんDubbo最高の目標とされたタイムアウトを設定します。
いくつか、設定することができ、短い、比較的単純なビジネスのような、しかし、複雑なビジネスのために、あなたが適切な時間を長くする必要があります。そのため、また、フォールトトレラントクラスタの問題があります。
ではDubbo、デフォルトのポリシーは、フォールトトレラントクラスタ障害の再試行があり、その数は2です。タイムアウトが短すぎるので、いくつかのビジネス自体が、実行に時間がかかる場合は再試行するフォールトトレランスメカニズムをトリガーします。要求がそうである同時再試行の数が多いいっぱいにDubboスレッドプールを、さらにはバックエンドのデータベース・システムに影響を与え、接続の結果が枯渇しています。
2、フォールトトレランスと冪等
私たちは、タイムアウトが短すぎる設定されている場合、それは再試行していきます多数の要求につながる、と例外が発生することがあり、上記と述べました。
読み取りおよび書き込み要求のこと、その他の詳細を隠すもあります。それは、読み出し要求である場合には、再試行は問題ではありません。私たちのインターフェースは、自動再試行、それをサポートしている場合、それは書き込み要求が、ある場合には？これは、パワー・インタフェースなどの問題を伴います。
書き込み要求インタフェースは冪等をサポートしていない場合は、フォールトトレラントクラスタは変更されているfailfast急速に失敗したこと。
図3に示すように、分散トランザクション
私は、業界で分散トランザクションが完全に技術的な問題を解決していない、感じています。そこには普遍的な解決策はありません、また両方の効率的かつ簡単な手段です。
それにもかかわらず、我々はそれ以外のデータは確かに汚れや乱雑になり、事前にこれを考慮に入れる必要があります。
解決策を考える前に、私たちは彼らのシステムを見てする必要がありますすることは本当に強い一貫性の追求ではないBASE理論、分散システムでは、異なるノードを許可すると、同期のプロセスの遅れがありますが、一定期間後に復元します、究極のデータの一貫性を実現しています。
これらの二つの考え方に基づいて、我々は、分散トランザクションを、独自のプログラムを開発するために行きます。
シーンは、XAプロトコルを考慮することができる、強力な一貫性を必要とするために、3段階または2段階の提出がで保証されて提出しました。
最後のシーンの一貫性の要件については、それがメッセージ・キューに基づいてTCCモード、補正モード、またはモードとみなすことができます。
メッセージキューモードに基づいてたとえば、あなたが使用することができますRocketMQ。これは、トランザクション・メッセージ、全体のプロセスは、おそらくこれです、この時間をサポートしています。
RocketMQキューのメッセージに取引メッセージを送信します。- メッセージが正常に送信され、ローカルの事務を行います。
- ローカル・トランザクションが成功した場合、提出する
RocketMQ消費者に見える提出後にトランザクションメッセージを。 - ローカル・トランザクションが失敗した場合は、削除
RocketMQトランザクションメッセージは、消費者は、このメッセージは表示されません。
また、ここではアムウェイアリオープンソースでSeata。最新バージョンは1.1.0、そのようなAT、TCC、SAGAおよびXAトランザクションモードなど複数のトランザクション・モードのサポートです。
私は記事が基づいている必要がありSeata 0.7下学ぶことができます興味を持っている友人たちによって書かれたバージョン。
SpringBoot +ダボ+ Seata分散トランザクション戦闘
4、メッセージキュー
分散システムアーキテクチャでは、メッセージキュー、デカップル及び高い並行性と高流量に対応するシステム間の非同期処理のために、それは間違いなく大きな武器です。
この武器を使用する前に、おそらく我々は検討中のメッセージキューの迷惑を持っている必要があるため。
考慮すべき最初のメッセージ・キューが使用できない場合、システム自体が利用できない多数発生しません、可用性です。
その後、メッセージは、それを失うことはありませんか？メッセージそれの送信の信頼性を確保するには？データ伝送時間と消費を確認した後に提出され、例えば、ブラシディスク自体、メッセージキューメカニズム、同期メカニズムを検討します。
その後、メッセージは失われていない場合、問題は多かれ少なかれメッセージが繰り返されるかもしれ、私たちは消費者を繰り返して検討すべきである今回は、そのメッセージの冪等で問題がないことを保証するために、消費繰り返されます。
また、メッセージシーケンスの問題があるかどうかのメッセージ・シーケンスの問題、あなたのビジネスシーン、あなたはこの問題を持っている場合、どちらかのいずれかでその消費量を確保するための時点で、設計時にそれを避けます。
5、統合ログ
マイクロサービスを分割して、ロギング・システムはまた、別々のモジュールに発展することがあります。ログを表示するには、我々は一つ一つが参照するには、異なるサーバーにログインする必要があります。
したがって、統合ログ処理プラットフォームを構築することは避けられません。我々は使用することができELK、ログ集約のためのソリューションを。
ここで、我々はまた、問題を追跡するためのリンクが必要です。マイクロサービスコールの複雑な連鎖では、単一のアプリケーションよりも問題を特定し、追跡することはより困難になります。
この問題については、我々はグローバルに一意に生成し、分散型コールチェーンの導入を検討しTraceID、コールチェーンアップを通じて全シリーズ、。組み合わせダボの枠組み、我々は自分自身を実現するにはFilter、この通過しますTraceID。
あなたは、特定のアイデアを参照することができます。SpringBoot ELK +ダボは戦闘を統合しました
もちろん、我々はまた、解決するために、成熟したオープンソースのフレームワークの数を使用することができます。
概要
この記事を簡単に問題マイクロサービスの設計・開発プロセスの一部をまとめたもので、それが関与している可能性があります。
言葉のひとつこれらのビューは、単に過去数年間に私の経験をまとめたもの。
それはあなたを助けている場合、あなたは別の視点を持っている場合は、積極的に〜を話し、共有してください〜奨励するために賞賛してください