網際網路基礎架構（網際網路架構的演變）

2023-05-17 10:10:22

從過去的 OA、CRM、ERP 等單機即可滿足要求的系統到現代網際網路時代各大公司的分布式、微服務平臺，網際網路架構正在經歷著巨大的變革，技術也在不斷的更新迭代。

圖片來自 Pexels

這也意味著眾多軟體開發者們的壓力和挑戰正在不斷的加大，這種新技術更新的速度甚至讓我們望而卻步。

而我們需要做的恐怕不僅僅是學習那麼簡單了，更要從宏觀的角度根據當前的技術形勢及時做出更符合我們發展前景的決定。

這篇文章作者會跟大家一起探究網際網路架構的演變歷程，並對每個歷程中的相關技術及應用做出合理的解釋。

希望各位也能參考架構的這些發展過程，結合自己當前的項目架構有一個適當的定位，同時對自己未來應該學習的東西做出明確的計劃和安排。

架構演變

大型網際網路公司系統的業務模塊、技術分布非常複雜，但是架構和技術永遠都不是架構師設計出來的，而是跟隨公司業務的發展不斷進行升級演變出來的，廢話不多說請聽胖達娓娓道來。

①單機構建系統

這個不用多說，剛開始接觸 Java 的同學應該都非常清楚，做畢設或者平時練手最多的圖書館小項目基本都是這種架構。

一個簡單的應用，配置一下資料庫連接，然後部署到自己電腦的 Tomcat 伺服器上，啟動之後興奮的不得了。

②Nginx 負載均衡 伺服器集群

試想一下，如果我們一時興起做了一個個人博客並且部署到了我們的伺服器上，採用的是單機的構建方式。

後來因為博客質量高竟然火了，訪問量快速增加，單臺伺服器已經無法滿足我們的需求，時不時的就有粉絲抱怨博客沒法訪問了，是不是很頭疼?

穩住，這波不慌，這個時候我建議首先想想如何給那臺可憐的伺服器洩洩火，讓伺服器的壓力降下來。

有一個辦法就是給它加一個或者多個夥伴一塊來分攤下壓力，把這麼多請求分散到每個夥伴身上，從而提高這種負載的能力。

但是夥伴是有了，一系列的問題也就來了，我整理了一下，統一回答如下：

問題一：這麼多夥伴，應該識別什麼樣的指令來接收用戶的請求呢?

其實完全不用擔心夥伴們識別什麼樣的指令，只要讓它傻傻的站在那等待分配就可以了，因為有一種東西叫做負載均衡器，專門給伺服器分配這種請求。

如果你不知道 F5，那你應該知道 Nginx，土豪錢多的公司一般會選擇前者這種硬體負載均衡器。

但是大多數網際網路公司會選擇後者，因為能從軟體的角度解決的問題為啥用硬體呢，誰不想省錢啊?

了解 Nginx，必須要知道它的三種功能：

反向代理：了解反向代理，首先要清楚什麼是正向代理，相信大家訪問國外的學習資源例如某 Hub(你懂的)的時候都用過 FQ 軟體 -VPN，這種通過 VPN 訪問谷歌、Youtube 等國外網站的過程中，我們知道我們的訪問目標伺服器是什麼，這其實就是正向網絡代理。

而反向代理則不同，就像我們上圖中所看到的多臺伺服器，如果經過反向代理，那我們其實並不知道實際訪問的伺服器是哪一臺。

因為我們的請求被前面架設的 Nginx 自動分配給了某一臺伺服器，就比如說我們打 10086 人工客服，你一定記得「你好先生，我是 10011 號話務員，很高興為您服務」這樣的話。

我們在打電話的時候並不知道由哪一個話務員來為我們服務，這些分配過程都是由 10086 服務臺自動進行的，這裡的 10086 服務臺其實就是我們系統中的反向代理伺服器，也即圖中的 Nginx。

動靜分離：在做 Web 開發的時候大家都清楚，JS、HTML、圖片資源、文件資源這些都屬於靜態資源，供用戶直接訪問，並不需要編譯或者解釋，是一些放在那裡就可以用的東西。

而 JSP、Java 文件這些東西其實都需要被 Tomcat 伺服器解釋一遍才能被機器識別，但是如果把它們都放在一起供用戶訪問，那每臺伺服器的壓力豈不是很大?

這個時候我們就可以做動靜的分離，將這些靜態的文件放置到 Nginx 伺服器上，後面的 Tomcat 伺服器用來放動態的 JSP、Java 文件，這樣的話就變向的給伺服器降低了壓力。

負載均衡：這個很明顯了，簡單來說，通過架設 Nginx 伺服器，經過一定的均衡算法將用戶的請求合理分發給後面的伺服器。

這個過程很好的降低了請求負載，讓每一臺伺服器都能舒舒服服的承載請求，做好自己的工作。

問題二：能確定夥伴之間公平分散請求嗎?

這個問題就具體到了 Nginx 的均衡算法問題，只有通過合適的算法均衡用戶請求到每臺伺服器上才能保證伺服器不打架不撂挑子，否則其中某臺伺服器不高興突然間罷工，剩下的伺服器可就遭殃了。

其實 Nginx 均衡算法總共有十種，但是常用的一般是下面幾種：

LC 算法(最近最少使用連接算法)：這種算法的規則就是判斷哪一臺伺服器一定時間段內的連接數比較少，就把用戶請求分發給它，其實就是誰的活少分配給誰，不能讓他太閒也不能讓其他伺服器太忙，否則就會掐架了。

輪詢算法：輪詢這種算法還是比較公平的，類似我們上學的時候排了一張值日表，周一的時候是小紅，周二的時候是小明等等等等，這樣就把活平均分配給了每一個人也即每一臺伺服器。

IP_HAsh 算法：這種算法是通過 IP 取模的方式制定伺服器，首先通過 IP 欄位轉換成 Hash 值，將取到的 Hash 值與負載伺服器的總數取模，按照模值獲取負載 IP 列表中的伺服器，最終確定是哪一臺伺服器來承載這次請求。

這種方式因為 IP 的 Hash 值一致性原因，每一臺 IP 訪問的都是固定的伺服器，用的是同一臺伺服器上的 Session，從而解決了 Session 一致性的問題。

問題三：這麼多伺服器怎麼返回用戶的請求呢?

這個問題換一種問法就是通過什麼樣的集群搭建模式來處理網絡問題，常用的包括下面幾種：

NAT 模式：也稱為網絡地址傳輸模式，用戶在實際訪問項目的時候實際上並不是直接去訪問 Tomcat 伺服器，而首先要經過第一臺 Nginx 伺服器。

但是這臺伺服器的 IP 是虛擬 IP，真實要訪問的 IP 其實是後面的 Tomcat 伺服器 IP。

那麼在這一步就需要根據均衡算法在配置中取出後面 Tomcat 伺服器的真實 IP 並做網絡跳轉，已達到訪問的目的。

在返回用戶請求的時候，也是如此，必須通過 Tomcat 伺服器的網絡跳轉訪問到 Nginx，繼而將請求返回到用戶方。

DR 模式：也稱為直接路由模式，這種方式相較於 NAT 模式有一個區別就是在返回用戶請求的時候，不再通過中間伺服器進行轉發，而是直接轉發給了用戶。

這樣做的目的其實也提高了網絡傳輸的速度，降低了 Nginx 伺服器的壓力。

問題四：用戶每次都去跟不一樣的夥伴勾兌，這次找夥伴 1，下次找夥伴 2，那怎麼保證 Session 一致呢?

這種情況是做負載均衡經常遇到的一個問題，如果不做處理，經常會遇到 Session 丟失的問題，處理這個問題一般有下面幾種方法：

IP_Hash 算法固定 Session：就像上面均衡算法所說的，通過 IP 的 Hash 值取模，固定訪問某臺伺服器。

這樣就確保了用戶的 Session 每次訪問都保存在同一臺伺服器上，不會出現找不到的現象，從而實現 Session 一致性。

Session廣播：也稱為 Session 複製，就是指每個用戶登錄之後，只要是訪問了我的伺服器記錄了 Session，就會把 Session 的信息在所有的伺服器上複製一份。

這樣就能保證每臺伺服器都包含這個用戶的 Session，當然這也是非常浪費的。

Session 持久化：就是將 Session 的信息保存到資料庫、文件或者內存中，用這種持久化的方式將其保存到一臺公共伺服器上。

這樣就能確保了 Session 一致性，而我們一般採用的方式就是將其保存到 Redis 中，方便存取而且內存讀取的效率很高。

客戶端存儲：基於 Cookie 實現，將 Session 直接存儲到 Cookie 中，這種方案其實不是很安全，雖然能夠做到加密，但是道高一尺魔高一丈，總會有方法破解，而且 Cookie 最多只能為 4K，大小受到限制。

上面講到的這種架構方式，確實能夠短期內解決個人博客訪問量激增帶來的問題，但是有沒有想過一個問題，Nginx 也是一臺伺服器，如果他掛了怎麼辦?還有誰能來給我們分配任務呢?難道讓這些夥伴乾瞪眼嘛?

這種情況引出了一個面試題：如何避免單點故障?不慌，接著來看下一種方案。

③HA 高可用 負載均衡 伺服器集群

想要解決這種問題，大家一定可以想到，再加一臺 Nginx 不就行了嘛?

沒錯，引入 HA 高可用就能解決這個問題，HA 高可用是目前企業防止核心計算機系統因故障停機的最有效手段，但是如何實現這種高可用讓兩臺 Nginx 互相切換呢?

下面還需要了解兩個新鮮的技術：LVS KeepAlived。

LVS 實現負載均衡：看到這個小標題，有人可能要噴我，說你都用了 Nginx 做了負載均衡了，為啥還要用 LVS 這種東西呢?

別著急首先了解下LVS：LVS 的英文全稱是 Linux Virtual Server，即 Linux 虛擬伺服器。

它是由國防科大畢業的章文嵩博士開展的一個開源項目，在 Linux 內存 2.6 版本中已經成為內核的一部分。

LVS 主要用於多伺服器的負載均衡，工作在七層模型中的第四層網絡層，可以實現高性能，高可用的伺服器集群技術，並且可把許多低性能的伺服器組合在一起形成一個超級伺服器。

它的配置非常簡單，有多種負載均衡的方法，而且穩定可靠，即使在集群的伺服器中某臺伺服器無法正常工作，也不影響整體效果，另外它的可擴展性也非常好。

那麼這種解釋能解決疑惑嗎?當然不能，且看下面：

由於 LVS 屬於內核級別的優化，而且工作在網絡層，當做為負載均衡伺服器的 Nginx 和 LVS 處理相同的請求時，所有的請求和響應流量都會經過 Nginx。

但是使用 LVS 時，僅請求流量經過 LVS 的網絡，響應流量由後端伺服器的網絡返回。

這樣的話，如果有大量的請求出現，那因為帶寬問題，LVS 的效率就會有顯著的表現，Nginx 的瓶頸也就出現了。

但是僅僅使用 LVS 作為負載均衡的話，一旦後端接受到請求的伺服器出了問題，那麼這次請求就失敗了。

但是如果在 LVS 的後端在添加一個 Nginx(或者多個)，讓 Nginx 做動靜分離和反向代理，每個 Nginx 後端再有幾臺應用伺服器。

那麼結合兩者的優勢，既能避免單 Nginx 的流量集中瓶頸，又能避免單 LVS 時請求失敗的問題，何樂而不為呢?

KeepAlived 實現 HA 高可用：KeepAlived 從字面意思上來講就是保持活著，比如說我們兩臺 Tomcat 伺服器就是兩個小夥伴，兩個小夥伴商量著，要不然咱們一個人幹活一個人歇著。

但是時常的要互相詢問一句：「老鐵?你累嗎?還能行不?」，如果這個時候他回復還行，那麼我就安心玩我的就行了。

但是如果他一直沒搭理我，怎麼問怎麼不應聲，那它應該是累了，你是不是需要把他的活接過來啊，沒人幹肯定不行。

嚴肅點哈，KeepAlived 技術其實主要就是通過發送心跳包的方式，在每臺伺服器之間進行狀態偵查，如果發現有宕機或者停止運行的伺服器，立刻讓閒置伺服器運行起來實現主備複製和轉移。

當然這其中還需要一種容錯技術來將系統運行的狀態恢復到本應該有的狀態，避免因為某臺伺服器的宕機影響執行的結果。

④CDN 內容分發網絡 Varnish 伺服器集群

隨著個人博客用戶量的不斷提升，我們的項目雖然已經可以應付的了這麼多用戶量了，但是略微還有點慢，又或者有點卡。

而且還有一個問題，中國的網絡環境一般都是南方多用電信網絡，北方多用移動聯通的網絡，電信的網絡訪問聯通的網絡明顯能感覺的出來會特別卡。

如果我們的博客放到了北方的聯通網絡上，而大量的用戶來自於南方，對用戶來講豈不是很痛苦。

每次訪問的時候下載一些靜態資源都會特別的慢，時間久了，可能會損失大量的用戶。

如何解決這些卡、慢的問題呢，下面再來看幾種優化技術：

CDN 內容分發網絡：CDN 內容分發網絡是構建在網絡之上的內容加速器，依靠部署在各地的邊緣伺服器，通過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，降低網絡擁塞，提高用戶訪問響應速度和命中率。

也就是說，如果我們系統中有一個 jquery.min.js，直接放在我們北方的網通伺服器上，南方的用戶下載會特別的慢。

但是如果我們直接用某個高速 CDN 伺服器上的 Jquery 資源引入，那用戶下載的速度豈不是會快速提高，用戶體驗也會變得更好。

Varnish 伺服器集群：Varnish 這個詞很多人都很陌生，其實它就是一個 HTTP 加速器和反向代理伺服器，也是為了優化方案而引入的技術。

這種技術一般被應用在 Nginx 後面，在 Tomcat 的前面，主要用來優化 Nginx 的動靜分離功能。

之前提到將 HTML、JS 這些靜態的資源都放置到 Nginx 伺服器中，Java、JSP 等文件放置到 Tomcat 伺服器中。

這樣能夠更好的分攤 Tomcat 伺服器的壓力，但是這個地方還有優化的空間，想一想是否在開發過程中存在一些 JSP 文件、Java 文件基本上是不變的。

也就是說不管怎麼調用，這些東西短期內都是固定的，那我們能不能把這些文件也提出來，讓 Nginx 直接調用以降低 Tomcat 伺服器壓力呢?

答案是可以的，直接將一些短期內不變得文件配置進 Varnish 伺服器中即可。

⑤資料庫讀寫分離

之前的部分我們對 Tomcat 伺服器左側進行了優化，但是右側的資料庫還是孤零零的只有一臺。

這樣的話，個人博客項目還好只有讀操作，能夠應付得了，但是如果我們擴展業務，將博客做成了大型的博客平臺，有大量的用戶頻繁進行讀寫操作，那我們的資料庫還能應付嘛?

肯定需要優化了，首先我們會想到的就是把資料庫的讀寫進行分離。資料庫讀寫的分離一般需要設置主從資料庫，主庫只用來寫數據，從庫用來讀取數據。

而兩個資料庫之間則需要實現數據的同步，否則會出現數據差異，實現資料庫同步的方法有很多，MySQL 提供了一種方法是 Binlog，目前還是比較普遍的，具體的操作配置步驟這裡不再描述，以後有機會會嘗試寫寫。

⑥NOSQL 資料庫 分布式搜尋引擎

讀寫分離做完之後，過不了多久會發現，如此多的用戶讀寫數據，主從庫的壓力也在日益攀升，變得越來越大，那麼如何優化讀取、寫入數據的速度呢?

引入 Redis 資料庫：既然我們的 MySQL 資料庫讀寫壓力那麼大，那麼我們就在它的前面添加一層 NOSQL 內存資料庫作為盾牌。

Redis 作為常用的 NOSQL 資料庫一直以來深受大家的歡迎，而且因為是內存中讀寫數據，所以效率也是非常的高。

將它放到關係資料庫的前面，用來存放一些高頻率、熱點的常用搜索數據，能夠抵抗大量的搜索壓力。

這樣的話在讀寫分離，Redis 分攤壓力的情況下，MySQL 的資料庫壓力會大規模降低。

增加分布式搜尋引擎：你以為這就完了嗎，不，還不夠，為了優化搜索的速度，給用戶帶來更好的體驗效果，引入分布式搜尋引擎才是好的選擇，目前行業內使用廣泛的分布式搜尋引擎非 Elasticsearch 莫屬。

Elasticsearch 技術簡稱 ES，是一個基於 Lucene 的搜索伺服器。它提供了一個分布式多用戶能力的全文搜尋引擎，基於 RESTful Web 接口。

Elasticsearch 是用 Java 開發的，並作為 Apache 許可條款下的開放源碼發布，是當前流行的企業級搜尋引擎。

Elasticsearch 分布式搜尋引擎可以進行分布式實時文件存儲，並將每一個欄位都編入索引，使其可以被搜索，並且可以擴展到上百臺伺服器，處理 PB 級別的結構化或非結構化數據。

這樣的話我們就可以通過這種方式構建索引，再去查詢就更加減輕了關係資料庫的壓力。

⑦NOSQL 資料庫(HA) 分庫分表 MyCat

隨著博客平臺的發展，海量用戶的暴增，搜索類目的多樣性，用戶體驗的實時性，對網站提出了更高的要求，必須滿足高並發、高可用、高性能的要求才能繼續業務的發展。

對於我們程式設計師而言要做的仍然需要更新當前的架構技術，以面對更強大的衝擊和考驗，那麼我們還要如何優化我們的系統呢?第七個階段我們又要引入三種方案：

NOSQL 資料庫的 HA：通過在 MySQL 伺服器前面添加 Redis 伺服器確實能夠抵禦不少的對 MySQL 資料庫的讀寫壓力。

但是對於前面的盾牌來講，難道它就沒有壓力嗎，怎麼降低 Redis 伺服器的壓力呢?

首先我們會想到去配置 Redis 集群的方式加一臺或者幾臺伺服器，但是配置 Redis 集群其實經常會出現錯誤。

而且對於 Redis 集群來說，經常要求 Redis 伺服器可以自動擴容，為了解決這些問題更好的管理 Redis 集群，我們可以選擇引入分布式 Redis 解決方案。

前段時間 Redis 官方的 3.0 出了穩定版，3.0 就可以支持集群管理的功能。這裡選擇的是國產的分布式 Redis 解決方案-Codis。

Codis 是一個分布式 Redis 解決方案，對於上層的應用來說，連接到 Codis Proxy 和連接原生的 Redis Server 沒有明顯的區別。

上層應用可以像使用單機的 Redis 一樣使用，Codis 底層會處理請求的轉發，不停機的數據遷移等工作，所有後邊的一切事情，對於前面的客戶端來說是透明的，可以簡單的認為後邊連接的是一個內存無限大的 Redis 服務。

分庫分表：隨著業務的遞增，分庫分表的技術也需要運用到如此龐大的項目中，主要是因為各種業務表正在變得越來越大，例如用戶表、博客表等等。

你會想到如果每個業務表都能分開存放那該多好，添加多個資料庫伺服器，每個伺服器負責一塊業務表的維護管理。

資料庫 1 存放用戶數據，資料庫 2 存放博客信息，從而達到進一步細分資料庫的目的，而這種拆分資料庫的方式就叫做垂直拆分方式。

還有一種拆分方式是這樣的，比如說我們的用戶表數據量非常非常大，一張表數據達到了 8 千萬，那我們查詢讀取這張表的時候會不會特別慢。

即便你已經垂直拆分到了一個伺服器上進行管理，但是你仍然不能解決一張表 8 千萬的問題，那麼如何解決呢?

聰明的你會想到分表存放，這種方式就是水平拆分方式，將用戶表分成表 1、表 2、表 3......

通過這樣的方式你可以將這 8 千萬的用戶分到子表中，而具體的分表方式可以採用很多種方案，例如進行 ID 取模，具體方式由於篇幅問題不再描述。

MyCat：分庫分表之後，你會發現資料庫壓力真的變小了很多，但是也會有很多不方便的事情。

比如說：

這個時候你會用到分庫分表中間件 MyCat，它是一個徹底開源的，面向企業應用開發的大資料庫集群，支持事務、ACID、可以替代 MySQL 的加強版資料庫。

一個可以視為 MySQL 集群的企業級資料庫，用來替代昂貴的 Oracle 集群 ，一個融合內存緩存技術、NoSQL 技術、HDFS 大數據的新型 SQL Server，結合傳統資料庫和新型分布式數據倉庫的新一代資料庫中間件產品。

⑧分布式文件系統

在系統的發展過程中，會發現有一些圖片、視頻、Excel 等不同格式的大文件也需要做出處理。

比如說大型系統中的用戶頭像，8 千萬的用戶就需要有 8 千萬的頭像，每張頭像都需要佔用一定的存儲空間(一般來說 4K 到幾百 M 都有可能)。

那麼如何去處理這些文件的存儲呢?保存到資料庫中技術上完全可以，但是僅限於說說哈，如果實際這麼做了可能你的系統會面臨很大的壓力。

為了解決這種問題，就出現了分布式文件系統這樣的技術，典型比較通用的包括 MogileFS、FastDFS。

MogileFS 是一個開源的分布式文件存儲系統，是由 LiveJournal 旗下的 Danga Interactive 公司開發。

目前使用 MogileFS 的公司非常多，如日本排名靠前的幾個互聯公司以及國內的 Yupoo(又拍)、digg、豆瓣、大眾點評、搜狗等，分別為所在的組織或公司管理著海量的圖片。

以大眾點評為例，用戶全部圖片均有 MogileFS 存儲，數據量已經達到 500TB 以上。

FastDFS 是由阿里資料庫大神開發，是一個開源的輕量級分布式文件系統，它對文件進行管理。

功能包括：文件存儲、文件同步、文件訪問(文件上傳、文件下載)等，解決了大容量存儲和負載均衡的問題。特別適合以文件為載體的在線服務，如相冊網站、視頻網站等等。

⑨應用服務化拆分 消息中間件

如果思考過京東、美團、淘寶等等這些大型網際網路公司的業務模塊，你會發現他們每增加一塊業務，其實就是在增加一個業務組件。

比如說某生活服務公司的業務分布如圖所示：

在上圖中會發現業務組件部分包括了用戶、支付、搜索、推薦、地理位置等等。

其中的每一個業務組件其實都對應著一項服務，而且都有專門的資料庫伺服器進行維護管理，也就是之前提到的分庫分表。

而分庫分表拆分的是數據，那如何對業務進行拆分，將每一種業務分成一種服務，需要什麼服務就去調用什麼服務，從而讓系統更加的專一和精確。

如果對應到我們的架構上，就需要在數據層和應用層添加一個層面——服務組件層，其實這種架構方式就是應用服務化拆分。

提到應用服務化拆分，就不得不提及服務化治理框架，這裡就需要引入三種主流的應用服務化技術：

Zookeeper：一般來說，Zookeeper 常常跟 Dubbo 是配合使用的，因為 Dubbo 需要進行服務註冊。

而 ZooKeeper 一個最常用的使用場景就是用於擔任服務生產者和服務消費者的註冊中心。

服務生產者將自己提供的服務註冊到 ZooKeeper 中心，服務的消費者在進行服務調用的時候先到 ZooKeeper 中查找服務，獲取到服務生產者的詳細信息之後，再去調用服務生產者的內容與數據。

Dubbo：提到服務治理，Dubbo 絕對是一個優秀的服務治理框架，它可以通過透明化的遠程方法調用。

就像調用本地方法一樣調用遠程方法，只需簡單配置即可，這樣不管是擴展了幾種業務組件，都可以像調用本地方法一樣調用其他的業務方法。

它使用起來非常方便，用過的人一般都知道，只需要加一個註解就可以使用其方法，而且調用的效率非常高。

MQ 消息隊列：MQ 消息隊列已經逐漸成為企業 IT 系統內部通信的核心手段。

它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步 RPC 的主要手段之一。

比如在電商系統中，來自訂單下載轉化後的大量訂單需要推送到物流配送管理系統中，就需要通過 MQ 這種技術來處理讓物流系統慢慢的按照資料庫能承受的並發量，從消息隊列中拉取並配送訂單，從而讓流程更加有序、穩定。

當今市面上有很多主流的消息中間件，如老牌的 ActiveMQ、RabbitMQ，炙手可熱的 Kafka，阿里巴巴自主開發 RocketMQ 等。

⑩微服務架構

上一個架構演變的階段作為目前主流的系統架構來說，完全可以抵住當前流量所帶來的壓力，但是未來隨著業務和用戶量的增長，仍然還會有更大的挑戰出現。

2012 年微服務的概念被提了出來，它的基本思想在於考慮圍繞著業務領域組件來創建應用，這些應用可獨立地進行開發、管理和加速。

在分散的組件中使用微服務雲架構和平臺，使部署、管理和服務功能交付變得更加簡單。

在微服務架構中，每個服務都是自我包含的，並且實現了單一的業務功能，而這種架構也必將成為未來的發展趨勢，目前也有很多微服務的框架已經落地並迅速發展，比如說 Spring Cloud 微服務框架。

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的開發便利性巧妙地簡化了分布式系統基礎設施的開發。

如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用 Spring Boot 的開發風格做到一鍵啟動和部署。

在未來的微服務盛行的趨勢下，Spring Cloud 也必將成為 Java 程式設計師必須掌握的框架之一了。

總結

在這篇網際網路架構的演變中，我只是簡單的對一些技術進行了說明，重點說明的是每一層的架構所引入的技術到底是為什麼會出現在這一層，具體解決了什麼樣的實際問題。

不管怎麼樣，技術發展如此快速的時代，我們每一個程式設計師都不應該一直埋頭於技術的研究，偶爾抬起頭看看架構的發展和未來的趨勢，或許對我們的程序之路有一個更宏觀的了解。只有這樣，我們才能離職業危機更遠。