當(dāng)你首次考慮這個解決方案的需求時(shí)，作為一名整合構(gòu)架師（Integration Architect），你或者會很快回想起那種老式的意大利面條式整合圖，你應(yīng)該會在那些缺乏集中式整合能力的企業(yè)的某些應(yīng)用中看到過那種圖形。而當(dāng)前的 問題領(lǐng)域類似于那些過去曾遇到過的挑戰(zhàn)，只是它已經(jīng)擴(kuò)展到了全球的范圍。

下圖顯示了你對這個解決方案模型的一種可能的理解方式。

?

?

在當(dāng)今的云服務(wù)時(shí)代，在同一個問題上你擁有了一些比過去更多的架構(gòu)選擇。你可以將云服務(wù)當(dāng)作你的集線器，并且使用一個基于平臺即服務(wù)（Paas）的 消息傳遞系統(tǒng)作為這個架構(gòu)的核心，這也意味著你所關(guān)注的挑戰(zhàn)將從每個商業(yè)機(jī)構(gòu)相互間的直接連接，轉(zhuǎn)移到讓這些商業(yè)機(jī)構(gòu)連接到云服務(wù)的功能上。

下圖展示了這種軸輻式模式在全球范圍的應(yīng)用。

這種類型的項(xiàng)目中依然有著巨大的障礙需要你去克服，但現(xiàn)如今類似于Windows Azure這樣的云提供商允許你在非常短的時(shí)間內(nèi)將你的數(shù)據(jù)中心連接到某個云端的消息系統(tǒng)，而且對基礎(chǔ)架構(gòu)方面的需求也很小。這種方式造就了在整個組織內(nèi) 傳遞消息的能力，它的成功也指導(dǎo)了我們?nèi)绾我暂^佳的方式將這種消息傳遞能力暴露給我們的客戶與合作伙伴。

為了實(shí)現(xiàn)這一點(diǎn)，我們在架構(gòu)中需要3個關(guān)鍵級別的能力。首先，我們需要建立起本地商業(yè)機(jī)構(gòu)的企業(yè)應(yīng)用整合（EAI）能力，它能夠連接云端的消息系統(tǒng)，并能夠與業(yè)務(wù)線應(yīng)用程序進(jìn)行整合。

處于架構(gòu)中間的是一個整合平臺，它包含了消息傳遞的能力，并且為所有我們有可能需要整合的第三方系統(tǒng)提供了EAI的能力。

最后一級是面向公眾的終端，在這里我們有一套API以及用戶界面，它們將開放給那些需要與Acme進(jìn)行整合的系統(tǒng)，如下圖所示：

?

從這張功能圖中可以看出，系統(tǒng)首先通過一組REST API為應(yīng)用整合公開的必需的接口，此外還為那些需要用戶手動查看數(shù)據(jù)的、技術(shù)能力較低的合作伙伴創(chuàng)建一個專門的網(wǎng)站。

在接下來的一張圖中，你將看到以上所列舉的各項(xiàng)能力將怎樣與每個商業(yè)機(jī)構(gòu)中的實(shí)際系統(tǒng)相關(guān)聯(lián)。你將看到每個商業(yè)機(jī)構(gòu)都建立了一個整合產(chǎn)品，它能夠連接消息系統(tǒng)，而這個消息系統(tǒng)又能夠與整個業(yè)務(wù)線應(yīng)用程序相整合。這種整合系統(tǒng)的示例有BizTalk及Websphere。

?

希望到了目前這個階段，你已經(jīng)能夠清晰地看到一個潛在的架構(gòu)，它能夠在這個全球的混合式整合模式中交付所需的功能。這個項(xiàng)目依然會面臨許多挑戰(zhàn)，但由云端提供的這一新的解決方案途徑意味著我們能夠以一種與過去不同的方式處理這個系統(tǒng)了。

接下來我們將分析一些你需要考慮的關(guān)鍵因素，以及你需要遵循的某些實(shí)踐，按照我的經(jīng)驗(yàn)來看，這些實(shí)踐是你要達(dá)到成功所必需的知識。

?

?

作為本文的一部分，我打算介紹一些我對某些關(guān)鍵考慮因素與良好實(shí)踐的想法，它們與成功地交付這種解決方案是密不可分的。其中的某些部分特定于云服務(wù)，而某些部分則是整合解決方案中較為常見的。為了將這些考慮因素與實(shí)踐分解成不同的區(qū)域，我們將從以下角度對他們進(jìn)行分析：

• 組織
• 設(shè)計(jì)

此外還有一些方面或者你也會考慮到，例如交付以及解決方案的運(yùn)維方面的問題，不過這部分就留到以后再討論吧

這一部分會討論一些組織方面的關(guān)鍵問題，但這或許會成為一個很大的主題，因此我還是會讓這一部分盡量保持簡短，并讓各位專注于之后的偏技術(shù)領(lǐng)域的部分。

為了給整個組織展現(xiàn)一個通用的API集合，必需要有一個通用的、與商業(yè)機(jī)構(gòu)無關(guān)的數(shù)據(jù)模型。如果該組織并沒有一個現(xiàn)有的數(shù)據(jù)模型，那這或者會成為整 個項(xiàng)目中最困難的部分。一個通用的數(shù)據(jù)模型意味著組織外的那些人對某個實(shí)體有著通用的認(rèn)識，無論該實(shí)體來自于哪個商業(yè)機(jī)構(gòu)。這個通用的數(shù)據(jù)模型可以展現(xiàn)為 權(quán)威的消息。

每個商業(yè)機(jī)構(gòu)都會面臨獨(dú)一無二的挑戰(zhàn)，這些挑戰(zhàn)都應(yīng)該由這些商業(yè)機(jī)構(gòu)自行處理，因?yàn)樗麄冊谙嚓P(guān)的領(lǐng)域有著專業(yè)特長。至于之前所說的通用數(shù)據(jù)模型的部分，對于一個本地商業(yè)機(jī)構(gòu)來說，它所面臨的一個挑戰(zhàn)是如何將它自己的數(shù)據(jù)映射到通用數(shù)據(jù)格式中。

很難在一開始就預(yù)見到所有的業(yè)務(wù)場景，而且每個商業(yè)機(jī)構(gòu)都有可能會面臨完全不同的某些場景，這種場景就不太值得去實(shí)現(xiàn)。在這種例外情況下，某個顧問可以選擇給適當(dāng)?shù)纳虡I(yè)機(jī)構(gòu)直接打電話。

這個項(xiàng)目的成本模型或者會變得非常有趣。本地商業(yè)機(jī)構(gòu)的EAI成本與它們通常的運(yùn)行成本應(yīng)該非常接近，或者它們需要擴(kuò)展某些系統(tǒng)，但它們應(yīng)該已經(jīng)了 解如何去處理這一部分成本了。而他們很可能不太了解的那部分新成本將來自于云端的REST API以及消息系統(tǒng)。你將面臨的挑戰(zhàn)為那部分潛在的跨多個商業(yè)機(jī)構(gòu)的成本設(shè)計(jì)出一種分解方案。在這種情況下，你的組織應(yīng)該選擇接受一份Windows Azure企業(yè)協(xié)議，這樣的話總體運(yùn)行成本就會非常低了。

成功實(shí)現(xiàn)該項(xiàng)目的一個關(guān)鍵因素就是確保你的團(tuán)隊(duì)中具有熟悉整合經(jīng)驗(yàn)的人才。組織經(jīng)常會落入某個陷阱中，即認(rèn)為任何開發(fā)者都能夠處理整合的問題，但在類似于這樣的大型復(fù)雜項(xiàng)目中，專業(yè)技能與經(jīng)驗(yàn)會顯得非常有價(jià)值。

?

?

下面將討論一些專注于設(shè)計(jì)的考慮因素：

在這個架構(gòu)中，我們選擇了Windows Azure消息總線（Service Bus）作為中央消息集線器，它為我們提供了消息系統(tǒng)的各種便利。并且它支持多種不同的協(xié)議，意味著我們可以使用多種不同的技術(shù)連接到它。除了在 Windows Azure網(wǎng)站上為主要編程語言提供的類庫之外，Windows Azure消息總線還支持REST與AMQP。

這個云端的混合架構(gòu)有一個較低層次的考慮因素，即應(yīng)該在哪里進(jìn)行EAI。EAI應(yīng)該盡可能實(shí)現(xiàn)在本地商業(yè)機(jī)構(gòu)內(nèi)，而不是實(shí)現(xiàn)在云端整合平臺上。這種 方式尤其適合于那些具有良好水平的IT支持并且具有現(xiàn)成的整合平臺的商業(yè)機(jī)構(gòu)內(nèi)，不過對一些技術(shù)水平較低的商業(yè)機(jī)構(gòu)也可以采用一些其它選擇，例如在云端搭 建一個BizTalk的實(shí)例，讓它處理各種EAI的挑戰(zhàn)。

在這個架構(gòu)中，我們選擇為客戶端應(yīng)用程序暴露一個基于資源的模型，和一組REST API。這組REST API可以在一定程度上將客戶端從消息系統(tǒng)中解耦，這為它們提供了一個簡化的資源模型，但它也允許我們在云端包含一些邏輯，以幫助實(shí)現(xiàn)一些API可能需要 的特性。這組REST API更允許我們在其中對資源訪問進(jìn)行集中控制。

消息與API的版本控制很可能成為這個解決方案中的一個重要的考慮因素。像這樣的項(xiàng)目很可能在整個項(xiàng)目的生命周期內(nèi)對數(shù)據(jù)進(jìn)行大量的改動。我們應(yīng)該在此架構(gòu)中實(shí)現(xiàn)常見的API與消息的版本控制技術(shù)。

在適當(dāng)?shù)牡胤绞褂卯惒侥Ｊ綄φ麄€解決方案中的多個領(lǐng)域有所幫助，包括性能和伸縮性。在實(shí)際中我發(fā)現(xiàn)許多項(xiàng)目都盡量避免使用異步消息，但這一功能對這個案例來說非常重要。

為基于云端的消息傳遞使用一個多帶帶的消息總線命名空間將有助于Acme簡化對消息傳遞的管理。這意味著隊(duì)列與訂閱將會集中在某一地點(diǎn)。

使用的Windows Azure消息總線Paired Namespace特性也將有助于你改善系統(tǒng)的可用性。

API中的消息傳入與傳出可以按照常見的REST模式進(jìn)行設(shè)計(jì)，但是在Windows Azure消息總線中進(jìn)行傳遞的消息的格式必須與其它所有Acme本地商業(yè)機(jī)構(gòu)的消息格式相兼容。理想的情況是Acme使用JSON消息格式以限制消息的 大小，但它也取決于終端應(yīng)用的能力。

對Acme中采用了BizTalk的商業(yè)機(jī)構(gòu)來說，有許多來自社區(qū)的文章詳細(xì)分析了如何在BizTalk中對JSON消息進(jìn)行解碼。

Windows Azure消息總線在內(nèi)部使用Windows Azure活動目錄訪問控制（ACS）或者Shared Access Secrets特性來保護(hù)對隊(duì)列/主題的訪問，并控制你對它們的操作權(quán)限。這一級別的安全性對集中式配置訪問權(quán)限會有所幫助，它可以允許任何一個本地商業(yè) 機(jī)構(gòu)的訪問。

這個解決方案的隊(duì)列及主題配置可能會依賴于你打算實(shí)現(xiàn)的消息傳遞模式。在這個解決方案中，我們有可能會大量用到主題以允許使用訂閱規(guī)則，以此決定各消息將傳遞給哪個本地商業(yè)機(jī)構(gòu)。

我們用到最多的模式是一個路由RPC模式，其中一個主題會將一個消息路由至某個訂閱中，隨后本地的商業(yè)機(jī)構(gòu)就會將一個響應(yīng)消息發(fā)送至某個包含會話信息的響應(yīng)隊(duì)列中。此外還用到了一種單向路由模式。

這個架構(gòu)中的多數(shù)跌幅規(guī)則都基于一個上下文屬性，它指出某位員工是屬于哪個國家或者本地商務(wù)機(jī)構(gòu)。由于這一商業(yè)用例的本質(zhì)，我們隨時(shí)都能夠從這位尋求幫助的員工與顧問之間的首次對話了解這一信息。

這一上下文屬性隨后加入到消息中，而在Windows Azure服務(wù)總線中我們可以使用一個簡單的基于該屬性的訂閱過濾器，將消息路由給正確的本地商業(yè)機(jī)構(gòu)。

在這個架構(gòu)中，一個常見的數(shù)據(jù)方面的問題就是數(shù)據(jù)的交互引用，一個商業(yè)機(jī)構(gòu)到另一個之間存在多種代碼映射。在這個場景中，較佳的方式就是為所有這些 引用數(shù)據(jù)字段創(chuàng)建一個集中式的總數(shù)據(jù)表，然后沿用之前將EAI工作推到邊緣的設(shè)計(jì)原則，讓每個商務(wù)機(jī)構(gòu)自行負(fù)責(zé)將中央商業(yè)數(shù)據(jù)映射到它們自己的特定商業(yè)數(shù) 據(jù)。

如果可能的話，使用工業(yè)標(biāo)準(zhǔn)代碼會帶來很大的幫助。例如使用ISO國家代碼以指代某個國家，對于表示與商業(yè)機(jī)構(gòu)無關(guān)的國家代碼就是一個好的選擇。

和通用數(shù)據(jù)模型一樣，這一領(lǐng)域也可能成為最難解決的問題之一。

在定義通用的數(shù)據(jù)模型時(shí)，想要對所有字段達(dá)成一致的認(rèn)識通常是很難的。而我推薦的方式是考慮數(shù)據(jù)的使用方式。某些數(shù)據(jù)是明顯的實(shí)體，例如一個名稱或 者地址，它們的結(jié)構(gòu)通常已經(jīng)很清楚了。而另一些數(shù)據(jù)將成為某一流程中能夠作出某些決定的關(guān)鍵屬性。這種數(shù)據(jù)需要進(jìn)行良好的定義，并且便于開發(fā)者在消息中指 出該數(shù)據(jù)，使這些數(shù)據(jù)可以在系統(tǒng)中使用。另外有些數(shù)據(jù)或許是用戶需要閱讀的重要數(shù)據(jù)，但并不需要以某種方式進(jìn)行結(jié)構(gòu)化，開發(fā)者只需要將其顯示給用戶而不需 要做其它任何處理。在這種情況下，或許可以為這個數(shù)據(jù)模型建立一個非結(jié)構(gòu)化的部分，讓某個本地商業(yè)機(jī)構(gòu)可以任意加載他們所需或與他們相關(guān)的數(shù)據(jù)。這種方式 對顯示特定于業(yè)務(wù)的額外信息也是種有效的方法，這些額外信息往往對于每個本地商業(yè)機(jī)構(gòu)來說都有所不同。

當(dāng)使用基于隊(duì)列的消息系統(tǒng)時(shí)，考慮消息的大小是非常重要的。在起初我還對消息的大小有所擔(dān)心，但在實(shí)際過程中消息的尺寸限制幫助我們更好地專注于消 息，確保不會創(chuàng)造出包含了許多無用數(shù)據(jù)的過大的響應(yīng)消息，這一點(diǎn)是過去經(jīng)常遇到的問題。使用JSON格式也能夠在很大程度上幫助你將消息的大小限制在較小 的范圍內(nèi)。

雖然有些技術(shù)可以使你利用會話以應(yīng)對大尺寸消息的處理，但在我們的案例中，我們一直嘗試將尺寸限制作為一種制約，它促使我們設(shè)計(jì)較小的有效信息以處 理某些特別的情況。由于這個架構(gòu)保留著橫向擴(kuò)展的可能性，如果我們打算將數(shù)據(jù)聚焦為一個較大的資源并返回客戶端，這個架構(gòu)也允許我們發(fā)送多條并行的消息以 傳遞各種不同的信息。

?

?

?

我希望本文讓你了解到云服務(wù)以及基于云服務(wù)的消息傳遞能夠?yàn)槟憬桓赌切┰谶^去看來過于復(fù)雜的項(xiàng)目提供了某些方法。這一項(xiàng)目的關(guān)鍵在于，很大程度上對 基礎(chǔ)設(shè)施的需求已經(jīng)改變了，或是已經(jīng)完全消除了，你可以以一個很低的成本快速地這對種類型的項(xiàng)目做一些概念式的實(shí)驗(yàn)。而在過去，基礎(chǔ)設(shè)施方面的需求會帶來 很大的成本要求與項(xiàng)目實(shí)施的復(fù)雜度，這使得項(xiàng)目的成功實(shí)施非常困難。

請記住以下這重要的一點(diǎn)：雖然該項(xiàng)目中的某些挑戰(zhàn)是不會改變的，它仍然是一個復(fù)雜的整合項(xiàng)目，但希望我的想法對這些考慮因素及實(shí)踐能對你的成功有所幫助。

Michael Stephenson 是一位來自英國的獨(dú)立開發(fā)者與云技術(shù)專家。他主要專注于微軟整合平臺上的整合技術(shù)，例如BizTalk與Windows Azure。Michael有多年的技術(shù)領(lǐng)導(dǎo)與教練的經(jīng)驗(yàn)，他為客戶交付了大量復(fù)雜的、真實(shí)世界的混合整合應(yīng)用。Michael近期在提倡BizTalk成熟度評估。他會定期更新他的博客，此外也可以通過Twitter或者Linked In找到他。???????????