1. springmvcサービスから得られたステータスフレームの変更は、マイクロフレームワークをspringcloudは何ですか？
悪いスケーラビリティ、パフォーマンスの難しさ
基本的なWebアプリケーションのパフォーマンスのボトルネックはデータベースです。このシステムは、MySQLデータベースを使用しています。3つのデータベースに対応する3つのアプリケーション。別々の読み取りないと書き込みませ。データベースの読み取りと書き込みの両方の操作。その時点で、テーブル内のデータの最大量5000万データ。約1000のQPSデータベース操作のピークは、QPS 2000の圧力測定結果をサポートすることができます。このインジケータは、私は驚いてます。なぜ、このような良好な性能を持っている？まず第一に、何のロジック複雑なクエリ、テーブルの操作ですべてのクエリ、実行するための複数のステートメントに分けノークロステーブルのトランザクション処理、複雑な処理は、ありません。最も複雑なアクションは、ほぼ20倍のデータクエリを実行します。第二に、そして最も重要な要因は、ここではSSDディスクです。現在の状況から、当社の技術革新のための十分な時間も年末までにハングアップすることができるはずです。これにもかかわらず、MySQLのはまだないように注意してください。事業活動に従事するたびに、私たちは怖がって凝視をプレイしている、祈りはあまり効果的ではありません。
アプリケーション層から、10の現在の識字率：1は、インターフェース10億訪れました。300QPSのピーク期間トラフィック。同社の事業は、半年間のデータの量、10回の予想交通量の増加を倍増、急速に成長しています。重大な挑戦でもあり、学生は、製品のスパイク、スパイクに従事すると脅した...毎秒何十万もの量は、サポートすることでなければなりません。これは、耐圧範囲MYSQL、メモリデータベースの読み取り動作に切断される必要はなく、SSHアーキテクチャで、拍動を達成するために、別個の読み出し及び書き込みを持っを超えます。また、HibernateはSQLを記述することなく、データベースの操作をカプセル化し、微細な最適化も、それが働いて得ることができます。システムが遅くなるたびに、あなたがDBAに依頼する必要があり、SQLヘルプは、それらのスタックを参照してください。時々、そのインデックスを構築する方法の研究、DBAのエクスポートSQL文をしてください。
システムは、長いサイクルを学習し、肥大化
100の以上のインタフェースは、3つの大きなプロジェクトに分割されています。最大のプロジェクトは600以上と300の以上のクラスに続いて1300の以上のクラスがあります。SSHアーキテクチャ、SVNバージョン管理、コンテナ等の樹脂、nginxのは、プレルーティング。このルートを安心、それが復興作業を通じて強力なサポートです。プロジェクトでは、モバイル端末のアプリ、PCWEBアプリケーション・インターフェースの純粋なバックエンド。また、復興作業が大幅に軽減され、より困難にします。フロントエンドはまたに接続された場合、それはより酸性に冷却します。
チームメンバーのための大規模システムでは困難を引き継ぎます。オリジナルの5人からの決済サービス独立した開発者の後、2ヶ月以内に10人に拡大。同時に、学生エキサイティングな製品はまた、アイデアのすべての種類の製品、開発の圧力サージになってきたように、血液と遊ぶために関係します。しかし、新しい学生が、起動できない、多くの場合、損失で、クラスの数百人を見て。私は達成するためにどのような機能かわからない、とその機能を向上させることになっています。3ヶ月後までは、徐々にしか役割に新しい従業員。それにもかかわらず、多くの恐竜レベルのコード、誰もあえて挑戦が残っています。クラスの最大2000行以上、500以上の行、重複コードの多数は、各調整が失敗に終わった方法の核心です。
協力の高コスト
プロジェクトチームの増加に伴い、それぞれの新しいバージョンの開発は、同じアイテムコードを修正するために一緒に仕事に人を必要とします。バージョン管理ツールの使用はブランチを管理するが、しかし、必然的に、多くの時間は、コードの競合の管理に費やします。新機能、機能拡張、バグ修正、さまざまなクライアントのサポートは、プロジェクトで行われ、あなたは別の枝を確立する必要があり、同時に5つのまたは6の分岐のピークが共通しています。この場合、コード違反の頻度が非常に高いです。一週間の開発の小型版では、紛争解決の分野における1日は正常です。
難しいテスト
テスト作業は徐々に悪化しています。
難易度の高い構築するためのテスト環境。枝の増加に伴い、テストへの各ブランチは、あなたが別のテスト環境を用意する必要があります。高い環境コストの建設。
ただ、分岐統合紛争管理のために、機能をテストし、我々は再びそれを再実行する必要が終了しました。真剣にプロジェクトのスケジュールに影響を与えます。
ライン高リスクオン
システムの複雑化によって、オンラインのリスクもますます大きくなります。小さな機能の変更、バグを修正し、ログを印刷し、行全体を必要とします。修正間違った場所と、システムが崩壊しました。オンラインの長い時間のため、一度ラインで、夜の半分をする必要があります
マイクロサービス改革の利点
あなたが変革プロジェクトを支払うことを始める前に、私たちはマイクロサービス建築事務所、データ・ウェアハウス・プロジェクトの改善を完了しました。コミュニティの詳細なプロジェクトの実施プロセスは、dockoneシェアの詳細をした、ここを参照してください。我々はマイクロサービスアーキテクチャに調整することは、これらの問題を解決することができると信じています。
パフォーマンスの問題
インタフェースの高性能な要件については、データキャッシュを確立する方法によって最適化することができます。
学習サイクル
ごく少数のインターフェイス項目が緊密に結合された単一のビジネス・ロジックが含まれ、1〜2時間のインターフェースコードの開発を読んで、あなたはすぐに始めることができます。
協力費
各プロジェクトは、相互作用だけで、プロジェクト間のインタフェースを介して、比較的独立しています。インターフェイス、開発を決定した後、試験は、オンライン、従って、通信コストを削減し、独立して行われます。
バージョン管理
プロジェクトが依存し、コードに依存しないとの間のインターフェースであるため、各プロジェクトには、別々のコード・ベースを作成することができます。プロジェクトのセグメンテーションは、各プロジェクトの開発は比較的小さく、同時に、変更を行うために一つだけの開発者があるでしょう。これは、合併作業が存在していませんが、またコードをマージする過程での問題を回避するために、基本的なコードです。実際には、マイクロサービスアーキテクチャの開発に基づいて、我々はトランク開発と直接分岐政策を採用しなかったが。
テストの難易度
各プロジェクトの独立した展開、独立したテスト。コード分岐を排除することによって、ノーコードの合併問題、作業負荷が軽減されたテストを繰り返します。
オンラインリスク
別ライン上の各項目は、問題が生じた場合でも、それはインタフェースの少ない数に影響を与えます。
新技術
マイクロサービス改革における四半期の後、新たな技術をシステムに導入され、開発はもはやSSHアーキテクチャに限定されません。スパークは、Hadoopの、HBaseのおよび他の大規模なデータは、プロジェクトで使用し、効果的にビジネスの存在の問題を解決するために始めている、関連技術、Couchbaseの、Redisのと他のキャッシング・システムを処理します。
などのプロジェクトおよびトラブルシューティングするために、より困難な物事がうまくいかない、などの多くによってもたらさもちろん、良い基盤、マイクロサービスの問題、
2.どのように確保するために、そのユーザーのログイン情報やその他の大規模なデータトラフィックデータ整合性の問題？
Redisのは、アバランシェキャッシュ、キャッシュコヒーレンシは、キャッシュ浸透/破壊に関する、分散キャッシュのような障害ホットデータセットなどの問題を使用しました。
キャッシュ内のデータを削除し、データベースを更新するために行く、最後に更新されたデータキャッシュに
書き込み要求が来て、私たちはキャッシュ内のデータを削除し、
その後、正常に削除され、我々は、データベース内のデータを更新します、場合は、この時点でデータベースを更新データは、失敗した全体の書き込み要求が失敗し、直接のリターンデータが読み取り要求を介して、この時間は変更されない、キャッシュは対応するデータを発見していないデータがキャッシュに書き込まれている間、データベースからデータを読み込みます、このデータベース内のデータとキャッシュデータが同じで、何のデータ整合性の問題が存在しない
データベース内のデータを更新した後、再度、キャッシュ内のデータを更新し、キャッシュ内の更新データに今回は失敗し、データベースに直接戻りますデータは、最新のデータであるデータは、この時点でキャッシュ、データキャッシュとデータベース内のデータに書き込まれている間、キャッシュ対応するデータを検出しませんが、データベースからデータを読み込みます、読み取り要求をされている起動します同じで、何のデータ整合性の問題はありません
成功したキャッシュを更新し、キャッシュ データベース内のデータによると、一貫性のある、データの一貫性の問題はありません
一見、データの整合性の問題に、このソリューションの完璧なソリューションでは、我々は、私たちは上記のスキームを分析してみましょう。例えば秒あたりの同時読み取りQPSのより複雑なビジネスシナリオ、そしてより大きな量、1ワット+に来るかもしれませんビジネス・ロジック：
ユーザーはリクエストが来書く我々はキャッシュを削除し、データベースを更新し、
その後、読み取り要求が来た、データベースの更新処理では、更新はこの時点で完了していない、元のデータベースの値が古い値で
見つかったキャッシュに値がありませんデータベースクエリのデータに移動し、キャッシュに書き込み、その後、データベースが終わっ更新されていない、元のデータがまだ古いデータを取得するための要求を読み込みます
、データベースの更新は完了ですが、キャッシュの更新に失敗しました、そしてキャッシュデータベースの新しいデータと古いデータは、データが発生した矛盾になる前に使用され、データの整合性の問題が浮上しています
したがって、上記のスキームは、特に同時例大量に、現象のこの種の確率は非常に実質的で、また問題がある。我々はそれを処理しますどのようにこの場合は？
我々は慎重に同時要求は、データの一貫性の問題を引き起こす可能性があり、その後、アイデアが、このような問題を解決するために、データの一貫性の根本的な原因である、並列に要求を読み取りおよび書き込み、上記の状況を見つけることができる分析します - シリアルを要求！
特定のビジネス・ロジックは次のとおりです。
ライトキャッシュバッファキューへの書き込み要求を超える要求と（キャッシュを更新し、キャッシュ内のデータを削除するデータベースを更新）書き込み要求の特定の操作を始める
読み取るために、再び、読み取り要求をデータベースの更新処理でいる場合再び、書き込み要求の実行が完了する前にキューを待って、キャッシュキューに格納されている要求が読み取り要求を実行します
。この時点で、キャッシュの失敗を削除する前に、データベース内に直接戻りデータを書き込んだ要求を古い値とデータキャッシュであります同じ、キャッシュ・コヒーレンシの問題が発生しないされ
、リターンが指示すると、データベースの更新が失敗した場合、データベースを更新し、キャッシュの書き込み要求が成功した削除した後、書き込み要求の終了を、データベースにこの時間値は古い値であり、要求が来て読んでそしてデータは、データの整合性の問題が発生しない、キャッシュに書き込まれている間、キャッシュ内のデータが、データベースに直接要求しないだろう見つかっ
成功した更新後のデータを、その後、キャッシュを更新するには、キャッシュが失敗した場合は、この時点での更新、その後、キャッシュにデータがない、データベースは新しい値、この時点での書き込み要求または読み込み要求の終わりです 同様に、データがキャッシュ内に見つからない、それはデータベースからデータを読み込み、キャッシュに保存されますがあり、キャッシュは事実、成功または失敗で、すべてのデータ整合性の問題が発生していないに関係なく更新されます
