這些年經歷的技術變遷與沉浮

最近又從頭到尾寫了一個小 java web 應用，上一次完整的寫 web 應用程序已是三年前了，
畢竟近年都專注在后端服務架構上，而較少有機會從前端到后端寫一個完整的 web 程序。
而每次有這樣的機會，我總會去跟進使用下最新的 web 技術來開發，畢竟三年前稱手的技術工具如今看來已經老態龍鐘，
回顧這些年的技術變遷與沉浮，不禁感慨。

C/S 的末路

在我進入程序員這個職業時，主流的企業應用開發還在 C/S 時代末期，而 B/S 架構方興未艾。
主流的企業系統架構都是 C/S 的。如上圖，數據庫充當 Server 端，當年很多的業務邏輯也有在數據庫中用存儲過程實現的，
而客戶端開發主流就是圖中所示的三個工具 PB/VB/Delphi。

早期我用 PB 開發，后來轉到了 Delphi，接觸了 Object Pascal，第一次了解了面向對象語言與設計思想，對 Borland 這家公司也充滿了敬慕。
再后來 B/S 架構逐漸興起，一些項目客戶要求采用 B/S 架構后，又不得不開始轉型。
當時對于網頁開發面臨兩個選擇 ASP 和 JSP，雖然只有一個字母的差別，現在回頭一想這個選擇對后期的轉型職業發展可謂影響巨大。
最后，我選擇了 JSP，后續就走上了 java 程序員這條道路，但決策的依據僅僅是因為當時聽說 java 的主流開發工具 JBuilder 也是 Borland 開發的。

JSP 開啟的混亂之治

剛開始學 java 就進入寫 JSP 的年代，基本是 java 的亂世時代。
JSP 里有業務邏輯的 java 代碼，有操作數據庫的 SQL 語句，還有頁面展示的樣式 CSS 和頁面本身的 HTML，偶爾還零星散落幾段 js 來控制彈窗什么的。

當我把一個 JSP 文件寫到一萬行代碼時，自己終于受不了，然后大量看書、上網搜索到底怎樣寫 JSP 才是對的？
然后我知道了設計模式，不止是 GoF 那本書提到的 23 個模式。大模式有講企業應用該如何架構的，小模式有講針對某種功該如何寫代碼的。
最讓人分裂的是當時 java 業內正在經歷兩個派別的大混戰，每個派別都有各種不同模式的最佳實踐書籍、文章去論證自己是最優選擇。
最后搞的我都不知道該怎么寫程序了，有人說：

對于初窺門徑的程序員，設計模式帶來的麻煩簡直不遜于它所解決的問題。

是的，我當時應深有同感，本來原本寫程序屬于拿劍就刺，雖無章法還算迅捷，但學了一大堆招式后每次出劍都在考慮招式用對沒，揮劍反倒滯澀不少。

EJB vs 輕量級 J2EE

那時 java 企業級應用開發的正統非 J2EE 莫屬，而 J2EE 的核心則是 EJB，EJB 本質上是一種分布式對象技術，提倡對象級的組件復用。
EJB 也正是 java 標準委員會主推的技術，而草根出身的 Rod Johnson 則發起了一場技術思想上的革命，
在《J2EE Development without EJB》這本書的譯者序里有句話：

任何一個從事 J2EE 應用開發的程序員或多或少都曾有過這樣的感覺：這個世界充斥著形形色色的概念和 “大詞”，
如同一個幽深廣袤的魔法森林般令人暈頭轉向，不知道該追隨這位導師還是該信奉那個門派。
這時，Rod Johnson 發出振聾發聵的一呼：爾等不必向泥胎偶像頂禮膜拜，圣靈正在爾等自身——這就是他在書中一直倡導的 “循證架構”。
選擇一種架構和種技術的依據是什么？Rod Johnson 認為，應該是基于實踐的證據、來自歷史項目或親自試驗的經驗，
而不是任何形式的偶像崇拜或者門戶之見。書中談到了企業應用方方面面的問題和解決辦法，而這些方案無一不是這種 “循證方法” 的產物。
除了把這些方案交給讀者，Rod Johnson 通過這本書希望傳達的、更為重要的信息正是 “循證” 的工作方式——那原本就應該是程序員的工作方式。

那年我剛進入一家規模還算大的公司，在一個項目的技術方案選型討論會議上，就為到底用不用 EJB 爭論個不休。
回過頭來看，現在塵埃落定，輕量級 J2EE 勝出，Rod Johnson 創建的 Spring 開源框架取代了 EJB 的位置。
而 “循證架構” 的思想也深入人心，今天我們再討論技術選型時早已放下主義，僅關注問題本身。

輕量級 J2EE 提倡通過分布應用本身來達到水平擴展的目的，可以換得更快、更簡單的編程模型和更好的維護性。
Martin Fowler 甚至在他的書《企業應用架構模式》中開宗名義：

分布式對象設計第一定律：不要分布對象。

以此對 EJB 最終蓋棺定論，埋入技術的黃土中，成為歷史的塵埃，而以 Spring 為中心的 SSH 類框架應用模式開始縱橫江湖。
如果說 EJB 后時代進入 java 領域的程序員缺失了什么，那么極可能是只知有劍（SSH），不知有譜（循證方法），用之而未思之，思而罔之。

SOA 與 微服務化

隨著互聯網發展，規模越來越大，應用也越來越復雜，即使使用輕量級 J2EE 技術雖然輕量，但業務也變的很重量。
單一應用承載的業務越來越多，越來越復雜，而且單一應用對于大型開發團隊的并行協作帶來了巨大挑戰。

大型互聯網公司基于 SOA 的思想摸索了一條新的架構技術道路，以國外 Amazon 和 Netflix 為代表，
提出了一套新的應用架構方式，也即是 SOA 的一種實現：微服務化。
微服務強調服務的單一職責原則，和面向對象設計中強調的對象設計原則一致，
這樣有點諷刺的是如今的分布式服務與 EJB 提倡的分布式對象倒是有點異曲同工了，只是微服務還是稍微比對象的粒度稍稍大一些。

而且從上面的圖中可以看出，現在的分布式服務架構，將專業化分工推向更細的粒度。
早年基本要從頁面開發到數據庫，都是全棧工程師，如今光是頁面就有頁面構建和 js 開發的區分，
而后端服務的技術棧則更加多樣化，技術不停變遷，你我還將在其中沉浮。

來自：http://blog.csdn.net/mindfloating/article/details/47029233