1. 分佈式架構VS單體架構
獲益從三個方面來考慮：
- 擴展性；
集羣規模擴展性；
地理擴展性（數據中心）；
管理擴展性； - 性能；
指標：短RT（Response Time），低延遲，高吞吐，較低的計算資源佔用率； - 可用性；
可用性=可用時間 / （可用時間+不可用時間）。
考慮容錯率，面向失敗的設計。
2. 分佈式八大技術
2.1 分佈式服務
趨勢：單體—>多應用；本地調用—>遠程調用。
RPC：遠程服務調用；consumer，provider。
SOA：服務分佈式部署；請求分流；數據操作讀寫分離。
分佈式服務這個領域，阿里內部兩大框架：HSF和Dubbo，後者已經開源。
2.1.1 HSF
HSF相關組件：服務註冊中心ConfigServer，持久化配置中心Diamond，元數據存儲中心Redis，控制檯HSFOPS。
流程：客戶端發起調用—>路由選址—>負載均衡—>序列化—>協議編碼—>發送數據—>接收數據—>協議解碼—>分派線程—>反序列化—>服務端反射調用。
4層領域：框架，應用，服務，配置。
- 框架提供基礎功能，負責通信、線程、協議、序列化、編碼解碼；
- 應用面向服務框架的註冊和發現過程；
- 服務粒度比較小，包含調用鏈路、地址路由、負載均衡；
- 配置：用戶使用API進行配置，生成調用代理或者暴露服務。
調用方式：
- 同步實時調用；
- Future異步調用；
- Callback異步調用（客戶端提供回調）；
- Generic調用；
- 服務端async調用；
2.1.2 Dubbo
Dubbo已經開源，提供了高性能的RPC實現服務的輸入輸出，與Spring框架無縫集成。
三大核心能力：
- 面向接口的遠程方法調用；
- 智能容錯和負載均衡；
- 服務自動註冊和發現；
四大角色：
- Provider：服務提供方；
- Consumer：服務消費方；
- Registry：註冊中心；
- Monitor：監控中心；
2.2 分佈式消息
分佈式消息主要解決的問題：
- 應用解耦；
- 削峯填谷；
- 保證最終一致性。
業界常見的分佈式消息框架：ActiveMQ，RabbitMQ，Kafka等。
阿里內部常用的分佈式消息框架：MetaQ，RocketMQ等。
2.3 分佈式緩存
緩存一般分爲本地緩存和分佈式緩存。
分佈式緩存的關注重點，從CPU、內存、緩存之間的數據傳輸速度差異擴展到了業務系統、數據庫、分佈式緩存之間的數據傳輸速度差異。
常用的分佈式緩存有很多，比較典型的如Redis，Tair。
2.3.1 Tair
高性能：基於高速緩存、內存或者SSD；
高擴展：輕量級中間件+三種數據引擎+負載均衡；
高可用：各種容災部署方式和解決方案；
主要應用場景：
- 數據庫緩存；
- 臨時數據存儲（Session數據、用戶Token、權限信息等）；
- 持久化存儲（廣告推薦類需要離線計算大量數據以及榜單生成等）；
三種存儲模式：
MDB：Memcached；
RDB：Redis；
LDB：LevelDB；
數據一致性保證：version；
負載均衡：一致性Hash；
多級緩存：處理熱點問題
2.4 分佈式調度
分佈式調度，阿里內部使用SchedulerX，市面上可以考慮Elastic-Job。定時任務組件Quartz。
SchedulerX是阿里自研的基於Akka架構的分佈式任務調度平臺，提供定時、任務編排、分佈式跑批等功能。
2.4.1 SchedulerX
主要功能：
- 強大的定時調度器（cron，fixed rate，fixed delay，日曆，時區）：
- 任務編排（工作流DAG）；
- 任務類型（java，shell，python，go，自定義）；
- 執行方式&分佈式編程模型（單機、廣播、並行計算、內存網格、網格計算）；
2.5 分佈式數據庫
分佈式數據庫訪問引擎，阿里內部使用TDDL，市面上開源的中間件有ShardingJdbc。
2.5.1 主要作用及應用場景：
- 垂直分庫分表
ACID被打破：事務操作會受到影響；
Join操作困難；
外鍵約束受影響的問題； - 水平分庫分表
自增主鍵會受到影響；
有些單表查詢會變成多表查詢； - 讀寫分離
數據複製問題：數據複製時間上一定有延遲，短期數據會不一致。數據庫複製一般是通過數據庫日誌bin-log實現的。
數據源選擇問題：即數據路由問題；寫走主庫，讀走從庫，事務中的讀走主庫。
2.5.2 整體層次劃分
- ORM層（Hibernate or Mybatis or Spring JDBC）；
- TDDL or ShardingJdbc層；
- 數據庫連接池Druid，C3P0等層次；
- JDBC Driver層；
- 數據庫實體；
2.5.3 主要組件
- SQL解釋器；
- SQL優化器；
- SQL路由；
- SQL執行；
- 結果歸併；
- 分佈式唯一主鍵生成；
2.6 分佈式搜索
阿里內部使用OpenSearch，目前市面上可以使用ElasticSearch或者Solr。
數據推送到搜索引擎這一塊的工作，阿里內部可以藉助阿里雲Odps的數據集成服務來進行定時調度處理；各公司如果沒有自研的話，可以考慮通過分佈式任務調度來進行相應的邏輯處理。
2.7 分佈式事務
跨庫，跨系統，跨服務的操作，會發生分佈式事務的問題。
阿里內部使用TXC這個分佈式事務中間件，通過極少的代碼侵入就可以實現分佈式事務。
TXC已經開源。大部分情況下僅需要引入TXC Client的jar包，進行幾個簡單的配置以及數行代碼改造，就可以輕鬆保證分佈式數據一致性。
TXC提供了豐富的編程和配置策略，以適應各種長尾的應用需求。
** 分佈式事務：是指事務的參與者、支持事務的服務器、資源服務器、事務管理器分別位於不同的分佈式系統的不同節點之上**
2.7.1 分佈式事務解決方案
- 兩階段提交
第一階段表決，第二階段執行；
2PC可以滿足強一致性ACID，但是代價是吞吐量（譬如數據庫需要頻繁地對資源上鎖，而且上鎖時間跨兩個階段，時間較長，並出現木桶效應）。
2PC理論的一個廣泛工業應用是XA協議，目前幾乎所有收費的商業數據庫都支持XA協議。但是對吞吐量的影響導致其應用較少。 - TCC
Try，Confirm，Cancel三個操作集，事務補償機制。
實現的是最終一致性：事務進行過程中，某些分支的中間狀態可以被事務外所觀察到，即“讀未提交”，從而導致多個分支的狀態可能不一致。但是所有分支最終會達到要麼全部提交，要麼全部回滾的一致狀態。
2.7.2 TXC
TXC結合DRDS解決分佈式事務的問題。
分佈式事務場景：
- 跨多個數據庫的事務場景（數據庫類型不同）；
- 跨數據庫系統、消息系統的事務場景；
- 跨服務的事務場景；
TXC三個組件
- 客戶端TXC-Client；
- 事務協調器TXC-Server；
- 資源管理器RM；
2.8 分佈式計算
分佈式計算氛圍實時計算和離線計算。
在阿里內部，離線計算一般跑在ODPS上；實時計算可以使用Spark，Storm，Flume，Flink等。