分布式系統產生背景：
　　在互聯網還沒有現在這麽方便的時候，所以很多公司的業務線都是垂直架構，如LAMP。由於各個公司的業務比較簡單，需要處理的用戶數據也相應較少，所以簡單易上手的垂直架構還能很有效地支撐各個公司的業務發展。但是隨著互聯網的普及移動互聯網的發展，需要處理的用戶數據得到了爆炸性的增長。而且為了同時服務於手機app和自助終端機等渠道的業務，各種新的需求層出不窮。在不斷地叠代升級的過程中，之前提到的公司垂直應用架構慢慢就演化成了一個個的巨無霸應用。系統變得臃腫龐大，業務錯綜復雜。一旦有新的需求到來，牽一發而動全身。不僅系統可能有很多地方需要同時修改（比如一個訪問mysql的接口，可能在代碼裏到處都是），而且整個系統都需要經過嚴格的測試才可以上線。開發效率低下，修改成本越來越高，測試周期越來越長，而bug越來越多。更讓人頭大的是，一旦之前維護這個項目的人員發生變動，新頂替上來的同事需要很長的時間才能把整個系統弄個半懂。所以垂直型巨無霸應用已經在大流量和高並發的沖擊下，越來越力不從心。

　　這時候的解決辦法便是，對復雜的巨無霸應用進行水平拆分。把公共業務包裝成服務提供出來，把各個相關業務封裝成子系統也提供出接口。達到降低代碼耦合，公共業務復用的目的。由於子系統和子系統之間已經進行了解構，所以一些業務可以通過簡單的加機器進行水平擴容來應對高並大和大流量。每個子系統的修改基本不會影響到其他子系統的穩定性，測試也不需要把整個系統拉過來全部測試一遍，提高了系統更新叠代的效率。

分布式系統中存在的問題：

　　在當前數據體量巨大的情況下，可以看出分布式業務系統的優勢很明顯。但是同樣，分布式系統給我們帶來了其他的一些問題和挑戰。常見的問題有很多，我只列覺我目前遇到的一些問題，供大家參考:)

分布式系統的產生背景和提出的挑戰