隨著越來越多的網際網路技術團隊開始採用微服務實施系統架構，伴隨著業務的擴大，系統擴容的問題就會擺上議程，那麼微服務架構該如何擴容呢？今天本文就嘗試將從上到下擴容方案梳理一下，供大家做為一個參考。
一個常見的微服務架構如下：
微服務基於Dubbo + Zookeeper的組合，快取和資料庫採用Redis + Mysql的經典組合。
利用DNS伺服器做前端入口層擴充套件
在上圖描述的架構中，Nginx作為整個系統的唯一入口，如果系統吞吐量增加，nginx的效能變為成為一個瓶頸，另外單臺nginx也容易引起單點故障，所以，我們就需要將nginx進行水平擴充套件，在這裡我們考慮使用dns-server來實現。
例如nginx的地址為192.168.0.1，新加一臺nginx的地址為192.168.0.2
通過在DNS伺服器配置記錄：
nginx.yw.com INTOP 192.168.0.1，
nginx.yw.com INTOP 192.168.0.2，
DNS伺服器會根據負載演算法計算得到其中一個記錄返回。利用DNS伺服器來承擔負載均衡，無需單獨管理負載均衡伺服器，輪詢返回不同的ip，從而實現nginx的水平擴充套件。
利用Nginx反向代理實現閘道器層的擴充套件
Nginx具備反向代理伺服器的功能，可以用於實現負載均衡。反向代理位於閘道器伺服器之前，可以快取閘道器請求，提高訪問速度，通過其負載功能，管理閘道器伺服器。
upstream apigw{
server 192.168.1.1:8080 weight=1;
server 192.168.1.2:8080 weight=1;
}
複製程式碼location / {
index index.jsp;
proxy_pass http://apigw; #在這裡設定一個代理，和upstream的名字一樣
複製程式碼採用Nginx，反向代理功能與負載功能整合在同一臺伺服器上，實現簡單。
提前準備好映象伺服器和指令碼
由於採用Dubbo, 服務節點的水平擴充套件已經是現成的，唯一要注意的，可以提前準備各類服務的映象，需要擴充套件的時候，直接生成一臺虛機，啟動對應伺服器。如果有自動化指令碼更好，生成機器後，可以做到一鍵到位。
按服務拆分Redis，並利用redis-sentinel保證高可用
為每一個微服務建立獨立的Redis快取服務例項，資料量和訪問量比較大的服務更是如此，避免相互影響。
Redis-Sentinel在這裡多說兩句，RS是Redis官方推薦的高可用性(HA)解決方案，當用Redis做Master-slave的高可用方案時，假如master當機了，Redis本身(包括它的很多客戶端)都沒有實現自動進行主備切換，而Redis-sentinel本身也是一個獨立執行的程式，它能監控多個master-slave叢集，發現master當機後能進行自動切換，選舉出master的多個slave中的一個來作為新的master,其它的slave節點會將它所追隨的master的地址改為被提升為master的slave的新地址。
這裡使用三臺伺服器，每臺伺服器上開啟一個redis-server和redis-sentinel服務，redis-server埠為6000，redis-sentinel的埠為6600.
redis-server
192.168.3.1:6000 主
192.168.3.2:6000 從
192.168.56.3:6000 從
redis-sentinel
192.168.3.1:6600
192.168.3.2:6600
192.168.3.3:6600
很多朋友或許會問，為什麼不直接考慮採用Redis Cluster，Twemproxy或者Codis這樣的方案。從本人過去的經驗看，如果你的業務量沒有到一定程度或團隊沒有精力去給他們打Patch二次開發，那就先用好Redis單機的主從方案，可用性反而更高。
Mysql 垂直分庫+水平分庫
關於垂直分庫的方案，之前已經寫過一篇文章闡述了，大家可以點選這裡參考一下。
今天，我們在這裡多闡述一下水平分庫的方案。水平分庫這件事，可以很粗糙，也可以很細緻。比方說，我們對於訂單庫，按照2016年之前的資料的資料匯入到另外一個庫，較新的資料繼續保留在原庫，畢竟1年前的訂單查詢是少數，然後，將資料庫的選擇放到業務程式碼中取控制，每次查詢，業務程式碼通過查詢時間來進行表選擇和資料整合。
但如果想把這件事，做得更細更合理，上面的粗糙的做法遠遠不夠用，那麼我們還是需要找到更加細緻的方案的。所幸的是，國內外的各家已經為我們造了很多輪子了，不需要我們再花力氣去造。在這裡，我也將我個人過去做過的一個調研方案和大家分享一下：
簡單來說，水平分庫分表的開源方案可以分為兩種型別，基於Library 包 和 Proxy 服務。Library目前發展比較好的還是Mysql官方的Fabric專案，一直都在優化和更新中。不過由於是非開源專案，所以很多具體的細節尚不清楚，主要基於官方文件處理。
對於Proxy方式的多個開源專案中，目前個人比較看好的還是MyCAT，主要原因是基於Cobar，起點就比較高，而且社群一直很活躍。
(插圖來源於MyCAT)
總結
通過將微服務架構從前到後各層中介軟體擴充套件方案的梳理，可以發現目前社群已經有了很多成熟的方案，大家可以根據各自業務的實際情況，進行分步實施，讓你的架構輕鬆擴充套件便可FreeStyle。:)
掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes
歡迎轉載，帶上以下二維碼即可
