天帶來的是架構活動中的常見原則，在我們平時做技術方案，非功能設計時一定需要銘記於心這些方法論。 架構目標 高可用性 整體系統可用性最低99.9%，目標99.99%。全年故障時間整個系統不超過500分鐘，單個系統故障不超過50分鐘。 高可擴展性 系統架構簡單清晰，應用系統間耦合低，容易水平擴展，業務功 ...
天帶來的是架構活動中的常見原則，在我們平時做技術方案，非功能設計時一定需要銘記於心這些方法論。
架構目標
-
高可用性
整體系統可用性最低99.9%，目標99.99%。全年故障時間整個系統不超過500分鐘，單個系統故障不超過50分鐘。
-
高可擴展性 系統架構簡單清晰，應用系統間耦合低，容易水平擴展，業務功能增改方便快捷。
-
低成本 增加服務的重用性，提高開發效率，降低人力成本；
-
最終一致性
服務設計能滿足數據最終一致性，能方便、快捷的滿足三方、或者對方對賬需求。
-
質量要求
我們要求在系統設計時候要兼顧下麵的各個質量要求
架構總體原則
DID原則解釋
Design(D)設計20倍的容量；Implement(I)實施3倍的容量；Deploy（D）部署1.5倍的容量
原因：DID為產品擴展提供了經濟，有效，及時的方法
要點：在早期考慮可擴展性可以幫助團隊節省時間和金錢。在需求發生大約一個月前實施（寫代碼），在客戶蜂擁而至的幾天前部署。
例子：“什麼時候該在可擴展性上投入”有些輕率的回答是，最好在需要的前一天投入和部署。如果你能夠多做到達需要改善可擴展性方案的前一天部署，那麼 這筆投資的時機最佳，而且有助於實現公司財務和股東利益的最大化。 讓我們面對現實，及時投入和部署根本就不可能，即使可能，也無法確定具體的時間，而且會帶來很多風險。
DID（設計-實施-部署）：思考問題和設計方案，為方案構建系統和編寫代碼；實際安裝或者部署方案。
設計（Design）:DID方法的設計（D）階段聚集在擴展到20倍和無限大之間，通過如今可擴展性大會，把領導者和工程師團隊聚集在一起，共同討論產品的擴展瓶頸，這是在DID設計階段發現和確定需要擴展部分的一個好辦法。
實施（I，Implement）:我們把規模需求的範圍縮小到更接近現實，例如當前規模的3~20倍。
部署（D，Deploy）:在部署階段資產的成本較高，如果是一家適度高增長的公司，也許我們可以把最大產能提高到1.5倍；如果是一家超高增長的公司，也許我們可以把最大產能提高到5倍。擴展具有彈性，它既可以擴張也可以收縮，因此靈活性是關鍵，因為你需要響應客戶的請求，隨著規模的收縮和擴張，在系統之間調整容量
架構設計原則
-
業務平臺化
-
業務平臺化，相互獨立。 如交易平臺、倉儲平臺、物流平臺、支付平臺、廣告平臺等 -
基礎業務下沉，可復用。如用戶、商品、類目、促銷、訂單等 （參考目前核心系統）。
-
核心業務、非核心業務分離
核心業務與非核心業務分離，核心業務精簡（利於穩定），非核心業務多樣化。
-
隔離不同類型的業務
-
交易業務是簽訂買家和賣家之間的交易合同，需要優先保證高可用性，讓用戶能快速下單 -
對高併發要求很高的業務，應該跟普通業務隔離
-
區分主流程、輔流程
分清哪些是主流程。運行時，優先保證主流程的順利完成，輔流程可以採用後臺非同步的方式。避免輔流程的失敗導致主流程的回滾。
應用架構設計要點
-
穩定性原則
-
一切以穩定為中心 -
架構儘可能簡單、清晰 -
不過度設計
-
解耦、拆分
-
穩定部分與易變部分分離 -
核心業務與非核心業務分離 -
主業務與輔業務分離 -
應用與數據分離 -
服務與實現細節分離
-
抽象化
-
應用抽象化：應用只依賴服務抽象，不依賴服務實現細節、位置 -
資料庫抽象化：應用只依賴邏輯資料庫，不需要關心物理庫的位置和分片 -
伺服器抽象化：應用虛擬化部署，不需要關心實體機配置，動態調配資源
-
松耦合
-
同步調用時，需要設置超時時間、對調用異常時候的failover處理。 -
非核心業務儘量非同步化：核心、非核心業務之間，儘量非同步解耦。 -
跨業務線（比如分期樂、桔子、鼎盛間）調用需要採用HTTP介面方式，避免底層業務邏輯耦合和依賴。
-
容錯設計
-
服務自治：服務能彼此獨立修改、部署、發佈和管理，避免一個服務發生災害引發連鎖反應(一定要對mq、rpc、db、redis的異常容錯處理、異常包括超時、業務異常、系統異常等)。 -
集群容錯：應用系統集群，避免單點。 -
多機房容災：多機房部署，多活。
6 數據的一致性原則
-
小規模分佈或不分佈的業務確保可用、數據可靠、一致，即A & C兼顧； -
中型分佈系統需要考慮【BASE-最終一致性】，如果涉及到訂單、交易、清結算等數據敏感場景，保持數據最終一致性是最基本原則； -
大規模分散式系統在不涉及訂單、交易、清結算等數據敏感場景上可以考慮【有損服務】；。
架構分解原則
架構依賴原則
-
依賴穩定部分
-
穩定部分不依賴易變部分 -
易變部分可以依賴穩定部分 -
要求：避免迴圈依賴
-
跨域弱依賴
跨業務域調用時，儘可能非同步弱依賴
-
基本服務依賴
-
基本服務不能向上依賴流程服務 -
組合服務、流程服務可以向下依賴基本服務 -
條件：基本服務穩定
-
平臺服務依賴
-
平臺服務不依賴上層應用 -
上層應用可依賴平臺服務 -
條件：平臺服務穩定
-
核心服務依賴
-
核心服務不依賴非核心服務 -
非核心服務可依賴核心服務 -
條件：核心服務穩定
作者|易安
本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Architecture-Application-Summary.html
