鬆耦合 loosely coupled
鬆耦合 loosely coupled 大概是我們談雲端整合時最常被提起的準則。在設計架構時為了達到 loosely 的效果，採用message queue 或service bus的框架來分離前端界面和後端邏輯之間的緊密關係，將它們融入架構中，這是達到鬆耦合最快速的方法了。
(討論架構時容易產生的怪異現象： 這一點相當的有趣，只要一談到架構則人們不論是程式師或是專案負責人甚至業務人員都會顯得特別感興趣，紛紛圍觀過來，然後接踵而來的就是一大堆的意見，然後很快的大家的聲調便會越提越高，爭論不休熱鬧異常！讓原本很正常的設計瞬間遭受大量的質疑，並成了有相當偏好的設計。這是目前大家對架構普遍喜好的現象，真可怕！其實嘛，UX設計師所面臨的評論場面，恐比架構師要悲壯的多了，在此，獻上敬意)
為此，我經常帶上一些色彩與虛幻來講架構的設計，藉著幽默來調和一下，這裡先跟大家分享（要聲明一下，這跟宗教信仰可是完全無關，請別想太多）。
問："禱告有用嗎？"
答：當然有用！
問：那為什麼我的禱告都沒有實現呢！
禱告當然有用，這些訊息它們都會迅速的進到上帝的Message Queue中若沒有任何exception產生它們是不會遺失的，至於上帝的Queue的大小則是絕對經得起挑戰的，所以你放心，只要你禱告了，它就一定會進入Queue裏頭，不會漏掉的，但會不會實現就要看內容了，這一點基本上跟架構就無關。
然而；許多寫Queue的人都不了解，Queue它們是有輕重緩急的區分的，這一點我們在一開始就要設計進去。舉例來說；像孩子們在聖誕節前夕的禱告，上帝就會想盡辦法，加班熬夜也會盡力的把訊息從Queue拿出來，設法去達成的(要知道將訊息填入Queue容易，但消化Queue時就必須一個一個拿出來，這是需要相當時間的)。此時要是遇到緊急的情況時，像那種必須立刻被處理的事情你就不能像聖誕節的禱告一樣把它放進queue裡頭來處理，必須走特殊的管道。故事如下：
康斯坦丁(John Constantine)，沒錯就是那位驅魔神探。
話說；他好不容易抓到大天使加百列與閻羅王之子瞞著他老爸密謀透過”命運之戟”偷渡到人間的關鍵時刻…。
話說，憑藉康斯坦丁一個凡人的力量當然不足以對抗閻羅王之子或是加百列，所以即便看到事情即將發生，也是束手無策，此時；他只好向上帝禱告了，希望能及時阻止這場災難。但這種正常的禱告訊息，我們知道的，他必須先放進Queue裏頭排隊的，等到輪到他被處理的時候上帝才會看到訊息然後加以處理。這就是Queue的運作方式。康斯坦丁當然是等不及了，情急之下，他便想到閻羅王曾經說過，如果他要死的時候，閻羅王會親自前來提領康斯坦丁下地獄的。因此，急中生智的康斯坦丁便選擇了割腕自殺的途徑，要知道自殺對天主教徒而言是要下地獄的，而死亡本身就是一種即時訊息，它是無須被放入Queue中就會立即被處理的。立即的Event引來了閻羅王，並阻止了他兒子利用”命運之戟”偷渡到人間的事件。康斯坦丁也因此得到了重生。
這個故事告訴我們，Queue的設計確實可以在不遺失訊息之下，成功的收取大量訊息，但不是所有的訊息都能一視同仁的，尤其是對那些有即時性的訊息，選擇Event的處理方式會比填入Queue中好多了。這一點我們可以向雲端來學習，也就是在Web Role (web前端) 與 Worker Role(後端的邏輯單元)之間運用Queue的方式來 loosely Coupled 的傳遞資料與訊息。這是一般的 PAAS 的設計架構。但如果你是採用IAAS的話，這些單元就必須自己組合了（下面這張架構圖就是在EC2上用幾個VM兜出來類似的solution)。這麼設計的目的是使得，不論是 web前端或是後端的邏輯單元都可以視負荷的種類，單獨的進行Scaling 作業。
上圖中右側是抽象的運用Web role 作前端，Worker role作後端邏輯層的架構設計，左側則是細部實踐後的結果。Web role 與 Worker role 之間運用message bus 做銜接。
上面的故事是閒話，其實講到整合，指的是雲端與既有系統之間的交互運作。也就是Hybrid cloud。
混合雲 Hybrid cloud
產生Hybrid Cloud 的架構很單純的，理由是你想作到雲端上的程式相互呼叫，或是另一種類是由既有的程式與雲端程式之間的呼叫，這就構成了混合雲的架構了，但在這麼作之前首先你該作的是判斷是否真的需要這麼作？！請參考下圖:
一口氣扯多了，下回再談…
Ruddy Lee 分享空間 