不管你喜不喜歡微服務，現在微服務無疑已經是程式設計師們繞不過去的話題了。無論你是想把目前的架構改成微服務，還是你要出去面試高階一點的崗位，需要深入理解微服務。
提起微服務，很多程式設計師對它是又愛又恨，想學微服務不知道如何開始，學了一點之後，又找不到地方去實踐。總之就是感覺微服務遙不可及，又很難駕馭。
首先要明白的是微服務是有套路的，而這些套路基本上解決了微服務結構面臨的幾乎所有重要問題。
這些套路就是微服務自己的架構模式
如果我們能深入瞭解這些模式的其來龍去脈，就可以理解了微服務絕大部分內容。學習快速，實用價值也極大。
1. 微服務最基本的模式
這篇文章先來講第一個最基本的模式，這個模式我估計需要三篇文章才能講透，這是上篇。打算中篇寫實踐，下篇寫問題。
希望大家能學的輕鬆。
微服務最基本的模式就是：
一個服務一個資料庫
上圖就是一個最簡單的微服務模式了。
一個服務一個資料庫這種模式，是微服務體系結構中的最基礎也是最核心的模式。看著簡單，但是，這個模式蘊含著微服務的最基本的思想。
要弄清楚一個服務一個資料庫這種模式，首先我們就需要問一下，為什麼我們要搞微服務。
2. 傳統系統的問題
在談及微服務的時候，和微服務對應的概念叫做單體系統( Monolithic application )。簡單說，微服務是為了解決單體系統的問題才衍生出來的。單體系統結構如下圖:
那麼這種單體結構出現了什麼問題，導致現在大家必須開口閉口微服務了呢？
3. 單體系統太大了
最首要的一個原因就是應用系統太大。而由於應用系統的過於龐大，如果僅是單體系統的話，就引發了各種各樣的問題，體現在以下三個方面：
3.1. 系統本身業務複雜，模組眾多
系統隨著時間的發展，業務需求越來越多。而為了滿足這些需求，就導致整個系統的模組越來越多。而系統模組越來越多，就導致能理解整套系統的人變得越來越少，直到最後沒有人可以理解整套系統。
3.2. 系統的程式碼庫非常龐大
程式碼量也會隨著系統的增大而增大，程式碼量的龐大影響了整個開發流程，會導致整個開發成本變得很高。
- 首先，程式碼量大，依賴關係複雜，所以對新接手的開發人員來說，配置開發環境非常耗費精力。
- 其次，程式碼量大，載入這些程式碼和對應的依賴需要的記憶體就多，所以就會導致開發人員的 IDE 執行非常緩慢，導致編輯程式碼都很麻煩。
- 再次，程式碼量大，如果要把整個程式碼編譯打包，需要的記憶體也很多，所以也會導致功能開發完成後，對系統的構建會非常緩慢，導致整個構建的時間非常漫長。
- 再有，程式碼量大，幾乎沒人能對整體程式碼有比較深入的瞭解，哪怕可能其中一個要改動的功能，都會因為過於複雜導致開發人員理解不深入。而這些不深入的理解又會讓開發人員不能使用最佳的方式去做功能開發，從而導致隱藏的 bug。
3.3. 技術團隊變得非常龐大
由於功能模組越來越多，這就需要越來越多的開發人員去開發和維護這套系統。但是，這些開發人員都是面對的同一套程式碼庫，雖然可以搞分支，大家各搞各的。可是一旦需要合程式碼，釋出上線，就是場噩夢。
各種程式碼衝突，程式碼丟失，都可能在上線的時候發生。
不僅如此，由於顧慮程式碼丟失和衝突，就需要在上線前，進行足量的測試，而這些測試又需要投入巨大的時間成本。
但是，現在都講敏捷開發，很可能在還沒上線的時候，後續的業務需求又接踵而至，簡直要命。
4. 業務需求的個性化
搞微服務，還有一個很重要的原因是業務需求的個性化和顆粒化。
隨著業務的發展，不管是由於市場競爭還是本身發展的需要，勢必需要對本身業務模型的深度挖掘以及提高使用者使用系統的各種體驗。而基於此類種種，就勢必要把系統的各個功能模組做深做透。
這又會引發幾個新的問題:
4.1. 系統功能模組可能變得更多更雜
系統功能模組可能被不斷拆分成了更細碎的模組，以致可能碎成了顆粒。而由於功能變得更碎更顆粒了，就會讓產品經理們更容易的提出一些非常細緻的業務需求。
這些非常細緻的需求，很可能會造成頻繁的功能修改和上線要求。而這些無窮盡的快速需求相對整體龐大的系統上線和開發人員的疲於奔命形成了最激烈的衝突。
4.2. 功能模組對系統的技術要求出現了衝突
比如，不同的功能模組，訂單模組和支付模組。訂單模組就希望系統能儘可能的能同時處理大量的訂單，甚至可以有一定的容錯性，出問題了砍單就可以了。
但是支付模組則不一樣，支付模組希望系統能儘量的穩定，並且必須對準確度要求極高，幾乎沒有容錯的空間。
同樣的，在同樣的支付模組中（根據系統模組劃分而定），可能同時存在本地賬戶轉賬和三方渠道支付，本地賬戶轉賬可能需要即時，要求極高的響應時間。但是對於第三方支付，則可以有一定的響應時間容忍度。
如果系統本身是個單體系統，就勢必要求開發人員對整套系統做一定的妥協，對衝突的技術需求做出一定的權衡。而這種權衡很可能影響的就是系統整體的體驗度。
4.3. 系統模組對伺服器的要求出現了衝突
由於功能的深耕細作，則勢必會出現效能上的不同需求。
比如，系統的訂單模組，個人下單可能會被頻頻訪問，此時，就需要系統的叢集多一些，去處理這些大規模的訪問。但是，同樣的功能模組裡，可能還存在一些企業團購需求，他們沒有那麼大的訪問量，就不需要那麼多的伺服器叢集。
又比如，使用者評論截圖，可能需要大量的資料儲存。但是，同樣的，針對使用者的個性化推薦就可能需要大規模的密集運算。
除了上面說的，系統龐大引發的問題帶來的一些附屬問題：
4.4. 故障的連鎖反應問題
單體系統從技術上，各個模組是耦合在一起的。在實際執行裡，很可能就會出現一處故障導致整個系統崩盤的現象。
比如，不常用的一個 XX 功能出現了記憶體洩露，導致整個系統全部不可用了。
4.5. 系統的技術鎖死問題
坦白來說，你得承認在程式設計裡，沒有一種語言是完美的，也沒有一個資料庫是萬能的。
比如，Java 做科學計算就沒有 Python 那麼方便高效。比如，我們需要儲存很複雜的物件關係的時候，MySQL、Oracle 就不如任何一種圖形資料庫。
所以，系統越複雜，需要不同技術的概率就越高。但是又由於系統的複雜，引入新技術的風險也就越大。所以，新技術的使用非常困難。
同時，系統龐大後，如果一些元件，甚至語言 SDK 本身的問題如果需要升級，也是一件既繁瑣，又充滿風險的事情，所以，技術版本升級也非常困難。
綜上，對於傳統的單體應用來講，系統龐大引發的技術問題，業務發展引發的需求衝突問題……都是無法單憑單體系統的架構思想就可以解決的。
那為什麼 SOA 也不能解決這些問題呢？
5. SOA 的問題
我們們先來看看SOA的結構
可以看到 SOA 架構中有個 ESB（企業服務匯流排）。這個 ESB 就是專門用於 SOA 的服務和服務之間的互動，是 SOA 必備的基礎技術設施。
正因為 SOA 有了服務匯流排的思想，就註定 SOA 切分的服務不可能太細，因為服務出現的越多，這個服務匯流排就最終會變成一個整體系統的瓶頸。
SOA 的服務切分規模本身就受到了限制，這個限制就會帶來以下的問題:
-
切分不夠細——我們說過，我們的主要問題根源是系統過於龐大，並且還堆在了一起。如果我們切分不夠細，那麼可能的結果就會變為，從一個很大的系統被切分為了寥寥幾個也很大的系統，最終沒有解決問題不說，還可能因為系統變成了不同的分散式服務，又引入了新的分散式系統本身所帶來的問題。
-
ESB 本身就可能成為一個龐大無比的系統怪獸——ESB 作為 SOA 的基礎設施，它本身就已經足夠複雜，很可能由於業務的發展，它自己也變成了一個恐怖的系統怪物。從而讓開發人員不僅需要維護原來的系統，很可能還需要為如何維護和修改ESB本身而傷透腦筋。
所以，可以看出來，SOA這種思維方式和架構實現本身不足以解決龐大單體系統帶來的問題。
6. 為什麼需要服務
回到我們的微服務的話題。我們知道了問題的根源，我們就需要著手解決這些問題。
首先，既然問題是由於系統的龐大複雜引起的，那麼我們就可以參考軟體裡很普遍的解決思想：分而克之。
無論一個系統有多大，如果我們將其拆的足夠小，就可以把一個複雜的大系統拆分成許多個小系統，再讓這分解出來的小系統通過對外提供服務的手段，將他們再聚合成一套大的完整體系，從結果上，就等價為了原來的複雜的大系統了。而這，就是微服務的最樸實的思想。
所以，微服務思想核心有兩個:
- 把系統拆分成不同的部分
- 這些部分要足夠小
微服務這樣做帶來了幾個好處:
-
無論多大多複雜的系統，我只要能拆，會拆，就能把問題簡化，從而不用懼怕系統變得複雜。
-
拆分出來的服務只要足夠小，那麼無論開發、部署、運維上，都能得到無數原來因為系統龐大而無法獲得的好處：修改程式碼可能變得簡單了，測試和執行也變得容易了……
-
拆分出來的服務能各自獨立發展，不會互相制約。原來系統是單體系統的時候，模組之間由於技術上的耦合，導致無法自由自在的選用最適合當前功能模組的技術，也不能隨心所欲的根據當前功能模組的負載情況去彈性的安排伺服器。
-
故障天然被隔離開了。我們把系統切分成了服務，每個服務都有自己的程式或者伺服器，這樣故障從物理層面就被隔離開了，從而避免了一處不重要的功能故障導致整個系統崩盤。我們只需要把核心的功能弄的足夠健壯，即使非核心功能有了問題，也不會造成太大的損失。
所以，一套巨大的系統，由於本身的臃腫和複雜，就可能會要對其自身進行拆分。而這些拆分，根據一些指導原則，將其拆解的夠小，夠簡單，那麼，拆解後帶來的效益是很可觀的。
7. 為什麼需要拆庫
服務已經拆了，已經獲得那麼大的好處了。
“但是為什麼資料庫也必須要拆？”——這其實是很多使用微服務的同學最疑惑的問題了。
資料庫拆分不拆分本質上其實就是資料共享的問題。而一個服務一個庫本身的觀念，其實就是盡最大程度的避免資料的共享。
資料共享會帶來如下幾個問題:
7.1. 技術實現依然可能耦合
因為沒有拆分資料庫，所以，很可能一個本來應該獨立出來的服務模組，必須依賴於另外的服務模組，而這和我們拆分服務的初衷出現了衝突。
比如，訂單服務和個性化推薦服務，很可能都需要訪問訂單相關資料。此時，如果不拆資料庫，則很可能由於訂單業務需求導致的訂單表結構的修改，倒逼個性化推薦服務也要跟著修改。
7.2. 底層資料的過度暴露
還是上面訂單服務和個性化推薦服務的例子，個性化推薦很可能只是需要一些使用者 id、訂單類別之類的東西，但是由於資料庫是共享的，很可能開放的就是訂單表的全部資料，而這些資料有很多算是敏感資料，應該被隱藏的，現在則被暴露出去了。
7.3. 無必要的資料訪問競爭
因為是同一個資料庫，這勢必會造成對共享資料的競爭性訪問，而這些競爭性訪問則會大大影響業務模組的彈性部署。比如，訂單模組很可能由於個性化推薦的一些定時批量查詢，被影響了其能承載的併發資料量。
所以，看出來了吧，分庫是必須要考慮進微服務整個體系結構的。
8. 最後留個尾巴
每一個服務對應一個資料庫這種模式，是微服務中的最核心最基本的模式，它體現了微服務最核心的思想：
拆分與解耦
一般來說，微服務大部分時候，都會盡量採用一個服務一個資料庫的模式。
這裡只說了為什麼要使用一個服務一個資料庫，而如何去分服務，如何去分資料庫，它們是否還存在一些實踐上的妥協，這會在下一篇文章裡仔細解析。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會通過公眾號，
把自己的成長故事寫成文章，
把枯燥的技術文章寫成故事。
我建了一個讀者交流群，裡面大部分是程式設計師，一起聊技術、工作、八卦。歡迎加我微信，拉你入群
