軟件的系統架構、語言框架發展變遷——代碼「挪騰」編年史（大誤！）

此文很是長，請慎讀！

不知不覺就寫了這麼多，其實不少問題還沒梳理清楚，大體從我開始學習寫代碼（05年吧）開始到如今，感覺到關於軟件開發的變遷發展。不少程序員都不太清楚各類架構、以及輔佐這些架構的框架、思想、風格、設計模式是幹什麼的，出於什麼目的、爲何使用，以及出現這些架構的時代背景，因此，做爲梳理寫了這篇。可能有些地方理解的不對，水平有限，請勿拍磚（無辜的大眼睛望着大家）

本文的小標題模塊都是根據時間線寫的，都有前後出現的邏輯關係，請勿跳着閱讀斷章取義的理解，謝謝！

在我工做以前的學生時代，流行桌面軟件客戶端C/S結構，剛開始工做時B/S結構中傳統MVC已經進入衰退期，先後端分離的接口方式以及微服務開始流行。

系統架構的做用：

一個系統是爲具體的業務目標而服務的，隨之而來的問題是，選用哪一種系統架構才最適合。但在敏捷開發的時代，業務目標可能不明確，追求小步快跑、快速迭代，其架構設計也應具備良好的適應性，絕對定性的採用某套成體系的架構設計方法已經沒法知足瞬息萬變的業務需求。

先來回顧一下軟件應用系統架構的歷史：

三層結構

在說整體的架構以前，首先要明確一個概念，也就是軟件設計的基礎結構，三層結構模型：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。在桌面軟件時代，好比咱們用的辦公軟件WORD，它的軟件開發結構就是這樣三層，表現層負責與用戶交互，業務邏輯層負責處理用戶編輯文本的各類操做，數據訪問層負責將用戶編輯的結果數據保存進文件或者對用戶保存的文件進行訪問和讀、寫。

MVC

在其中，不得不說MVC（Model模型，View試圖，Control控制器）在其中的做用，爲了應對圖形化操做系統到來，本來在DOS下命令行式的軟件須要圖形化的展現，但它的業務邏輯層和數據訪問層沒有太大變革，因而二十世紀八十年代針對表現層的MVC設計模式被提出。

C/S結構

以後，隨着軟件行業的發展，OA、ERP等軟件的需求增加，出現基於桌面客戶端與局域網服務器通訊的C/S（Client/Server）結構模式，表示層存在於C端Client，而業務邏輯層、數據訪問層在Server端。就像是咱們如今智能手機的原生App（區別於H5方式的Hybrid App）訪問服務器的這種模式。表示層的MVC設計模式在C端上展示，原生App就是基於這樣的MVC圖形界面展現設計模式產生的web MVC，如iOS的Object－C：視圖類：UIView，和控制器類：UIViewController。Android中JAVA的Adapter、Activity等。

B/S結構

後來，C/S結構過重，每個企業應用軟件都須要安裝客戶端，就像如今手機裏好多App，而這些應用的表示層大都差很少（都是一些選擇框、輸入框、展現列表等），因而出現了基於瀏覽器的B/S結構，即Browser/Server(瀏覽器/服務器)結構。使用瀏覽器做爲表示層的統一解析器，展現交互界面，和如今流行的H5方式的Hybrid App、微信的小程序等很類似，注重輕量化，跨平臺的特性。

注：MVC 的概念最先出如今二十世紀八十年代的施樂帕克實驗室中（發明圖形用戶界面和鼠標的實驗室），當時施樂帕克爲 Smalltalk 發明了這種軟件設計模式。

SSH，springMVC框架

在ERP類的業務中，採用B/S結構，並在表示層使用MVC的設計模式是早期比較流行的一種方式。其著名的輔佐框架是SSH（Struts，Spring，Hibernate）組合，以後springMVC也比較流行（Struts、springMVC都是對JAVA的Servlet進行的一種封裝）。當時的時代背景，各行業都在需求創建本身的業務系統，主要是內部管理資源而使用，從傳統的手工做業方式轉變爲自動化的流程管理，目的是使用IT技術來提升生產力、管理水平。在使用場景中，對服務的響應速度和承載能力、併發等要求不高，系統的主要使用對象爲公司內部人員，採用單服務系統應用部署方式和瀑布式的開發模式，可以知足業務需求。

服務器端的代碼結構爲DAO層、Service層、Controller層、View層

View層：做爲展現給用戶看的交互界面，通常採用JavaScript＋HTML＋CSS來實現，加上springMVC或Struts對數據的綁定。

Controller層：負責展現層的業務邏輯分發，對model進行數據綁定。

Service層：負責處理具體的業務邏輯。通常再細分爲Service接口層和Service實現層。

DAO層：負責對數據庫的查詢、修改等。

PHP、ASP開發語言

當時的互聯網熱潮還處在web1.0時代，也就是你們上網看看新聞，逛逛論壇等，以獲取信息爲主。網絡購物等也比較初級，用戶也很少，計算機比較貴，上網人數仍是有限的。一些網站的主要語言是使用PHP、ASP等將DAO層、Service層、Controller層、View層合在一塊兒，快速開發出小型網站，數據庫採用mySQL。不少論壇、購物網站、都是PHP＋mySQL搭建的，素有PHP是最好的語言（在論壇上吼這句話，會有無數程序員開始爭吵，樓主要迅速逃離，不然有被「亂棍打死」的危險）

SOA（Service-Oriented Architecture）面向服務的架構設計思想

SOA的場景是多應用系統之間的交互須要應運而生的設計思想。原先單應用系統，一個企業的全部服務都在一個系統上實現，工做流集中在一塊兒，對於早期簡單的業務場景可能適用，但隨着企業規模擴大、產品的多樣化，以及互聯網的衝擊，這種所有集中在一個系統上的架構顯得不合時宜，而將企業工做流或者業務流程分佈在各個功能獨立化的應用中的作法變得迫切須要，因而面相服務的架構設計SOA被提出。大型企業包括跨國集團、金融機構等。

ESB（Enterprise Service Bus）企業服務總線技術

伴隨着多應用系統的出現，應用與應用之間的交互成了問題，幾個應用乃至十幾個應用之間的複雜交互造成如蜘蛛網通常的交叉鏈接，通訊效率和維護都很是的低下，而ESB將各個應用服務連接在這根總線上進行通訊安排和管理來解決上述問題。當SOA設計思想開始普遍應用時，對ESB的依賴愈來愈多。

架構的轉變

隨後的IT發展，在互聯網化的進程中愈加給力。利用互聯網的進行各類創新服務，其中傳統交易的線上化被普遍使用。隨之而來的是使用系統的對象產生了變化，從企業內部人員和少數有錢人，發展成普通大衆，且在網上發生的行爲愈來愈多、在線時間愈來愈長，本來B/S結構的MVC設計模式、單系統服務應用的部署、以及瀑布式的開發模式都沒法知足快速增加的業務需求。

因而，將先後端拆分、前端異步加載、後端微服務化，甚至出現雲服務，敏捷開發等解決方案成了必然的結果。

RESTful API

爲了適應互聯網的業務需求，提高用戶的瀏覽體驗，先後端拆分部署變成必需。拆分後前端獨立加載，不一樣於MVC的model綁定後臺顯示數據，三層結構中的表現層獨立加載在瀏覽器之中，使用Ajax等異步加載手段從後臺的RESTful 風格的API接口獲取數據進行展現。

（代碼挪騰開始了，真折騰呀！）

代碼結構爲 前端H五、後臺RESTful API。

前端H5：

JavaScript的各類框架（jQuery，web MVC的AngularJS等）＋HTML5＋CSS，也能夠是DDD（領域驅動設計模式）的表現層。

後臺RESTful API風格：

JAVA Servlet技術提供的API接口：Action層（負責邏輯分發）、Service層合、DAO層。

DDD（領域驅動設計模式）後三分層：應用層、領域層（Domain）、基礎設施層。

Micro-services 微服務

固然，光作先後端拆分還不夠，爲應對現代互聯網的爆炸式增加訪問量和敏捷開發的不斷快速迭代須要，微服務技術的出現無疑能夠很好的解決這個問題。微服務是把傳統應用上的多個服務作細微拆分紅原子組件，可隨時進行多個一樣服務的複製和部署，以應對流量壓力、業務須要，作到可彈性伸縮。主要包括：服務拆分、服務的註冊、服務發現（客戶端發現、服務端發現）、進程通訊等機制。以及配套的運維體系（Dev-Ops等)、應用容器化（Docker等）、緩存數據庫（MongoDB、Memcached、Redis等）。JAVA上的微服務框架有springCloud，其餘語言亦有本身的微服務框架。

雲計算服務

人云亦云的雲計算服務如下簡稱雲服務，將已經成熟的服務開放出去給用戶使用、而且每一個用戶都有其獨立的一套環境（虛擬空間），這就是雲服務的本質。不管是提供磁盤空間、仍是基礎環境、甚至是軟件應用，主體思想都是每一個用戶是獨立的。雲服務的產生緣由有不少，基於共享和企業節約成本的目的是主要驅動力，雲服務適合初創企業、以及不知是否將要繼續的業務。雲服務的要點有，基於高度規範化和標準的通用服務，最先的企業網站模版與虛擬空間一體化產品就是現代雲服務的早期試驗田。

這裏微服務和雲的關係很微妙，雲服務的其中一種實現方式就是開放的微服務化，不少人把雲計算服務和微服務劃等號，其實雲計算服務是商業模式，微服務是技術集合。

架構變遷、順應時代的須要從而帶來開發管理的變化

Agile software development 敏捷開發

敏捷開發相較於傳統的瀑布式開發方式，具備快速迭代、最小化可用，丟棄繁瑣的各類詳設文檔，以求最快速度的上線使用，適應現代互聯網高速創新的須要。

（但大部分時候開發速度加快，不是敏捷開發帶來的，而是沒日沒夜加班換來的，😓）

敏捷開發可分爲兩個部分去理解，開放方式的敏捷化以及運維方式的敏捷。

開發方式的敏捷是指，從需求設計、到編寫代碼的中間流程所有精簡，免除企業中總體的複雜流程。

運維方式的敏捷是指，從代碼寫完到自動集成發佈、自動完成測試、到最後的自動部署，自動上線的過程。

用到的工具備，需求管理工具看板：Trello等、版本管理：Git等、自動化集成Jenkins、自動測試腳本等，包依賴管理工具maven等，構建方式Ant、Gradle等。

如何編寫語言框架

講了那麼多系統架構的變遷和歷史，那麼爲了適應各類業務須要的架構支持框架是怎麼寫的呢？

首先要明確你的語言框架是用來幹什麼的，出於什麼目的編寫框架。

其次，框架在哪一層，封裝些什麼內容，封裝到何種程度，都是根據你的業務需求來定的。

打個比方：在早期MVC的框架Struts，它的定位就是封裝前端與後臺的數據交互，封裝表示層的複雜實現，因此是基於底層的封裝。又如同，利用Struts在其之上作的各類公司內部開發框架等，就是對於某些業務類型特定的開發邏輯進行的封裝，這種屬於邏輯層的封裝。

編寫底層框架

底層框架的封裝，提供出來可供調用的接口，其總體設計都是基於公共目的，如springCloud處理了微服務技術中各類消息傳輸、服務註冊、發現等的複雜實現，供開發者方便調用，搭建起本身的微服務應用。通常都是底層實現的優化，對於開發者的，算法能力、數據結構、以及編譯和模塊設計思想要求都較高，常見於非營利性組織，或開源社區的大牛製做發佈。這種框架是對業務需求的高度抽象總結後，適應時代發展作出的，會有組織者提出並牽頭，有完整的框架自身功能結構的規劃。天然也會有衆多愛好者爲其貢獻插件和組建。對於開發者來講，寫這一層的框架纔是真正鍛鍊技術和有意義的。

編寫邏輯層框架

在邏輯層的封裝其應用範圍會更加的窄，好比一個集成的開發框架，從生成模版代碼到打包都是一體化的，是爲某一用途設計的框架封裝。JAVA中的框架開發使用其特有的反射機制，在邏輯層封裝的比較多，常見於各個公司內部的開發框架，一些大型軟件外包公司都有本身的開發框架。因其發展多年，業務條線基本定型，開發模式成熟，故可以使用這種方式封裝框架供定向開發目的使用，以保證軟件開發質量、不管是公司多年的高級工程師、仍是剛畢業的新手都能在這種開發框架下寫代碼不出錯。網上有不少這種開發框架不限於JAVA的，還包括JS的封裝了jQuery調用和一些業務邏輯的開發框架，因爲是在底層上的邏輯層二次封裝，其適用面比較窄，業務目的性明確，因此每每被淘汰率很高，特別是如今互聯網高速發展的時代，今年的開發框架，明年就不適用了，也沒人維護，成了被遺忘的「坑」。

編程語言（須要的技能：編譯技術、數據結構的設計、虛擬機或硬件平臺的知識）

｜

底層框架（須要的技能：算法功底、功能的實現方式、總體的規劃能力）

｜

邏輯層框架（須要的技能：熟練使用底層框架、開發中公共代碼的積累）