流量調度：不要將流量調度和服務治理混爲一談 (服務治理是流量調度的前提)；主要功能；關鍵技術。
狀態數據調度：完整解決數據 Scale 問題的應該還是數據結點自身，相應的技術方案。
流量調度（是內部的，更是外部接入層的事；中心之外的事，邊緣計算，類似於 CDN 上完成的事）
服務治理（內部系統、中心的事），所以兩個還是應該分開的。
一、流量調度的主要功能：
1.自動地進行流量調度，提升整個系統的穩定性；
2.讓系統應對爆品等突發事件時，在彈性計算擴縮容的較長時間窗口內 、底層資源消耗殆盡的情況下，保護系統平穩運行，提高系統架構的穩定性和高可用性。
此外，這個流量調度系統還可以完成以下幾方面的事情。
服務流控。服務發現、服務路由、服務降級、服務熔斷、服務保護等。
流量控制。負載均衡、流量分配、流量控制、異地災備（多活）等。
流量管理。協議轉換、請求校驗、數據緩存、數據計算等。
這些都應該是一個 API Gateway （API網關）應該做的事。
二、流量調度的關鍵技術
好的 API Gateway 需要具備以下的關鍵技術。
1.高性能。使用高性能的語言。
2.扛流量。需要使用集羣技術，在集羣內的各個結點中共享數據。像 Paxos、Raft、Gossip 這樣的通訊協議 Gateway 需要部署在廣域網上，集羣的分組技術。
3.業務邏輯。簡單的業務邏輯，像 AWS 的 Lambda 服務一樣，可注入不同語言的簡單業務邏輯。
4.服務化。通過 Admin API 來不停機地管理配置變更的，而不是通過一個.conf 文件來人肉地修改配置。
三、狀態數據調度
最難辦的就是有狀態的服務了，保存一些數據，不能丟失的，需要隨服務一起調度的。
把問題轉移到了第三方服務上， Java中沒有狀態，但是 Redis 和 MySQL 有狀態。
所以，分佈式系統架構中出問題的基本都是這些存儲狀態的服務。數據存儲結點在 Scale 上比較困難，成了一個單點的瓶頸。
四、分佈式事務一致性的問題
要想讓數據有高可用性，就得寫多份數據，會導致數據一致性的問題；數據一致性的問題又會引發性能問題。
在解決一致性問題時，我們有一些技術方案。
Master-Slave 方案。
Master-Master 方案。
兩階段和三階段提交方案。
Paxos 方案。
3 年前寫的《分佈式系統的事務處理》這篇文章。可看到各種不同方案的對比
分佈式系統事務基本上都是兩階段提交的變種。阿里的 TCC–Try–Confirm–Cancel，或是我在亞馬遜見到的 Plan–Reserve–Confirm 的方式，通過業務補償，或在業務應用層上做的分佈式事務的玩法，基本上都是兩階段提交（或變種）。
應用層上解決事務問題，只有“兩階段提交”這樣的方式，數據層解決事務問題，Paxos 算法則是不二之選。
五、數據結點的分佈式方案
數據存儲結果有太多不同的 Scheme，有文件系統，有對象型的，有 Key-Value 式，有時序的，有搜索型的，有關係型的……這個“數據存儲的動物園”中，基本上都在解決數據副本、數據一致性和分佈式事務的問題。
比如：AWS 的 Aurora，改寫了 MySQL 的 InnoDB 引擎。爲了高可用的 SLA，寫 6個副本。其不像MySQL 的通過 bin log 的數據複製，而是更爲“驚豔”地複製 SQL 語句，使用各種 tricky 的方式來降低 latency。使用多線程並行、使用 SQL 操作的merge 等。
MySQL 官方也有 MySQL Cluster 的技術方案。MongoDB、國內的 PingCAP 的 TiDB、國外的 CockroachDB，還有阿里的 OceanBase 都是爲了解決大規模數據的寫入和讀取的問題而出現的數據庫軟件。
文件存儲的，需要分佈式文件系統的支持。一個 Kafka 或 ZooKeeper 把數據存儲到文件系統上。結點有問題時，再啓動一個 Kafka 或ZooKeeper 的實例，也要把它們持久化的數據搬遷到另一臺機器上。
（注意，雖然 Kafka 和 ZooKeeper 是 HA 的，數據會在不同的結點中進行復制，但是我們也應該搬遷數據，這樣有利用於新結點的快速啓動。否則，新的結點需要等待數據同步，這個時間會比較長，可能會導致數據層的其它問題。）
需要一個底層是分佈式的文件系統，新的結點只做一個簡單的遠程文件系統的 mount 就可以把數據調度到另外一臺機器上了。
解決數據結點調度的方案應該是底層的數據結點，業務層可以像操作單機數據庫一樣來操作分佈式數據庫，阿里的用於分庫分表的數據庫中間件 TDDL 都會成爲過渡技術。
狀態數據調度小結
應用層上的分佈式事務一致性，只有兩階段提交這樣的方式。
底層存儲可以解決這個問題的方式是通過一些像 Paxos、Raft 或是 NWR 這樣的算法和模型來解決。
狀態數據調度應該是由分佈式存儲系統來解決的，這樣會更爲完美。但是因爲數據存儲的Scheme 太多，所以，導致我們有各式各樣的分佈式存儲系統，有文件對象的，有關係型數據庫的，有 NoSQL 的，有時序數據的，有搜索數據的，有隊列的……
狀態數據調度應該是在 IaaS 層的數據存儲解決的問題，而不是在 PaaS 層或者 SaaS層來解決的。有三種方案：
1.使用比較廉價的開源產品，如：NFS、Ceph、TiDB、CockroachDB、ElasticSearch、InfluxDB、MySQL Cluster 和 Redis Cluster 之類的；
2.另一種是用雲計算廠商的方案。
3.如果不差錢的話，可以使用更爲昂貴的商業網絡存儲方案。