オリジナル住所：梁桂趙さんのブログ
ブログのアドレス：blog.720ui.com
国民の関心番号へようこそ：「サーバー側の思考を。」認知の限界を破り、洗練されたとともに、一緒に育つ同じ周波数のグループ。
まず、マイクロサービスを受け入れる、単一のシステムを逃げましたか？
単一のシステムは、機能の大規模かつ包括的なセットであるモノマー系とマイクロサービスとの間の差は、各サーバは、このアプリケーションのフルサービスを実行しています。マイクロサービスは、生態系の一部であり、他のマイクロサービスは共生関係であり、自律的かつ独立した機能モジュールです。展開の変化に影響を与え、そのような低効率の開発など、メンテナンスコストをモノマー系を開発するのは非常に簡単です、テスト、展開するだけでなく、多くの単一のシステムが直面している問題：今、業界では一般的に、単一のシステムやマイクロサービスに関する意見します大規模な、コミュニケーションやコラボレーションを促進するために、各サービス容易に開発・保守を実施することができ、それは小さなアジャイルチーム開発と継続的な送達に適している貧しい人々スケーラビリティ、技術選択の高コスト、およびマイクロマイクロサービスの導入することができ、各マイクロデューティサービス単一、高い凝集力及び低い結合。同時に、独立した、スタンドアローン、独立した展開に各マイクロ開発サービスは、サービス展開やダウンタイムは、それだけで現在のサービスに影響を与える場合は、全体のビジネスシステムを生成しません、各マイクロサービスとの間に独立しています衝撃;各マイクロシステムサービスは、スケール、大規模かつ高同時ユーザの顔の拡大を続ける独立水平拡張と垂直拡張を行うことができ、各マイクロサービスは異なるプログラミング言語と異なる記憶技術を使用することができ、より多くの米国を行います新しい技術を試すのは簡単。また、事業再構築のための単一のサービスは、ビジネスおよび技術的な債券に大きな負担に直面することはありません。
マイクロサービスシステム、単一のシステムからのマイクロサービスシステムへの変革のプロセスに著者の見解は、我々は真剣にマイクロサービスの利用を上演かについて考える必要があります。マイクロサービスは、難易度の高い設計・運用・保守要件についてですが、また、技術の複雑さのいくつかをもたらした、銀の弾丸ではありません。したがって、我々は考えると分散、データの一貫性、管理・運用・保守サービス、サービス展開の自動化ソリューションの複雑さに対処する必要があります。個々のサービスの複雑さを軽減するサービスのより小さなボリュームに複数になるためにモノマーを分割することにより、実際には、マイクロ・サービス・システム、しかし、ビューの全体的な点から、このアプローチは、多数のサービス、サービスの存在をもたらしましたコールは、より複雑になり、システム全体のアーキテクチャをもたらす、相互に増大します。
私たちはしばしば、ビジネス価値とコストの考慮事項を無視して、あまりにも多くの技術の追求、それが私たちのうまく設計された、分散型アーキテクチャにつながる可能性が真剣に我々の開発スピードとビジネスの急速な反復に影響を与え、そして不確実性と、多くの場合、私たちのビジネスにつながります1年6ヶ月でのアーキテクチャは、車輪の再発明を完全には適用されませんでした。また、場合失明につながることができます開発されていないビジネスは、事前にサーバリソース、良いよりも起動ビジネスのためのより多くの害の多くを無駄にしました。したがって、我々は、プロジェクトの初期段階では、ビジネスの急速な成長を確保するための信頼性と独立性と完全性を最小限にするためにシステムを確保、マイクロサービスアーキテクチャの導入後の技術の複雑さを軽減するために、例えば、それがために良いmicroService、高い要件の運用・保守のために困難ですアーキテクチャは、安定したインフラストラクチャが必要です。良いビジネスの発展に伴い、システムは明確なビジネス思考で、この時点で、当社の事業展開に限定されているその拡張性、スケーラビリティ、可用性とパフォーマンスの規模を拡大し、私たちを継続し、再びマイクロを考慮することが、より多くのリソースを投入しますサービス変換。
マイクロサービスアーキテクチャのモジュラーユニットとしてのサービスを使用して、私たちは私たちの後復興のためのスペースを確保するために、早い時間のモジュラー設計でMavenのモジュールによって予備分離に頼ることができます。共生関係にあるマイクロ生態系サービスということに注意してください。彼らのビジネス価値が共生する必要がありますがここでは、彼らは、依存可能なリンクに限定されていません。したがって、その後ポスト認識システムモノマーコア値、ファンクションキー、およびこれらの機能および自己完全モジュール別に分割しました。ここでは、リハビリテーションプログラムは、作者の読むことができる「マイクロ可用性スケーラブルなサービスアーキテクチャを：ダボ、春のクラウド・サービスメッシュをもとに」「レガシーシステム、」書籍の章XIIのマイクロサービスアーキテクチャ変換。
要約すると、全体的にマイクロ個々のサービスの複雑さを軽減するために複数のサービスの小さな容積になるように、モノマーシステムを分割することにより、サービスが、我々は、このアプローチは、多数のサービスをもたらし存在し、サービスしていますコールは、より複雑になり、システム全体のアーキテクチャをもたらす、相互に増大します。したがって、私たちは唯一の技術に焦点を当てますが、現段階の利益の保護を最大化するために、入出力比を考慮する必要はありません。
第二に、離れて泥の大きなボールから滞在するモノマー系を取り除きますか？
モノマー系は、多くの人がそのサービス内のポリ混乱を批判し、それが泥の大きなボールのように見えます。次に、サービスの後に、この問題を解決するには？単一のサービスの複雑さを低減するので、単一システムの複数の機能を見てより多くのサービスの小さな容積になるように、モノマーシステムを分割することにより、実際には、マイクロ・サービスは、しかし、全体的なシステムアーキテクチャがより複雑になり、明らかです。示すように実際には、マルチサービスの運用環境の可能なシナリオの間で呼び出します。
典型的には、微小生態生産サービス環境は、サービスの百数十があるかもしれない、上記の場合よりも複雑です。だから、私たちのために、どのように体系的依存関係を整理し、サービスをリンクすることは非常に重要です。場合は特に大きなプロモーション、コアリンクへの強力な保護の必要性は、ジョブがさらに重要になります。この点で、私は、APMのトラフィックコレクションをコーミング自動化されたリンクをお勧めします。
加えて、我々はアーキテクチャを設計し、サービスの粒度があるたび分割問題は、例えば、新しいプロジェクトを作成、または当社のサービスは、可能な限り凝集残るようにサービスの境界が曖昧ときのために、我々は、サービスのための明確な境界を議論する必要がありますセックス。
第三に、移行サービスは、システムの堅牢性マイクロが行う改善できますか？
ここでは、現行のビューがあります：単一のシステムでは、サービスまたは一顧場合しかし、マイクロサービスの展開の使用を達成することができ、サービスに障害が発生した場合、全体の業務システムが影響を与えることになる、大規模かつ包括的な機能セットですマシンは、唯一のビジネス全体のシステムに影響を与えずに、現在のサービスに影響を与えます。
実際には、このビューは非常に正しいようだが、実際のビジネスシナリオでは、キーは私たちの変革の原因を促進することではありません。まず、単一障害点を回避するために、モノマーは、確かに、クラスタリングとロード・バランシングを必要とする、マイクロクラスタ化と負荷分散サービス（垂直分割サービス）が相互に排他的な関係ではなく、高度に並行とに分布にすることを、そして注目共生関係。また、サービス展開を解決するために、我々はローリングリリースがサービスにおける無中断することにより達成されると考えることができます。したがって、モノマー系は、必ずしも堅牢ではありません。一方、マイクロサービスの導入後に、全体的に、このアプローチは、システム全体のアーキテクチャは、一つのリンクに、より複雑になり引き起こし、また増加し、お互いのサービス間でサービスコールの大多数をもたらしましたノード障害の確率が大幅に増加し、より多くの信頼はまた、多くの問題が発生する可能性があることを意味します。この場合、コール・リンク上でこれらのマイクロサービスのバーの1がダウンしたサービスを提供することができないと仮定して、その後、どのように自分の使いやすさを確保するための強力なアップストリームサービスに依存していますか？（私は、効果的なプログラムが対処されていない、特に強い依存呼び出し、サービス低下やヒューズメカニズムがビジネスにとって有害であるかもしれないここです。）このように、多くのシナリオでは、サービスの停止も、全体の業務システムに影響を及ぼす可能性があります。
我々は、設計のための失敗やガバナンスのサービスシステムを構築していないのであれば、それは、サービス全体の堅牢性につながります。
第四に、移行サービスは、マイクロシステムのパフォーマンスを向上させることができますか？
だから、の主な要因マイクロサービスの移行は何ですか？私は最も重要な利点の動機は、スケーラビリティとパフォーマンスの考慮事項サービスを強化することだと思います。なぜなら、ホストマシンの限界のサービスがボトルネックに達する可能性があり、さらに多くのマシンのリソースを圧迫するためには、それは良いアイデアであるサービスを分割します。同時に、我々はまた、自動的に機械の使用を調整するための更なる拡大を縮小することができます。ただし、移行サービスは、マイクロシステムのパフォーマンスを向上させることができるのだろうか？私のポイントは必ずしも真実ではありません。オリジナルのRPC通信が数倍になることと、コール・リンクは、長くなるのサービスの後、パフォーマンスの損失が増加しています。例えば、一つの大きな課題は、オフサイトネットワーク遅延生きることで、街全体の遅延未満百ミリ秒単位で可能という地域横断的ネットワーク遅延を想定し、問題があるだろう、HTTPリクエストは、RPCコール全体で200個の都市が関与課題は非常に大きな遅延によってもたらされたので、その後、全体の応答時間は、多くのことを増加します。だから、データ遅延の問題を解決するアリのためには、提案された解決策のアイデアの最初のユニットは、高分子内のユニットは、地域横断的訪問をしないとすぐに完了されているのと同じエリアに収束要求を行い、「ユニットは、閉じました。」加えて、同期化はまた、閉塞のリスクを増大させることにより、再試行クロスネットワークサービスコールのタイムアウト問題があります。
そのため、システムを改善するために全体のビジネスプレスマシンのリソースのためのシステム全体のパフォーマンスを向上させるために、サービス間のリンク上で呼び出すコストのサービス・パフォーマンス。
第五に、各コールが提供するマイクロサービス=サービスの可用性は、信頼性が高く、ありますか？
マイクロサービスの可用性のために、多くの人々がそれぞれの呼び出しによって提供されるサービスは、信頼性が高く、利用可能であることを理解しています。このビューは、右ではありません。実際には、マイクロ・サービスは、そのサービスの全体的な可用性を確保します。通常、サービスはAあなたは10秒を呼び出す場合、その状況は後者を詰まらせる可能性がある、サービスBを呼び出す場合、間接的に、サービスに結果が利用できない、爆発スレッドプールにつながりました。したがって、我々は可能な限り回避され、同期の問題を遮断する、時間の非常に短い期間内に完全な結果を保証するために、タイムアウト応答機構がかかります。
サービスBに障害が発生した場合に加えて、すべてのコールは、サービスに依存しますブロックされて表示されますがある場合、多数の要求は、サービスの麻痺が生じ、スレッドリソースが完了し、消費されている原因となります。実際には、サービスとサービス間の依存関係は、「なだれ」効果のサービス障害を引き起こすことにより、間接的に、カスケードの伝播を引き起こす全体のマイクロサービス・システムが使用できない原因となります。この問題を解決するために、ヒューズメカニズムが場に出ます。
第六に、マイクロサービスデータベースは、相互に独立し、透明であり？
主流のビューはマイクロサービス、各サービスは、独自のキャッシュとデータベースとキャッシュとデータベースは相互に独立し、透明であり、を有することです。そのため、共有キャッシュと共有データベースが間違っています。あなたがそのデータサービスAサービスBを取得する必要がある場合はどのように行うには？一般的には、Bは、APIインターフェースデータを取得するサービス、Aインターフェイスを呼び出すことによって組み立てられたビジネスを行うサービスを提供することです。したがって、マイクロサービスの後、サービス間のデータ交換は、ミクロデータサービスとの間の独立性を損なうことになるビジネスロジックB、Bとの間を横切るサービスのサービス・データ・アクセス・サービスと、インタフェースを介して行われます。
この時点で、私は冷たい水にそれを注ぐ必要があります。何が絶対的ではなく、データを共有する必要があるかもしれないいくつかの特別なシーンがあります。まず、それは古いデータベースサービスとの移行の必要性を達成するために多重化新しいサービスシナリオ、新しいサービス機能やデータへの古いサービスの移行です。第二に、そのようなデータ集約レポートなどのサービスのうち、同じデータ・ソースに依存してもよいです。我々は、単にRPCインターフェイスに依存している場合は、この場合には、失敗の大きなチャンスが得られ、散発的なタイムアウトを呼び出すにつながる可能性があります呼び出します。その後、数による集中管理ETLやデータウェアハウスは、プログラムから引き出され、そして、したがって、この問題を解決するためには、通常のルーチンデータの共有、またはローカルベースのサービスの境界内のデータ集約続い方法によるデータの冗長データの同期であり、外国再処理されたデータ。第三に、より現実的なコスト。実際には、それ以上のデータベースは、より多くの資金調達コストをもたらすでしょう。多くの場合、我々は、資金調達コストの問題を検討します。私たちは、元のデータベーステーブルを再利用する明確なビジネス価値を待って、その後、別の独立したデータベースを検討することを選択しました。
一方、高価回避する技術的解決策を共有するデータとデータ不明状況との間のデータ移行のコンテキストを繰り返し、より簡単に必要なときにサービスのサイズを調整し、データ移行サービス粒度及び安定した後ことができます。したがって、我々は可能なマイクロサービス、マイクロサービスのメリットをフルに活用の主流ビューに適合するように、両者の間の適切なバランスを追求しなければなりません。
マイクロサービスの実装を保護するために七の団体？
マイクロサービスと新しい要件前方に置く組織構造、大規模なチームが複数の小さなチームに分かれ、各チームはその動作および1つ以上のサービスの保守・運用・保守を開発し、必要なプロセスを提供し続け、連続することをお勧めします展開、DevOpsチーム。
異なるサービスは、実際のシナリオの下で、別のチームの開発と保守によって提供することができる、便利なサービスを他の言葉で、社内チームは容易に開発し、コミュニケーションとコラボレーションを促進するために維持しますが、ためにすることができ、閉ループを生成することができ、より微細社内チームを外部チームのコミュニケーションとコラボレーションのコストの大きなコストがあります。示されているように、サービスCの理解のためのチームAには、我々はそれが単一のサービスまたはマイクロサービス、それが下流のサービスに依存する必要があるいくつかのサーバーを展開していているかわからない、電流制限、ヒューズと降格の存在ブラックボックスであります戦略、およびアクセス方法。私たちは通常の状況下では、これらの問題を確認する必要がある場合は、手動調整と確認が必要。
もちろん、これは避けられない質問をもたらした労働者の組織部門で、我々は可能な限り、マイクロサービス事業の独立性と完全性を保証するために、サービスモジュールについて分割することが、私たち自身の社内サービスチームの結束を確保しようとしますサービスの存在にあまり依存し、呼び出しをチェーン。ここでは、それが新たな問題をスローします。マイクロサービスどのように「マイクロ」？実際には、分割されたサービスを可能な限り小さくないが、極端な場合は、このアプローチが間違っている、サービスとしての機能を分割することです。したがって、マイクロサービス事業の独立性と整合性を確保する必要があり、分割サイズは、ビジネス・サービス・モジュールの周りの分割を分割しています。ビジネスの価値が別々のサービスに分割した場合/技術的価値が明確ではないが、プロジェクトの人生はすでに十分持っていた全体で、モノマー系に結合することができます。開発やビジネスニーズを持つならば、我々は、システムのソースコードレベルのモジュラー構造を調整し、独立したマイクロサービスにそれを分割することができます。
チームの利益と上のマイクロ生産サービスの出現を検討するように時々、チームは、プロジェクトの絶対的な所有権を持っている「半完成品を。」私は、このケースは一意ではないと信じているが、ノルムの大半。今、私たちは、ケースを見てください。チームは再利用機能を考慮し、「ブロックコメント」機能を含む「インタラクティブなコンポーネントを、」開発しました。この時点で、Bチームも同様の開発を知りませんでした「インタラクティブなコンポーネントを。」Cチームは、この要求を持って、それはAが希望で、この「インタラクティブコンポーネントは、」再利用することができますが、理由は、現在のビジネスチームAのより考慮の設計では、この「インタラクティブな要素」で、何の良い複合体が存在していないことをチームを知っています例えば、サポートされていない、の使用は機能「Gailouコメント」、およびので、Cの評価チームは、あなたのビジネスニーズに、独自開発の「インタラクティブなコンポーネント」に沿って一週間を過ごすことに決めた後に、他のプロジェクトの現在の進行状況の理由はすぐにサポートを提供することができないチーム。この場合、個々のプロジェクトチームは、「インタラクティブなコンポーネントを。」を維持します チーム間の国境の責任は限界が生じているため、この場合、サービスを再利用し、あるいは状況の断片化された自然の中で結果として、これは一般的に、企業レベルの計画と協調が必要です。偶然にも、単一のシステムワークでは、チームAとチームBが、両方は、両チームの両方の利益が、彼らはオリジナルのアーキテクチャ融合を壊していないが、元の境界に基づいて領域を識別することを確実にするために統合する必要があります。
さらに、安定性の低い外部のRPCインターフェイスと仮定して、一般的には、不安定性の原因を分析することであるが、クロスチームの協力の場合には、外部サービスはブラックボックスであるかもしれない、とおそらくチーム間の見えない壁の壁です、そのコミュニケーションとコラボレーションのコストが非常に大きい、今回はみんなの利益が合意に達するためになるように、誰かが全体のリンクをリードする必要があります。さて、今日は、可能な限り最も効率的な方法は、このような冗長なキャッシュやインタフェースアダプタなど他の手段によって、この問題を回避するための社内チームです。したがって、それはおそらく、組織構造や環境の下でJiaoyouのビジネス価値を最大化するために、現在のプログラムであり、我々は、現在および将来の展望に適応する必要があります。サービス・モード・アダプター：それはインタフェースアダプタになると、非常に一般的なマイクロアーキテクチャ設計サービスもあります。一般的に、私たちに必要な形式で私たちのメッセージ本文と矛盾への外部サービスは、この時点で、我々は、サービス適応ロジックを大量に導入することなく、当社のビジネスロジックを保護するために、そして、現実を変革する可能性は低いように見えるそれらをプッシュする必要があり、我々アダプテーション層（アダプタ・サービス）に導入され、メッセージ本体が標準化されたフォーム上の外部サービスに適合し、次にアップサービスにさらさ、例えば払い戻し適応、適応および他の物流されるであろう。
したがって、会社はかなりの程度までサービス境界の影響を決定するために組織しました。通常の状況下で、我々はビジネスを満たすために、自分のチームの境界内の領域を分割しない技術的な観点から、これは「半」ですが、できるだけ多くを必要とするが、それはJiaoyouは、現在の環境のビジネス価値を最大化し、おそらくですプログラム。部門のいわゆる長い期間、我々はそれが十分に大きい値を持っていることを見ると、さらなる統合も考慮することをお勧めします。
最後の声で書かれました
最後に、我々は、プロジェクトの配当をもたらすための新技術、技術の導入について話しています。新学習技術は、コストやメンテナンスコスト、および保護、運用、保守の可用性を考慮する必要があります。例えば、私の護衛の運用・保守に、私は会社で様々な技術の使用を容易にすることができますが、私は私が運転・保守のこの分野での専門家ではないです知っているので、どうかは、必ずしも、別の会社ではMongoDBを使用する勇気はありません問題が発生し、私は解決策ではないかもしれません。だから、新技術の技術的なリスクの導入が存在してもよいです。非常に多くの場合、我々は設計に基づいてすることができない、これは正確ジュニアエンジニアとシニアエンジニアの間のギャップです。例えば、Redisの分散ロックを達成するため、多くの人々は、コードのみでこのロジックを実装する方法を考えるが、Redisのクラスタマスター・サービスがハングアップした場合、それは、非同期から一次同期、および分散ロックですので、サービスに直接切り替えます重点は、あなたは、この時間分散ロックは、データを失った、ということです、あなたのビジネスはビジネスで使用する場合は、ロックを分散し、再三の要求になります、それは現時点では動作しますが、最新のデータのみ機能ロック確かにしなければならないですそれは、特に金融や支払いで、重要なシーンなので、ロック分散のRedisのシングルポイントのバージョンではない場合は、安定性の問題を解決する必要があり、良い方法、使用しないではありません。（引用「高可用性のスケーラブルなマイクロサービスのアーキテクチャ：ベースダボ、春のクラウド・サービスメッシュ」著者「グループの例チェンチャオのシェア、特に素晴らしい。）ここで、少しトリッキーな質問の下で、背中のトピックに、私たちは、前者は低コスト試行錯誤があるので、あなたは、多くの場合、古いプロジェクトは、より保守的であるが、新しい技術を使用しようとする新しいプロジェクトを見つけるでしょう。興味深いことに、新会社は、技術の発展に敏感である、などの多くの中小企業は、たくさんの練習を持っているとネイティブな方法のクラウドに上陸しました。この時点で、あなたはおそらく、私が見解について知っている：通常の状況下では、技術スタックの使用は、同社の運用・保守サポートの背後にあるだけでなく、技術的な深さの力を制御します。だから、私たちは、戦場で準備ができて、新しい技術、事前に予約する必要がありますが、ほとんどのケースでは、我々は確実にし、既存の技術（ツール）のビジネス価値を最大化します。
要約すると、この記事では、実用的な思考の多くを沈殿させて、私が見て、仕事以来聞いて、キーポイントは、サービスの低下を歌うのではなく、私たちはミクロで見て、アーキテクチャを考える純粋に技術的な観点から、独立した思考残ってみましょうサービスは、それが既存の技術（ツール）のビジネス価値を最大化するようにします。
最後に書かれました
[サーバー]思考：私たちはフロントラインの戦闘インターネットアーキテクチャとプロジェクト経験を探索するコアサーバ技術と話します。探求し、交流の自分のサークルを見つけるために単独R＆D人材のすべてをしてみましょう。ここでは、認知の限界を打破するために、問題を解決するために最短経路に接続され、認知接続トップ技術ダニエル、思考の接続優れた方法、接続するすべての罰金の方法をアップグレードすることができます。
すべての「サーバー側の思考」でよりエキサイティングな記事、！