物流系統高可用架構案例

 

系統可用率

多級緩存

動態分組切換

DB物理隔離

服務分組隔離

跨機房隔離

漏斗模型



DB限流






 

   

     系統一般可以分為前端應用系統和后端數據庫系統，前端應用系統實施分布式集群部署技術上是比較成熟的，后端數據庫系統實現異地多活技術難度很大，目前也只有阿里，京東這樣的公司才真正實現。因此，對於大多數應用，前端應用雙機房集群部署，后端數據庫系統采取成熟的主備從的模式，也就是單個機房作為寫入，備庫在另外機房，可以快速進行切換，讀庫雙機房部署，是優選的方案。對於這個架構方案，存在跨機房寫延長的問題，可以根據場景利用異步的方式進行解決，一般也是沒有問題的。對於系統來講，也有些特別，利用分揀中心的本地服務器和操作人員的設備，實現離線生產，進一步提高可用性。

     大系統小做，服務拆分，是互聯網應用的特點，也符合敏捷交付的理念。對於傳統軟件，如Windows，Office等，都要經過一個漫長的需求，研發，測試，發布周期，在“唯快不破”的互聯網時代，這顯然是無法滿足業務要求的，即使最后上線，也可能因為周期太長而不再適用了。因此，對一個互聯網服務，一般會首先完成最核心的功能，快速進行上線，不斷進行迭代，后續再進行輔助功能跟進。對於核心功能，隨着用戶數的增加，會不斷進行服務拆分，如何進行拆分，拆分到什么樣的粒度，是不是微服務是解決問題的銀彈？這些都要根據實際的應用場景來評估，絕不是越細越好，而是要達到一個優雅的平衡。

     並發控制，服務隔離。並發控制，現在已經成為互聯網服務基本要求，在應用程序端和數據庫端，也都有成熟的方案，如果忽略，可能造成災難性的后果。對於重要的服務，還要進行隔離，例如同一個服務，要提供給內部調用，公司級調用和公司外開放服務調用，開放服務調用者我們一般認為是不可靠的，甚至有可能是惡意的，如果不進行隔離，開放服務調用有可能使得服務資源占滿，對內也無法提供服務。從技術上，可以是硬件級隔離，全部隔離，也可以是前端應用的隔離。

     灰度發布也是互聯網服務的一大利器，有了灰度發布，才使得快速迭代成為可能，並且，很多服務因為各種原因線下也是很難測試的，只能在線上測試。如果沒有灰度發布，只能全量發布，就存在較長測試周期問題，如果沒有重復勉強上線，就存在很大的系統崩潰的風險。按照用戶，區域進行灰度發布是比較常用的方法。

     全方位監控報警，可以分為技術層面和業務層面，技術層面包括對CPU，內存，磁盤，網絡等的監控，業務層面，包括對處理積壓量，正常的業務量等。做到全方位監控，才有可能在影響用戶之前，提前解決問題，提升系統可用性。否則，等用戶發現問題，在很大的壓力下，技術團隊更難處理，導致系統不可用時間加長。

     核心服務，平滑降級。任何技術手段，都不可能保障100%可用，並且，即使能夠做到，其代價也是巨大，不經濟的，因此，對於核心服務來講，能夠平滑進行降級，提供基礎的服務，也是非常重要的。對於系統來講，就利用分揀中心本地服務器和操作人員的設備，研發了離線生產系統，來應對集中服務萬一不可用的情況。

     大型互聯網服務，一般都微服務化了，這樣意味着一個用戶操作，都是由多個服務接口支持，如果按照傳統的同步接口設計，那么，不僅面臨性能問題，而且，QPS也是無法滿足的，因此，需要將同步接口調用異步化。在2012年左右，eBay就提出所有系統調用異步化，后面，幾乎所有大型互聯網公司，都對自身系統進行了異步化改造，並且，取得了很好的效果，在和騰訊CTO Tony交流中，他就提出即使支付這種服務，也是有辦法進行異步化設計的。同步接口異步化，也是需要系統工具支持的。

    數據一致性
     我們就能分為四個基本的場景：高實時性/高一致性，高實時性/低一致性，低實時性/高一致性，低實時性/低一致性。針對具體的業務，我們可以匹配到具體的數據場景，這樣，我們就能找到對應的解決方案

• 實時&強一致場景：這個在大數據技術成熟之前，是非常棘手的，但是，現在解決方案已經比較成熟了。典型應用是生產系統的實時監控，例如實時生產量，各個生產環節差異量等，其實是作為生產系統的一部分。利用當前主流的大數據處理架構是可以解決的，例如線上生產庫binlog實時讀取，Kafaka進行數據傳輸，Spark進行流式計算，ES進行數據存儲等。如果利用傳統的ETL抽取方案來解決，頻繁對生產數據庫進行抽取，並不是可行的方案，因為，這樣會極大的影響線上OLTP系統的性能。還可以舉一個生產系統實時監控案例，架構方案是應用系統完成寫數據庫的同時，把內容通過消息發送，后面的大數據處理系統接收消息來進行處理，這個架構方案，對於實時性某種程度上可以保障，但是，也存在效率問題，但是，對於強一致性就非常不合適了，因為消息系統如ActiveMQ等不僅無法保障消息數據不能丟失，而且對應消息順序也是無法保障，項目實施后，雖然采取了很多補救措施，也無法滿足強一致性需求，不得不重起爐灶。
• 實時&弱一致性場景：典型的應用場景是消息通知，例如電商的全程跟蹤消息，如果個別數據出現丟失，對於用戶的影響並不大，也是可以接受的，因此，可以采用更加廉價的解決方案，應用完成對應的動作后，將消息發出即可，使用方訂閱對應的消息，按照主鍵，如訂單號，存儲即可。
• 離線&強一致場景：這是典型的大數據分析場景，也就是眾多的離線報表模式。從技術上，傳統的ETL抽取技術也能滿足要求，數據倉庫對應的技術也能夠解決。
• 離線&弱一致場景：對於抓取互聯網數據，日志分析等進行統計系統，用於統計趨勢類的應用，可以歸為此類，這類應用主要是看能夠有足夠廉價的方案來解決，是不是可以巧妙的利用空閑的計算資源。這個在很多公司，利用晚上空閑的計算資源，來處理此類的需求。

      在對業務能首先是業務數據化，並且具有數據質量保障。系統的支撐下，實現了所有物流操作的線上化，也就是數據化，並且，對每個操作環節都是可以進行實時分析，這就奠定了很好的基礎。如果業務都是線下操作，或者系統無法准確及時收集數據，那么，即時數據量夠大，缺乏關鍵數據和數據不准確，也會給大數據處理帶來很大的困難。第二基礎就是大數據處理技術，包括收集，傳輸，存儲，計算，展示等一系列技術。夠進行實時監控和准確評估后，也就是利用大數據對業務進行預測。預測一直是大數據應用的核心，也是最有價值的地方。對於物流行業，如果能夠提前進行業務量預測，那么，對於資源調度等非常有意義，不僅能夠實現更好的時效，而且能夠避免浪費。舉一個的例子，就是單量預測，根據用戶下單量，倉儲生產能力，路由情況等，可以進行建模預測。

     智慧物流，以大數據處理技術作為基礎，利用軟件系統把人和設備更好的結合起來，讓人和設備能夠發揮各自的優勢，達到系統最佳的狀態。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

希望對您系統架構，軟件項目開發,運維管理，系統架構與研發管理體系, 信息安全, 企業信息化等有幫助。 其它您可能感興趣的文章：
DevOps的基本原則與介紹
Docker與CI持續集成/CD
持續交付中高效率與高質量
持續集成CI與自動化測試
軟件研發工程基礎設施
容器化實踐金融業案例一
雲計算參考架構幾例
微服務與Docker介紹
互聯網直播平台架構案例一
高可用架構案例一
某互聯網公司廣告平台技術架構
某大型電商雲平台實踐
雲計算參考架構幾例
移動應用App測試與質量管理一
全面的軟件測試
著名ERP廠商的SSO單點登錄解決方案介紹一
軟件項目風險管理介紹
企業項目化管理介紹
智能企業與信息化之一
由企業家基本素質想到的
敏捷軟件質量保證的方法與實踐
構建高效的研發與自動化運維
IT運維監控解決方案介紹
IT持續集成之質量管理
人才公司環境與企業文化
企業績效管理系統之平衡記分卡
企業文化、團隊文化與知識共享
高效能的團隊建設
餐飲連鎖公司IT信息化解決方案一

如有想了解更多軟件研發 , 系統 IT集成 , 企業信息化，項目管理，企業管理 等資訊，請關注我的微信訂閱號：

 

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發布在我的獨立博客中-Petter Liu Blog。