Spring 源碼分析(四) ——MVC（一）Web 基礎

軟件的分類

        軟件（Software）是一系列按照特定順序組織的計算機數據和指示，是計算機中的非有形部分。而計算機中的有形部分稱爲硬件，由計算機的外殼及各零件及電路所組成。計算機軟件須要有硬件才能運做，反之亦然，軟件和硬件都沒法在不互相配合的狀況下進行實際的運做。

        通常來講，計算機軟件被分爲編程語言、系統軟件、應用軟件和介於二者之間的中間件。其中系統軟件爲計算機使用提供最基本的功能，可是並不針對某一特定應用領域。而應用軟件則剛好相反，不一樣應用軟件根據用戶和所服務的領域提供不一樣的功能，也能夠根據軟件結構分紅：單機類型、C/S類型和B/S類型三種不一樣的類型。由於網站架構纔是咱們此次研究的重點，因此咱們就對應用軟件進行專門分析。

        基本上不須要聯網的應用軟件，均可以歸類爲單機類型，好比咱們常見的Office、搜狗輸入法、單機遊戲等等。這種軟件類型簡單、使用起來也很是普遍，能夠說是應用軟件的鼻祖。

        而有些應用軟件須要將應用程序中的數據進行統一管理，因此咱們必須將保存數據的數據庫統一放在一臺主機中。這樣全部的用戶就能夠從同一臺主機中獲取數據了，這時就分客戶端和服務端了。用戶安裝的軟件叫客戶端，統一管理數據的主機就叫服務端，而這種軟件結構就叫C/S結構。一般狀況下，若是將業務邏輯所有都放在服務端進行統一處理就能夠得到更好的安全性和穩定性並且軟件升級也比較容易，但這會加劇服務端的負載。反之亦然，若是將業務邏輯放在客戶端這樣就能夠下降負載，但安全性、穩定性以及軟件升級都成了問題。因此，在C/S結構中合理的進行的業務邏輯的分配就是一件仁者見仁智者見智的事情了。下面是C/S的結構圖：

        其實，C/S結構已經完成了網絡通訊了，但爲了解決剛纔所提到了不足，設計者將客戶端進行了統一的整合，並且默認安裝在客戶的計算機中，這就是"瀏覽器"。客戶經過瀏覽器訪問不一樣的頁面，進而完成不一樣業務邏輯而且進行完成數據交互，這種軟件結構就是B/S結構。下面就是B/S的結構圖：

        其實，這三種結構談不上誰好誰壞，通常根據需求而定。B/S結構開發簡單、使用方便並且功能強大，因此使用最爲普遍。但單機結構的軟件基本上是每臺計算機上都會有。而C/S結構雖然比B/S複雜，但靈活性和處理效率都要比B/S高出許多，因此如今一些大型的軟件和遊戲基本使用的仍是C/S結構。下面咱們就來論述一下關於B/S結構的基礎知識。

網絡傳輸模型                                         

        在討論基礎架構前，咱們咱們必須先了解一下底層網絡傳輸體系，畢竟網站是創建在互聯網之上的，有些專門地通信協議也須要特別注意一下。通常網絡傳輸的分解方式有兩種：一種是 OSI 參考模型，一種是 TCP/IP 參考模型。下面是它們的分紅方法及對應關係圖：

        OSI 參考模型一共分爲 7 層，不過它主要用於教學，因此筆者不作闡述。實際使用中更多的是 TCP/IP 的 4 層模型。對於 TCP/IP 的 4 層模型能夠簡單地理解爲：

                網絡接入層：將須要互相鏈接的節點接入網絡中，從而爲數據傳輸提供條件。

                網際互聯層：找到要傳輸數據的目標節點。

                傳輸層：數據傳輸數據。

                應用層：使用接收到的數據。

        下面是 TCP/IP 4 層模型的層次圖：

        對於互聯網這種使用普遍的東西，標準是很是重要的，可是在傳輸參考模型中，這種制度不叫標準而是協議。在 TCP/TP 模型中網絡接入層是沒有協議的，而重要的協議，在網絡互聯層是 IP 協議，傳輸層是 TCP 協議，應用層是 HTTP 協議，固然還有 DNS 協議和基於 HTTP 上層的相關規範也就是 Web 中的 Servlet。 

網站架構的演化

        咱們都知道如今的 Web 軟件都是基於 B/S 結構的，因此將 B/S 結構作一些小小的改動，就是一個小型網站的架構，固然是最原始階段的網站架構。小型網站最初的時候並無多少訪問量，一臺應用服務器或者將應用服務器拆分紅應用服務器和數據庫服務器，基本就已經很夠用了。下面就是最簡單的網站架構圖：

        將應用程序、文件等等放在一臺應用服務器上，而數據庫則在另外一臺數據庫服務器上。一般服務器操做系統是 Linux，應用程序使用 PHP 或者 Java 進行開發，而後用 Tomcat 或者 Apache 進行部署，數據庫使用 MySQL，最後聚集各類免費開源軟件以及廉價的服務器就能夠開始運營了。

        固然，隨着業務規模的發展，服務器確定不夠用的，這時就須要添加新的服務器，來進行應用與文件的分離了，而且須要遵循「二八原則」添加專門地緩存服務器來改善網站的性能。但若是出現了高併發加海量數據的狀況，最經常使用的手段是使用集羣加數據庫讀寫分離的方法來解決，固然，使用反向代理和 CDN 提高網站性能也是必不可少的環節。至此，一個基本分佈式系統就算是創建起來了。固然，這樣的架構其實仍是能夠繼續進行優化的，好比使用非關係型數據庫、進行業務拆分以及使用分佈式服務等等。這個世界沒有哪一個網站從誕生開始就是大型網站，因此一味地追求網站架構是一種得不償失的行爲。但隨着業務的增加，推進網站架構的演進仍是很是有必要的，由於這樣你才能爲所欲爲的去應對各類狀況。

        性能、可用性、伸縮性、擴展性以及安全性是網站架構最核心的幾個要素，基本這些問題解決了，網站架構的大部分困難也就克服了。此外，這個世界沒有哪兩家公司的業務狀況是徹底相同的，因此在架構演化的道路上絕對不能盲從。不要受大公司以及從大公司挖過來的技術高手的太大影響，從而偏離了原先的架構演化路線。大公司的經驗和成功模式當然很重要，但盲目借鑑，可能會偏離符合實際的架構演化道路。也不能爲了技術而技術，一味追求最新技術，只會讓架構之路越走越難。最後有時候，問題並非出在它的系統架構，而是業務架構出了問題，因此，合理地調整業務需求每每比修改架構更爲有效。

        總的來講，在網站架構演化的過程當中，追求技術是爲了擴展業務邊際，架構設計與業務必定是相輔相成的。

——水門（2016年3月寫於武漢）