主婦：
「その年、私たちは、クラウド上でどのように滑らかされていますか？「雲の背景にテキストで述べたように、すべてのシステムが、部屋から、別の部屋に移動しました。
図のように：
移行前に、エンジンルームA（M6）での展開は、単一部屋アーキテクチャです。
移行後、部屋のためのエンジンルームB（アリクラウド）でのシステム展開、。
「その年、私たちは、クラウド上でどのように滑らかされていますか？「3つの結論があります。
コア（1）は、単一の部屋アーキテクチャ「であり、完全に接続されました」。
設計目標（2）エンジンルーム移行プログラムは以下のとおりです。スムーズな移行、ノンストップサービス;することができますバッチで移行され、いつでもロールバックすることができます。
（3）移行をスムーズにしたい部屋の実装は、一時的なマルチルーム・アーキテクチャは避けられません。
[4] 4つのコアの問題は、どのように一時的なマルチルームアーキテクチャを実装するには？
上述したように、単一の部屋はマルチルームアーキテクチャをコピーするために「完全に接続された」場合、が存在するであろう部屋を横切る呼の多数大幅に遅延要求を増加させる、ビジネスは、この遅延を低減するために、許容されないと、」実行されなければなりません部屋の接続。」
ライブマルチルームアーキテクチャ、理想的な状態「に接続されたエンジンルーム」とは何ですか？
上記のように、他の部屋を横切って同期非同期データ通信に加えて、マルチルームライブアーキテクチャ、理想的な状態、すべての通信は、「エンジンルームに接続」されていること。
（1）ウェブ接続ビジネスサービス。
（2）ビジネスサービス、さらには基本的なサービス。
ライブラリ、別読み取りおよび書き込みから読み取り（3）であっても、サービスデータベース、書き込みに主データベース、。
アーキテクチャは、各部屋に故障がエンジンルームに発生した場合、切断されたフローに他の部屋は、高可用性を達成するために、「教室」失敗を冗長することができ、独立したシステム、同期非同期データを介して取得したデータの唯一の合計量であり、上記。
マルチルームアーキテクチャと間違っては何ですか？
「非同期データの同期は、」（例：1分）遅延があり、この遅延の存在は、深刻なビジネス上の問題につながる、一貫性のないデータの2つの部屋を行います。
例えば、ある瞬間には、ユーザXが$ 100のバランスを有し、二つの部屋は、精密天秤、次のデータが格納されています。
（1）バランス100は、北京でX（最寄りのアクセスルームA）は$ 20のバランスが残り、80を消費し、データが1分室Bに同期されます。
（2）バランス100、Xの消費広州ミセスX（最寄りのアクセスルームB）は、30元の残高が$ 70占め、このデータは1分室Aに同期されます。
その結果：
（1）過剰消費（100バランス、何か150を購入）。
（2）異常なバランス（残高が20、または30であります？）。
上記のアーキテクチャは、あらゆるビジネスシーンに適しているのですか？
任意のいじめのうちの建築設計業務。
各部屋は、グローバルなビジネスシーンデータへのアクセスをたくさん持っている場合は、マルチルーム・アーキテクチャは適用されない、一貫性のないデータがたくさんあるでしょう。しかし、各部屋にはローカルビジネスデータへのアクセス権を持っている場合、マルチルーム・アーキテクチャは、まだ生きています。
典型的なビジネス：滴、速い犬のタクシー。
これらのサービスは、持っているデータの集約効果を：
同じ都市（1）は、単一のユーザ、
（2）注文同じ都市内のドライバ。
（3）同じ都市での取引の注文;
ビジネスのこのタイプは、ビジネスは大きな影響が発生することはありません複数の1分間の遅延「非同期データ同期」、の間に余裕がある場合でも、ライブにマルチルームアーキテクチャのために非常に適しています。
「部屋が接続されていると、」ライブ・マルチルームアーキテクチャ、理想的な条件の下で行うことができない、妥協はありませんか？
あなたは完全に理想的な状態が部屋を横切って呼び出すことはできません避ける場合は、私がやろうクロスコールの部屋を「最小化」。
非必須、ルームサービスでの優先接続サイトの場合には、上記のように：
エンジンルーム（1）サイトレベルのみビジネスサービス層接続。
（2）ビジネスサービス層のみ下地層のルームサービスに接続されています。
（3）サービス層、エンジンルームとの唯一の接続は、ライブラリを「読み取り」。
書き込みへのライブラリの（4）、決して、唯一の「書き込み」に部屋を横切って読みライブラリ。
プログラムは完全に部屋を横切って呼び出さないようにしませんが、書き込み要求が唯一の部屋を横切っている、コールに部屋を渡る「最小化」でした。
しかし、インターネットビジネス、主に小規模ビジネスを読み書き：
（1）100％Baiduは検索サービスを読み取ります。
（2）京东淘宝电商99%的浏览搜索是读业务，只有下单支付是写业务；
（3）58同城99%帖子的列表详情查看是读业务，只有发布帖子是写业务；
写业务比例相对少，只有很少请求会跨机房调用。
该多机房多活架构，并没有做到100%的“同机房连接”，通常称作伪多机房多活架构。
伪多机房多活架构，有“主机房”和“从机房”的差别。
多机房多活架构的初衷是容机房故障，该架构当出现机房故障时，可以把入口处流量切到另一个机房：
（1）如果挂掉的是，不包含主库的从机房，迁移流量后能直接容错；
（2）如果挂掉的是，包含主库的主机房，只迁移流量，系统整体99%的读请求可以容错，但1%的写请求会受到影响，此时需要将从库变为主库，才能完全容错。这个过程需要DBA介入，不需要所有业务线上游修改。
画外音：除非，站点和服务使用内网IP，而不是内网域名连接数据库。架构师之路已经强调过很多次，不要使用内网IP，一定要使用内网域名。
伪多机房多活架构，是一个实践性，落地性很强的架构，它对原有架构体系的冲击非常小，和单机房架构相比，仅仅是：
（1）跨机房主从同步数据，会多10毫秒延时；
画外音：主从同步数据，本来就会有延时。
（2）跨机房写，会多10毫秒延时；
小结：
（1）理想多机房多活架构，是纯粹的“同机房连接”，仅有异步数据同步会跨机房；
（2）理想多机房多活架构，会有较严重数据一致性问题，仅适用于具备数据聚集效应的业务场景，例如：滴滴，快狗打车；
（3）伪多机房多活架构，思路是“最小化跨机房连接”，机房区分主次，落地性强，对原有架构冲击较小，强烈推荐；
临时性多机房多活架构，是机房迁移过程中的一个过渡状态，机房迁移步骤又该如何？且听明天分解。
思路比结论重要。
架构师之路-分享技术思路
相关文章：
讨论：
贵司有没有多机房多活，架构如何？
画外音：长文阅读量好低。
