【51CTO.com原創稿件】 業務驅動技術的發展是亙古不變的道理。最開始的時候，業務量少，業務復雜度低，采取的技術也相對簡單，基本滿足用戶對功能的需求。

[[317717]]

圖片來自 Pexels

隨著 IT 信息化的普及，更多的交易放到了網絡上，信息量增加和訪問次數頻繁就是要解決的問題了。

因此，逐漸加入了緩存、集群等技術手段。同時對業務的擴展性和伸縮性的要求也越來越高。

高并發、高可用、可伸縮、可擴展、夠安全的軟件架構一直是架構設計追求的目標。

今天我們來看一下架構設計經歷了哪些階段，每個階段都解決了哪些問題，又引出了哪些新問題。

主要是引起大家的思考，在不同的業務發展階段采取合適技術手段，用變化擁抱變化是 IT 人追求的目標。

應用與數據一體模式

最早的業務應用以網站、OA 等為主，訪問的人數有限，單臺服務器就能夠應付。

通常，將應用程序和數據庫部署到一臺服務器上面，如圖 1 所示：

圖 1：應用與數據一體模式

在這一階段，我們利用 LAMP(Linux Apache MySQL PHP)技術就可以迅速搞定，并且這些工具都是開源的。

很長一段時間內，有各種針對這種應用模式的開源代碼可以使用。這種模式基本上沒有高并發的要求，可用性也很差。

有的服務器采用托管模式，上面就安裝了不同的業務應用，一旦服務器出現問題，所有的應用就罷工了。

不過其開發和部署成本相對較低，適合剛剛起步的應用服務。圖 1 就描述了單個應用和數據庫運行在單臺服務器的模式，我們稱這種模式為應用與數據一體模式。

應用與數據分離模式

隨著業務的發展，用戶數和請求數逐漸上升，服務器的性能出現了問題。其中比較簡單的解決方案就是增加資源，將業務應用和數據存儲分開。

其架構圖如圖 2 所示：

圖 2：應用與數據分離模式

其中，應用服務器需要處理大量的業務請求，對 CPU 和內存有一定要求;而數據庫服務器需要對數據進行存儲和索引等 IO 操作，對磁盤的轉速和內存會考慮更多。

這樣的分離解決了性能的問題，我們需要擴展更多的硬件資源讓其各司其職，使系統可以處理更多的用戶請求。

雖然業務上依舊存在耦和，但硬件層面的分離在可用性上比一體式設計要好很多。

緩存的加入

隨著信息化系統的發展和使用互聯網人數的增多，業務量、用戶量、數據量都在增長。

我們同時發現，用戶會對某些數據的請求量特別大，例如新聞、商品信息和熱門消息。

之前這些信息的獲取方式是依靠數據庫，因此受到數據庫 IO 性能的影響。此時數據庫成為了整個系統的瓶頸。

如果再增加服務器的數量，恐怕也很難解決，于是緩存技術就登場了，其架構圖如圖 3 所示：

圖 3：緩存的加入

這里提到的緩存技術分為客戶端瀏覽器緩存、應用服務器本地緩存和緩存服務器緩存。

①客戶端瀏覽器緩存：當用戶通過瀏覽器請求服務器的時候，會發起 HTTP 請求。如果對每次 HTTP 請求進行緩存，那么可以減少應用服務器的壓力。

②應用服務器本地緩存：它使用的是進程內緩存，又叫托管堆緩存。以 Java 為例，這部分緩存放在 JVM 的托管堆上面，同時會受到托管堆回收算法的影響。

由于它運行在內存中，對數據的響應速度很快，通常我們會把熱點數據放在這里。

在進程內緩存沒有命中的時候，會到緩存服務器中獲取信息，如果還是沒有命中，才會去數據庫中獲取。

③緩存服務器緩存：它相對于應用服務器本地緩存來說，就是進程外緩存，既可以和應用服務部署在同一服務器，也可以部署到不同的服務器。

一般來說，為了方便管理和合理利用資源，會將其部署到專門的緩存服務器上面。由于緩存會占用內存空間，因此這類服務器會配置比較大的內存。

圖 3 描述了緩存請求的次序，先訪問客戶端緩存，之后是進程內的本地緩存，接下來是緩存服務器，最后才是數據。

如果在任意一層獲取了緩存信息，就不再往下訪問了，否則會一直按照這個次序獲取緩存信息，直到數據庫。

用戶請求訪問數據的順序為客戶端瀏覽器緩存→應用服務器本地緩存→緩存服務器緩存。

如果按照以上次序還沒有命中數據，才會訪問數據庫獲取數據。加入緩存的設計，提高了系統的性能。

由于緩存放在內存中，而內存的讀取速度比磁盤要快得多，能夠很快響應用戶請求。

特別針對一些熱點數據，優勢尤為明顯。同時，在可用性方面也有明顯的改善。

即使數據庫服務器出現短時間的故障，緩存服務器中保存的熱點或者核心數據依舊可以滿足用戶暫時的訪問。當然，后面還會對可用性進行優化。

服務器集群的加入

經過前面三個階段的演進，系統對用戶的請求量有了很好的支持。實際上，這都是在解決高性能和可用性的問題，這一核心問題會一直貫穿整個系統架構的演進過程中。

隨著用戶請求量的增加，另外一個問題又出現了，那就是并發。把這兩個字拆開了來看：并，理解為“一起并行“，有同時的意思;發，理解為“發出調用”，也就是請求的意思。

合起來就是多個用戶同時請求應用服務器。如果說原來的系統面對的僅僅只是大數據量的話，那么現在就需要面對多用戶同時請求。

如果還是按照上一個階段的架構圖推導，單個應用服務器已經無法滿足高并發的要求了。

此時，服務器集群就加入戰場了，其架構圖如圖 4 所示：

圖 4：服務器集群的加入

服務器集群也就是多臺服務器扎堆的意思，用更多的服務器來分擔單臺服務器的負載壓力，提高性能和可用性。

再說白一點，就是提高單位時間內服務處理請求的數量。原來是一個服務器處理，現在是一堆服務器來處理。就好像銀行柜臺一樣，增加柜員的人數來服務更多的人。

這次架構演進與上次相比，增加了應用服務器的個數，用多臺應用服務器形成集群。

應用服務器中所部署的應用服務沒有改變，在用戶請求與服務器之間加入了負載均衡器，幫助用戶請求路由到對應的服務器中。增加服務器的舉動表明，系統的瓶頸是在處理用戶并發請求上。

針對數據庫和緩存都沒有做更改，這樣僅僅通過增加服務器數量就能夠緩解請求的壓力。

服務器集群會通過多臺服務器來分擔原來一臺服務器需要處理的請求，在多臺服務器上同時運行一套系統，因此可以同時處理大量并發的用戶請求。

有點三個臭皮匠頂個諸葛亮的意思，因此對集群中單個服務器的硬件要求也會降低。此時需要注意負載均衡均衡的算法，例如輪詢和加權輪詢。

我們要保證用戶請求能夠均勻分布到服務器上面，同一個會話的請求保證在同一個服務器上面處理，針對不同服務器資源的優劣動態調整流量。

負載均衡器加入之后，由于其位于互聯網與應用服務器之間，負責用戶流量的接入，因此可以對用戶流量進行監控，同時對訪問用戶的身份和權限進行驗證。

數據庫讀寫分離

加入緩存可以解決部分熱點數據的讀取，但緩存數據的容量有限，那些非熱點的數據依舊會從數據庫中讀取。數據庫對于寫入和讀取的性能是不一樣的。

在寫入數據的時候，會造成鎖行或者鎖表，此時如果有其他寫入操作并發執行，會存在排隊現象。

而讀取操作比寫入操作更加快捷，并且可以通過索引、數據庫緩存等方式實現。

因此，推出了數據庫讀寫分離的方案，其架構圖如圖 5 所示：

圖 5：數據庫讀寫分離

此時設置了主從數據庫，主庫(master)主要用來寫入數據，然后通過同步 binlog 的方式，將更新的數據同步到從庫(slave)中。

對于應用服務器而言，在寫數據的時候只需要訪問主庫，在讀數據的時候只用訪問從庫就好了。

利用數據庫讀寫分離的方式，將數據庫的讀/寫職責分離。利用讀數據效率較高的優勢，擴展更多的從庫，從而服務于讀取操作的用戶請求。畢竟在現實場景中，大多數操作都是讀取操作。

此外，從數據同步技術的角度來說，又可以分為同步復制技術、異步復制技術和半同步復制技術。在數據庫讀寫分離帶來益處的同時，架構也需要考慮可靠性的問題。

例如，主庫如果掛掉，從庫如何接替主庫進行工作。主庫在恢復以后，是成為從庫還是繼續擔當主庫，以及如何同步數據的問題。

反向代理與 CDN

隨著互聯網的逐漸普及，人們對網絡安全和用戶體驗的要求也越來越高。之前用戶都是通過客戶端直接訪問應用服務器獲取服務，應用服務器會暴露在互聯網中，容易遭到攻擊。

如果在應用服務器與互聯網之間加上一個反向代理服務器，它接收用戶的請求，然后再轉發到內網的應用服務器，充當外網與內網之間的緩沖。

反向代理服務器只是做請求的轉發，在它上面沒有運行任何應用，因此當有人攻擊它的時候，是不會影響到內網的應用服務器的。

這無形中保護了應用服務器，提高了安全性。同時，它也在互聯網與內網之間起到適配和網速轉換的作用。

例如，應用服務器需要服務公網和教育網，但是兩個網絡的網速不同，可以在應用服務器與互聯網之間放上兩臺反向代理服務器，一臺連接公網，另一臺連接教育網，屏蔽網絡差異，服務于更多的用戶群體。

如圖 6，公網客戶端和校園網客戶端分別來自公網與校園網兩個不同的網絡：

圖 6：加入反向代理服務器

由于兩個網絡訪問速度不同，因此會針對兩個網絡分別設置共網代理服務器和校園網代理服務器，通過這種方式將位于不通網絡的用戶請求接入到系統中。

聊完反向代理，再來說說 CDN，它的全稱是 Content Delivery Network，也就是內容分發網絡。

如果把互聯網想象成一張大網的話，每個服務器或者客戶端就是分布式在網中的一個節點。

節點之間的距離有遠有近，用戶請求會從一個節點跳轉到另外一個節點，最終跳轉到應用服務器獲取信息。

如果跳轉的次數越少，就能夠更快地獲取信息，因此可以在離客戶端近的節點存放信息。

這樣用戶通過客戶端，只需要較少的跳轉次數就能夠觸達信息。由于這部分信息更新頻率不高，推薦存放一些靜態數據，例如 JavaScript 文件、靜態的 HTML、圖片文件等。

這樣客戶端就可以從離自己最近的網絡節點獲取資源，大大提高了用戶體驗和傳輸效率。

加入 CDN 后的架構圖如圖 7 所示：

圖 7：加入 CDN

CDN 的加入明顯加快了用戶訪問應用服務器的速度，同時也減輕了應用服務器的壓力，原來必須直接訪問應用服務器的請求，不用經過層層網絡，而只用找到最近的網絡節點就可以獲取資源。

但從請求資源的角度上來看，這種方式也有局限性，它只能對靜態資源起作用，需要定時對 CDN 服務器進行資源更新。反向代理和 CDN 的加入解決了安全性、可用性和高性能的問題。

分布式數據庫與分表分庫

經歷前面幾個階段以后，軟件的系統架構相對趨于穩定。隨著系統運行時間的增加，數據庫中累積的數據越來越多，同時系統還會記錄一些過程數據，例如操作數據和日志數據，這些數據也會加重數據庫的負擔。

即便數據庫設置了索引和緩存，但在海量數據查詢的時候還會捉襟見肘。如果說讀寫分離，是將數據庫從讀寫層面進行資源分配，那么分布式數據庫就需要從業務和數據層面對資源進行分配。

①對于數據表來說，當表中包含的記錄過多時，會將其分成多張表來存儲。

例如：有 1000 萬個會員記錄，就可以將其分成兩個 500 萬，分別放到兩個表中存儲。

也可以按照業務將表中的列進行分割，把表中的某些列放到其他表中存儲，然后通過外鍵關聯到主表，被分割出去的列通常是不經常訪問的數據。

②對于數據庫來說，每個數據庫能夠承受的最大連接數和連接池是有上限的。為了提高數據訪問效率，會根據業務需求對數據庫進行分割，讓不同的業務訪問不同的數據庫。當然，也可以將相同業務的不同數據放到不同的庫中存儲。

如果將這些數據庫資源分別放到不同的數據庫服務器中，就是分布式數據庫設計了。

由于數據存儲在不同的表/庫中，甚至在不同的服務器上面，在進行數據庫操作的時候會增加代碼的復雜度。此時可以加入數據庫中間件來消除這些差異。

圖 8：分布式數據庫與分表分庫

架構如圖 8 所示，將數據拆分以后分別放在表 1 和表 2 中，兩張表所在的數據庫服務器也各不相同，庫與庫之間還需要考慮數據同步的問題。

由于數據的分散部署，要從業務應用獲取數據就需要依靠數據庫中間件幫忙。

數據庫的分表分庫以及分布式設計，會帶來性能的提升，同時也增大了數據庫管理和訪問的難度。原來只用訪問一張表和一個庫，現在需要跨越多張表和多個庫。

從軟件編程的角度來看，有一些數據庫中間件提供了最佳實踐，例如 MyCat 和 Sharding JDBC。

此外，從數據庫服務器管理的角度來看，需要監控服務器的可用性。從數據治理的角度來看，需要考慮數據擴容和數據治理的問題。

業務拆分

當解決大數據量存儲問題以后，系統就能夠存儲更多的數據，這意味著能夠處理更多的業務。

業務量的增加，訪問數的上升，是任何一個軟件系統在任何時期都要面臨的嚴峻考驗。

通過前面幾個階段的學習，我們知道系統提升基本依靠空間換取時間，使用更多的資源和空間處理更多的用戶請求。

隨著業務的復雜度越來越高，以及高并發的來臨，一些大廠開始將業務系統進行切分，分開部署。

此時的架構圖如圖 9 所示：

圖 9：業務拆分

如果說前面的服務器集群模式是將同一個應用復制到不同的服務器上，那么業務拆分就是將一個應用拆成多個部署到不同的服務器中。

此外，還可以對核心應用進行水平擴展，將其部署到多臺服務器上。應用雖然做了拆分，但應用之間仍舊有關聯，存在應用之間的調用、通信和協調問題。

由此也會引入隊列、服務注冊發現、消息中心等中間件，它們可以協助系統管理分布到不同服務器、網絡節點上的應用。

業務拆分以后會形成一個個應用服務，既有基于業務的服務，例如商品服務、訂單服務，也有基礎服務，例如消息推送和權限驗證。

這些應用服務連同數據庫服務器分布在不同的容器、服務器、網絡節點中，對它們的通信、協調、管理和監控都是我們需要解決的問題。

分布式與微服務

近幾年，微服務是比較火的架構方式，它將業務應用進行更加精細化的切割，使之成為更加小的業務模塊。

做到模塊的高內聚低耦合，每個模塊可以獨立存在，由獨立的團隊維護。每個模塊內部可以采取特有的技術，而不用關心其他模塊的技術實現。

模塊通過容器的部署運行，模塊之間通過接口和協議進行調用。任何一個模塊都可以將自己公開給其他的模塊調用。

同時可以將熱點模塊進行水平擴展，增強系統的性能。當其中某一個模塊出現問題時，又可以由其他相同的模塊代替其工作，增強了可用性。

大致總結下來，微服務擁有以下特點，業務精細化拆分、自治性、技術異構性、高性能、高可用。

它像極了分布式架構，下面來看看它們的區別，如圖 10 所示：

圖 10：分布式與微服務的區別

從概念上理解，它們都做了“拆”的動作，但在下面這幾個方面存在區別：

①拆分目的不同：分布式設計是為了解決單體應用資源有限的問題，在一個服務器上無法支撐更高的用戶訪問，因此將一個應用拆解成不同的部分，然后將其部署到不同服務器上，從而分擔高并發的壓力。

微服務是對服務組件進行精細化，目的是更好地解耦，讓服務之間通過組合完成高性能、高可用、可伸縮、可擴展。

②拆分方式不同：分布式服務架構將系統按照業務和技術分類進行拆分，目的是讓拆分的服務負載原來單一服務的業務。

微服務則是在分布式的基礎上進行更細的拆分，它將服務拆成更小的模塊，更加專業化，分工更加精細，并且每個小模塊都可以獨立運行。

③部署方式不同：分布式將服務拆分以后，通常會部署到不同的服務器上。

而微服務也可以將不同的服務模塊放到不同的服務器上，同時它也可以在一個服務器上部署多個微服務，或者同一個微服務的多個備份，并且多使用容器的方式部署。

雖然分布式與微服務有以上區別，但從實踐的角度來看，它們都是基于分布式架構的思想構建的。

微服務是分布式的進化版本，也是分布式的子集。它同樣會遇到服務拆分、服務通信、協同、管理調度等問題。

總結

本文按照技術跟隨業務變化的思路，描述從單體架構到集群，再到分布式架構以及微服務的發展階段，講述了每個軟件架構階段變化的特點，前后架構更替的原因和關系，說明了軟件架構發展會一直隨著業務發展的方向變化。遵循高性能，高可用，伸縮性，擴展性，安全性的架構目的。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】