引言

互聯網服務和BS架構的傳統企業軟件相比，系統規模上產生了量級的差距。例如

傳統BS企業內部門戶只需要考慮數百人以及幾千人的訪問壓力，而大型互聯網服務有時需要考慮的是千萬甚至上億的用戶；
傳統企業管理系統管理的物料信息等，可能只有數萬或數十萬條記錄，而一個大型B2C網站的商品SKU動輒千萬，考慮到商品信息更新的歷史記錄，商品訂單記錄等數據，更是天文數字。

原始的SSH+DB的BS開發模式，顯然已經無法滿足現代互聯網服務的需要。隨着企業軟件不斷地向雲端遷移的趨勢越來越明顯，最終中小型企業軟件系統的開發將變得越來越非主流，模式和架構被淘汰后，只熟悉原始的開發模式和架構的工程師，也將遭遇被淘汰的壓力。

SOA化

大型互聯網服務的體系架構有什么特點呢？以大型B2C電商網站為例，其功能至少應該包含以下幾個部分

商鋪
商品及庫存
銷售（促銷，活動等）
訂單
支付
物流
用戶
財務等數據統計和報表功能
其他支撐系統（例如訪問統計功能）

每個功能模塊都有自身的業務邏輯，且側重點各有不同，需要着眼的技術難點也不相同

商品的數據量較大，前端用戶對於高性能的檢索有較高要求，高並發時的庫存管理也要處理好；
訂單的狀態控制業務較復雜，數據量的累積很快；
支付和物流，與外部對接的技術復雜度一般較高；
報表功能一般后台計算量很大；

如何開發這樣的復雜大型系統，經過不斷地迭代和發展基本上找到了一條比較合適的道路：

將每個模塊都作為一個單獨的系統來進行架構設計和實現
模塊與模塊之間定義一定的接口規則來交互
每個模塊可以交由不同的團隊負責開發，並且可以根據需求選用不同的架構和技術棧

這時的每個模塊都擁有自己的輸入和輸出結構，相對獨立，可以被稱作一個服務。這種系統的整體架構就是SOA（面向服務的體系結構）。“它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。”，最重要的一點，“接口是采用中立的方式進行定義的，它應該獨立於實現服務的硬件平台、操作系統和編程語言”。

“這使得構建在各種各樣的系統中的服務可以使用一種統一和通用的方式進行交互。” --- 百度百科

隨着規模的增大，系統架構如何變遷到SOA的，Dubbo官方網站上有個很好的總結：

單一應用架構
- 當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
- 此時，用於簡化增刪改查工作量的 數據訪問框架(ORM) 是關鍵。
垂直應用架構
- 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。
- 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
分布式服務架構
- 當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
- 此時，用於提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。
流動計算架構
- 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率。
- 此時，用於提高機器利用率的 資源調度和治理中心(SOA) 是關鍵。

網站系統更加細節具體的架構演化，還可以參考一篇很好的博文 http://www.cnblogs.com/pflee/p/4507579.html

或者閱讀一本好書《構建高性能Web站點》

服務框架Dubbo

服務化的思路簡化了一些事情，但是也有一些問題尚未解決：

如果某個處理需要調用其他服務的接口，不像本地調用某個庫函數那么直觀方便，性能也有影響；
某個服務如果發生了變化，例如由於容量不夠進行了集群化，依賴這個服務的其他服務需要相應的做什么樣的調整，梳理需要花不少時間。
隨之系統規模的增大，服務數量也不斷增多，接口的URL很快的出現了爆炸式的增長，管理困難；服務與服務之間的依賴關系將越來越難控制，那個服務必須先啟動？我的服務癱瘓了會影響到誰？誰又會影響到我？

Dubbo[]是阿里開源的 ”一個分布式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案“，幫助我們解決上述的那些問題。

其核心部分包含:

遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“同步轉異步”和“請求-響應”模式的信息交換方式。　基礎功能
集群容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。 特色功能
自動發現: 基於注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。 重要功能