前情提要：《當年，我們是怎么平滑上云的？》一文中提到了上云的背景，將所有的系統，從一個機房，遷移到另一個機房。如上圖：遷移之前，系統部署在機房A(M6)內，是單機房架構。遷移之后，系統部署在機房B(阿里云)內，換了一個機房。《當年，我們是怎么平滑上云的？》有三結論：(1)單機房架構的核心是“全連接”；(2)機房遷移方案的設計目標是：平滑遷移，不停服務；可以分批遷移；隨時可以回滾；(3)想要平滑的實施機房遷移，臨時性的多機房架構不可避免；【4】核心問題四，臨時性多機房架構如何實施？如前文所述，如果將單機房“全連接”架構復制到多機房，會有大量跨機房調用，極大增加請求時延，是業務無法接受的，要想降低這個時延，必須實施“同機房連接”。多機房多活架構，什么是理想狀態下的“同機房連接”？如上圖所示，多機房多活架構，最理想狀態下，除了異步數據同步跨機房通訊，其他所有通訊均為“同機房連接”：(1)web連業務服務；(2)業務服務連基礎服務；(3)服務連數據庫，主庫寫，從庫讀，讀寫分離；上述架構，每個機房是一套獨立的系統，僅僅通過異步數據同步獲取全量數據，當發生機房故障時，將流量切到另一個機房，就能冗余“機房級”故障，實現高可用。上述多機房架構存在什么問題？“異步數據同步”存在延時(例如：1min)，這個延時的存在，會使得兩個機房的數據不一致，從而導致嚴重的業務問題。舉個例子，某一個時刻，用戶X有余額100元，兩個機房都存儲有該余額的精準數據，接下來：(1)余額100，X在北京(就近訪問機房A)消費了80元，余額僅剩20元，該數據在1分鐘后會同步到機房B；(2)余額100，X的夫人在廣州(就近訪問機房B)用X的賬號消費了70元，余額剩余30元，該數據在1分鐘后也會同步到機房A；從而導致：(1)超額消費(100余額，卻買了150的東西)；(2)余額異常(余額是20，還是30？)；上述架構適合于什么業務場景？任何脫離業務的架構設計都是耍流氓。當每個機房都有很多全局業務數據的訪問場景時，上述多機房架構并不適用，會存在大量數據不一致。但當每個機房都訪問局部業務數據時，上述多機房架構仍然是可行的。典型的業務：滴滴，快狗打車。這些業務具備數據聚集效應：(1)下單用戶在同一個城市；(2)接單司機在同一個城市；(3)交易訂單在同一個城市；這類業務非常適合上述多機房多活架構，多個機房之間即使存在1分鐘延時的“異步數據同步”，對業務也不會造成太大的影響。多機房多活架構，做不到理想狀態下的“同機房連接”，有沒有折中方案？如果完全避免跨機房調用的理想狀態做不到，就盡量做到“最小化”跨機房調用。如上圖所示，在非必須的情況下，優先連接同機房的站點與服務：(1)站點層只連接同機房的業務服務層；(2)業務服務層只連接同機房的基礎服務層；(3)服務層只連接同機房的“讀”庫；(4)對于寫庫，沒辦法，只有跨機房讀“寫”庫了；該方案沒有完全避免跨機房調用，但它做到了“最小化”跨機房調用，只有寫請求是跨機房的。但互聯網的業務，絕大部分是讀多寫少的業務：(1)百度的搜索100%是讀業務；(2)京東淘寶電商99%的瀏覽搜索是讀業務，只有下單支付是寫業務；(3)58同城99%帖子的列表詳情查看是讀業務，只有發布帖子是寫業務；寫業務比例相對少，只有很少請求會跨機房調用。該多機房多活架構，并沒有做到100%的“同機房連接”，通常稱作偽多機房多活架構。偽多機房多活架構，有“主機房”和“從機房”的差別。多機房多活架構的初衷是容機房故障，該架構當出現機房故障時，可以把入口處流量切到另一個機房：(1)如果掛掉的是，不包含主庫的從機房，遷移流量后能直接容錯；(2)如果掛掉的是，包含主庫的主機房，只遷移流量，系統整體99%的讀請求可以容錯，但1%的寫請求會受到影響，此時需要將從庫變為主庫，才能完全容錯。這個過程需要DBA介入，不需要所有業務線上游修改。畫外音：除非，站點和服務使用內網IP，而不是內網域名連接數據庫。架構師之路已經強調過很多次，不要使用內網IP，一定要使用內網域名。偽多機房多活架構，是一個實踐性，落地性很強的架構，它對原有架構體系的沖擊非常小，和單機房架構相比，僅僅是：(1)跨機房主從同步數據，會多10毫秒延時；畫外音：主從同步數據，本來就會有延時。(2)跨機房寫，會多10毫秒延時；小結：(1)理想多機房多活架構，是純粹的“同機房連接”，僅有異步數據同步會跨機房；(2)理想多機房多活架構，會有較嚴重數據一致性問題，僅適用于具備數據聚集效應的業務場景，例如：滴滴，快狗打車；(3)偽多機房多活架構，思路是“最小化跨機房連接”，機房區分主次，落地性強，對原有架構沖擊較小，強烈推薦；臨時性多機房多活架構，是機房遷移過程中的一個過渡狀態，機房遷移步驟又該如何？且聽明天分解。思路比結論重要。

架構師之路-分享技術思路

相關文章：《當年，我們是怎么平滑上云的？》討論：貴司有沒有多機房多活，架構如何？畫外音：長文閱讀量好低。 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的kepware怎么读modbus/tcp数据_多机房多活架构，究竟怎么玩？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。