從Gilt遷移到Scala以及Paypali遷移到Node.js，我認為原因有兩個，這兩個代表了現在和未來的一種趨勢：

1. Node.js和Play框架倡導的微服務。

微服務這種架構使得維護擴充方便，打破了原來Java和Rails的鐵板一塊的整體式系統，這種微服務架構特點是RESTful介面+微服務。而傳統Java和Rails是一種“MVC+服務"傳統架構，為什麼“MVC+服務”容易導致鐵板一塊的系統呢？MVC是一種面向前端的模式，當你使用這種組合時，你的重點就不免放在MVC的實現上，“服務”變成一種附加的次要的為MVC服務的架構，而輕量的RESTful介面使得我們重點又會到“服務”上，我們可以專注將我們的服務設計成一種微服務。

從可測試角度看，MVC架構因為比RESTful多了一個頁面檢視，也就是直接繫結了終端頁面，或者說繫結了前端頁面，這就難於方便進行後端業務邏輯的測試，見要麼TDD死，要麼後端MVC死，而對RESTful的URL進行測試，或者對微服務進行測試都是非常輕量方便易觀察的，不和具體框架繫結，基本都是純粹業務。

2. Node.js和Play框架倡導的非同步Reactive程式設計。

非同步程式設計最大的特點是吞吐量大，延遲小，因為沒有堵塞，這就容易挖掘現有硬體和作業系統等底層系統的潛力，同樣的成本投入，非同步系統要比傳統鐵板一塊的同步系統更能應付爆發式湧潮的瞬間大流量。

基於非同步的Reactive程式設計引入事件驅動概念，是一種自發式Reactor，能夠將原來在一個請求中完成的繁重工作分發成並行等多工方式完成，大大提高了系統的可擴充套件性可伸縮性，當一臺伺服器硬體已經挖掘到極致，也就是說這種垂直擴充套件已經完全挖掘了多核CPU的潛力，可以再通過水平擴充套件假設多臺伺服器提升整個系統的處理能力。

這種垂直和水平立體式的擴充套件能力完全顛覆了傳統Rails和Java Spring的順序程式設計模型，因為順序程式設計方式很容易導致同步堵塞式系統，具體可參考：http://www.jdon.com/46372，這個貼雖然使用了Node.JS作為非同步程式設計案例說明，同樣也適合Scala的Play框架和Akka的非同步Reactive程式設計。

總之，微服務體現了物件導向的細粒度鬆耦合原則，發揮了設計上的優勢；而非同步程式設計則體現面向函式程式設計的精確能力，發揮了效能上的優勢。一個架構如果兼顧設計與效能兩者能不是一種優秀的架構嗎？

[該貼被banq於2014-05-19 12:50修改過]