互聯網業務背景
隨這移動互聯網、雲計算、大數據、物聯網技術的發展，促進電子商務、工業互聯網和互聯網金融等業務領域健康發展。無論是互聯網公司，還是傳統行業，一切商業都將互聯網化，這幾乎是所有大佬能達成的唯一共識。所以目前我們面臨的首要任務就是構建和改造我們的系統使其面向互聯網。
互聯網應用的幾個特性：
Ø 高性能
Ø 高可用性
Ø 大數據
Ø 低成本
互聯網系統設計原則
面向互聯網化的過程中，系統架構應該按照以下幾個規則進行設計。
1.1 業務架構設計原則
1.1.1 業務平台化
Ø 業務平台相互獨立，如交易平台、支付平台、廣告平台。
Ø 基礎業務下沉，可復用。如，用戶、商品、類目。
1.1.2 核心業務、非核心業務分離
Ø 系統核心業務與非核心業務分離，核心業務精簡（利於穩定），非核心業務多樣化。如，如主交易服務、通用交易服務。
1.1.3 區分主流程、附流程
Ø 區分哪些是系統主流程。運行時，優先保證主流程順利完成，輔流程可以采用后台異步化的方式。避免主流程失敗導致主流程的回滾。如，下單時，同步調用快照，異步通知台賬，發表。
1.1.4 隔離不同類型的業務
Ø 交易業務就是簽訂買家、賣家之間的交易合同，需要確保高可用性，讓用戶能夠快速下單。
Ø 履約業務對可用性沒有太高的要求，可以優先保證一致性。
Ø 秒殺業務對高並發要求很高，應該跟普通業務隔離。
1.2 應用架構設計原則
1.2.1 穩定性原則
Ø 一切以穩定為中心
Ø 架構盡可能簡單、清晰
Ø 不過度設計
1.2.2 解耦/拆分
Ø 穩定部分與易變部分分離
Ø 核心業務與非核心業務分離
Ø 主流程與輔流程分離
Ø 應用與數據分離
Ø 服務與實現細節分離
1.2.3 抽象化
Ø 應用抽象化：應用只依賴服務抽象，不依賴服務實現細節、位置
Ø 數據庫抽象化：應用只依賴邏輯數據庫，不需要關心物理數據庫的位置和分片
Ø 服務器抽象化：應用虛擬化部署，不需要關心實體機配置，動態調配資源
1.2.4 松耦合
Ø 跨域調用異步化：不同業務域之間盡量異步化解耦。
Ø 非核心業務盡量異步化：核心、非核心業務之間，盡量異步解耦
Ø 必須同步調用時，需要設置超時時間和任務隊列長度
1.2.5 容錯設計
Ø 服務治理：服務能彼此獨立修改、部署、發布和管理。避免引發連鎖反應
Ø 集群容錯：
Ø 集群容錯：應用系統集群，避免單點
Ø 多機房容災：多機房部署，多活
1.3 數據架構設計原則
1.3.1 統一數據視圖
Ø 保證數據的及時性、一致性、准確性、完整性
1.3.2 數據、應用分離
Ø 應用系統只能依賴邏輯數據庫
Ø 應用系統不能直接訪問其他宿主的數據庫，只能通過服務訪問
1.3.3 數據異構
Ø 源數據和目標數據內容相同時，做索引異構。如，商品庫不同維度
Ø 內容不同時，做數據庫異構。如，訂單買家庫和賣家庫
1.3.4 數據讀寫分離
Ø 訪問量大的數據庫做讀寫分離
Ø 數據量大的數據庫做分庫分表
Ø 不同業務域數據庫做分區隔離
Ø 重要數據配置庫
1.3.5 合理使用緩存
Ø 數據庫有能力支撐時，盡量不要引入緩存
Ø 合理利用緩存做容災
1.4 技術架構設計原則-運行時原則
1.4.1 可監控
Ø 服務的TPS和RT是否符合SLA
Ø 是否出現超出預期流量
1.4.2 應用可回滾，功能可降級
Ø 應用出現問題時，要求能回滾到上一版本，或做功能開關或降級。
1.4.3 在線擴容
Ø 超預期流量時，應用系統可選擇在線水平擴展
1.4.4 安全保證
Ø 確保系統保密性和完成性
Ø 具有足夠的防攻擊能力
1.4.5 可容錯
Ø 核心應用要求多活，避免單點設計，並且自身有容錯和修改能力。故障時間TTR小
1.4.6 故障轉移
Ø 多機房部署，發生故障時，能即時切換
1.5 技術架構設計原則-部署原則
1.5.1 N+1原則
Ø 確保為故障多搭一套系統，避免單點問題。
Ø 功能開發與運維分開。系統開發完成后，交給專業的運維團隊管理和運營。
1.5.2 D-I-D原則
Ø 設計20倍的容量（Design）
Ø 實現3倍的容量（Implement）
Ø 部署1.5倍的容量（Deploy）
1.5.3 支持灰度發布
Ø 系統新上線，要求支持“灰度發布，分步切流量，故障回滾”
1.5.4 虛擬化部署
Ø 虛擬部署：系統采用虛擬機部署，節省資源和管理成本
1.5.5 業務子網
Ø 機房部署以業務域划分：基本服務和數據庫，相同業務域的服務器部署在一起；不同業務域的服務器物理隔離
系統升級選取規則
對典型的社交類應用的架構及技術進行分析，目前社交類應用一般會包含的
架構風格有：微服務，EDA、CQRS、前端 SPA，通過這些架構風格實現系統的可
擴展性，高可用，以及在大用戶、高並發下的高性能等，具體的架構風格和關鍵
設計約束對應關系如下：
