微服務架構學習與思考(12)：從單體架構到微服務架構的演進歷程

從單體架構到微服務架構的演進歷程

一、單體架構

1.1 什麼時候用單體架構

在創業初期或專案開始時，專案整體功能比較少，開發人員也少，且專案需要用最少時間開發出來，用 MVP 方式快速進行市場驗證是否可行，這時候就可以用單體架構進行快速開發。

1.2 單體架構設計舉例-電商應用

功能分析：

拿淘寶網來舉例，現代電商網站功能是很複雜的，有多少功能呢？可以看看我前面的文章《電商產品設計全攻略》讀書筆記(https://www.cnblogs.com/jiujuan/p/14452748.html) 裡的電商管理系統和電商平臺產品結構 2 小節。

拿淘寶網舉例的話，當然是最早期的淘寶網 - -！，它最簡單的 3 個功能：商品展示，使用者下單，訂單中心。這三個功能構成一個最簡單的電商業務流程。

展示給使用者看的商品頁面以及使用者購買商品的操作功能。那我們需要對使用者和訂單進行管理，怎麼辦？

就需要一個管理後臺來對使用者訂單進行管理。如此簡單分析過後，就知道了電商網站應用功能。

應用功能架構圖：

程式架構設計：

這時候我們開發的單體應用程式，部署在應用伺服器上。程式架構可能採用 MVC 這種程式架構模式。

當然也有可能什麼架構都不用，直接擼程式碼了，所有的程式都混合在一起，這就是所謂的「大泥球」單體，這是一種糟糕的開發方式。

java 裡最常用的 MVC 框架，比如 SpringMVC 框架。

劃分模組

比如根據上面電商功能架構圖，在程式裡可以把電商功能劃分為相對應的模組，如使用者模組，訂單模組，商品模組。

這時程式裡不管是前臺功能，後臺功能都有這些模組。

（應用程式模組）

這時候應用程式模組都在一個大的單體專案裡，前臺功能和管理後臺共用一套程式碼。

模組裡的功能

比如前臺商品模組，就有商品列表，商品詳情頁等頁面功能。

程式開發

編寫程式時可能應用 MVC 這種程式設計模式來進行程式程式碼開發。

程式部署架構圖：

編寫的程式程式碼部署到應用伺服器上，使用者的所有資料儲存到 MySQL 資料庫裡。

程式和 MySQL 都部署在同一臺伺服器上。

二、單體架構演進

2.1 MySQL 效能瓶頸-快取

隨著專案上線，公司對專案加大力度推廣和運營，使用者數越來越多。

有一天，使用者投訴說，商品詳情頁面瀏覽好慢。如是你一番操作猛如虎，發現詳情頁顯示慢，效能瓶頸出現在資料庫 MySQL 上，

MySQL 在使用者存取高峰時，扛不住那麼大的存取量。這時你想到的解決方法，可以用快取來快取一部分資料，不必每次都到 MySQL 取資料，

可以用 Redis 來快取部分商品資訊資料。如是，增加一個 Redis 快取，架構圖如下：

2.2 MySQL 讀寫分離

這時候，你也可能想到另外的一種方法：資料的讀寫分離，減輕對 MySQL 存取壓力。

經過上面 2 種措施改進後，商品詳情頁存取速度開始變快，存取正常了。

但是這種舒服日子沒過幾個月，又有使用者開始反饋頁面存取比較慢。

你又一番埋頭辛苦分析，發現是單臺伺服器負載高，單臺伺服器的效能已經到了極限，它已經承載不了那麼多使用者的存取。

如是你想，把資料儲存和應用程式部署到 2 臺伺服器上，減輕伺服器的負載壓力。

2.3：資料儲存和應用程式伺服器分離

於是你申請買了一臺伺服器，把 MySQL 和 Redis 都部署在這臺新買的伺服器上，讓原來那臺伺服器負載得到緩解。

新的架構部署成功後，使用者存取頁面又恢復正常。

但是隨著業務發展越來越好，新增使用者越來越多，應用伺服器的負載又居高不下了。

這時候要增加新的應用伺服器了，這樣做是最簡單的。多臺應用伺服器形成叢集，那怎麼存取這些應用伺服器？才能使每臺伺服器負載保持平衡，或者效能好的多接受一些使用者存取？這時候就要用到負載均衡了。

2.4 叢集-分散式

叢集-負載均衡(多臺應用伺服器)

部署多臺應用伺服器形成一個應用伺服器叢集，前面使用者通過負載均衡器來進行服務的存取。

比較常用的負載均衡軟體有 Nginx、LVS、KeepAlived 等等。

還有硬體負載均衡，比如 F5 等。

部署後，頁面存取又恢復了正常。

過了幾個月，資料伺服器也出現負載過高情況，這時候可以把 Redis 快取和 MySQL 分離，部署到不同伺服器上。

隨著資料量增加，把 Redis 部署為分散式快取。

資料庫分離和 Redis 分散式快取

把 MySQL 和快取 Redis 部署到不同的伺服器上。

隨著快取資料的增多，Redis 也部署為主從模式，然後到 Redis Cluster 叢集模式，也就是 Redis 的分散式快取。

此時資料儲存伺服器負載得到緩解，存取恢復正常。

由於業務發展太快，使用者變得更多，資料庫又出現了效能瓶頸，這時可以對資料庫進行分庫分表

分庫分表

為了進一步的降低資料庫由於資料量太多，存取太大而造成的瓶頸，可以對資料庫進行分庫分表，減輕資料庫的存取壓力。

三、應用程式發展演進

3.1 應用程式功能變化-硬體發展

上面畫的架構圖都是後端技術部分，伺服器端架構從單體到叢集再到分散式的演進。

那麼前面給使用者使用的應用程式呢？也是在變化之中。

比如在《淘寶技術這十年》裡的淘寶網的發展變化，剛開始時是一個很簡單的 PC 端頁面，到後來隨著手機普及，行動網際網路發展起來，

手機應用就出現了。淘寶 APP 也隨之出現。隨著國民應用微信逐漸發展壯大，小程式也成為第三種網際網路程式應用形式。當然，還有其它終端，比如平板 ipad，自動售貨機等等各種終端。

上面是不同硬體出現，程式應用承載出現不同形式。

（多終端使用者出現後的架構圖）

那麼淘寶網的功能呢？當然增加了很多。

還孵化出了多種不同的業務應用，比如天貓，1688，支付寶，聚划算，淘寶旺旺等等很多應用。

在今年 2013.1 再去開啟淘寶 APP 看看，裡面的功能多到眼花繚亂。

現在的電商系統有哪些子系統，系統裡都有啥功能，可以看看我之前釋出的這篇文章。

3.2 多端程式單體架構

多種終端的出現，當然不是一下子就出來的，都有一個發展過程，只不過到寫這篇文章為止，出現了上面說的PC，手機 APP、小程式，平板等多個終端，最常用的還是前面 3 種。

最開始開發程式時，應用程式要適應多個終端，最簡單的方式就是拷貝 PC 端的程式碼到多個終端程式裡。按照上面 1.2 小節的電商最簡單業務功能模組實現，多終端應用程式功能架構如下：

（後端功能模組架構圖）

上面的三種終端程式應用，還是使用同一個 MySQL 資料庫，也及是說訂單資料、使用者資料等都儲存在一個庫中。

可能會問，怎麼區分訂單來自哪一個終端？

可以給訂單資料一個型別標識來進行區分，訂單是從哪一個終端過來的。

那管理後臺呢？

多終端程式可以共用一個管理後臺。

多終端的後臺功能模組都搞起來了，但是這種程式模組架構有什麼弊端缺點呢？

程式碼重複

增加/修改功能複雜：比如說要修改一個訂單模組的功能，需要修改 3 個終端的後臺程式碼

程式碼維護複雜：每次維護程式碼都需要動 3 個後端的程式碼

那有沒有辦法可以改進上面所說的情況？

能不能把 3 個後端重複模組程式碼合併為一個，統一向前端提供服務，當然是可以的。怎麼做？

前後端分離 - 把前後端程式碼進行分離，前端展示操作頁面和後端功能模組分離

抽象公共模組 - 把多個後端公共模組進行抽象為一個模組，為前端提供統一服務