AspectW：剖面導向之例外處理與重試機制 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National Chengchi University 碩士論文 Master’s Thesis. 立. 政治大. ‧ 國. 學 ‧. AspectW：剖面導向之例外處理與重試機制. n. al. Ch. engchi. er. io. Mechanism. sit. y. Nat. AspectW: an Aspect-Oriented Catch and Retry. i n U. v. 研究生：高沛功指導教授：陳. 恭. 中華民國一百零三年六月 June 2014.

(2) AspectW：剖面導向之例外處理與重試機制 AspectW: an Aspect-Oriented Catch and Retry Mechanism. 研究生：高沛功. Student：Pei-Gong Kao. 指導教授：陳. Advisor：Kung Chen. 政治大國立政治大學資訊科學系碩士論文. 學. ‧ 國. 立. 恭. sit. y. ‧. Nat. A Thesis. er. io. submitted to Department of Computer Science. n. al National Chengchi University iv. n U i Requirements in partial fulfillment e n g cofhthe. Ch. for the degree of Master in Computer Science. 中華民國一百零三年六月 June 2014. ii.

(3) AspectW：剖面導向之例外處理與重試機制. 摘要. 雖然絕大多數的現代程式語言都有嚐試與補獲（try-and-catch）的例外處. 政治大理機制，提供開發人員撰寫模組性高的例外處理程式碼，既可以立即處理立. ‧ 國. 學. 例外狀況，也可以將例外傳遞（propagate）到系統其他模組。但是很多例外情況是暫態的（transient），發生後，應用程式是有可能從例外狀況恢. ‧. 復（recovery）過來，而不必啟動例外處理的程序。例如：分散式系統在. y. Nat. er. io. sit. 進行網路連線時，可能因為網路一時不穩定而失敗，但稍停幾秒後再進行連線就可以了。於是就有學者倡議擴充例外處理機制，增加補獲與重試. al. n. v i n Ch （catch-and-retry）的功能。本研究採用剖面導向（aspect-oriented） engchi U 的觀點，參考 AspectF 的方法來實作一個輕量級的補獲與重試模組， AspectW，讓開發人員可以“流利（fluent）介面”的方式輕鬆撰寫例外捕獲與重試的程式碼，達到了讓開發人員不必更動主功能邏輯程式碼就能簡單地加入補獲與重試的功能。. 關鍵詞―Exception, Exception handling, Try-and-Catch, AOP, Catch-and-Retry iii.

(4) AspectW: an Aspect-Oriented Catch and Retry Mechanism. Abstract. Most modern programming languages support try-and-catch mechanism that enables developers to write modular exception handling code. 政治大 them to the other modules 立 in the system. However, many exceptions which can not only process exceptions immediately but also propagate. ‧ 國. 學. are transient, when occurred, the application is likely to recover from the exception, thereby rendering it unnecessary to start up the. ‧. exception handling code. For example: during a network connection. sit. y. Nat. in a distributed system, you may fail due to network instability. er. io. moment, suffice to wait for a few seconds and then re-connect it.. n. Thus, some scholars ainitiate to expand thevexception handling. i l C n h e n g c h i Umechanism. This thesis takes mechanism, and proposed catch-and-retry an aspect-oriented point of view, and adapts the AspectF library to implement a lightweight level catch-and-retry library, AspectW, so that developers can use the “fluent interface” approach to easily write exceptions capture and retry code. As a result, developers do not have to modify the main logic code and could simply add catch-and-retry code to handle exceptions well. Keywords―Exception, Exception handling, Try-and-Catch, AOP, Catch-and-Retry iv.

(5) 誌謝. 首先誠摯的感謝我的指導教授陳恭老師，從提案開始就嚴格細心的指導，不時的討論並指點我正確的方向，研究其間數次的進度報告也不斷指正，使我在這二年中獲益匪淺。. 治政兩年的日子裡也要感謝同學們的支援。因為是在職專班相處時間不算大立 ‧ 國. 學. 長，但透過網路科技可以明顯感受到這真是一群嘰嘰喳喳的同學們，在嘰喳有餘中課程作業的相互支援、互相玩笑。也要感謝學長們的幫助與學習. ‧. 心得的分享。. sit. y. Nat. 感謝我親愛的家人，感謝父母養育我、同理我、關心我，在我人生低. er. io. n. al 點時給予我溫馨的打氣。感謝兄長看重我、鼓勵我、支持我，使我仍能保 iv. n U engchi 有前進的動力。女朋友在背後的默默支持更是我前進的動力，沒有的體諒、. Ch. 包容，相信這兩年的生活將是很不一樣的光景。最後，謹以此文獻給我摯愛的雙親。高沛功謹誌國立政治大學資訊科學研究所在職專班中華民國１０３年３月１８日。. v.

(6) 目錄. 第１章緒論 ............................................................................................ 1 １.１前言 .......................................................................................................... 1 １.２研究動機 ................................................................................................... 2 １.３研究目的 ................................................................................................... 3 １.４. 治政研究成果 ................................................................................................... 5 大立 ‧ 國. 學. １.５論文大綱 ................................................................................................... 6. 第２章相關研究與技術背景 ................................................................... 7. ‧. ２.１ Catch And Retry ....................................................................................... 7. sit. y. Nat. io. n. al. er. 2.1.1. Basic Retry ....................................................................................... 10. i n U. v. 2.1.2. Parameterized Retry ........................................................................ 10. Ch. engchi. 2.1.3. Recovery From Multiple Exception ................................................... 11 2.1.4. Scheduling Control Over Retries ...................................................... 11 ２.２ Aspect-Oriented Programming ............................................................... 12 2.2.1 AOP 術語 .......................................................................................... 13 2.2.2 How AOP Works: Weaving ............................................................... 17 2.2.1 AOP Benefits .................................................................................... 18 ２.３ Implementing Retry - Featuring AOP ...................................................... 19 vi.

(7) 2.3.1 Related Works For Catch And Retry ................................................. 21 2.3.2 Architecture And Programming Model .............................................. 23 ２.４ AspectJ ................................................................................................... 26 ２.５ AspectF .................................................................................................. 29 2.5.1 AOP 的一般案例................................................................................ 30 2.5.2 一個簡單的 AOP 框架....................................................................... 32 2.5.3. 政治大與一般 AOP 方案比較....................................................................... 33 立. ‧ 國. 學. 第３章系統設計與架構 ........................................................................ 35. ‧. ３.１設計理念 ................................................................................................. 35. sit. y. Nat. 3.1.1 緣由 .................................................................................................. 35. n. al. er. io. 3.1.2 理念 .................................................................................................. 37. Ch. i n U. v. 3.1.3 功能規劃 ........................................................................................... 37. engchi. 3.1.4 為何決定打造 AspectW .................................................................... 39 ３.２設計原理 ................................................................................................. 47 3.2.1 AspectW 核心原理 ............................................................................ 47 3.2.2 Catch-And-Retry 指令設計 ................................................................ 53 3.2.3 Restore 設計原理說明 ....................................................................... 57 3.2.4 常見例外故障情境與指令下法........................................................... 59. vii.

(8) ３.３. 設計過程 ................................................................................................ 63. 3.3.1 AspectW 核心碼開發過程 .................................................................. 63 3.3.2 AspectW 補獲與重試指令設計過程 ................................................... 64 3.3.3 與 AspectF 的重試指令比較 .............................................................. 65. 第４章系統實作與展示 ........................................................................ 67 ４.１實作語言與工具 ...................................................................................... 67. 二個 Facebook 案例套用 ................................................................. 74. ‧. 4.2.2. 三個基本應用模式 ............................................................................ 69. 學. 4.2.1. ‧ 國. ４.２. 政治大系統實作展示 .......................................................................................... 69 立. sit. y. Nat. 第５章結論與建議 ............................................................................... 79. n. al. er. io. ５.１結論 ........................................................................................................ 79. Ch. i n U. v. ５.２未來發展 ................................................................................................. 80. engchi. 參考文獻 ............................................................................................... 81. viii.

(9) 表目錄表３.1 AspectJ 與 AspectF 比較表 ....................................................................... 46. 圖目錄. 政治大. 圖圖圖圖圖. １.１１.２２.１２.２２.３. OOP 程式碼模型圖 .................................................................................. 3 AOP 程式碼模型圖 .................................................................................. 3 行動計算架構圖 ....................................................................................... 8 主從式架構圖 ........................................................................................... 8 Basic Retry .............................................................................................. 10. 圖圖圖圖圖圖圖圖圖. ２.４ Parameterized Retry ................................................................................ 11 ２.５ Recovery From Multiple Exceptions ....................................................... 11 ２.６ Scheduling Control Over Retries ............................................................. 12 ２.７ AOP 概念圖解之一 ................................................................................ 13 ２.８ AOP 概念圖解之二 ................................................................................ 14 ２.９ AOP 術語示圖 ........................................................................................ 16 ２.１０導入 AOP 前 ....................................................................................... 17 ２.１１導入 AOP ............................................................................................ 17 ２.１２ “retrying”語法結構 ........................................................................... 21. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. 圖２.１３圖２.１４圖２.１５圖２.１６圖２.１７圖２.１８圖２.１９圖２.２０圖２.２１. al. Ch. engchi. i n U. v. 以 C# 組織有次數上限的“retrying” ............................................... 22 Spring Batch 的 retry 範例 .................................................................. 22 AspectJ 範例一之 Hello...................................................................... 26 AOP 範例一之 World ......................................................................... 27 Aspect 類別範例 ................................................................................. 27 Join Points in AspectJ .......................................................................... 28 AspectJ Notation 轉換說明 ................................................................ 29 AOP 的一般案例 ................................................................................ 31 AOP 的一般案例 2 ............................................................................. 32. 圖２.２２ AspectF 一般案例 ............................................................................... 32 圖２.２３ AspectF 語法 ....................................................................................... 33 ix.

(10) 圖圖圖圖圖圖圖圖. ３.１３.２３.３３.４３.５３.６３.７３.８. 雲中樹網路模型圖 ................................................................................. 35 AspectJ 重試標籤簡化範例 ................................................................... 38 AspectW 重試範例 ................................................................................. 39 購物車結帳單計算程序 ......................................................................... 40 購物車結帳單計算程序 with AspectF .................................................. 41 主功能區與縫合區關聯比較 ................................................................. 42 一個 AspectW 使用範例 ........................................................................ 46 剖面功能 TraceBefroe 原始碼 ............................................................... 48. 圖圖圖圖圖圖圖圖圖. ３.９剖面功能 RetryOnce 原始碼 .................................................................. 48 ３.１０核心原始碼之一 Combine 函式原始碼 ............................................ 49 ３.１１核心原始碼之一 Do 函式原始碼 ...................................................... 50 ３.１２ AspectW 基礎語法 ............................................................................. 52 ３.１３指定故障的應對方式 ......................................................................... 55 ３.１４ REF<T>類指標類別 ........................................................................... 57 ３.１５ REF<T>使用範例 ............................................................................... 57 ３.１６ AspectW 用在 Catch-And-Retry 機制的指令下法............................ 59 ３.１７ Catch-And-Retry 頻率最高的指令形式 ............................................ 60. 圖圖圖圖圖圖圖圖圖. ３.１８多重例外狀況處理 ............................................................................. 60 ３.１９ Parameterized Retry & Ignore ............................................................. 61 ３.２０發射導彈(firing a missile)................................................................... 61 ４.１ Basic Retry with AspectW ....................................................................... 66 ４.２ Basic Retry without AOP mechanism ..................................................... 66 ４.３ Parametered Retry with AspectW ........................................................... 67 ４.４ Parametered Retry without AOP mechanism .......................................... 67 ４.５ Recovery From Multiple Exception with AspectW ................................ 68 ４.６ Recovery From Multiple Exception with AspectW - part1 ..................... 68. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖４.７ Facebook Status Updates - scenario ........................................................ 75 圖４.８ Case Study : Facebook Status Updates with AspectW ............................ 75 圖４.９ Organizing a Facebook Event – scenario ................................................ 77 圖４.１０ Case Study : Organizing a Facebook Event with AspectW ................. 77. x.

(11) 第１章緒論１.１. 前言. 補獲與重試(Catch-And-Retry)機制並非是個新顈的觀念。對於處理通訊網路上暫態的. 治政 (transient)故障，在雲端運算(cloud computing)時代以前是較不重視的，大都當作是大立偶發的例外。而量變造成質變，網際網路社交應用掘起，如：Facebook 、Twitter、WhatsApp ‧ 國. 學. 等的大規模分散式系統(large-scale distributed systems)，每日傳遞的訊息量已達. ‧. 十億次數等級了。在百萬次通訊等級偶發的例外故障，到了每日十億次通訊等級的規模後就不是偶發而是“常常”了，對於提供服務的廠商若不處理這“常常”發生的故障，. y. Nat. io. sit. 對本身的產品品質形象的質變是會有危害的，當客戶們從網路等媒體開始流傳品質不良. er. 的傳言是會影嚮產品行銷的。. al. n. v i n Ch 透過補獲與重試機制並無法根治大規模分散式系統在長程通訊上暫態的例外故 engchi U. 障，通訊對象可能位在地球另一端，訊號路徑可能長達數千公里且路程還有無數個交換設備。不過補獲與重試機制可以降低通訊故障的發生機率讓品質不良的質變效應不要出現。在技術上套用補獲與重試機制對於開發人員來說常常是困擾人的，尤其是當系統已上線一段時間在功能調整、需求增加與系統維護後程式碼已變成了交互糾纏(tangled) 的狀態。本研究採用以 AOP(aspect-oriented programming)觀念為基礎，設計了 AspectW 模組讓開發人員可以方便、簡易又彈性的加入補獲與重試機制。. 1.

(12) １.２. 研究動機. 例外處理(exception handling)的研究一直是程式語言研究發展的重要議題。在今天的程式語言中，例外(exception)為開發人員提供了當發生一些故障或其他特殊情況時引發和傳遞出訊息的機制，此機制稱為嚐試與補獲(try-and-catch)。而這機制並不包括進行相應的反應，並從這些故障和其他條件中恢復(recovery)，因為這些復甦過程通常是依各應用程式狀況而定。然而，我們相信在大規模分散式系統有一套通用的復甦機制存在，因為我們觀察到一個現象。特別是在大規模的網絡服務，以及其他分散式系統中，. 政治大. 雖有多種的故障與錯誤要對抗，而我們發現對抗的方式就是什麼都不做僅僅稍停數秒再. 立. 重新執行剛剛出錯的指令即可。在瀏灠網站與寄送電子郵件(email)時偶有這樣同樣的. 學. ‧ 國. 體驗。把這樣的體驗轉換成一個機制，就是補獲與重試(catch-and-retry)機制。. ‧. 補獲與重試機制其實是軟體在通訊應用時品質提昇的一個機制，在單機系統上討論這一項是沒有什麼意義的，在討論系統架構時常是被忽略的。它在大規模分散式系統架. y. Nat. io. sit. 構下才會顯得出意義。在討論軟體系統演算法或是建構系統的主要架構功能時通常也不. n. al. er. 會把它放在心上。在建構系統的雛型階段這項考量在大部份況狀是不須要的。問題就出. Ch. i n U. v. 在後續的實作到上線的過程，它就真的被忽略了以致系統上線後問題才開始。對於接手. engchi. 維護的開發人員來說，這些長期維護的系統程式碼只有糾纏不清。常為了加入一項機制而必需牽動許多的程式碼。這又讓程式碼糾纏的狀態更加的嚴重，整體狀況變成了負向循環，也讓程式碼設計意圖的可讀性與理解度不斷的下降。要讓程式碼在長期維護過程中不會互相糾結纏繞是有方法的就是導入 AOP[1]。AOP 的研究背景原因之一就是要對抗糾纏不清的程式碼，也有了相當多的研究基礎與應用。我們研究了數種 AOP 實作方案，發現了一個輕量、簡單又實用的 AOP 技術，在考量評估後決定引進。我們引進了 AspectF[9]的 AOP 實作方法，在觀點上它提高對縫合(weaving) 的重視，在技術面上導入 “流利介面(fluent interface)”[10]的設計，讓開發人員. 2.

(13) 使用時可以更順手也更有彈性，可以在流程程式碼中依需要把剖面功能縫合到流程邏輯之中並成為一體。在此研究我們結合了 AOP 觀念與 AspectF 的實作方法再加入為補獲與重試機制設計的剖面功能指令，設計並實作出 AspectW，可以用來防止程式碼慢慢地變成糾纏程式碼 (tangled code)狀態，也可以同時簡單地把補獲與重試機制加入到程式邏輯裡而不必牽動過多程式碼。. １.３. 研究目的. 政治大實現補獲與重試機制可以從三個層面下手： 1)在系統初始設計階段就從結構面最小化立. ‧ 國. 學. 通訊故障帶來的衝擊。2)執行平台支援，使用具有補獲與重試能力的執行環境。3)應用程式特別制定。本研究著重在應用程式特別制定這一層。. ‧. 在組織流程程式碼時又可拆分成主功能邏輯程式碼與非主功能機制程式碼，這一點. Nat. sit. y. 剛好與 AOP 觀念相呼應，其中非主功能機制可以對照成剖面功能。補獲與重試是屬於非. n. al. er. io. 主功能機制，也就是輔助的，所以常在開發過程被忽略總是在事後回頭來加入，而在這. i n U. v. 之前若未導入 AOP 的話通常要牽動許多已組織好的程式碼，因而會有意想不到的狀況發生。. Ch. engchi. 研究 AOP 在商務領域的應用。我們可以想像如圖 1.1 OOP 程式碼模型圖，一個網路. 圖１.２ OOP 程式碼模型圖. 圖１.１ AOP 程式碼模型圖. 3.

(14) 購物平台系統透過 OOP(Object-oriented programming)方法把各作業功能切割後，比如：瀏覽商品、購買商品、留言評論，各個子功能在理想上是完全獨立不相依的。可仔細查看內部每道完整的作業流程中都有“security”程式碼段落檢查是否依然有效的登入認證，還有“logging”記錄使用行為的程式碼。這相同局部的程式碼幾乎完全一樣，所以會做成共用元件，只要共用元件一改變全部流程都改變了，也就是說各業務功能在實際上並非完全不相依。改用 AOP 的觀念來看同樣的內容。請參考圖 1.2 AOP 程式碼模型圖，圖中“Func.. 政治大. code”代表主功能邏輯程式碼；“Non-func. code”代表非主功能機制程式碼。AOP 的. 立. 研究告訴我們有些程式碼就是無法被明白的封裝起來，這部份程式碼就定義為剖面. ‧ 國. 學. (aspect)。這些非主功能機制程式碼基本上都是剖面。這些剖面普遍性散佈在各作業功能的局部，有些目的相同、邏輯也相當所以是可以共用的，可以把共同的機制做成可重. ‧. 複使用的元件，在使用上差異的部份用參數化來處理。透過縫合(weaving)把剖面也就. sit. y. Nat. 是就非主功能機制與主功能邏輯組合成完整的流程。在縫合的過程中主功能邏輯程式碼. n. al. er. io. 不必為了配合而做邏輯調整，也就是不會有像前面所提牽一髮動全身的狀況了，只需針對性的更動局部就行了。. Ch. engchi. 重新整理這份研究的目標，主要有：. i n U. v. 一、具有 AOP 的優勢。二、提供容易使用的語言機制(language mechanism)，讓開發人員可以簡易地在系統內加入補獲與重試機制。三、其中補獲與重試機制並具有兩項特性：隔離(isolation)、復原(recovery)。. 4.

(15) 在補獲與重試機制部份，它不只是一個指令而已，也不是終端使用者會提出的需求，它是一個產品品質議題。研究此機制所真實面對的故障情境，與開發人員經常使用的應對動作，並考量整體運作的行為模式再轉換成指令設計方向，整理如下：一、 Retry，補獲到故障後重新執行出錯的指令，過程中可能會適當的變更參數。二、 Restore，補獲到故障後立即進行應用程式狀態(application state)的還原。三、 Ignore，忽略補獲到的故障。有時有些故障是可以忽略的，比如：按讚。可能. 政治大. 有重試過幾次可最終就是失敗，這時忽略若不影響大局就忽略掉吧。. 立. 四、 Handle Fail，用於進階的操作。補獲到故障無法以常用的方法應對時，就必. ‧ 國. 學. 需再依當時狀況制定應對措施。. ‧. 以上這四類指令設計於呼應補獲故障時通常的行為模式：是否要重試？可以忽略不管嗎？故障使得應用程式狀態不正常嗎？要復原狀態嗎？常用的方法無效必須依個案. y. Nat. er. al. n. 研究成果. io. １.４. sit. 加入特別的措施嗎？. Ch. engchi. i n U. v. 本研究基於前述研究動機、研究目的並蒐集相關文獻與技術探討。實作文獻中提到的可行方案，綜合了研究成果設計了一個模組，一個具有使用上高彈性的類別，取名為 “AspectW”，此名稱中的“W”代表著強調縫合(weaving)的能力。這是一個小型模組也可以用小工具來形容，它極輕量。AspectW 除了提供一些已被判定為剖面功能的基本指令外，最重要的是特別為補獲與重試機制設計了一組動作指令。依照前一節研究目的提到的四個應對例外故障的動作指令，這些指令也依面對的狀況差異提供了一些多載 (overloading)版本，讓開發人員可以輕鬆的使用。此研究主要的成果有：. 5.

(16) 一、引入一種極輕量的 AOP 實作技術，AspectF。應用 lambda expression 的原理特性即可實作出來，不必複雜的 dynamic proxy、IL(Intermediate Language) 等技術。二、重構 AspectF[9]的核心，設計了 AspectW，剖面功能改以補獲與重試機制為主要應用。三、整理出了補獲與重試機制的四個動作指令設計方向：retry、restore、ignore、 handle-failure。其中 retry 指令再分成 basic retry 與 parameterized retry。. 政治大. 這些指令可以在不影嚮主功能邏輯程式碼下可簡單輕鬆的加入或移除。. 論文大綱. ‧ 國. 學. １.５. 立. 本論文主要分成五個章節，第一章為緒論，主要在介紹整個研究的源起與概要特點，包. ‧. 括了前言、研究動機、研究目的、研究成果及各章節概述。第二章是相關研究與技術背. Nat. sit. y. 景，補獲與重試機制的來龍去脈介紹。AOP 的研究心得。以 AOP 實現補獲與重試機制要. n. al. er. io. 具備的規格與特徵。也研究 AOP 實作的領導者之一 AspectJ 的原理與使用方法。研究過. i n U. v. 程中的幾種其它實現方案與 AspectJ 大同小異就不再特別討論。也特別要介紹 AspectF. Ch. engchi. 這個評估後決定採用的 AOP 解決方案，它提出了對剖面(Aspect)的新看法與實作原理。第三章詳細說明設計理念、設計考量、為何決定打造 AspectW 與設計原理。第四章嘗試以真實的案例來展示此系統。最後第五章提出結論與未來可能的發展。. 6.

(17) 第２章相關研究與技術背景這一章節將介紹此研究的背景與主要歷程，過程中一些不打算採用的部份則忽略不記。在章節 2.1 Catch And Retry 介紹源由；章節 2.2 Aspect-Oriented Programming 介. 政治大. 紹 AOP 的觀念；章節 2.3 Implementing Retry 介紹達成的規格與特徵；章節 2.4 AspectJ. 立. 介紹 AOP 實作的領頭者；章節 2.5 AspectF 介紹本研究決定採用的實作技術。. ‧ 國. 學. ２.１. Catch And Retry. ‧. Catch And Retry[3]是一個程式語言編碼的機制(mechanism)，適合應用在多層架構的. sit. y. Nat. 分散式應用系統。這個系統可能是以大規模伺服器端架構(large-scale server-side. al. er. io. infrastructure)為主的應用，有資料中心(data center)、它的用戶端(client-side). v. n. 可能是以 JavaScript 編製的 web application，如：Facebook、Google+、Twitter 等類似的社交應用系統。. Ch. engchi. i n U. 在網際網路盛行的現代，資訊系統架構分分合合又分分，從大型主機架構[5]為主演進成主從式架構(如圖 2.1)近幾年有變成行動計算架構為主(如圖 2.2)。在行動計算架構下系統的離散程序又更勝以往。大型主機架構或主從式架構大概是一台伺服器端服務好幾台客戶端。到了行動計算架構就變成可能好幾台伺服器同時服務非常多台的客戶端。而資料訊息在此複雜的網路通訊路徑傳遞過程中出現例外性錯誤的機率將大大的提昇。在今天的程式語言中，例外(exceptions)為開發人員提供一項機制用以觸發和傳遞已發生的一些錯誤或其他特殊情況的訊息(signal)。一般來說這些機制都沒有產生對應 7.

(18) 政治大的反應，並從這些錯誤訊息和其他條件進行復原，因為這樣的復原反應通常是由應用程立圖２.１行動計算架構圖. 圖２.２主從式架構圖. ‧ 國. 學. 式另外再特別的加工來支援。. 在今天的程式語言中，例外(exceptions)為開發人員提供一項機制用以觸發和傳遞. ‧. 已發生的一些錯誤或其他特殊情況的訊息(然而，我們相信存在一套復原機制(recovery. Nat. io. sit. y. mechanism)可以套用在分散式系統中。. n. al. er. 特別是大規模的網絡服務以及其他分散式系統中，必須對抗多種多樣性常見的故障. Ch. 和錯誤，這些錯誤可以統括分類成二類： . engchi. i n U. v. 資料性錯誤(Data errors): 維持資料的新鮮度和一致性在分散式系統中的代價是昂貴的，甚至在某些狀況下是不可能辦到的。這樣的資料錯誤可能包括讀取過時(reading stale)的值或讀取來自多個不同源頭的資料庫。. . 可用性錯誤(Availability errors): 也或許是因為網路分區(network partitions)，硬體故障(hardware failures)，性能跳針(performance stutters)，或軟體缺陷(software bug)的關係，當遠端的服務已失效或反應緩慢時，分散式系統的編碥工作中必須對這些狀況都有對應的準備與處理機制。. 8.

(19) 當然 Data errors 並非完全與 Availability errors 完全無關，有些 Data errors，比如：資料遺失，可能是因為某部份的儲存體可能失效造成的。這些在網際網路服務和其他許多分散式系統的錯誤通常可以在各個設計階層進行處理： 1）在系統初始設計結合節點和數據複製以盡量減少這些誤差的影響； 2）在系統基礎架構層級檢測和修復相關的故障（例如，通過重新啟動、重新映像失敗的節點）； 3）在應用程式編程階段處理使用者介面與系統性能部份。整理了這些方法，可以實際運用的復原機制包括：. 政治大. Re-execution of failed operations：重新執行出錯的指令。 . . Scheduling control：重新排程執行出錯的指令，指定該指令在何時(when)、何. ‧ 國. 立. 學. . 處(where)、是否(whether)執行。 . ‧. 這兩個機制可以混合同時使用，也是大部份已被常用的技術原則。Catch And Retry. Nat. sit. y. 是建造一個程式碼區塊(block)的復原機制。其結果是一個易於使用的語言機制，可以. n. al. er. io. 大大簡化復原程式碼的撰寫。然而只是重新嘗試是有缺陷的，比如無限的重新嘗試錯誤. i n U. v. 的指令。解決的方法之一是簡單的指定重試次數以避免無限循環的危險，處理多重的例. Ch. engchi. 外時也可以變更參數後再重新執行原指令，這些參數也可提供在重試排程中。 Catch And Retry 重新嘗試在語意上的關鍵字整理起來只須幾個： try, catch, retry, fail, finally。在功能面部份要能滿足幾項需求： 1) 指定重新嘗試次數，以避免無限次迴圈的危險。 2) 可以處理多重的例外，同一指令可能有多種可能的錯誤出現。 3) 在重新嘗試時可以被參數化，不同的參數但滿足相同的目的，或許品質可能降低一些但目的不變。下面將以案例來說明這些。. 9.

(20) 4) 對指令設定排程參數，當該指令出錯時依排程參數重新嘗試。. 2.1.1. Basic Retry 當程式執行過程中一但由例外機制發出了資料性錯誤或可用性錯誤，在程式語言階層上使用 retry 關鍵字表示要重新嘗試 try 區塊程式碼。範例將以 C#語法說明，類似的語法在不同的語言如 Java、JavaScript 一樣有效用。一個選擇性的整數參數指定可重新嘗試 try 區堆幾次，如：“retry 3;”。表示可以最多可以重新嘗試３次且這參數必需是常數。若沒有指定重試次數那就假設與“retry 1;”同意。限制允許的重試次數可以防. 政治大. 止可能發生無限的重試。圖 2.3 是一個範例。. 立. 儘管試圖依多次的重新嘗試特定的. ‧ 國. 學. try 區塊，還是會有這些重新嘗試的動作最終還是失敗的狀況。為了處理這種情況，. ‧. 每個 try 區塊可以選擇性的伴隨一個 fail. Nat. sit. y. 區塊用來處理指定的重新嘗試次數後依然. n. al. er. io. 還是失敗的狀況。在 fail 區塊若希望把例外送往更外層處理，那就簡單的再. Ch. engchi. “throw;”不必指定參數。需注意一點，. i n U. v. 圖２.３ Basic Retry. 若在多重例外的狀況下將以第一個遇到的 fail 區塊為主。. 2.1.2. Parameterized Retry 愛因斯坦定義過何謂精神錯亂：“同樣的事情做了一遍又一遍，並期待有不同的結果”。但在在分散式系統中，重新嘗試相同指令常可導致不同的結果，例如：當故障 (fault)只是暫態的(transient)或者該系統具有不確定性(non-deterministic)。在 Parameterized Retry 的語法中把參數明列放在 try 後面，表示這是在重新嘗試時為可修改的。若該參數沒指定新值就使用原值。在 try 區塊中不可以變更這些明列在. 10.

(21) try 後的參數。要注意一點，在 try 區塊中是沒有交易屬性的。換句話說，重新嘗試 try 區塊之前可能會已有副作用(side-effects) 了，這是在上一次的執行 try 區塊時的例外往外丟時留下的。圖２.４ Parameterized Retry. 在本文提供的圖 2.4 Parameterized. Retry 範例中，主要流程目的是 SendMessage，目的是採用 HTTPS 協定傳送訊息給朋友，. 政治大. 若失敗時把協定換成 HTTP 再重新傳送訊息給朋友，使用不同的方法，但目的是一樣的。. 立. 2.1.3. Recovery From Multiple Exception. ‧ 國. 學. 一個指令執行時可能有多種的失敗狀況，這是常見的分散式系統狀況之一，故可以處理多重失敗是 Catch-And-Retry 機制必要的功能之一。. ‧. 例如本文中的範例，如圖 2.5，從網絡. y. Nat. er. io. sit. 讀取資料時若網路連線出現故障時會先稍為稍停一小段時間再重新嘗試，稍停一小段. n. al. Ch. 時間是因為在分散式系統的網路錯誤常只. engchi. i n U. v. 是短暫的。在重試了五次還是連不上就認定. 網路已確實斷線了。在此同時，若遇到的資料讀取過時的狀況這時就先刷新資料後再. 圖２.５ Recovery From Multiple Exceptions. 重新嘗試讀取資料程序。Catch-And-Retry 會自動分派正確的例外處理的 catch 區塊。. 2.1.4. Scheduling Control Over Retries 雖然發生故障時立即重新嘗試往往是有用的。也有很多時候，我們知道立即重新嘗試機制是不可能成功的，除非有些額外的條件先滿足才行。比如，若遠端的主機需先完成重新開機的程序；比如，有些遠端的中繼資料或 cache 尚未完成刷新程序等。. 11.

(22) 為了支援此情況，必需擴展 catch 區塊的功能讓它可以接受有明確指定重新嘗試的操作函式。以本文範例圖 2.6 中的 r 函式，此函式抓取 (capture) 原所屬的 try 區塊的功能，這個函式 r 同時也有封裝性 (closure)的特質。要注意，此機制的一個. 圖２.６ Scheduling Control Over Retries. 重要的問題是可能會破壞原先設計好的流程，要注意流程結構不要因為重新排程而破. 政治大. 壞。也有些功能邏輯是無流程性的或是可有可無的，比如 Facebook 中的按讚功能。. 學. ２.２. ‧ 國. 立. Aspect-Oriented Programming. ‧. 在這一段將說明 Aspect-Oriented Programming[1](AOP, 剖面導向程式設計[2])的觀. sit. y. Nat. 念。AOP 是在 1997 年由 Xerox Palo Alto 實驗室所提出，此概念一提出立即引起程式語. io. al. er. 言與軟體工程方面學者與專家的重視與迴響，之後相關的各種研究陸續發佈出來。其中. n. 又以該實驗室以 Java 為基礎的 AOP 程式語言 AspectJ 最盛行。. Ch. engchi. i n U. v. AOP 的研究背景是基於發現使用 OOP(object oriented programming)方法來開發系統的許多問題。OOP 無法足夠有效的清楚的把程式碼中的各局部的內容用意清楚表達，最終程式碼總是會變成複雜的糾纏程式碼(tangled code)狀態，即程式碼交互纏繞難以理解該段代碥的邏輯與用意，不但維護難度增加，若要加入新的機制也是難上加難且還常有意想不到的例外狀況。軟體設計流程(software design process)和程式語言(programming language)存在著一個相互支援的互助合作關係。在軟體設計流程中會把系統向下分割成較小的單元。程式語言提供機制讓開發人員(programmer)把這些抽象的系統子單元各別實作出來，然後這些子單位再依不同的方式組合，最後產生整個系統。若程式語言對這些抽象 12.

(23) 過的子單位本身就有合適的語法機制支援，且設計流程分割出來的子單元也適合程式語言實作的話，它們的合作就會相當的良好，程式碼也能清楚的表達各局部的設計用意。可實際上設計流程與程式語言之間的鴻溝是不窄的，比如：商業程序、認證機制、參數驗證機制、交易機制、記錄機制等，同時組合在一整串的處理流程。用相對的角度來看，一個軟體系統可以區分成可被封裝的元件(component)與無法被封裝的剖面(aspect)。而這兩部份可以被“縫合(weave)”成一體。在真實的應用系統開發上其程式碼有三種狀況：容易理解但效率差，有效率但不易. 政治大. 理解，還有以剖面基礎(AOP-based)實作可以同時有效率與容易理解。換句話說，AOP. 立. 的目的就是要讓程式程式碼具有高度的可讀性，同時也保有高度的執行效率。. ‧ 國. 學. 2.2.1 AOP 術語. ‧. 有關於 AOP 的許多名詞術語都過於抽象不易理解，單從字面上並不容易理解其名詞意. sit. y. Nat. 義，這邊將配合圖形來說明。. er. io. 一、Cross-cutting concern. al. n. v i n 在幾個不同的業務流程程式碼中，記錄程式碼常以橫切(cross-cutting)型式加入。 Ch engchi U. 其它如安全(Security)檢查、交易(Transaction)等系統層面的服務(Service)，在一些應用程式之中也常被安插至各個業務物件的處理流程之中，這些動作在 AOP 的術語中被稱之為 Cross-cutting concerns。以圖形來說明 Cross-cutting concerns 的意涵，例如圖 2.7，原來的業務流程是很單純的。現在為了要加入記錄（Logging）與安全（Security）. 13. 圖２.７ AOP 概念圖解之一.

(24) 檢查等服務，業務物件的程式碼中若被硬生生的寫入相關的 Logging、Security 程式片段，則可使用以下圖 2.8 圖解表示出 Cross-cutting 與 Cross-cutting concerns 的概. 立. 念。. 政治大. 圖２.８ AOP 概念圖解之二. ‧ 國. 學. Cross-cutting concerns 若直接撰寫在負責某業務物件的流程中，會使得維護程式. ‧. 的成本增高，例如若您今天要將物件中的記錄功能修改或是移除該服務，則必須修改所. y. Nat. al. er. io. sit. 有撰寫曾記錄服務的程式碼，然後重新編譯，另一方面，Cross-cutting concerns 混. v. n. 雜於業務邏輯之中，使得業務物件本身的邏輯或程式的撰寫更為複雜。二、Aspect. Ch. engchi. i n U. 將散落於各個業務物件之中的 Cross-cutting concerns 收集起來，設計各個獨立可重用的物件，這些物件稱之為 Aspect。例如在登錄的動作設計為一個 LogHandler 類別， LogHandler 類別在 AOP 的術語就是 Aspect 的一個具體實例，在 AOP 中著重於 Aspect 的辨認，將之從業務流程中獨立出來，在需要該服務的時候，縫合(Weave)至應用程式之上，不需要服務的時候，也可以馬上從應用程式中脫離，應用程式中的可重用元件不用作任何的修改。另一方面，對於應用程式中可重用的元件來說，以 AOP 的設計方式， 14.

(25) 它不用知道處理提供服務的物件之存在，具體的說，與服務相關的 API 不會出現在可重用的應用程式元件之中，因而可提高這些元件的重用性，您可以將這些元件應用至其它的應用程式之中，而不會因為目前加入了某些服務而與目前的應用程式框架發生耦合。三、Advice Aspect 的具體實作稱之為 Advice，以記錄的動作而言，Advice 中會包括真正的記錄程式碼是如何實作的，像之前提到的 LogHandler 類別就是 Advice 的一個具體實例，. 治政大 Advice 中包括了 Cross-cutting concerns 的行為或所要提供的服務。立 ‧ 國. 學. 四、Joint Point. ‧. Aspect 在應用程式執行時加入業務流程的點或時機稱之為 Join Point，具體來說，. n. al. 五、Point Cut. Ch. engchi. er. io. 之後（或兩者都有），或是某個例外發生的時候。. sit. y. Nat. 就是 Advice 在應用程式中被呼叫執行的時機，這個時機可能是某個方法被呼叫之前或. i n U. v. Point Cut 是一個定義，藉由這個定義您可以指定某個 Aspect 在哪些 Join Point 時被應用至應用程式之上。具體的說，您可以在某個定義檔中撰寫 Point Cut，當中說明了哪些 Aspect 要應用至應用程式中的哪些 Join Point。六、Target 一個 Advice 被應用的對象或目標物件。七、Introduction. 15.

(26) 對於一個現存的類別，Introduction 可以為其增加行為，而不用修改該類別的程式，具體的說，您可以為某個已撰寫、編譯完成的類別，在執行時期動態加入一些方法或行為，而不用修改或新增任何一行主功能邏輯程式碼。八、Weave Advice 被應用至物件之上的過程稱之為縫合(Weave)，在 AOP 中縫合的方式有幾個. 政治大. 時間點：編譯時期(Compile time)、類別載入時期(Class loading time)、執行時期 (Runtime)。. 立. ‧ 國. 學. 結合以上介紹過的 AOP 相關名詞具體的使用圖 2.9 來加以說明，有助於對每一個名. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖２.９ AOP 術語示圖. 詞的理解與認識：. 16. v.

(27) 2.2.2 How AOP Works: Weaving 未使用 AOP 開發的軟體系統，開發過程中主功能邏輯與非主功能機制的程式碼是混合在一起的。當上線維護一段時間後，需求或規格的調整，程式碼也不段的增加或移除，原本就混合的程式碼再混入更多的程式碼。在這過程中，常會使用使用一個技巧，「複製、貼上」，這個技巧可以稱為“scattering”，因為這個技巧讓同一用意的程式碼分散在多處。慢慢地經過一段時間不斷的再增加或移除程式碼，這情形就像是「溫水煮青蛙」謎思一樣，程式碼會越來越讓人難以理解，通常在上線三、五年後的程式碼就會變成糾. 政治大. 纏的(tangled)狀態變得難以理解，尤其是負責人更換以後會更明顯。. 立. 以下將以一個案子來說明縫。如圖 2.10 導入 AOP 前，其中‘logging’(紅色)部份是. ‧ 國. 學. 非主功能機制；而 ‘core’(綠色)部份是主功能邏輯。我們可以看到‘logging’的程式碼是分散的，雖然它的用意是一體的。此商業邏輯在實務上是經常應用的，比如：購買商. ‧. 品，在購買前的紀錄表示客人有意願購買，此部份在“log start”位置實作。在之後. n. al. er. io. sit. y. Nat. 客人可能買了也可能最終不買，這狀況我們也想紀錄，此部份在“log end”位置實作。. Ch. engchi. 17. i n U. v.

(28) 在導入 AOP 時，這些‘logging’部份的程式碼可以移動到新的 class，而原來‘core’ 的程式碼原封不動。接下來使用 AOP 工具把‘core’與‘logging’程式碼依照指定好的 “point cut”位置進行組合。這個組合的程序就稱為縫合(Weaving)。可以用圖 2.11 導入 AOP 圖例來說明。圖左“Functional code”是主功能邏輯程式碼 class；圖右 “Non-functional code”是非主功能機制程式碼 class。在經過縫合程序後產生新的 class，這個 class 把主功能邏輯程式碼與非主功能機制程式碼組合成一體。. 2.2.1 AOP Benefits. 立. 政治大. 這一小節將說明使用 AOP 的好處，整理後簡述如下：. ‧ 國. 學. . Clean up spaghetti code. ‧. 程式碼不再像義大利麵一樣交錯複雜，變得比較乾淨比較清析，也就會比較容易閱. n. al. . Reduce repeating. 圖２.１１導入 AOP 前. Ch. engchi. er. io. sit. y. Nat. 讀，也就比較容易理解。可以一眼就知道主功能程式碼在那，非主功能程式碼在那。. i n U. v. 使用 AOP 後，一個普遍常用的編碼技巧「複製、貼上」就不需要了。也就是程式碼重複的部份也大大減少。所謂良好編碼的一個重要指標 DRY(Don’t Repeat Yourself) 也可達到。 . Encapsulation. 系統的封裝程度也會提昇，程式碼重複引用程度也獲得提昇。把邏輯程序中 Crosscutting concern 的程式碼抽取出來移至新的類別，更改程式碼時也不用處處更改只需. 圖２.１０導入 AOP 18.

(29) 更動一處即可。. ２.３. Implementing Retry - Featuring AOP. 每天都有經驗告訴我們，有些錯誤是非常短暫的，單單只須要重試(“retrying”)就能處理掉這些錯誤。比如，網路傳輸路徑上的電子訊號干擾可能讓遠端的設備在一個短暫的時間週期裡讓訊號無法送達。比如，一個遠端應用服務突然在一小段時間的存取衝到. 政治大就能讓系統正常的持續運作去下，我們只須要重新執行這個失敗的指令即可。立. 高峰，而讓部份請求服務被拒絕。在很多的情形下，也不需要提供任何種類的復原機制. ‧ 國. 學. 可惜的是，重試指令在很多執行平台或是程式語言是沒有明確的支援的。且重試也不是萬能的不該盲目的使用在所有的不正常狀況。. ‧. 一些程式語言，如：C#、Java 或有支援重試指令的程式語言，如：Smalltalk 和. y. Nat. io. sit. Eiffel 其錯誤處理都是透過例外機制“exception”來溝通此錯號訊號。而且並沒有一. n. al. er. 個簡單的方法在企圖重試前去清除前一回合執行失敗時留下的產物。開發人員必須明確. Ch. i n U. v. 的提供指令程序且有時很複雜又傾向出錯的程式碼(error-prone code) ，來修複程式. engchi. 執行產出的產物或還原到原先執行前的狀態。. 在這份文件裡，我們打算以 AOP 技術實作“retrying”。此方法可以讓開發人員不必再特地去撰寫狀態清除程式碼(“state-clean” code)去清除指令錯誤時的不正常產出。重試一個已出錯的指令是常被我們使用的一個修復策略。儘管如此，此策略只限制在幾個要點上才有效果，這些出錯的指令是不是“等冪的(idempotent)” --- 意指同一指令不管執行幾次的結果都是一樣的，且開發人員原本就打算讓一些指令或函數本身就具有可以重新執行的特性。. 19.

(30) 考慮當今的軟體資訊系統與網路或網際網路(WWW)大多有強烈的連結，那麼使用者或者應用程式對於這些極短暫性、臨時性的跳針般的錯誤現象要有通用性的應對方法。例如：使用瀏覽器去瀏覽某個網址時，第一次執行時出現了該網頁不存在的訊息回報，可稍停個二、三秒再重新瀏覽同個一網址卻成功了。同樣的，例如寫好了一封 E-mail，在第一次按下送出指令到 STMP 伺服器時失敗了，可是第二次再做同樣的按下送出指令到 SMTP 伺服器卻成功了。其發生的原因並非總是相同的可能是多種變化的，像是伺服器可能太忙著另一個或數個先到的服務要求；或可能是網路在一小段時間失效了，一個. 政治大必去做任何種類的狀態復原或修復動作，只要重新嘗試執行失敗的指令就能使得系統在立不預期的某項資源臨時性的沒有作用了。然而，我們也確實觀察到一個實際的現象，不. 正常的狀態再持續運作下去。. ‧ 國. 學. “retrying”在有時也或許不是首選的方法，有時它必須預先稍停一小段或幾秒定額. ‧. 的時間後才開始再度重試前次失敗的指令；有時它或許要重試多次以上才會成功；有時. y. sit. n. al. er. io. 須同時運用。. Nat. 它或許在重試前必須把程式狀態或來龍去脈回復到與執行前一樣；也或許這些動作都必. i n U. v. 然而，對於任一的案例，一位老練的開發人員總是有辦法輕易的就能應付這些繁瑣. Ch. engchi. 俗事。一個比較大的議題是：如何用一個簡單的風格撰寫出等冪指令(“How to write idempotent operations in a simple manner?”) 。儘管如此，有些運算指令也許是難以達到此目標的，尤其是數量較大的較謹慎設計完成的運算指令。此外，這類應用程式內的工作中本身已有提供了方法來自動修復應運算指令錯誤造成的應用程式不正常狀態。有些程式語言，例如：Smalltalk 和 Eiffel ，有實作出“retry” 指令的結構，但大部份的開發人員認為並不容易使用，因為開發人員自己必須返回前次運算失敗的不正常產出。這等同強烈暗示著所引用的運算指令在存取使用時是否具備“等冪”的特性。一. 20.

(31) 般來說這是相當困難的，因為光是呼叫函數的堆疊方法就可能有數種。此外為了代入這些返回前次運算的額外程式碼程序，可能迫使開發人員必須打破已設計完好的程式封裝結構 --- 此封裝結構正也是所謂好的應用程式設計的關鍵點之一。. 2.3.1 Related Works For Catch And Retry 關於“retrying”的語法結構組成與內容，以下將以 C# 語法形式來表達，當然相同的設計精神也能應用在不同的程式語言。. 治政大如下圖 2.12 所示，在設計好的 try 立區塊是具有交易性質(transactional) ‧ 國. 學. 的。因此，在這個受保衛的區塊內被叫. ‧. 用的運算指令都算是交易的一部份。當執行緒進入 try 區塊時交易就開始啟. y. Nat. er. io. sit. 動，若區塊內完整的執行過程沒有引發任何的例外狀況的話，在離開區塊時會. n. al. Ch. 有提交(commit)動作。若有例外被引. engchi. i n U. v. 發，那交易就立即中止，並跳到對應的 catch 指令區塊的起點，在這一點上能. 圖２.１２ “retrying”語法結構. 夠執行必要的操作，以嘗試解決該問. 題，並允許剛剛失敗的運算區塊再重新嘗試執行。一個重點是，在應用程式中運作當中的 heap 與 stack 記憶體變數的滾返(rollback) 以使得應用程式的狀態是乾淨正常的。執行恢復操作後，重新執行受保衛的區塊可以由開發人員要求指定與否。. 21.

(32) 這例子雖然簡單，但以指出了“重新嘗試”語意結構的基本設計原則。其中“retry” 指令在幾個程式語言是有效用的，像是 Smalltalk、Ruby、Eiffel。這些程式語言的對 retry 關鍵字的運用就像是 goto 關鍵字一樣，遇到例外後跳入對應的處理程式碼區塊，再進行恢復、還原等運算指令，然後再判定是否重新執行。很明顯的，若故障導致的問題沒有得到解決的話，那將導致一個無限的循環。為 retry 指令指定一個次數上限是個很簡單的解法。即使程式語言不支援“retrying”的語法結構，我們仍可以使用其它的語法組合來獲. 政治大. 得相同的效果，例如 C#，可以合併 for/while 迴圈語法與 try-catch 語法來組合出. 立. 學. ‧ 國. “retrying” 語法結構。. 右圖 2.13 為一範例。考慮到 SQLException 的異常原因可能是因為服. ‧. 務尚未啟動完成。這是合理的考量，故. y. Nat. io. sit. 先稍停十秒後再重新開啟連線，除非成. 圖２.１３以 C# 組織有次數上限的“retrying”. n. al. er. 功連線了或重試次數達到上限。. Ch. 使用 AOP 機制，相同的結果可以在. engchi. i n U. v. 更有組織的方式和橫向來撰寫程序程式碼。如果我們考慮異常處理的程序的橫切面，其中引發異常的位置是理想的點(join point)為處理異常發生插入(weaving)程式碼 (advice)。例如在 Spring.NET 可以宣告一些規則(point cuts)去縫合例外處理的程序(advice) ：在 Spring 1.2 版提供 AfterThrows 介面，到了 Spring 2.0 支援了標籤(annotation)語法. 22 圖２.１４ Spring Batch 的 retry 範例.

(33) @ThrowAdvice。不管採用那一種語法結構，確定的是當有例外被引發時，都要有對應的 advice 來接續處理。通常情況下，每個 advice 會有一個引數參數指向所引發的例外類別(exception class)。. 2.3.2 Architecture And Programming Model 例外的處理模型，以現代的程式語來說（如：C++，C#，Java）共同使用 try 區塊來“防衛(guard)”在執行期可能引發例外的運算指令。在我們所設計的程式模型裡，程式中的. 政治大. try 區塊是具有交易性質的。它可以滾返(rollback)失敗的運算的不正常產出，且允許. 立. 重新嘗試在使用時可以驗證，程式碼變得更乾淨、更容易維護，而開發人員也不必花費. ‧ 國. 學. 精力去恢復應用程序的不正常狀態的這件事解脫出來。事實上這是我們和傳統的異常處理模型的方法之間的主要區別。這也是整個方法的關鍵點。也可以說是此系統的交易類. ‧. 型，實際上已符合了 STM(Software Transactional Memory)框架，使得 try 區塊變成. er. io. sit. y. Nat. atomic。. 整理了以上的討論，可以歸納出重新執行 try 區塊時至少必須保證二個要件：. al. n. v i n Ch U data structures, etc.)就是應用程式狀態(variables, e n gheap, c h istack,. 一、. 在那當下，在那第一次進入 try 區塊的當下。二、. 該 try 區塊必須是隔離的(isolated)，這意味著如果執行外部的 I/O 操作，它必須能夠撤消他們或者他們必須是等冪的(idempotent)。. 此兩個要件將在後續討論。 Restoring Application State. 23.

(34) 復原應用程式狀態是至關重要的，其用以保證開發人員的設計意圖得以保持。例如，如果一個開發人員在一個 try 區塊內累加變數“total”，如果該區塊由於例外而被重新執行，在完成區塊內的運算離開後，該變數只能被累加一次。有幾種可行的方法可以用來恢復應用程式的不正常狀態。典型的方法包括：法一、執行緒進入受保護的區塊中，為所有與其接觸的物件建立一個副本。此副本是用來在運算時更新的。如果該區塊正常的完成離開，原先所接觸的物件再由副本來更新取代原值。如果發生了重試程序，那副本就會被丟棄，這等同保存了原先的應用程式狀態。. 政治大. 立. ‧ 國. 學. 法二、不建立副本。直接更新其所接觸的物件，但所有的更新都會留下紀錄。該程式碼區塊若正常的離開其更新紀錄就可以丟棄。如果發生了重試程序，那剛剛的更新. ‧. 紀錄就用來還原所接觸的物件，等同也還原了原先應用程式的狀態。. Nat. sit. y. 這些方法的實作細節都有各自棘手的部份。在物件導向的平台，第一種方法感覺更. n. al. er. io. 自然，儘管它比第二個方法需要更多的記憶體和嚴重依賴垃圾收集器(garbage. i n U. v. collector)的執行。關於交易模式(transactional model)在我們的系統是不可或缺的. Ch. engchi. 的部份，也已形成了一個更一般化的議題：STM(software transactional memory)。STM 在不同的執行平台也都有一些實作，也有用於網際網路的離散式交易的研究，但到現在為止效果還是不命人滿意。所以決定此研究不使用 STM 工具或模組，改提供一些輔助的功能函數達到相同的效果，同時也減化開發人員在例外發生時欲還原應用程式狀態的需求。 Isolation in try blocks 正如前面所提，然而只是保留應用程式的狀態是不夠的。例如有些運算是具有嚴峻挑戰的，例如：我們不希望存入相同的金額到銀行帳戶超過一次；我們不希望寫入相同. 24.

(35) 的數據到磁碟多於一次等等。若出現這類情形則表示著這個交易運算不具隔離性 (isolation)。此外，有一些 I/O 操作是不能撤銷的，就像“發射導彈(firing a missile)”一樣。然而，仍然必須允許同時存在交易性程式碼與非交易性程式碼在同一段程式程式碼中。因此，在執行時期(runtime) 去區別出運算類別(class)是否交易性是需要的。一個簡單的方法是直接在開發時期明確指定所有的交易性物件類別都要實現 Transactional 介面，稱做 Transactional-aware class。此介面至少要提供三個 callback 函數：一個告. 政治大. 知已進入交易程序了；一個告知交易運算正常完成可以提交(commit)了；一個告知交易. 立. 要撤銷。而且這交易行為的提交與撤銷在巢狀結構下也要有效用。採用這方法顯然有時. ‧ 國. 學. 會太過複雜或麻煩且似乎也不實際。其實也只有執行外部的 I/O 運算時才須要小心的以這個方法標記。實現這類 callback 函數的複雜度各不相同，用語意來整理說明可以清. ‧. 楚的表示了二個方向：. y. Nat. er. io. sit. 一、若 I/O 指令已叫用可以先暫時緩存它，直到提交(commit)訊號到達才真的寫入。二、在某些情況下有些 I/O 運算可以設計成等冪的運算，這就代表著它可以被重複. n. al. 執行多次但結果都一樣。. Ch. engchi. i n U. v. 最後一點，這點與現行資料庫系統是一樣的，比如：有一個交易中先前寫入的數據被讀取了，而此交易尚未提交，那就會有資料衝突發生。在外部 I/O 操作上此類問題還沒有通用的解決方案，只能小心的防止它發生。大部份的情況下都是簡單的提供掛鉤 (hook)來撤消或檢測衝突。在一般的開發平台上，直接參與外部 I/O 內部運算是極其有限的。在任何狀況下，若證明交易太難以達成那就選擇讓它變成非交易性的運算吧。. 25.

(36) ２.４. AspectJ. AspectJ 是由 Java 語言延伸的 AOP 語言。每一個有效的 Java 程式就是一個有效的 AspectJ 程式。AspectJ 的編譯產生出符合 Java byte-code 規範，可執行在 Java virtual machine(JVM)。在 AspectJ 經由編譯縫合非主功能的實作稱為橫跨(cross-cutting)。AspectJ 定義了兩種橫跨：靜態橫跨(Static Crosscutting)和動態橫跨(Dynamic Crosscutting)。. 政治大動態的。動態橫跨的擴展，甚至取代了核心程序執行流程從而改變系統的行為。立. 動態橫跨是縫合非主要功能至主要功能的執行流程之中。大多數 AspectJ 橫跨都是. ‧ 國. 學. 靜態橫跨是修改系統靜態結構（如：類別、介面和剖面）的縫合。其本身不改變系統的執行行為。靜態橫跨最重要的功能是支援動態橫跨的實作。例如：想要新增成員變. ‧. 數成員函數至類別或介面中，為了確定特定類別的狀態和行為。這可被使用在動態橫跨. y. Nat. 以下以案例來說明如何使用 AspectJ：. n. al. Ch. engchi. AspectJ 範例一：Hello & World. er. io. sit. 的行為上。另外，靜態橫跨可以被使用在宣告編譯時的警告和錯誤的橫跨多個模組。. i n U. v. 使用 AspectJ Compiler 開發 AspectJ 程式，“Hello” 與“World” 分別由主功能類別與剖面類別各自輸出。準備主類別 Hello 程式用一般 Java 寫法即可。. 圖２.１５ AspectJ 範例一之 Hello. 再寫剖面類別 World，寫法有些不同其目的在縫合 Advice。. 26.

(37) 圖２.１６ AOP 範例一之 World. 編譯與執行後畫面上出現 ==> Hello World 注意到了嗎，“Hello”與“World”並非在同一字串一起輸出，在主程式中只有印出 “Hello”而已。然而透過剖面縫合程式碼，在此範例上，在呼叫完 main()函式後會接續執行印出“ World”。. 立. 政治大. ‧ 國. 學. 在此簡單的範例可以看出基本的 AspectJ 結構，其組成分成三大部份：原主功能類別(此例為 Hello)、剖面類別(此例為 World)與非主功能類別。其中非主功類別就是在. ‧. 剖面類別中與 point-cut 逢合的部份，此例為“System.out”。. Nat. sit. n. al. er. io. 2.17 所示。. y. 以下再看另一個剖面類別的案例，這個案例是接近實際應用案例的一個簡化，如圖. Ch. engchi. i n U. 圖２.１７ Aspect 類別範例. 27. v.

(38) 此案例中定義了一個 point-cut 名為“stateChanges” ，它會將映射到主功能類別程式碼中類別名稱是“Subject”，成員函式名為“click()”的位置。也定義一個 advice，當跑完 stageChanges 關節後，也就是“Subject.click()”跑完後，對原主功能類別 “Subject”內部屬性進行更新。在 introduction 段落裡，甚至也能為主功能類別添加新的成員變數與成員函式“observers”和“getObservers()”。 AspectJ 定義的 Joint Points 大概可以涵概了 class 所有的節點，可以分成四類： object creation、method invocation、field access、error handling。在 Advice. 政治大. 執行時間點可以是 before、after 或 around。在圖表 2.18 明列。. 立. ‧. ‧ 國. 學. Nat. sit. y. 圖２.１８ Join Points in AspectJ. n. al. er. io. 也有人研究用 UML 來表達剖面，設計一套 Aspect-Oriented Design Notation[13],. i n U. v. 可在設計階段能視覺化呈現 AspectJ 剖面部份。圖 2-19 是一個範例。. Ch. engchi. 28.

(39) 立. 政治大. ‧ 國. 學. 圖２.１９ AspectJ Notation 轉換說明. ‧. 由圖左標準的 UML interaction 圖形轉變到圖右的 AspectJ Design Notation，圖. sit. y. Nat. 中是轉變的中繼圖形。由圖左中的«JavaCreate» stereotype 由一個轉化成三個. io. er. «create»、«execute»和«initialize»；«JavaCall» stereotype 由一個轉化成二個 «call»和«execute»；«JavaLoad» stereotype 也是由一個轉化成二個 «load» 和. al. n. v i n C h都能再有三重 advice，before、after、around。我們 «initialize»。這些 stereotype engchi U 從外部角度來看此設計，可以發現此設計等同擴張了系統的對外接觸面。AspectJ 的擴張能力已強大到甚至可以改變主功能流程的行為，從而可以使得 Aspect Class 甚至由輔助變成主要，這個強大若用的好是好，若用不好的話麻煩就大了。. ２.５. AspectF. 在研究了數種 AOP 的實作方法我們認為 AspectF[9] 是最好的解決方案。現在已知只在 C#/.NET Framework 有實作。其它的方案以 AspectJ 為領頭為學習對象。AspectJ 的功. 29.

(40) 能強大，對 AOP 的實現也最為完整，但我們實際使用的評價是太複雜、不易使用。AspectJ 功能最強大完成度也最高但太複雜易用性低，而 AspectF 功能較精簡但好用。在技術上以 lambda expression 為核心再進行應用。這個方法超乎想像的簡單，卻也能讓程式碼撰寫更乾淨清晰、可維護性也更高。. 2.5.1 AOP 的一般案例剖面(Aspect)是在撰寫程式程式碼的過程中，出現在不同的運算程序中的局部相同區段中有著相同的功能片段，例如它可能是一種處理異常的方法，也可以是呼叫方法時的紀. 政治大很可能出現在程式的不同局部地方且有一些是重複使用(reuse)多次的。如果在編碼的立錄(logging)意圖，或者是呼叫函式的執行花費時間記錄(time execution)，這些部分. ‧ 國. 學. 過程中沒有使用任何的 AOP 框架的話，那麼將重複的撰寫這些相同的程式碼，這將使得你的程式碼難以維護。例如你的業務邏輯層需要進行日誌記錄，錯誤處理，執行時間需. ‧. 要記錄。. Nat. sit. y. 以下舉一個一般的情境案例，如圖 2.20 所示。此案例中撰寫了一些實際的程式碼，. n. al. er. io. 這個程式片段實現了客戶資料的插入操作，同時程式中還有日誌記錄、異常處理和時間. i n U. v. 記錄的操作，由於這種多機制多設計意圖的程式碼混合，在閱讀的邏輯上就顯得混亂可. Ch. engchi. 讀性也變差。但是設想一下，如果要在業務邏輯中添加驗證或其它剖面的時候，那麼隨著程式碼的增加業務邏輯將會變得更亂，真是要多亂有多亂，也就是變成了糾纏程式碼 (tangled code)狀態。而且當增加業務邏輯規則時，常需要不斷的「複製、貼上」程式碼，再微調每個業務邏輯層的部份。例如：你需要在業務邏輯中增加一個 UpdateCustomer 的成員函式，你就必須再「複製、貼上」程式碼一遍再微調，這真是很苦悶的一件事。. 30.

(41) 立. 政治大. ‧. ‧ 國. 學圖２.２０ AOP 的一般案例. sit. y. Nat. 再想像一下，對於業務邏輯變更來說，如果我們的項目需要大範圍的修改例外處理. n. al. er. io. 的方式，那你就必須把所有業務層的方法一個一個的進行修改。然後如果新的需求又來了，要修改時間統計的方式…這過程真是苦不堪言啊。. Ch. engchi. i n U. v. 剖面導向程式設計解決了上述問題，如圖 2.21 所示，其功能邏輯與圖 2.20 是一樣的，看起來是不是很簡潔呢？在 AOP 中，例如把 logging ，time execution，validation 這些剖面從業務程流程式碼中進行分離。如上例所示，你可以通過 Attribute (在 java 稱為 annotation) 解決，這樣的程式碼乾淨又清析，這裡每一個 Attribute 代表一個剖面。例如：通過增加 Logging 剖面你可以進行日誌記錄。總之，無論你用了什麼 AOP 框架，它都保證了剖面在運行時被編入了你的程式碼中。. 31.

(42) 圖２.２１ AOP 的一般案例 2. 2.5.2 一個簡單的 AOP 框架. 政治大 AspectF 不是使用 Attribute 或是操作反射(reflection)來實現，只是簡單的對目標指立. 使用 AspectF 來達成與上一節所提需求有相同效果，如圖 2.22 所示。在應用語法上. ‧ 國. 學. 令區塊指定剖面功能就行了。使用這種方式的程序具備了很高的重用性和可維護性，而最重要的是它很輕量級，還能使得縫合(weaving)變得極有彈性，極適合多變的業務規. ‧. 則變化。. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖２.２２ AspectF 一般案例. AspectF 相當的輕量，在結構上只有一個類別(class)名稱也就是“AspectF”。而它的剖面可以簡單的再自訂新增以應付多變的需求。如上述案例所示的程式碼，AspectF 語法不太傳統，用簡化的 EBNF 表示法來簡單說明基礎語法：. 32.

(43) 圖２.２３ AspectF 語法. 將 AspectF 語法與範例比較就能很清楚其結構。AspectF 的語法結構分成三個部份。首先是“Aspect.Define”，表示即將包裹(wrapping)其下的一塊業務邏輯程式碼區塊，並將為它添增一些剖面功能函式。第二部份是“Do()”函式，把商業邏輯包裹住，不. 政治大. 必有其它的修改。要注意的是別忘了加上大括號“{”與“}”，因為 Do()函數的參數型別其. 立. 實是個 lambda expression。在後面的設計原理再詳細介紹，此段重點放在如何使用與. ‧ 國. 學. 為何好用、易用。第三部份就是依需求在“Aspect.Define”與“Do()”中間加入<Aspect Function>，圖 2.22 的例子中有 Log 與 HowLong 兩個。. ‧ y. Nat. er. io. sit. 2.5.3 與一般 AOP 方案比較. 通過 AspectF 我們就可以在業務邏輯的外部直接指定剖面功能，同時使業務流程主功能. n. al. Ch. i n U. v. 邏輯程式碼與非主功能機制程式碼分離但又鄰近在旁。可以輕易理解完整的業流程同時又不會交互糾纏。。. engchi. 讓我們看一下它與通常的 AOP 解決方案在特徵上有何不同： (1) 不在類別的成員函數的外面定義剖面，而是在的内部直接定義。 (2) 以函數實現剖面，取代以類別實作剖面的方式。再以 AspectF 的特性來看，它有以下優勢： (1) 使得業務流程的剖面更清晰。. 33.

(44) (2) 可以不用過度考慮性能的損失，因為它只是一個輕量級的類別。在內部運作原理其實是以 lambda expression 為核心。 (3) 剖面功能函數可以傳遞參數。有些 AOP 方案是不允許這麼做的。 (4) 甚至不能稱為一個框架，因為它只是一個叫做 AspectF 的類別而已。 (5) 可以在流程程式碼的任何位置設置剖面也能用於迴圈內與巢狀結構，使用彈性極大。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 34. i n U. v.

(45) 第３章系統設計與架構在建置大規模分散式的網際網路應用服務，例如：搜尋引擎、電子郵件服務、社交網路應用等等，開發人員必需花費不少的精力處理資料性錯誤(Data errors)與可用性錯誤. 政治大. (Availability errors)，目的之一是讓系統不因一些例外故障而停止運作或讓使用者. 立. 感觀上的認為“又當機了”。而這些例外故障中有一部份都是暫態的(transient)，非常. ‧ 國. 學. 短暫且無法預期，像是跳針一樣，完全不做任何處理在幾秒後重新執行出錯的指令卻又成功了且不影響系統的運作狀態。本系統將以補獲與重試(catch-and-retry)機制來處. ‧. er. io. sit. Nat. 以簡易地又不衝擊主流程狀況下加入補獲與重試機制。. y. 理這些例外故障，在技術上採用我們設計的 AspectW，一個極輕量的 AOP 實現方案，可. 在這章節將會對系統設計原理進行介紹，包含簡介系統設計架構、系統設計方法及. n. al. Ch. 如何使用 AOP 特點來達成本系統的設計理念。. ３.１. engchi. i n U. v. 設計理念. 3.1.1 緣由網際網路近年來的發展已是超越一般化的遍及了，從早期主機到工作站，數年前開始普及到家庭個人電腦，幾年前又盛行到個人行動智慧裝置，手機、平板等。個人使用一個以上裝置同時上網已是常態。在主機伺服器方面，在 Google 引領下開始拋棄超大型主機為主的架構轉向叢集架構為主。幾年前開始雲端運算，主機伺服器虛擬化形成主流。這些硬體部署演進與軟體應用演進是互相影響著。不管是採用或混用那一類雲端技. 35.

(46) 術 IaaS、PaaS 或 SaaS 都只會讓系統部署更分散且是動態的分散。我們可以用一個簡化的模型來描述此狀況，就先稱作“雲中雲網路”模型吧。也不過在數年前，想要描述網路的複雜度只需一朵雲就夠了。而現在，尤其是網路、主機都虛擬化後用一朵雲來代表網路的複雜度是不夠的，而是雲中有雲，網路中有網路，實體網路中有虛擬網路。如圖 3.1 所描繪，我們可以想像一個現代的網際網路應用系統，它有自己的商業邏. 政治大. 輯，用“Biz Srv”表示；可也引用了第三方. 立. Google Map 等等；在認證時又採用另一個第. 學. ‧ 國. 的元件服務，用“Widget Srv”表示，比如. 三方認證服務，用“Authz”表示，比如. ‧. Facebook 等。現代的社群網站、照片分享等. Nat. y. 圖３.１雲中樹網路模型圖. er. io. sit. 應用服務大多符合此模型。. 在如此複雜的網路中，訊號的實際傳遞路線可能有上千公里半個地球之遠是家常便. al. n. v i n Ch 飯。跑了上千公里又通過了無數個裝置與設備，訊號偶有跳針也是可以理解。這些錯誤 engchi U 發生的原因可能是硬體真的故障了，可能是軟體有缺陷，可能是性能到達瓶頸遲頓了一下，可能是雜訊讓訊號變化。這些網際網路上的故障原因來源是多樣也多變的難以捉摸清楚，但我們也發現了一些現象，有些故障只需重新執行就會成功了。第一次執行失敗，第二次或第三次執行同樣的指令卻成功了，這樣的經驗偶而在瀏覽網站時發生，本來是 404/504 重新刷新卻成功了；偶而在寄出電子郵件時發生，第一次交寄失敗第二次卻成功；偶而在 IM(Instant messaging)也發生剛送出的訊息系統回覆傳送失敗，重新輸入同樣的訊息再送出對方卻收到二次同樣的訊息，明顯的內有重試機制的設計。. 36.