1.10 探討傳統企業IT系統架構

傳統企業的IT系統有其自身的特點，不是照抄照搬互聯網企業的IT架構就能解決其問題的，但是可以借鑒相關的成功經驗。

1.10.1 從架構角度解決企業應用痛點

通過調研發現，企業應用系統面臨的三個主要痛點如下：

●靈活性差。

●交付時間長，動輒三個月或者半年，甚至一年。

●性能差，用戶體驗不好。

企業應用的痛點與解決方案如表1.1所示。

針對靈活性差，通過降低耦合度來解決也是軟件工程中的一個基本原則。這樣的問題反映出軟件設計及開發水平不高的現實。很多時候，開發人員分不清程序和軟件的區別，還只停留在功能實現的低水平上。這不單是靠優化架構就能解決的，還要靠提高整體開發水平來解決。

針對交付時間長，可以考慮從提高重用和組件化等方面著手，不斷積累企業應用組件庫。這好比燒磚建房，從實際需求出發，逐步建立并不斷更新有限的磚塊規格集合，未來所有的房屋都使用標準件來搭建。

針對性能差的問題，可以在組件化的基礎上逐步適度地進行服務化及分布式部署，這是因為不是所有的應用系統都適合服務化。有了這樣的基礎，對系統的擴展，包括水平擴展和垂直擴展，都會變得容易，分布式部署也會水到渠成。

1.10.2 企業應用系統架構服務化遷移步驟

通過對前面的痛點及解決方案的分析，可以總結出好的企業應用系統架構的三要素與三步走策略，如圖1.8所示。

●組件化。

●服務化。

●分布式。

組件化是服務化的基礎，服務化是和多進程/多線程相關的，是以降低應用部署粒度和降低耦合度為基礎的。“對象”“組件”“服務”三者之間的關系如圖1.9所示。

而分布式部署的基礎是進程/線程間的通信。要理解 RPC（遠程過程調用），最好先理解IPC。

1.10.3 企業應用系統架構服務化參考模型

針對企業應用系統架構的服務化，提出通用的概念模型（如圖1.10所示），考慮了多種邏輯和物理架構。該模型是結合企業應用，并基于多層分布式體系結構而進行實例化的，其具體解釋說明如下：

●應用組裝層只能調用服務，不能直接訪問基礎能力提供者。

●開放服務之間沒有依賴關系。

●私有服務層用來實現基本的邏輯處理。

●基本能力通過私有服務暴露。

●私有服務能夠相互調用，調用關系必須是樹形結構的，避免形成調用環。

●對于開放服務需要由注冊機構管理，例如：哪些服務可用、怎樣調用、使用狀態如何，以及服務終止、版本更新等。

希望該模型能夠覆蓋企業的全部應用，包括基于Package的二次開發系統（如SAP、Oracle），基于SaaS的云應用（如salesforce.com），以及基于Java/.Net自開發的一些應用。在實踐中逐步完善這個模型，希望能為企業架構的優化助力。