網際網路架構演進曆程

 本篇部落格隻是用于記錄昨天所學，并不一定正确，評論區歡迎指正，我馬上改

目錄

首先談談什麼是單體架構？

分布式架構

緩存

網際網路架構演進曆程：

1.單體架構

2.分布式架構

首先談談什麼是單體架構？

 所謂單體架構我了解就是，假設我們将伺服器了解為一台提供服務的計算機，那麼從頭到尾隻有一台計算機在提供服務，所有的服務都部署在一個web伺服器上，而web伺服器與資料庫伺服器同時部署在一台計算機上，一起提供服務。

 讓我們先來看看，單體架構下服務的運作順序。首先我們在位址欄裡面輸入位址，此時浏覽器會将我們輸入的位址發給dns（這個應該部分人不陌生，記得之前管家類的軟體上都會有dns調優，就是那個玩意），dns根據我們輸入的位址進行域名解析，比方說如圖的淘寶就解析為202.100.10.128。當dns傳回給浏覽器這個ip位址時，浏覽器就會根據這個ip位址去尋找這條一台計算機，也就是伺服器。找到了之後将http請求發給web伺服器，也就是tomcat（并不指web伺服器就一定是tomcat，僅以tomcat舉例，便于了解），那麼web伺服器去解析請求處理業務，尋找資源并傳回。需要查詢資料庫的就與資料庫進行TCP連接配接，然後将結果原路傳回給浏覽器，然後浏覽器将結果呈現給使用者。

那麼這樣走下來，是不是大家就覺得還可以，是這個流程，這也就是目前大部分學習階段的學生寫的架構。因為不釋出，使用者數不多，測試基本上也就是組内的幾個人測試通路，看不出問題。

但是！如果釋出了，火了，使用者數量有幾萬個了。那麼問題就出來了。

幾萬個使用者同時通路這台伺服器，也就是學生手裡的筆記本，那麼每一個使用者請求筆記本都需要cpu去處理，web伺服器上業務處理需要cpu，資料庫需要cpu，哪兒哪兒都要cpu，cpu就不夠，發生了争搶現象，有的使用者的請求就卡住阻塞了， 遲遲得不到回複。這時候伺服器的效率就是異常低下了。那麼怎麼去解決這個問題呢？下面講的分布式架構就是為了解決這個問題。

那麼單體架構是否沒有優點？

不是的，有的。

優點：維護起來簡單，部署起來也簡單。最顯而易見的優點。還有我了解的一個，就是都在一個計算機上，使用者數少的情況下，通路速度應該要略高于分布式，但是也不一定。

缺點：存儲能力有限，計算能力也有限。系統可靠性差（打個比方：學生筆記本當機就所有資料服務都停止了，而且可能發生資料丢失）

單體架構技術棧：jsp+servlet+javabean（基本是不用了），spring+springMVC+mybatis（ssm）+springboot（現在在用）

2.分布式架構

分布式架構也有多種，有web伺服器和資料庫伺服器分開的，也有web伺服器有多個，分布在不同計算機，資料庫也一樣分布在多個計算機，猜想分布式資料庫量大了，就是現在的大資料了，大概吧！

補充一個知識點

計算機中服務的唯一辨別是端口

網絡的服務唯一辨別是ip位址

如圖，第二張圖和第一張圖唯一差別就是web伺服器和資料庫不在一個計算機上了，打個比方：就是同學A寫代碼，idea裡面配置檔案寫的資料庫位址不在自己電腦上了，而是在同一組的同學B電腦上，這就是是最簡單的一個分布式例子了。當通路同學A的電腦上的web伺服器，伺服器要去查詢資料庫就發sql給同學B的電腦上的資料庫進行查詢處理然後傳回。原先一台電腦既要處理web業務又要處理資料庫的業務，現在一台電腦隻處理一個事情，那麼web服務就相對于擁有原先兩倍的cpu，資料庫同理，效率就提高了。當web伺服器部署在不同電腦，即擁有多個web伺服器時，效率會更高！

但是！随之而來的另一個問題來咯！小飛棍來咯~

當web伺服器越來越多，使用者越來越多，那麼勢必查詢資料庫的操作也會越來越多，但是要知道一個資料庫所能支援的連接配接數是有限的。

這裡補充一個知識點：

Mysql5.0版本：預設的最大連接配接數為100，上限為16384

 不同版本資料庫不同，但是也能說明一件事情，就是資料庫連接配接數确實是有上限的，而且數量不多。

show variables like’%max_connections%’;

//查詢語句，用于查詢資料庫連接配接數，大家可以自己試試，看看自己的資料庫連接配接數是多少

 set global_max_connections = 200;

//sql語句設定連接配接數，可以是300.400.500.1000

//但是一般不會寫這個，我們一般會在項目配置檔案中配置最大連接配接數

當資料庫連接配接到到頂了，那麼再布置多的web伺服器也沒有意義了，資料庫通路受限了！這就是效率的瓶頸了！

此時解決資料庫連接配接問題至關重要！否則分布式就沒有太大意義了！

使用緩存和連接配接池可以部分解決資料庫連接配接限制問題。

連接配接池是使連接配接複用，減少連接配接數！實際上使用者基數大的情況下，也沒啥用，再減少也少不到哪裡去，還是受限。

緩存呢？

緩存即将一次查詢的結果存儲在web伺服器上面，當别的使用者再次請求這個資料庫查詢的時候就不再查詢資料庫了，而是直接傳回這個結果，減少了通路資料庫的次數。如果說将大量使用者會進行的重複資料庫操作緩存在伺服器是可以大量減少資料庫操作的，但是這要求我們的緩存具有高命中率。所謂高命中率就是，緩存的東西是大量使用者需要的，而不是緩存個别使用者的。比如商品清單，某某清單，所有使用者進淘寶首頁都會查詢這個商品的清單，那麼就可以緩存這個清單到web伺服器，使用者别的使用者再請求，直接返給他就行了。

這裡就引入了一個問題，要用緩存來解決資料庫連接配接限制問題，提高效率，不是說隻有有緩存就行的，而是對我們的緩存有要求的。那麼我們建立一個緩存對象，需要考慮上什麼問題？

1. 資料結構（散列結構=>存取資料速度要快，随機存取）
2. 資料淘汰算法（緩存滿了基于什麼方式淘汰資料）
3. 緩存資料的生命周期
4. 緩存資料的定時重新整理（提高資料一緻性）
5. 緩存命中率分析（命中率低說明設計不合理）
6. 并發通路時的線程安全
7. 資料的序列化和返序列化

資料結構：很重要的一個問題。緩存對象的資料結構一定要具有随機存取，尤其對取資料的速度有高要求，我們緩存了一個商品清單，就不可能用數組，不然使用者查詢一個商品資訊，我們難道就要周遊一次數組嗎？顯然這種資料結構不行，map就會比數組好一些，根據使用者給的商品key值就能直接找到該商品資訊，返給他，效率就高了很多，是以緩存的資料結構尤其重要。

資料淘汰算法：緩存是需要更新換代的！緩存滿了，我們基于什麼算法去淘汰緩存，是新時間優先（即保留新的緩存，将舊的緩存淘汰掉）還是多通路優先（不管時間，保留最多人用的那個緩存，将較少人用的緩存淘汰） ，這是我們需要去考慮的問題，隻管時間與隻管使用人數顯然都是不行的，這時候一個好的GC算法就很重要。

最常見的幾種過期政策如下：

多長時間沒有被請求，則過期，最典型的就是ASP和ASP.net 提供的 Section 功能。

依賴于檔案變更的緩存，一旦檔案被修改，緩存則過期，典型的是 WEB站點的 Web.config 。

緩存資料生命周期：

1.進入緩存。（進入緩存的時候，可能需要指定它以後的過期政策，如果不指定，需要使用系統預設的過期政策）

2.從緩存中獲得它，注意，這時候需要處理線程安全的問題。

3.更新緩存，注意，也需要考慮線程安全問題

4.離開緩存，這個可能是外部請求，也可能是緩存根據過期政策把它清理掉。

自己設計一個緩存的生命周期，什麼時候更新什麼時候淘汰等。。

緩存定時重新整理：主要就是上面講到過的，什麼時候重新整理緩存，老舊的已經過時的資料要被淘汰

命中率：前面講過不贅述

安全問題：這個是緩存最大的問題！主要發生在獲得緩存和更改緩存的過程中！因為必然是涉及線程并發，那麼多線程同時通路同一個緩存對象肯定就會存線上程安全問題，不注意線程安全，可能導緻一個使用者修改了緩存，然後其他使用者獲得的都是修改後的資料，全部出錯！

解決方法很簡單，把你的業務邏輯，代碼觸發情況都考慮清楚，不要遺留沒有觸底的地方。

簡單的方法會導緻你的代碼邏輯變得非常複雜。

這也就是有些人，在非必要的時候，建議你不要用緩存的原因。一旦開始使用緩存，你就應該準備增加大量的代碼來處理資料同步的問題。

當然也可以使用一些線程安全的産品，但是線程安全的産品并不一定代表線程安全，主要還得看代碼，業務邏輯！CurrentHashMap是線程安全的HashMap！

資料的序列化和反序列化

序列化：将 Java 對象轉換成位元組流的過程

反序列化：将位元組流轉換成 Java 對象的過程。

發生在兩個程序遠端傳輸

以下是一些使用序列化的示例：

1. 以面向對象的方式将資料存儲到磁盤上的檔案。例如，分布式緩存Redis 存儲 Student 對象的清單。
2. 将程式的狀态儲存在磁盤上。例如儲存遊戲狀态。
3. 通過網絡以表單對象形式發送資料。例如，在聊天應用程式中以對象形式發送消息。