在雲端時代的開發趨勢,就是SOA架構。 ——台達電子雲端技術中心資深處長 翟本喬

台達電子雲端技術中心資深處長翟本喬曾為Google研發省電伺服器,目前正在開發台達電自家的雲端服務平臺。翟本喬認為,企業若要將自家軟體移轉上雲端平臺,必須把握3大關鍵來實踐軟體即服務(SaaS)平臺的彈性,達到快速甚至自動化地開關、伸縮與搬移,而且不受底層故障或不相容的影響。在應用上,SaaS平臺不再以獨立運作的單套軟體為中心,所有軟體功能及其功能元件都轉化為一個個服務窗口,環繞著使用者,透過API介面進行協同合作來完成使用者的任務。

真正要實踐這樣理想的SaaS平臺,在單套軟體與整體系統架構都必須符合雲端的概念。首先,SaaS平臺上的單套軟體都具備了Scale-out與容錯的能力,以充分發揮雲端兼顧高彈性與穩定的效益,而所有應用集結而成的SaaS平臺,整體的系統架構設計是高度模組化的服務導向架構(SOA),因而能打通個別應用的大門,讓所有功能元件沒有上下層級之分,都能在同一水平互相介接存取,以使用者為中心來提供服務。

關鍵1:要能Scale-out

在翟本喬的心目中,理想的雲端平臺要能讓企業Pay as you grow,企業使用這樣的雲端平臺時,不必理會每臺虛擬機器(VM)的規格大小,或要買多少臺VM才足夠,企業只要將軟體丟上雲端平臺,此平臺就能按軟體的負載量變動,來自動增減資源用量。

好比企業從頭到尾只用了一臺能彈性伸縮的VM,否則企業每次在軟體負載量攀升時,還要考慮將整套軟體搬到更大臺的VM,如此又會重回傳統Scale-up的觀念。

企業要實現Scale-out軟體,不只是IaaS和PaaS底層架構的協助,上層應用軟體也要設計為分散式運算架構,來支援負載平衡功能,才能做到Scale-out,軟體能夠Scale-out,才能充分發揮雲端平臺自動擴充資源的效益。

翟本喬表示,目前絕大多數軟體應用都偏向執行交易(Transaction-based)的需求,如訂票系統、一般網站服務等,每筆交易與服務要求(Service Request)的關聯度不高,很適合設計為分散式運算架構。透過分散式運算的設計,這套應用就能支援負載平衡功能,將過剩的負載量移轉到別的機器,可及時Scale-out。

然而,許多企業會用虛擬化軟體的vMotion或Live Migration功能,將負載量過高的應用系統從小機器搬上大機器,這樣只做到了Scale-up,與雲端訴求Scale-out的概念背道而馳。「企業真正需要的是負載平衡功能,而不是vMotion或Live Migration。」翟本喬坦言。

當企業設計分散式運算的軟體架構時,必須讓每臺機器都能互相溝通,合力完成軟體設定的任務,不會有特定任務必須交給特定機器執行的情況。翟本喬打了一個比方,一個大型的巨蛋運動場設立了數百個入口,每個人都必須拿門票於入口處驗票才能入內,每個入口處如同執行任務的機器,每次的驗票工作就是任務或稱為交易。

如果管理員開放所有入口處都提供驗票服務,容易發生不同入口重複放行拿了同一張票去影印的觀眾。為了避免分散驗票的作法造成重複放行的問題,以傳統的作法來說,巨蛋管理員只會開放單一個入口處進行驗票,因此降低驗票的速度。

翟本喬表示,正確作法應該是數百個入口都同時開放驗票,當A入口處查核過一張票後,必須通知其他所有入口已查核過此票,若其他入口又查到此票,就不許放行,其他入口收到A入口的通知,也必須發布已知此消息的回應。如此一來,所有入口就能同時驗票,且不會出錯了。更重要的是,當特定入口擁塞了過多人潮,還能將這些人潮移轉到其他入口,以分攤工作量,這就是分散式運算可達到負載平衡的好處。

這項驗票的例子呼應了企業設計傳統與雲端軟體架構的不同:傳統軟體往往有一個核心的集中式模組,底下延伸出許多子模組,建構起階層式且垂直林立的軟體架構,所有子模組必須經過上層的集中式模組,才能繼續工作。例如,所有元件都要存取同一套資料庫,這個集中式模組因為難以將工作量分攤給其他模組,容易成為整套軟體無法Scale-out的瓶頸。翟本喬表示,企業設計雲端軟體架構時,必須時時把握去中央化的概念,這樣的軟體才能Scale-out。

關鍵2:建立容錯機制

為了讓雲端軟體在動態Scale-out的過程中,仍能夠兼顧穩定性,雲端軟體還必須具備嚴密的容錯機制。此外,雲端平臺的龐大規模,也促使企業必須打造具備高容錯能力的軟體,因為雲端平臺上的軟體正在存取的資料或執行的任務,通常不知道現在正在哪臺機器上,任務可能隨時動態移轉到不同機器來執行,軟體在這一秒沒有存檔,下一秒這個檔案的儲存空間可能就被其他檔案複寫掉。以前IT人員尋找資料存放的磁區再復原的作法已不可行。

企業若要讓雲端軟體完全不受底層平臺影響,在最初設計軟體架構時,就必須把握容錯的觀念。容錯的核心觀念是讓軟體在執行程式的途中,在任何狀態下都要能夠挽救。

翟本喬舉了一個例子,當使用者編輯完檔案,要存檔時,系統若將舊檔刪除,再寫入新檔,那麼從刪除舊檔到存完新檔的過程,就可能遺失檔案,萬一新檔存到一半當機,使用者就會失去這筆檔案而難以挽救。正確的軟體容錯機制應該是,使用者替正在編輯的檔案以不同檔名開設成另一個新檔,同時保存舊檔,當使用者完成編輯後,先存好新檔,再將新檔復寫到舊檔上,萬一新檔或舊檔在編輯或讀寫過程當機,都還有另一個檔案存在,不會無法挽救。翟本喬指出,企業設計雲端軟體架構和程式運作程序時,也必須把握類似的容錯觀念,讓軟體隨時都能被挽救。

關鍵3:SOA系統架構

Scale-out與容錯是單套雲端軟體的關鍵特性,若是從整套的SaaS平臺來看,企業整體的系統架構設計必須符合雲端的精神,盡量設計為高度模組化的SOA架構,才能讓軟體實現任意開關、動態搬遷等雲端的彈性。「雲端時代的開發趨勢,就是SOA架構。」翟本喬說。

傳統企業軟體架構會依據不同部門來建立軟體,如財務、法務、人資、工程等在不同部門之下的軟體,個別軟體之間都是垂直並立或上下階層的關係,當使用者要跨部門取用不同軟體時,就必須自行前往個別軟體來使用,或在不同軟體之間的資料庫互相匯入和匯出資料。這樣的使用經驗是以軟體為中心,使用者必須掌握軟體之間的關係才能完成任務。

例如,每個月人事單位必須匯出人資系統的資料,再匯入薪資系統,才能計算出每位員工的薪水,若薪資系統改版或更換廠牌時,人資系統可能面臨資料格式不同或系統不相容等問題,而無法完成任務。

SOA架構可以解決這些問題,建立以使用者為中心的SaaS服務平臺。翟本喬說明,在SOA系統架構下,個別軟體當中的每個軟體元件都是服務,每個服務都提供API介面,開放給其他軟體取用,即使底層平臺執行服務的方式改變了,也不影響服務的運作。

此外,每個軟體元件具備無狀態(Stateless)的特性,每項任務要求傳遞給軟體元件時,該元件只在處理此要求時,會記得處理狀態。一旦將處理結果移交給使用者後,此元件就會忘記這項要求。藉此,這套軟體就能在沒有任何要求的狀態下,可隨時關閉和搬遷。

這樣的SOA架構做到極致,就能夠打造出以使用者為中心的SaaS平臺。因為每套軟體的功能元件都釋出了API介面,如同打通了個別軟體的大門,大門裡,所有元件都轉變為一個個的服務窗口,讓軟體與軟體之間、功能與功能之間能任意介接存取,彼此不是階層式的上下關係,而是同在一個水平面上的協同合作關係,協力完成使用者交付的任務。

此SaaS平臺可依據使用者的任務,串連起原本個別軟體的功能元件。例如,當企業要建立網路購物服務,SaaS平臺可透過API介面結合信用卡付款、美工編輯、貨運服務等不同功能元件,串連出這項服務。又如,每個月人事單位不必匯入和匯出不同系統的資料,人資系統會透過API介面自動存取薪資系統的年資和部門別等欄位的資料,自動計算每位員工的薪水。

翟本喬建議,現在企業還擁有許多傳統的軟體,不必急著一次轉換為雲端軟體,可以等到軟體自然汰換時,再把握Scale-out、容錯與SOA架構來開發,而企業目前正在開發的新軟體,就應該把握這3大關鍵來設計,才足以稱為雲端軟體。

改變軟體架構,而不是改變開發方式

以開發團隊的運作來說,翟本喬認為,企業不需要改變開發方式,要改變的是軟體架構設計,運用Scale-out、容錯與SOA等觀念來設計架構,軟體元件也要API化,這樣就能打造出SaaS平臺。


相關報導請參考「2012企業雲端開發術」


Advertisement

更多 iThome相關內容