在路上—基於SCA規範的應用服務架構成長記(一)(連載中…)

        每個人在人生的不同階段都在成長，父母們為自己記錄了過去的成長曆程，自己也在成年以後記錄著自己的成長曆程。程式員或者架構師都有著自己的“孩子”，不論自己的孩子是好是壞，都為自己的孩子有一點成績而激動不已。現在的我也正在培育著一個自己的“孩子”，雖然在它成長過程中我要付出很多，但是看著它的成長，讓我覺得所有的付出都是值得的。因此通過這種方式，記錄下它的成長，記錄下遇到的種種困難和解決之道，為自己也為其他程式員架構師在培育“孩子”的過程中提供可能有協助的一些資訊。  一．初涉SCA       阿里新子公司成立，我也從業務開發組調動到了平台架構組，平台架構組當時的職責就是完善XPlatform來支援多個業務產品線部門的業務開發，XPlatform是基於MDA理念的快速開發平台。但隨著業務部門開發靈活性要求的日益增加，XPlatform在可定製化，模組化就日漸暴露出了不足。在4月份的技術戰略調整以後，開始了翻天覆地的XPlatform重構計劃，而我就被分配負責考慮底層架構重構以及服務架構的設計。       當時首先考慮模組化重構底層的時候，感覺OSGI是一個很好的方向，因此在重構服務架構前期的Cache模組時候採用了OSGI策略，可以動態替換Cache，但是在使用的過程中發現，此模組化並非我們所需的模組化。OSGI的模組化比較徹底，就連每個Bundle的dependency都是自己維護和管理，這樣對於動態載入和卸載提供了堅實的基礎，但同時也為它提供了最難處理的一個問題：複雜的ClassLoader機制。而回顧當前的業務開發情境，是否真的有這樣強模組隔離的需求，回答往往是否定的。而作為動態載入和卸載，的確是很好的一種特性，但是作為商業化的產品，特別是現在的互連網應用，機群中部署的應用模組往往來說並不需要單獨裝載和部署。另一方面來看OSGI面向的主要是對於單機服務開發模組化的解決方案，並非SOA的解決方案，而當前互連網應用在很大程度上需要互聯互連，模組化是基礎，但是並非最終的解決手段。       這時候開始關注與SCA，對於SOA具體實施的一種實踐性的規範，規範本身的模組化可擴充性給我留下了很深的印象。SCA和OSGI在模組化思想上有很多類似的地方，在SCA中Composite就是Bundle虛擬體，而SCA的優點就在於它只是規範，只是一種設計思想，不約束實現語言，平台以及其它細節，這也是互連網應用的一種趨勢。資訊共用達到資訊價值最大化，這是公司專屬應用程式的目標，在實現這個目標的時候需要拋開實現過程中的細節。就好比程式員往往關注的是使用什麼好的技術能夠開發出最炫的應用，而老闆關注的是如何在最短最快的情況下滿足使用者需求，兩者之間如何能達成雙贏，那麼就是架構師的職責了。       既然認定了SCA這條路，那麼就開始走吧，第一步當然是看規範，OSOA上關於SCA的規範十分詳盡。SCA規範雖然已經有些年頭了，但是正式納入OSOA並且成為一個較為廣泛認可的規範其即時間並不長，國外Sun,Bea都用一些類似的產品，但也沒有大規模推廣，而在Apache的孵化項目中Tuscany是SCA最出名的實踐開源項目，對於我來說當然是加入開源大家庭。我在接觸Tuscany的時候，它還是0.9之前的milestone2，但到現在為止，短短的幾個月，已經發布到了v1版本了，可見發展迅速。對於Tuscany的關注，我看見現在國內也越來越多，Tuscany最大的特點就是它的架構可擴充性很強，這也是SCA規範所需要的架構體系，要做到SCA的模組化和擴充性，必須有靈活的基礎架構作為支撐。       三下五除二，用Tuscany搭建了SCA規範中描述的幾個通用情境，簡單的java bean，spring的整合，非同步回調，rmi遠程調用等等，當然遇到了不少問題，由於Tuscany本身也是孵化過程中，最大的問題就是相應的文檔少，作為一個初學者，只能通過Demo瞭解大致的使用方式，遇到問題也就通過跟蹤它的代碼來學習，不過這個過程，讓我也對整個架構的體系架構有所瞭解，就如大牛所說，真正的體系架構是一個運行期的概念，而非設計期的，設計期其實就是SCA規範本身，而運行期的部分才是真正的體系架構。       預研終究是在做實驗性的工作，是否能夠產品化，還需要實踐來檢驗。XPlatform的重構正式啟動了，平台架構師們組織了一次內部重構技術方案討論會，我將前期的研究結果以及SCA的思想和實現都作了展示，同時結合我們重構的目標作了技術實施可行性介紹。與會的另外一個架構師提出了使用Spring實現SOA的ESB模式的解決方案，經過比較和討論最後我的計劃方案得到了肯定，但是我自己心裡其實也沒有底，畢竟如果真的在XPlatform的體系架構中實施SCA，那麼將會波及各個產品線的底層架構，如果後續出現無法修複的問題，那麼這個責任可不小。同時在過去的那些年頭，EJB就是一個很好的反面例子，一個規範理念是重要的，但是實施環境是否合適也會決定成敗，SCA是否適合未來的阿里軟體技術方向，當時的我沒有把握。最後我主動提出降低風險的設計方案，平台底層分成兩部分：基礎服務架構（BSF）和應用服務架構（ASF），前者主要應用於XPlatform內部核心組件的插拔互動，後者應用於上層應用的組裝，發布，互動。        Alisoft-xplatform-core-service-framework這個就是服務架構項目的子工程目錄名，也是我的SCA之路的第一步。當走出這第一步以後，就再也不能回頭了，常用老馬的一句話來激勵自己：我可能不是最聰明的人，也不是最努力的人，但是堅持可能就讓我比別人成功。Tuscany為我開啟了SCA的實踐之路，但Tuscany並不是像看起來那麼美，要走適合服務架構的SCA之路，難題才剛剛開始。