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

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

?

?

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

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

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

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

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

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

?

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

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

?

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

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

?

?

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

• 組織
• 設計

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

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

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

每個商業(yè)機構都會面臨獨一無二的挑戰(zhàn)，這些挑戰(zhàn)都應該由這些商業(yè)機構自行處理，因為他們在相關的領域有著專業(yè)特長。至于之前所說的通用數(shù)據(jù)模型的部分，對于一個本地商業(yè)機構來說，它所面臨的一個挑戰(zhàn)是如何將它自己的數(shù)據(jù)映射到通用數(shù)據(jù)格式中。

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

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

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

?

?

下面將討論一些專注于設計的考慮因素：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

?

?

我希望本文讓你了解到云服務以及基于云服務的消息傳遞能夠為你交付那些在過去看來過于復雜的項目提供了某些方法。這一項目的關鍵在于，很大程度上對 基礎設施的需求已經(jīng)改變了，或是已經(jīng)完全消除了，你可以以一個很低的成本快速地這對種類型的項目做一些概念式的實驗。而在過去，基礎設施方面的需求會帶來 很大的成本要求與項目實施的復雜度，這使得項目的成功實施非常困難。

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

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