怎麼學習分佈式系統的知識
分佈式系統學習的大障礙
幹IT的程序員都知道學習意味者漲薪，幹IT的人都有一種感覺代碼在手天下我有的感覺。但是我們都知道學習技術最大的難點就是堅持不下去，好不容易學習完了還沒地方施展，學的東西過個幾天就忘的差不多了。我也是掙扎在IT技術海洋的一個癡兒。開通這個學習分佈式系統的專欄有兩個目的：第一是要記錄自己學習的筆記和歷程，第二是整理一份自己的學習分佈式系統的一些系統筆記方便廣大的讀者更輕鬆的學習IT技術。
分佈式系統的由來
分佈式系統的行業現狀
其實近些年在IT圈最流行的各種技術名詞和概念。剛剛開始學習這些新的新的技術的時候我們都是很茫然，什麼微服務、SOA、區塊鏈等技術。我通過從網上查找或者購買的一些知識付費的專欄或者工作中和同事的探討逐漸的摸清了這些技術的一個大概輪廓。接下來說說的僅屬於個人見解，首先聲明本人雖然在本行幹了多年，但是不是什麼技術大牛或者某個大廠的架構師等等。所以如果有什麼什麼錯誤或者不當煩勞大佬們指正小弟。你們是我技術生涯的指路的明燈。
最近我發現不管是面試還是本行業同行的交流都在討論微服務、SOA、異地多活、鏈路跟蹤、自動化運維、應用監控、分佈式緩存等等名詞。第一感覺就是很牛掰。但是都是幹嘛的，我聽到這些第一感覺就是很牛逼，但是都是幹嘛用的。我現在寫的業務代碼根本不用這些幹嘛要弄這麼複雜（本人一直在小公司工作，沒見過什麼市面）。但是隨着不斷的學習越來越理解這些東西存在必要性。任何技術活架構的存在都不是偶然，脫離業務的技術是沒有價值的，任何技術的存在都是依附與業務。就連我們認爲用處不大的算法都是爲了業務的存在，因爲現在封裝的技術或者框架太多了所以讓我覺得我們只要框架用的好什麼業務都可以完成。話說回來如果框架及其難用或者沒有框架我們該何去何從？前面的廢話太多下面我們來系統的闡述以下我理解的分佈式系統。
分佈式系統的演變
說到分佈式系統的我們務必要了解一下單體架構。因爲單體架構滿足不了我們的業務來所以逐漸的演變誕生來分佈式系統架構。
舉個例子：單體系統就像一個初創公司，分佈式系統就像分佈式系統，
初創公司中僅僅有那麼幾個人每個人都是身兼多職。當然這個公司的盈利是非常有限的。當有一天這個初創公司做成了一定的規模，他們的業務也比較多，再也不是那種一個人或者兩個人就可以完成應有的工作了，管理上也會越來越亂。所以這個時候就需要擴大人員規模，公司部門化，這樣我們要做一項工作只需要將規定的部分分給某個部門去做，然後向這個部門去要指定的工作成果，將每個部門做的成果組裝到一塊就可以完成指定的業務工作，部門化也方便了人員管理。
同樣最開始單體應用架構會把所有的業務都在一個服務上完成。當用戶量小的時候這個服務還可以正常運行，但是當用戶量逐步上來的時候這種單體架構的服務會越來越喫力直至最後不堪重負到最後的崩潰。這個時候我們的服務器就類比我們公司裏面招的人，一個人完成不了那麼我們就去招兩個人或更多，既然一臺服務器滿足不了這麼多用戶量的需求那麼我們去買兩臺服務器去共同處理共同分擔這麼多的用戶量。購買服務器的成本就像我們招人需要發工資一樣。既然我們需要將工作分配到每個服務器上那麼我們就會需要一個分配機制去分配用戶請求，服務器不像我們人類這麼只能幾個人一協商把工作一分配就可以各幹各的活，所以這其中需要我們去搭建一個負載均衡的服務去分配請求。但是其中還是有個問題就是我們的系統中可能有多中業務，比如其中A業務和B業務模塊，但是A業務的用戶請求比較多熱度高，需要10臺服務器去承載，但是B業務使用的人很少，一臺服務還有餘。這樣我們的服務器資源就得不到很好的利用。公司中財務需要2個人就夠了銷售需要10個人，這個時候不能說我直接拷貝原公司的樣子再創建多個一摸一樣的公司吧，銷售的確實是夠了但是多出來的財務人員就是天天沒事幹浪費成本。所以這個時候就會進行業務拆分將A模塊和B模塊拆分成服務，這個時候就可以針對不同的服務進行服務器的擴充。所有的業務在一個服務中還有一個弊端就是各個模塊之間的依賴性太強而且模塊的，當其中一個地方出現問題那麼就會導致整個系統的崩潰。而且模塊的重用度比較低。所以我們開始了模塊服務化，多服務器支撐同一個業務的架構指路也就是我們的分佈式架構。
分佈式架構是一種比較廣泛的架構理念。我們以上所說的各種技術都是在分佈式架構理念的基礎上衍生出來的。比如說SOA(面向服務的架構)，MSR（微服務）。分佈式架構給我們解決了系統吞吐量和系統穩定性的問題但是也帶來了一些其他問題比如架構複雜，部署運維複雜等問題，出現問題之後排查耗時。之後出現的大部分技術或概念都是針對分佈式架構帶來的新的問題而出現的，以下是單體架構和分佈式架構的對比。
| 優點/缺點 | 單體架構 | 分佈式架構 |
|---|---|---|
| 功能開發 | 耗時 | 效率高耗時短 |
| 部署/運維 | 簡單容易 | 複雜耗時 |
| 性能 | 響應快吞吐量小 | 響應慢吞吐量大 |
| 技術 | 技術單一簡單 | 技術面廣深度大 |
| 系統擴展性 | 差 | 優秀 |
| 系統管理 | 重點在開發 | 重點在部署和後期運維 |
分佈式系統介紹總結
1 分佈式解決問題
1.1 增加系統的可用性
1.2 增加系統的吞吐量
2 微服務和SOA都是實現分佈式系統的一種架構方案
SOA 和 MSR的對比
SOA和MSR如果不仔細區分還真的不知道區別在哪，之前我記得我面試的時候就被這種面試題給問懵了，當時概念差不多能說出來但是區別的化真的感覺就是一樣的。這兩種架構技術的出現的原因都是爲了解決分佈式架構中出現的問題。
按照我的理解SOA和微服務本質上都是將系統模塊服務化，拆分業務模塊成服務，SOA面向服務的架構主要是實現服務之間的整合，其整合模式是按照固定的協議和中間件（企業總線ESB）進行服務之間的信息交互。還是舉例子，一個小區內要進行交流中間又一個信箱每個格子都是針對一個門，那麼其中信箱就相當與企業服務總線每個信箱格子都是針對一個門牌號就相當與協議。通過信息進行交流。
微服務也是將業務模塊拆分服務化，不過服務之間的組合有點不一樣需要一個服務編排或服務整合的服務。就好像網關服務進行請求的分發和鑑權等作用。相對於SOA而言和業內的案例而言微服務針對的業務更爲複雜所以服務拆分的粒度相對較大，比較松耦合。
兩者之間的區別類比與公司，SOA就像公司部門化，微服務就像部門公司化。公司部門化，公司中分出了各個部門每個部門負責一個職能，那麼當我們各個部門進行重大信息交流的時候就會進行開會，這個會議就像ESB（企業消息總線）所有的指令和任務信息都是在會議上發送給各個部門的。部門公司化，當人員過多之後可能會將每個部門成立一個公司然後將各個公司分散到各地也就是分公司，這個時候會議已經不能實現信息的試試交互了，這個時候公司會有一個公司總部，當需要某個分公司去完成某個任務的時候都是通過總公司去下發任務通知分公司。這個公司總部就像是服務編排和整合服務。
微服務的出現使得開發速度變得更快，部署快，隔離性高，系統的擴展度也很好，但是在集成測試、運維和服務管理等方面就比較麻煩了。所以，需要一套比較好的微服務 PaaS 平臺。就像 Spring Cloud 一樣需要提供各種配置服務、服務發現、智能路由、控制總線……還有像 Kubernetes 提供的各式各樣的部署和調度方式。
本章小結：
1. 分佈式系統
- 解決的問題
- 系統穩定性
- 系統吞吐量
- 帶來的問題
- 架構設計複雜
- 部署運維麻煩
- 實現方案
- SOA
- 微服務
2. SOA和微服務的對比和區別
- SOA架構：服務件的組合交互通過固定協議和中間件（ESB企業服務總線）進行信息交互，服務拆分粒度相對較小
- 微服務： 服務之間的整合和交互通過一個服務編排或組合的服務進行整合，拆分的粒度比較小。
總結
分佈式系統介紹到這，僅僅對分佈式系統的認識進行了一個宏觀的介紹。下一章將細化分佈式系統設計的一些關鍵 部分和技術棧，比如緩存系統、異步消息系統 、負載均衡、數據景象等。本人小公司菜鳥一枚希望找到志同道合的同行多多交流多進步。如有錯誤枉指正。