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

C/S 的末路

在我進入程序猿這個職業時，主流的企業應用開發還在 C/S 時代末期，而 B/S 架構方興未艾。

主流的企業系統架構都是 C/S 的。如上圖，數據庫充當 Server 端，當年非常多的業務邏輯也有在數據庫中用存儲過程實現的，
而client開發主流就是圖中所看到的的三個工具 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 提倡的分布式對象倒是有點異曲同工了，僅僅是微服務還是略微比對象的粒度稍稍大一些。

並且從上面的圖中能夠看出，現在的分布式服務架構，將專業化分工推向更細的粒度。

早年基本要從頁面開發到數據庫。都是全棧project師，現在光是頁面就有頁面構建和 js 開發的區分，
而後端服務的技術棧則更加多樣化，技術不停變遷，你我還將在當中沈浮。

以下是我自己開的一個微信公眾號 [瞬息之間]，除了寫技術的文章、還有產品的、行業和人生的思考，希望能和很多其它走在這條路上同行者交流，有興趣可關註一下，謝謝。

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