系統可用率
多級快取
動態分組切換
db物理隔離
服務分組隔離
跨機房隔離
漏斗模型
db限流
系統一般可以分為前端應用系統和後端資料庫系統，前端應用系統實施分布式集群部署技術上是比較成熟的，後端資料庫系統實現異地多活技術難度很大，目前也只有阿里，京東這樣的公司才真正實現。因此，對於大多數應用，前端應用雙機房集群部署，後端資料庫系統採取成熟的主備從的模式，也就是單個機房作為寫入，備庫在另外機房，可以快速進行切換，讀庫雙機房部署，是優選的方案。對於這個架構方案，存在跨機房寫延長的問題，可以根據場景利用非同步的方式進行解決，一般也是沒有問題的。對於系統來講，也有些特別，利用分揀中心的本地伺服器和操作人員的裝置，實現離線生產，進一步提高可用性。
大系統小做，服務拆分，是網際網路應用的特點，也符合敏捷交付的理念。對於傳統軟體，如windows，office等，都要經過乙個漫長的需求，研發，測試，發布週期，在「唯快不破」的網際網路時代，這顯然是無法滿足業務要求的，即使最後上線，也可能因為週期太長而不再適用了。因此，對乙個網際網路服務，一般會首先完成最核心的功能，快速進行上線，不斷進行迭代，後續再進行輔助功能跟進。對於核心功能，隨著使用者數的增加，會不斷進行服務拆分，如何進行拆分，拆分到什麼樣的粒度，是不是微服務是解決問題的銀彈？這些都要根據實際的應用場景來評估，絕不是越細越好，而是要達到乙個優雅的平衡。
併發控制，服務隔離。併發控制，現在已經成為網際網路服務基本要求，在應用程式端和資料庫端，也都有成熟的方案，如果忽略，可能造成災難性的後果。對於重要的服務，還要進行隔離，例如同乙個服務，要提供給內部呼叫，公司級呼叫和公司外開放服務呼叫，開放服務呼叫者我們一般認為是不可靠的，甚至有可能是惡意的，如果不進行隔離，開放服務呼叫有可能使得服務資源佔滿，對內也無法提供服務。從技術上，可以是硬體級隔離，全部隔離，也可以是前端應用的隔離。
全方位監控報警，可以分為技術層面和業務層面，技術層面包括對cpu，記憶體，磁碟，網路等的監控，業務層面，包括對處理積壓量，正常的業務量等。做到全方位監控，才有可能在影響使用者之前，提前解決問題，提公升系統可用性。否則，等使用者發現問題，在很大的壓力下，技術團隊更難處理，導致系統不可用時間加長。
核心服務，平滑降級。任何技術手段，都不可能保障100%可用，並且，即使能夠做到，其代價也是巨大，不經濟的，因此，對於核心服務來講，能夠平滑進行降級，提供基礎的服務，也是非常重要的。對於系統來講，就利用分揀中心本地伺服器和操作人員的裝置，研發了離線生產系統，來應對集中服務萬一不可用的情況。
資料一致性
我們就能分為四個基本的場景：高實時性/高一致性，高實時性/低一致性，低實時性/高一致性，低實時性/低一致性。針對具體的業務，我們可以匹配到具體的資料場景，這樣，我們就能找到對應的解決方案
實時&強一致場景：這個在大資料技術成熟之前，是非常棘手的，但是，現在解決方案已經比較成熟了。典型應用是生產系統的實時監控，例如實時生產量，各個生產環節差異量等，其實是作為生產系統的一部分。利用當前主流的大資料處理架構是可以解決的，例如線上生產庫binlog實時讀取，kafaka進行資料傳輸，spark進行流式計算，es進行資料儲存等。如果利用傳統的etl抽取方案來解決，頻繁對生產資料庫進行抽取，並不是可行的方案，因為，這樣會極大的影響線上oltp系統的效能。還可以舉乙個生產系統實時監控案例，架構方案是應用系統完成寫資料庫的同時，把內容通過訊息傳送，後面的大資料處理系統接收訊息來進行處理，這個架構方案，對於實時性某種程度上可以保障，但是，也存在效率問題，但是，對於強一致性就非常不合適了，因為訊息系統如activemq等不僅無法保障訊息資料不能丟失，而且對應訊息順序也是無法保障，專案實施後，雖然採取了很多補救措施，也無法滿足強一致性需求，不得不重起爐灶。
實時&弱一致性場景：典型的應用場景是訊息通知，例如電商的全程跟蹤訊息，如果個別資料出現丟失，對於使用者的影響並不大，也是可以接受的，因此，可以採用更加廉價的解決方案，應用完成對應的動作後，將訊息發出即可，使用方訂閱對應的訊息，按照主鍵，如訂單號，儲存即可。
離線&強一致場景：這是典型的大資料分析場景，也就是眾多的離線報表模式。從技術上，傳統的etl抽取技術也能滿足要求，資料倉儲對應的技術也能夠解決。
離線&弱一致場景：對於抓取網際網路資料，日誌分析等進行統計系統，用於統計趨勢類的應用，可以歸為此類，這類應用主要是看能夠有足夠廉價的方案來解決，是不是可以巧妙的利用空閒的計算資源。這個在很多公司，利用晚上空閒的計算資源，來處理此類的需求。
在對業務能首先是業務資料化，並且具有資料質量保障。系統的支撐下，實現了所有物流操作的線上化，也就是資料化，並且，對每個操作環節都是可以進行實時分析，這就奠定了很好的基礎。如果業務都是線下操作，或者系統無法準確及時收集資料，那麼，即時資料量夠大，缺乏關鍵資料和資料不準確，也會給大資料處理帶來很大的困難。第二基礎就是大資料處理技術，包括收集，傳輸，儲存，計算，展示等一系列技術。夠進行實時監控和準確評估後，也就是利用大資料對業務進行**。**一直是大資料應用的核心，也是最有價值的地方。對於物流行業，如果能夠提前進行業務量**，那麼，對於資源排程等非常有意義，不僅能夠實現更好的時效，而且能夠避免浪費。舉乙個的例子，就是單量**，根據使用者下單量，倉儲生產能力，路由情況等，可以進行建模**。
智慧型物流，以大資料處理技術作為基礎，利用軟體系統把人和裝置更好的結合起來，讓人和裝置能夠發揮各自的優勢，達到系統最佳的狀態。
高效能，高可用系統架構
本文是學習大型分布式 架構的技術總結。對架構乙個高效能，高可用，可伸縮，可擴充套件的分布式 進行了概要性描述，並給出乙個架構參考。一部分為讀書筆記，一部分是個人經驗總結。對大型分布式 架構有很好的參考價值。1 大型 的特點 2 大型 架構目標 3 大型 架構模式 4 高效能架構 以使用者為中心，提供...
高可用 架構
不要把雞蛋都放在同一籃子裡 標準 1 正常情況下，使用者無論訪問哪乙個地點的業務系統，都能夠得到正確的業務服務。2 某個地方業務異常的時候，使用者訪問其他地方正常的業務系統，能夠得到正確的業務服務。與 活 對應的是字是 備 備是備份，正常情況下對外是不提供服務的，如果需要提供服務，則需要大量的人工干...
有關系統架構的高可用原則
對於乙個高可用服務，很重要的乙個設計就是降級開關。在設計降級開關時，主要有以下思路 1.開關集中化管理 通過推送機制把開關推送到各個應用。2.可降級的多級服務 比如服務呼叫降級為唯讀本地快取，唯讀分布式快取，唯讀預設降級資料 如庫存狀態預設有貨 3.開關前置化 如架構是nginx tomcat，可以...