分散式系統的那些事兒（一）

05-10

巨石應用在如今互聯網+時代逐漸淘汰，而分散式系統，集群，微服務可謂現在的流行趨勢。那麼近期花點時間來講講分散式系統吧。

什麼是分散式系統，很多人一直不理解，只知道把系統分散式部署就行了，但是沒有做過這樣的系統，也沒在裡面寫過代碼，當然連部署都不知道，那麼就更加的模糊了。

籠統而言，分散式系統從軟體上來講，對於用戶來說是一個不可分割的整體。從硬體上講就是多台獨立的伺服器。舉個栗子，我們在訪問淘寶的時候，我們不會去關心淘寶後台代碼是怎麼實現的，是如何部署的，我們唯一想要的就是完成購物流程，買到心儀的商品，整個過程流暢，用戶體驗好，網頁打開快速，各方面人性化即可。而從硬體上來講呢，用戶完全不需要知道，比如在某個時候真正更新維護系統，而且卻不影響用戶的購物流程。就像王者榮耀那樣，很多時候這個遊戲在更新的時候不影響遊戲，那麼這就是硬體分散式做的牛逼的地方了。而很多遊戲在更新的時候用戶是必須要下線的。

既然有分散式系統那麼肯定也會有集中式系統，淺白點講就是文中一開始講的巨石應用，也就是說整個軟體就一個war包，所有功能都在裡面，十分大，對於單台計算機的運算能力性能要求十分高。如今很多的企業級後台應用都是這樣的。這樣的應用顯然已經不符合如今的互聯網時代，所以要做SOA或者微服務進行拆分這樣的工作流也是十分的巨大。而在做拆分的這個過程好不誇大的講需要半年，甚至1年，如果再加上期間人員流動，尤其新人，在不懂業務的情況下是完全不會做的。

那麼有些人會問了，現在要開發一個系統，到底是搭建分散式呢還是單一web應用呢？那麼我的回答是看情況，如果預計這個系統將會承載很多的用戶量，大並發質量的，那麼肯定要做分散式，如果對於企業來講，僅僅只是固定用戶群體，比如特定的VIP用戶，對於這樣的系統設計為單一也沒事。

兩種系統的優缺點，顯而易見了，單一應用維護起來相對簡單，一個包上傳重啟即可。而分散式環境下對運維的能力有一定的考驗。此外，單點故障的問題分散式是不存在的，單一應用的伺服器掛了那麼整個網站就掛了，這就是所謂的高可用。

設計分散式系統有多複雜？那麼大致可以分為以下幾點：

分散式許可權如何控制，包括單點登錄

如何從單一系統拆分為多個子系統

各個系統之間如何通信？RPC還是Restful？

如何保證系統通信的安全，如何不被攔截

如何保證系統的高可用

分散式事務如何實現？數據的最終一致性如何解決?

如何監控各個子系統。

並發的時候如何考慮全局的所有子系統？（並發一直以來都是一個很大的概念）

如何防範各類網路攻擊

先寫到這裡吧，接下來的文章都會圍繞分散式來講。