分散式系統實現核心是錢，因為要架構硬體，做架構的和做維護的人力成本不低。如果租用服務商的系統也費錢！

分散式系統很多，可面向的應用情景不同，思路也有所變化。分散式檔案系統，分散式資料庫，分散式WebService，分散式計算等不同的分佈系統要求都是不一樣的。但是，同源同宗，各類分散式系統也有共通的地方。

水平擴充套件和垂直拆分是分散式架構常用的兩種思路，經常合著用。如果我們的服務請求不斷增加，一臺伺服器無法滿足了，那就要兩臺伺服器，如果還不行，那就增加到三臺......這種我們稱為水平擴充套件。如果我們有兩個資料請求，資料A和資料B，一臺伺服器已經無法滿足，我們加一臺機器來負載均衡一下，一臺處理資料A，另一臺處理資料B，這種方式我們稱為垂直拆分。

要實現請求的平均分配就需要做負載均衡。實現負載均衡之後呢，還需要解決資料的一致性問題，這個是需要透過同步來完成保障的。根據不同的場景和需求，同步的方式也是有多種選擇的。

分散式系統搭建確實是比較困難的，涉及的點比較多，有幸參與過，來說說自己的拙見吧！

下面以保險公司為例:

1，應用服務:根據業務系統分為契約，核保，批改，理賠，每個大的系統下面可能會有細分！至少要保證四個大的服務群！

服務:都是使用spring cloud搭建公司的微服務，保證各系統之間的服務對外提供，每個服務對外提供都使用nginx進行負載均衡，真正的應用服務有四臺或者兩臺！

資料庫:每個業務對應的服務系統連線8庫1024表，使用mycat中介軟體搭建的分庫分表，單表保證資料不超過1000萬，也就是每個服務的資料容納能力為102億的資料記錄！資料都是用邏輯刪除，考慮對三年期以上的資料進行資料轉移儲存，在資料庫中進行物理刪除！

nosql:使用mongoDB對大部分key value形式的中間json資料進行讀取效率，使用redis快取諸如列舉，定義表等可靜態處理的資料，使用redis實現分散式鎖，全域性session等實現單點登入！

2，訊息傳輸:

batch:採用自寫的批（i batch）處理框架，根據不同的呼叫異常，資料錯誤等採取不同的重試機制，減少人工干預，多次重試不能透過的資料，發郵件進行人工處理！

訊息:同時使用訊息中介軟體（kafka.ons都用過）進行服務之間資料傳輸，訊息先進行資料落庫，避免資料的丟失，各步驟有返回值判斷加重試機制，保證各服務之間資料的一致性！

3，資料驅動:

使用工作流驅動資料，保證資料的安全有序進行，避免流程的複雜化，不可控性！保證每一條資料都能沿著這條線進行！同時控制多個服務節點資料的一致性！

4，監控:

資料庫連線池，服務註冊與發現，宕機監控！服務的機器狀態cpu，記憶體的監控等等！

還有更多的問題，期待您的補充！