今天和朋友聊軟體開發技術的架構，聊到了目前JavaWeb應用所用的一些技術，比如高可用、高并發、高性能以及一些軟體NGINX、MyCat、Keepalived等等，這些軟體在我目前所做的項目中都還沒有用到，然後又聊到這軟軟體的技術的和使用場景等等問題。
又聊到了Web開發的演變曆史。從最開始的用戶端請求—>伺服器響應，到現在的分層設計，幾乎可以清晰的看到軟體技術演變的邏輯。一開始的用戶端請求—>伺服器響應模式是最基本的，也是最簡單的，相當于最初的模型，使用者在浏覽器端請求什麼，伺服器端就傳回什麼。這時的代碼可以說是都在一個檔案中，比如xxx.html、xxx.jsp，還沒有相對結構化的架構。
軟體設計的演變
而随着業務的發展，這樣的系統已經不能滿足需求了，然後厲害的人就提出了改進和嘗試，比如能不能把一個檔案中的部分代碼分離出來單獨做成一個子產品，這樣清晰且易于處理。于是設計出了更好的分層模式，于是這樣的開發方式就被遇到同樣問題的程式員們所接受，慢慢的就演變出了一些常用的架構模型，比如Web開發裡常用的三層架構、MVC模型等等。
表現層（UI），通俗講就是展現給使用者的界面，對應項目中的Web層包含Servlet和Controller等。
業務邏輯層（BLL）：也稱作領域層，負責系統業務邏輯的處理，對應項目中Service和ServiceImpl等。
資料通路層（DAL）：該層所做事務直接操作資料庫，針對資料的增添、删除、修改、更新、查找等，對應項目中的Dao。
在提出該分層架構的時代，多數系統往往較為簡單，本質上都是一個單體架構（Monolithic Architecture）的資料庫管理系統。這種分層架構已經是Client-Server架構的進化了，它有效地隔離了業務邏輯與資料通路邏輯，使得這兩個不同關注點能夠相對自由和獨立地演化。
在開源技術架構中，表現層實作的代表作品是Struts1/2、Spring MVC，業務層實作的代表作品是Spring，持久層實作的代表作品是Hibernate和Mybatis。
MVC模型的架構說實話在我剛接觸JavaWeb項目開發的時候我并不知道這架構的好處，或者說不知道為什麼要這樣寫，那時我隻會看着前輩們的代碼依葫蘆畫瓢。直到做了幾年JavaWeb的開發，對這些架構用的也多了，慢慢也熟悉了，才有點感覺。而在用用其他語言開發的類似架構時才發現它們是類似的，隻是實作的代碼不同而已，這時我才明白為什麼會這樣設計。
而要了解為什麼會這樣，最好的方法就是去看它的演變曆史，當你從最開始的起點看起，順着時間方向看到現在，就會看到它的這個發展邏輯，自然為什麼要那樣，而不是這樣也清晰了。
再說到現在的軟體開發技術、不如高可用、高并發、高性能、微服務等等，如果隻是去看這些名稱，感覺很高大上，看到後會讓你感覺很難、很牛逼的樣子，自己好像要具備很強的能力才能去搞這些技術。而實際上，如果你從軟體開發演變的角度去看時，它們其實并沒有多難，也沒有多牛逼，這些技術産生也隻是為了解決目前在軟體開發中所遇到的問題而已，而随着時間的推移，肯定會遇到更複雜的業務場景，也會遇到更牛逼的技術和架構出現。
而如果你了解了底層的思想或者演變的邏輯，就會很清晰的看到它隻是這個行業在發展中的一步而已。而這個底層的思想或者演變的邏輯，在我看來是非常簡單的。這種底層的思想或演變的邏輯會展現在很多不同的技術架構上，你隻要對比看，就能看出來。
回到上文中的一開始的提到的用戶端請求—>伺服器響應的模式，你就會發現，現在的技術開發架構，都是在這兩個環節中不斷細分出來的，兩層、三層、四層等等。而目的隻是讓系統保持正常運作，比如：一個業務系統，一開始隻有10人用10人請求，半月後有1000人請求，三個月後使用者指數增長，同一時刻，出現10萬人同時請求，那麼你要在系統出現不同數量級請求下都要保持穩定可通路，比如我們的12306購票系統。一開始簡單的設計就不能滿足需求了，這時你就要進行技術上的更新嘗試，于是你就會用到一些聽上去很高大上的技術。而這些技術的目的，其實隻有一個，就是解決現存的問題，滿足需求。
而前文提到的分層思想，就是一種不錯的解決思路，通過分層，逐級擴大并行處理量來達到目的，一開始文中所提到的一些技術，軟體等等都隻是某一次中所用到的技術而已，它們是解決某個方面的問題的。這種分層思想在軟體架構方面用的很廣泛，比如我們熟悉的TCP/IP協定就是分層模型。
而在我們了解了分層思想後，對于具體的業務需求和對應的技術的選型就清晰了，分層思想在軟體架構中是特别常用的一種架構方式。分層架構是一個很可靠的架構模式。它适合大多數的應用。如果你不确定在項目中使用什麼架構，分層架構是再好不過的了。
其實縱觀整個軟體發展史，你會發現總是需求在推動着技術的發展疊代。
參考文獻：
0、軟體設計的演變過程 - 簡書