摘要：但是假如我們單純的把數(shù)據(jù)庫一分為二，然后對(duì)于后續(xù)數(shù)據(jù)庫的請(qǐng)求，分別負(fù)載到兩臺(tái)數(shù)據(jù)庫服務(wù)器上，那么一定會(huì)造成數(shù)據(jù)庫不統(tǒng)一的問題。

前言

隨著計(jì)算機(jī)系統(tǒng)規(guī)模變得越來越大，將所有的業(yè)務(wù)單元集中部署在一個(gè)或若干個(gè)大型機(jī)上的體系架構(gòu)，已經(jīng)越來越不能滿足當(dāng)今計(jì)算機(jī)系統(tǒng)。同時(shí)，隨著微型計(jì)算機(jī)的出現(xiàn)，越來越多廉價(jià)的PC機(jī)成為了各大企業(yè)IT架構(gòu)的首選，分布式的處理方式越來越受到業(yè)界的青睞。本文將介紹分布式架構(gòu)的發(fā)展歷史和分布式架構(gòu)的一些相關(guān)概念。

下面以一個(gè)簡單的電商系統(tǒng)為例，當(dāng)數(shù)據(jù)量、訪問量提升，觀察這個(gè)系統(tǒng)可能會(huì)發(fā)生的結(jié)構(gòu)變化。假如我們系統(tǒng)具備以下功能：用戶模塊（用戶注冊和管理），商品模塊（商品展示和管理），交易模塊（創(chuàng)建交易及支付結(jié)算）。

一、單應(yīng)用架構(gòu)

網(wǎng)站的初期也可以認(rèn)為是互聯(lián)網(wǎng)發(fā)展的早起，我們經(jīng)常會(huì)在單機(jī)上跑我們所有的程序和軟件。把所有軟件和應(yīng)用都部署在一臺(tái)機(jī)器上，這樣就完成一個(gè)簡單系統(tǒng)的搭建，這個(gè)時(shí)候的講究的是效率。

二、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器分離

隨著網(wǎng)站的上線，訪問量逐步上升，服務(wù)器的負(fù)載慢慢提高，在服務(wù)器還沒有超載的時(shí)候，我們應(yīng)該做好規(guī)劃，提升網(wǎng)站的負(fù)載能力。假如代碼層面的優(yōu)化已經(jīng)沒辦法繼續(xù)提高，在不提高單臺(tái)機(jī)器的性能，增加機(jī)器是一個(gè)比較好的方式，投入產(chǎn)出比非常高。這個(gè)階段增加機(jī)器的主要目的是將web 服務(wù)器和數(shù)據(jù)庫服務(wù)器拆分，這樣不僅提高了單機(jī)的負(fù)載能力，也提高了容災(zāi)能力。

三、應(yīng)用服務(wù)器集群

隨著訪問量的繼續(xù)增加，單臺(tái)應(yīng)用服務(wù)器已經(jīng)無法滿足需求。在假設(shè)數(shù)據(jù)庫服務(wù)器還沒有遇到性能問題的時(shí)候，我們可以增加應(yīng)用服務(wù)器，通過應(yīng)用服務(wù)器集群將用戶請(qǐng)求分流到各個(gè)服務(wù)器中，從而繼續(xù)提升負(fù)載能力。此時(shí)多臺(tái)應(yīng)用服務(wù)器之間沒有直接的交互，他們都是依賴數(shù)據(jù)庫各自對(duì)外提供服務(wù)。

架構(gòu)發(fā)展到這個(gè)階段，各種問題也會(huì)慢慢呈現(xiàn)，比如用戶請(qǐng)求由誰來轉(zhuǎn)發(fā)到具體的應(yīng)用服務(wù)器，這時(shí)候可能會(huì)出現(xiàn)下面的架構(gòu)模型。

四、數(shù)據(jù)庫讀寫分離

當(dāng)數(shù)據(jù)庫壓力變大時(shí)，那么怎么去提高數(shù)據(jù)庫層面的負(fù)載呢？有了前面的思路以后，自然會(huì)想到增加服務(wù)器。但是假如我們單純的把數(shù)據(jù)庫一分為二，然后對(duì)于后續(xù)數(shù)據(jù)庫的請(qǐng)求，分別負(fù)載到兩臺(tái)數(shù)據(jù)庫服務(wù)器上，那么一定會(huì)造成數(shù)據(jù)庫不統(tǒng)一的問題。所以我們一般先考慮讀寫分離的方式。

五、使用搜索引擎緩解讀庫的壓力

數(shù)據(jù)庫做讀庫的話，常常對(duì)模糊查找效率不是特別好，像電商類的網(wǎng)站，搜索是非常核心的功能，即便是做了讀寫分離，這個(gè)問題也不能有效解決。那么這個(gè)時(shí)候可以引入搜索引擎，使用搜索引擎能夠大大提高我們的查詢速度。

六、引入緩存機(jī)制緩解數(shù)據(jù)庫的壓力

隨著訪問量的持續(xù)增加，逐漸出現(xiàn)許多用戶訪問同一部分內(nèi)容的情況。對(duì)于這些熱點(diǎn)數(shù)據(jù)，沒必要每次都從數(shù)據(jù)庫去讀取，我們可以使用緩存技術(shù)，比如memcache、redis 來作為我們應(yīng)用層的緩存；另外在某些場景下，比如我們對(duì)用戶的某些IP 的訪問頻率做限制，那這個(gè)放內(nèi)存中又不合適，放數(shù)據(jù)庫又太麻煩，這個(gè)時(shí)候可以使用Nosql 的方式比如mongDB 來代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫。

七、數(shù)據(jù)庫的水平/垂直拆分

我們的網(wǎng)站演進(jìn)的變化過程，交易、商品、用戶的數(shù)據(jù)都還在同一個(gè)數(shù)據(jù)庫中，盡管采取了增加緩存，讀寫分離的方式，但是隨著數(shù)據(jù)庫的壓力持續(xù)增加，數(shù)據(jù)庫的瓶頸仍然是個(gè)最大的問題。因此我們可以考慮對(duì)數(shù)據(jù)的垂直拆分和水平拆分。

垂直拆分：把數(shù)據(jù)庫中不同業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫。

水平拆分：把同一個(gè)表中的數(shù)據(jù)拆分到兩個(gè)甚至更多的表中。

八、應(yīng)用的拆分

隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)越來越多，應(yīng)用的壓力越來越大，工程規(guī)模也越來越龐大。這個(gè)時(shí)候就可以考慮將應(yīng)用拆分，按照領(lǐng)域模型將系統(tǒng)拆成用戶、商品、交易子系統(tǒng)。

這樣拆分以后，可能會(huì)有一些相同的代碼，比如用戶操作，在商品和交易都需要查詢，所以會(huì)導(dǎo)致每個(gè)系統(tǒng)都會(huì)有用戶查詢訪問相關(guān)操作。這些相同的操作一定是要抽象出來，可以通過服務(wù)化的方式來解決。

九、服務(wù)化

服務(wù)拆分以后，各個(gè)服務(wù)之間可以通過RPC 技術(shù)進(jìn)行通信，比較典型的有：webservice、hessian、http、RMI等。

感謝您耐心看完的文章

順便給大家推薦一個(gè)Java技術(shù)交流群：710373545里面會(huì)分享一些資深架構(gòu)師錄制的視頻資料：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化、分布式架構(gòu)等這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多！