この記事の出所：GitHubにはこちらをクリック・ || GitEE・こちらをクリック
まず、データベースの拡張
1、ビジネスシーン
インターネットプロジェクトは、多くのあるビジネスシナリオ「データ量は、複雑性の高い事業は、サブライブラリーサブテーブルが必要です」。
そのような階層化アーキテクチャは、
（1）上位層サービスBIZ、ビジネス・ロジック・パッケージである
;（2）サービスは、中間層サービス、カプセル化されたデータへのアクセスである
（3）下層がデータDB、店舗のビジネスデータです。
2、拡張シナリオと課題
データの量を連続的に添加されたときに、要求の数に直面している、2を選び、2つのデータベース、データベースに必要な膨張を吸収することができない - 3つの拡張モードに、以下に示すように：
そのような拡張の問題
（1）サブライブラリーサブテーブルの戦略は、大規模なデータ移行につながった;
（2）連続したサービスデータの影響;
（3）完了するために指定された時間、技術的な圧力、誤りがちな予期しません。
どのように滑らかな連続サービスシステムを確保するために、データのノンストップの移行、この記事では、議論される問題です。
ソリューションの第二に、拡張
図1に示すように、拡張プログラムを示します
（1）サブライブラリーサブテーブルシャード-JDBCミドルウェアを使用して、MySQLデータベースに基づいて、
（2）全体としてのプログラムの思想SpringCloudマイクロサービスアーキテクチャに基づきます
2、拡張の問題を解決するために
（1）拡張を必要とせずに懸濁し、
小（2）圧力データの移行は、指定された時間を必要としません。
図3に示すように、データ・アクセス・レイヤ・ロジック
プログラム記述
サブライブラリー、サブテーブルと呼ぶ2つのデータベースに基づいて、2つのサービスの
三つのサブライブラリサブテーブルのデータベースに基づく、と呼ばれる：3つのサービス
サービスの二組、サービス2つおよび3つのサービスを提供する（1）
アクセスしている場合、データベースの（2）拡張データへのサービストリプル直接アクセス、処理は終了します。
（3）あなたは、データへのアクセスを取得するために、サービスの3つのデータ、2つのサービスへのアクセスを得ることができない場合。
（4）時刻移行開始の期間にわたって、圧力は、上記2つのサービスを訪問します。
（5）これは、データ・アクセス・サービスを停止しないように。
（6）このアクセスモデルは行うことは非常に簡単SpringCloudに基づいています。
図4に示すように、論理的なデータ移行層
プログラムの説明
（1）は、2つのデータライブラリに基づいて保存処理を閉じる
（2）オープン・ストレージ・プロセスは、3つのデータ・ライブラリに基づくので、新たな記憶データが3つのサービスに直接アクセスすることができます。
（3）データ移行ミドルウェア、走査の両方元のデータライブラリの開発を。
（4）スキャンしたデータは、三つのサブライブラリポリシー決定に基づいて移行する必要があるかどうか。
データを移行する必要がある場合（5）、次いで3つのサービスのデータ・ストレージ・インターフェースを呼び出します。
（6）データの移行が完了し、データの元の場所を削除します。
（7）この移動パターン行うことは非常に簡単SpringCloudに基づきます。
図5に示すように、移行プログラムの利点
（1）全体のプロセスは、オンラインサービスを継続する;
低級開発の複雑さ（2）データ移行ミドルウェア;
（3）ゆっくり速度を移行することができる、何時間圧力は存在しません。
第三に、ソースコード管理
GitHub·地址
https://github.com/cicadasmile/spring-cloud-base
GitEE·地址
https://gitee.com/cicadasmile/spring-cloud-base