第三章 CAP 應用於雲端聯盟
第一節 系統架構
將證明違約協定應用於雲端聯盟上,跟以往最大的差別在於,雲端聯盟 上,通常使用者提出請求後,單一服務提供者無法完成使用者所提出之請求,
需要多個服務提供者介入,每個服務提供者都可能對應到多個使用者。如圖 1
所示。
ClientB
Cloud1 CloudN
ClientC
ClientA ClientD ClientE ClientF
Cloud2 ……
…… ……
……
圖 1 雲端聯盟架構圖
接下來我們利用雲端醫療系統來當例子,假設使用者 A 為病人,使用者 B 為醫生,使用者 C 為檢驗單位,服務提供者為醫院系統。在單一雲端下,當病
人去掛號看診時,會對醫院的醫療系統提出服務請求,例如掛號,當醫生看診
時,也會使用醫療系統來查看病患的病歷,以及將診斷結果寫回醫療系統,過
9
程中可能需要檢驗單位之協助檢驗,檢驗單位也會將檢驗結果寫回醫療系統,
提供醫生觀看。
但在多個醫院所組成之聯盟下,可能因為病人上次並不在同個醫院看診,
醫生也有可能不在同個醫院看診,所以有可能在看診的過程中,病患的病歷儲
存在另外一個醫院上,當醫生在目前的醫院上找不到相關病歷,就必須根據使
用者之證據去其他醫院查詢相關病歷。
將 CAP 應用於雲端聯盟上,還會有使用者角色及數量的問題。在以往
CAP 中,使用者往往是使用者周邊的裝置,例如:手機、平板、電腦,但是在 雲端聯盟上是由其他不同角色的使用者組成,例如:病人、醫生、護理人員、
檢驗單位,在使用者數量上,也從原本可能少數的裝置,變成大量且不同身分
的使用者。
第二節 產生的問題
若用以往的 CAP[10]架構,會有以下的問題產生。首先是證據部分,在[10]
研究中只有一個服務提供者,服務提供者需儲存所有的證據,當使用者想要服
務提供者提出服務時,傳送一個請求訊息 Q 給服務提供者,服務提供者收到後
會驗證裡面的訊息是否正確無誤,再回傳 R 給使用者,代表收到使用者之請
求。使用者驗證完服務提供者簽章後,再回覆 RR 給服務提供者,服務提供者
收到 RR 後開始動作,當服務提供者完成使用者要求後回傳 ACK 給使用者。服
務提供者必須把所有證據留下,並用鏈結雜湊的方式串接起來,使用者僅需儲
10
存最後一筆證據,服務提供者就無法竄改已經鏈結的證據。當稽核時,使用者
拿出最後一筆證據,服務提供者拿出所有的證據來驗證。
但在雲端聯盟的架構下,會有三個問題產生,導致無法稽核。第一,一個 服務會有多個服務提供者的參與,導致證據會分散在不同的服務提供者上。會
因服務提供者上證據的不連貫,增加稽核的困難、甚至導致無法稽核的問題產
生。第二,原本應用於雲端儲存系統上,稽核時所有使用者拿出最後一筆證據
是可行的,但是在雲端聯盟環境下,使用者的數量無法預估,稽核時要求所有
使用者上線拿出最後一筆證據不太可能實現,也導致無法稽核的情況發生。第
三,會遭遇慢速攻擊[17],當有使用者提出服務請求,因網路傳輸問題或是惡
意的使用者提出請求後未能在限定時間內完成動作,而導致其後的使用者無法
繼續動作,導致服務提供者癱瘓之情形發生。
上述的三個問題都會導致 CAP 無法在雲端聯盟上進行,在後續的章節內,
我們針對上述問題提出解決方法,將 CAP 進行改良,並以理論及實驗證明提出
之改良的證明違約協定是可解決上述問題,並可實際運行在雲端聯盟上。
11