IT世界的技術更新非常迅速。一年前我曾寫過一篇關於：微服務是否是企業服務匯流排和其他中介軟體的死亡魔法。本文章是之前文章的後續以及關於微服務、容器和原生雲架構的中介軟體關係討論的更新。各種規模的企業正在以令人不可思議的速度快速向這些技術靠攏！

在2016年6月的今天，許多企業已經採用容器和原生雲架構或正在採用它們。 這個話題也越來越和中介軟體供應商相關。 因此，我們需要做一個有關微服務，容器和雲原生架構的中介軟體世界的現狀的更新。

本文的關鍵要點：

• 原生雲架構可以支援靈活和敏捷的開發，部署，以及運維各種軟體
• 現代中介軟體技術可以利用容器，微服務，以及原生雲架構
• 僅僅利用容器來包裝和隔離是遠遠不夠的，還有很多其他概念值得理解和利用

微服務和Docker的發展勢頭

微服務和容器的主要目標是縮短軟體開發時間，以及實現開發、部署以及運維的更大靈活性。為什麼它過去幾個月的發展勢頭這麼猛？因為幾乎所有科技巨頭企業如亞馬遜，谷歌，Facebook，Netflix都在這裡激烈競爭。

微服務就像是一個面向服務的架構（SOA）：這是一種架構和供應商技術分別獨立的設計理念。因此，目前並沒有明確的界定標準或規範。你永遠需要在和其他人討論之前定義你所理解的微服務術語。每個人都有不同的定義。在這篇文章中微服務是被開發，部署和獨立縮放的服務。它們可以不針對任何技術來提供業務或整合邏輯。有些供應商提供建立微服務的特殊支援（我們將在後面的文章中看到的），但基本上不涉及任何特定的技術支援。

關於微服務架構的討論最早是一篇由Martin Fowler在2014寫的著名文章開始的，該文章的廣泛應用起始於NetFlix的一系列豐富的開源微服務應用框架。稍後我們會回來介紹更多細節，本文章的很多內容都是受到了Netflix傑出和詳細的技術部落格帖子的啟發。

容器依賴其上執行的作業系統。容器的實現是基於Linux核心的資源隔離功能，如核心 
namespaces（隔離的應用程式執行環境，包括程序樹，網路，使用者ID，以及安裝的檔案系統），以及cgroup（提供資源限制，包括CPU，記憶體， I / O和網路），和一個有聯合能力的檔案系統如AUFS和其他。這允許獨立容器在單個Linux例項中執行，避免了初始化以及維持虛擬機器的開銷。

相比於虛擬機器，容器的主要特點是標準化包裝，可移植性，基於按需建立的目的從而達到較低的啟動和佔用時間，可重複性，更好的資源利用率，更好地融入發展中的生態系統整體（如持續整合/持續交付）。容器化的應用程式可以在任何環境隨意建立和執行，無論是你的膝上型電腦，測試系統上，預生產和生產系統。而這一切完全不需要改變容器以及容器內的應用程式的任何內容。

在微服務對立面，也有幾個容器軟體的特殊實現方式。但是大多數的發展勢頭都已經被Docker拋在了後面。Docker的生態系統在日益增長。這必將在未來幾年更加鞏固，同時它也將變得比今天更加成熟。其他關於Docker技術的例子還有如， CoreOS’ rkt (Rocket) 及 Cloud Foundry’s Garden / Warden。請注意，所有這些容器的概念並不是什麼新鮮事，早在UNIX系統中就已經存在多年，比如Solaris Zones。 
還有一些其他的商業案例如VMware Photon Platform / vSphere Integrated Containers 或者Microsoft’s Windows Server containers / Hyper-V containers or VMware Thinapp。

這裡我們有一個非常好的關於Docker以及容器的概括介紹：Docker, the Future of DevOps，另外”The Open Container Initiative (OCI)”則是在2015年中期建立的一個全球性的，廠商無關的標準。許多軟體供應商都是該委員會成員，包括Amazon, Intel, Docker, Facebook, IBM, Microsoft, Oracle, Pivotal, 和 VMware，以上只是眾多官方支持者的一部分。

一個原生雲架構

微服務和容器其獨立的服務以及靈活的部署僅僅是基礎需求。下面的章節會討論更多針對原生雲架構的附加需求。請注意，每節中我們都列出了很多可用的框架例子，這不代表它們是完整的列表。

原生雲架構實現了：

• 服務可擴充套件性
• 服務彈性
• 高可用性
• 自動負載均衡和故障切換
• DevOps
• 公有云、私有云及混合雲通用
• 廠商無關的部署
• 快速升級
• 更高的利用率並降低基礎設施成本
• 更高的效率和靈活性

有了這一切，你可以專注於創新和解決您的業務問題，而不是在“靜態和僵化的傳統架構”的大量技術問題中浪費時間。要知道，原生雲意味著你可以不僅僅在公共雲中部署軟體。私有云或混合雲的部署也包含在雲原生的定義中！

持續整合和持續交付

持續整合(CI) 和持續交付(CD) 需要很多不同的東西自動構建，部署和執行微服務。 這包括用於自動測試和部署，內部和外部的服務發現以及微服務和容器的分散式配置指令碼。

自動化測試和部署指令碼

持續整合CI 和持續交付CD始於數年前。你的包的構建，測試和部署服務全部自動化完成。這提高了生產率，生產效率和產品質量。下面是被用於CI / CD建立指令碼的主要框架和工具：

• 自動構建管理: Apache Ant, Apache Maven, Gradle, …
• 持續整合: Jenkins, Bamboo, …
• 持續交付: Chef, Puppet, SaltStack, Ansible, …

服務發現

我們使用了大量不同的獨立服務以及每個服務都有數量龐大分散式例項在工作。內部服務發現框架用來實現定位服務實現負載均衡和故障切換目的。因此，我們需要每個服務提供者在可用時向服務發現者登記註冊。從而使消費者能夠基於註冊發現服務並連線使用它。 
關於如何使用服務註冊中心有很多可選項，例如Netflix’ Eureka, Apache Zookeeper,Consul, Etcd。許多稍後討論的框架還包括隱式服務註冊。在本文中分類各種不同的框架並不是件簡單的事情，很多時候各種特性是相互重疊的。

除了內部服務發現外，外部服務發現框架用於暴露內部微服務介面給外界（其可以是公共網際網路，合作伙伴或其他內部部門）。這通常被稱為“Open API initiative”或“API Management”，並作為打包和API的自配置的入口（例如，在本例中的微服務），貨幣化和安全執法閘道器（如認證，授權，限流）。為API管理一些相關的選項有：

• JBoss apiman: 開源的，底層的編碼框架，可以利用其它Redhat的JBoss專案
• Apigee: 專注於API 管理市場的競爭者
• Akana (former SOA Software): 專注於API 管理市場的競爭者
• CA’s Layer7: 強大的安全閘道器，可以利用其他CA產品
• TIBCO’s Mashery: 強大的入口網站和社群，可以利用其他TIBCO產品，包括 
  應用TIBCO API Exchange Gateway滿足高階安全和路由要求

請參閱下面文章的有關使用案例和“Open API”產品分類詳細資訊：API管理如何改變雲端計算，大資料，物聯網的遊戲規則。

動態分散式配置管理

在原生雲架構存在著大量敏捷和動態的變化以適應分散式的微服務和容器，你無法手工管理和配置它們。服務被設計以適應失敗，重生並迅速更新。因此，你需要自動化的配置管理以設定分散式節點上的新容器快速且自動配置。一些所需的功能如下：

• 執行期動態自適應(例如，改變特定例項的服務行為，資料庫連線或者是日誌層級)
• 基於複雜的請求或部署上下文改變多維屬性
• 基於請求上下文啟用或者停用特性(例如，顯示特定的使用者介面或者是特定的地區或者裝置)
• 改變雲的設計模式行為(詳見後續章節中的“彈性設計模式”)

動態分散式配置管理的兩個相關的框架是Netflix’ Archaius和 Spring Cloud Config. 這些框架使用動態配置的輪詢和回撥機制（特定IP地址和主機）以適應彈性和不斷變化的雲的本地環境，因為傳統的推送模式無法在其中正常工作。

可擴充套件性和故障切換

一個原生雲架構的主要特點就是根據負載彈性伸縮和SLA的能力。這需要先進的叢集管理，以及伺服器端和客戶端彈性的負載平衡和設計模式。

叢集管理(計劃和編制)

靈活的開發和部署是微服務和容器的一個關鍵優勢。包括新增新功能以及舊功能的裁剪。零宕機和故障切換是必需的，同時你也需要保證高效的資源利用率。

叢集管理器是專為故障切換和高可擴充套件性而設計。 它被用於自動編排容器排程和管理主機，包括每個主機的規則和約束應用。

很多種叢集管理框架已經實現，尤其是針對Docker。下面是一些最相關的實施案例（更詳細地討論在這裡）：

• Docker Swarm: 一個Docker原生框架，使用Docker API，可以很容易地利用其他Docker框架，如Docker Compose，它必須與其他框架如ETCD，Consul或ZooKeeper結合
• CoreOS Fleet: 基於systemd直接構建的底層框架，經常被用於作為高層解決方案的底層基礎架構
• Kubernetes: 來自Google的開源專案並且得到了眾多其他公司的支援包括IBM, Red Hat和Microsoft。Kubernetes是結合了複雜的功能和相對簡單的安裝/配置的一個偉大組合。它不同於其他一些先進的叢集管理器，你甚至可以通過一個簡單的“docker run”命令就將它設定在本地計算機上。如果你在雲平臺上安裝它，那麼它也可以利用平臺的特定功能，例如在AWS上它可以使用亞馬遜的ELB，或者它也可以利用Google雲平臺的Google LB。
• Mesos’ Marathon: 基於強大（且複雜）的Apache Mesos之上的一個編排框架，一個“分散式系統核心”。Mesos被用於大規模多用途的不同框架之上的封裝(如Apache Hadoop, containers via Marathon, batch processing via Chronos).

負載均衡(服務端和客戶端)

原生雲上有眾多伺服器隨時在生生滅滅。由此基於微服務和容器的負載均衡需要變得更加錯綜複雜。只是基於公共的IP地址和主機負載分佈是不夠的了。如基於幾個因素的加權負載均衡概念能夠提供更卓越的彈性，如流量，資源使用情況或錯誤的條件。

傳統的伺服器側負載平衡多年來用於在多個伺服器之間分發網路或應用流量以增加應用程式的容量和可靠性。著名的例子是F5公司的Big-IP產品或亞馬遜的AWS彈性負載均衡（ELB）服務。它們用於所謂的邊緣業務，即外部服務的消費者分別匯入為終端使用者的網路流量。

此外，許多微服務架構也包括客戶端負載平衡，以避免不必要的服務間的通訊。因此一些框架，如Netflix Ribbon也嵌入到客戶端LB到每個微服務。這降低了通訊的跳轉，而不再需要在內部的微服務之間服務通訊多層跳轉，我們稱之為所謂中間層或核心服務。

韌性設計模式

所有原生雲架構的新概念都需要新的設計模式來提供一個可重複的通用方案來解決經常出現的問題。韌性設計模式通過實現高延時寬容，容錯和故障恢復邏輯可以防止連鎖故障，允許快速失敗和快速恢復.

其中一個著名的模式就是Circuit Breaker用來檢測故障並封裝邏輯從而防止故障持續性重複發生 (在維護，臨時的外部系統故障或系統意外的困難期間)。Akka framework就是對這個模式的很好的解讀和實現。Netflix Hystrix也提供了一個複雜的實現用於在分散式系統中達到延時和容錯的目的。“Application Resiliency Using Netflix Hystrix”就是Ebay Tech釋出的一個非常好的文章用於解釋他們如何利用它來實現雲模式的。

我們已經有大量的雲端計算模式出現（未來將會更多）。例如，Kubernetes的技術部落格所解釋的“Patterns for Composite Containers”，例如“Sidecar容器”，“大使容器”或“介面卡容器”。

容器解決方案堆疊

正如你在上面的章節所看到的，目前已經有很多可用的框架和工具鏈，而且它們的數量還在每月增長。這可能會提醒許多讀者Apache Hadoop的故事，它不太成熟的框架，及其生態系統令人難以置信的增長速度。今天的Docker也是如此。因此，一些“解決方案堆疊”正在興起，以幫助使用者入門以及管理使用一個單一（和有商業支援的）容器堆疊的所有挑戰，就像眾所周知的Hadoop環境曾經遇到的一樣。 容器解決方案堆疊的幾個例子是Tectonic（Kubernetes + CoreOS平臺），Docker資料中心，Mantl 或者 HashiCorp’s Nomad。 更多方案可能將在未來幾個月出現。

至此，我們已經討論了幾個概念，框架和模式，以利用容器和微服務實現雲端計算的本地架構。但是，你也需要某種雲平臺用以部署和執行這一切。

私有，公共和混合雲平臺

一個雲平臺可以是私有云，公共雲或者混合雲，它提供了一種自助服務和靈活的雲端計算基礎設施（基礎設施作為一種服務，即IaaS）。在雲基礎設施之上，你需要一個平臺（平臺作為一種服務，即PaaS），由此你可以部署和執行你的容器。下圖顯示了兩者的主要特點：

大多數企業選擇成熟可用的雲產品，如Amazon Web Services，Microsoft Azure或開源OpenStack的IaaS和PaaS的平臺，如Red Hat’s OpenShift（這是基於Docker和Kubernetes的）或Cloud Foundry（提供開源並且由幾個供應商提供的增強版本如IBM with Bluemix 或 Pivotal）。

使用現有的PaaS平臺的主要優勢是一個原生雲架構的主要需求，如靈活的可伸縮性，容器編排，動態服務發現，負載平衡或動態分散式配置管理外的即裝即用的支援。因此，你應該在基於上面所討論的各種不同架構建立自己的平臺之前評估不同的PaaS平臺。大多數平臺隱式利用了這些框架的其中一種或另一種。

在討論了所有這些原生雲架構的需求和可用的框架細節後，現在讓我們來看看為何說這一切和中介軟體都是相關的。

中介軟體的聯絡（一體化，API管理，事務處理）

在進一步之前，我需要澄清：微服務，容器和原生雲架構並不適合所有的場景。請記住：這裡引入了很多新的概念和複雜性。“微服務不是免費的午餐”！

因為整合是大多數中介軟體專案取得成功的關鍵，因此在下面的段落中我會格外注重平臺整合。無論是雲，移動，大資料或物聯網等趨勢，都不可能在沒有和IT架構很好的融合下生存。

企業服務匯流排（ESB）是在許多企業作為自定義應用程式，商業現有軟體，遺留應用程式，資料庫和雲服務之間的戰略整合平臺。然而，並非每一個ESB部署都需要是原生雲。在銀行，零售商，航空公司，電信公司和其他執行關鍵任務的公司，部署一個具有高效能，高可用性和容錯性的ESB中心仍可能是未來幾十年的最佳選擇。

在另一方面來說，ESB並不是個像你可能認為的那樣複雜的，中央控制並且重量級的野獸。這在5至10年前可能是真實的（這也是其中一個多個SOA專案在那段時間失敗的原因之一）以及它在今天對於某些供應商來說仍然是真實情況。但總的來說（並且對許多廠商都是如此）企業服務匯流排在2016年已經是一個成熟，穩定，易於使用的元件，它應提供：

• 整合
• 編排和服務協同
• API和商業服務
• 訊息
• 獨立部署
• 可擴充套件性和輕量級平臺
• 自動化

根據你的需求，你應該能夠決定你需要什麼樣的原生雲以及是否能夠利用微服務及容器（包括所有的利弊）。不只是選擇這些概念，也包括你真正需要的工具和功能。

中介軟體範例

說了這麼多，讓我們來看看幾個不同的中介軟體的例子，以及你可能會如何利用微服務，容器和原生雲架構為此服務：

• 整合: 構建（微）服務，並使用ESB的整合功能的API; 整合和協調不同（微）服務（構建複合服務）
• API管理: 通過API暴露，釋出和貨幣化微服務給內部，外部合作伙伴或公共世界。
• 事務處理: 實時處理關聯分佈的微服務事件增加商業價值（如欺詐檢測，交叉銷售和預測性維護）

上述所有的中介軟體元件：

• 需要敏捷性和靈活性
• 控制和利用其他微服務
• 必須支援微服務特徵本身(容器, CI / CD, elastic 彈性伸縮性等) 適配到原生雲架構，並允許快速變化

讓我們回過頭來看整合平臺的例子和ESB。如果你需要一個更靈活，原生雲集成的解決方案，而不是傳統的，更核心的ESB部署，那麼你有三種選擇（這裡不關心品牌或產品名稱）：

基於PaaS整合中介軟體

這非常類似於預置部署ESB用於實施“核心服務”，例如: 中央部分，往往是複雜和關鍵任務的服務。開發是在傳統的IDE上完成。然而，關鍵的區別在於，該解決方案是原生雲即它支援容器和微服務。你可以使用這種整合中介軟體開發被本地部署到PaaS平臺上，如Cloud Foundry或OpenShift上的整合應用。一些供應商提供了一個供應商無關的解決方案，在那裡你可以部署整合應用程式到任何地方，而不依賴於特定的雲平臺或供應商。

你可以開發不同更敏捷，快速變化並且提供網路擴充套件性的的“原生雲服務”：

• 整合應用程式和服務: 建立商業化的web APIs提供後端web 服務如ERP，CRM，利用如SOAP，SAP，Oracle，IBM MQ等企業的技術管理訂單系統。
• 功能微服務化: 建立應用只需專注於業務功能，而無需理解底層程式碼複雜性
• API協同服務: 圖形化的協同API充分利用PaaS的整合工具（如流程編排，資料對映器或聯結器）

市場上對於部署基於PaaS平臺的原生雲上建立整合應用並沒有很多可選項。 
TIBCO的 BusinessWorks Container Edition 是一個供應商無關的配套例子支援CloudFoundry, Docker, Kubernetes, AWS ECS, 等。 JBoss Middleware Services 允許其中介軟體應用程式（包括JBoss Fuse和A-MQ）在OpenShift上部署。

雲集成中介軟體 (iPaaS)

一個IPaaS雲集成中介軟體是基於雲，使用web瀏覽器而不是桌面IDE的，並且支援執行整合指令碼流程，有整合的開發和生命週期管理，有應用流程管理和監控，協同基本的雲功能例如多租戶，彈性和自我配置。iPaaS能和預置部署的ESB或基於PaaS平臺上的整合中介軟體緊密合作。

iPaaS工具提供了直觀的基於Web的整合，它的目的在於提供給使用者一些技術理解。例如，如何建立和部署REST服務或配置連線和開放API的政策。它通常用來構建“邊緣服務”，有時也被稱為“微流”它可能會更頻繁地發生變化，它也往往不是關鍵任務。

一些iPaaS解決方案的示例如下：Dell Boomi, Informatica Cloud, MuleSoft Anypoint Platform,SnapLogic, Jitterbit, 以及 TIBCO Cloud Integration. 
更詳細的介紹，包括iPaaS的利弊可以在這裡找到：“iPaaS: 什麼是雲技術以及為什麼它這麼重要”.

SaaS雲集成中介軟體 (iSaaS)

這種SaaS解決方案提供了企業使用者一個直觀的基於Web的使用者介面，即“Citizen Integrator”，從而根據do-it-yourself (DIY)原則無需技術知識即可完成個人整合。 Citizen Integrators通過配置，而無需開發開發或從頭構建他們新的整合流程即可構建新的整合。例如，企業使用者建立一個自動流程通過從SaaS服務，如Salesforce或Marketo和他的微軟Excel表自助服務來同步他的資料。

iSaaS整合是預置部署，PaaS和iPaaS整合有明顯的互補性。對於沒有戰略和關鍵任務的企業，它們也應該被視為“邊緣業務”。但對於具體的業務使用者來說非常重要。iSaaS解決方案的例子有如下：SnapLogic, TIBCO Simplr, 或 IFTTT.

混合整合平臺(HIP)

一個成功的關鍵是，你可以在不同的平臺間傳輸內容。Gartner稱之為混合整合平臺（HIP）。不同的元件共享元資料，一個單一的IDE和統一運營管理。卓越的整合能力以及API管理元件對於敏捷開發，部署和運維也是非常重要的。

例如，你可能希望開發一個基於PaaS的編排服務整合解決方案，並希望稍後移植它到預置整合平臺版本。 或者你可能想用iPaaS中介軟體定義一個REST服務（基於“合同第一條原則”）以及模擬它在預定義後實現的預置ESB上的介面服務。同樣的服務也需要通過API暴露給合作者或者公共訪問者。

更多的中介軟體框架和供應商

最後，我想強調某些其他框架和供應商，它們可能會與實現你的原生雲微服務相關，但在文章中還未提及的：

• WSO2 Jave微服務框架 是基於廠商開源中介軟體之上的低層次的編碼框架一個很好的例子。
• Amazon EC2 容器服務 (ECS) 和 Google 容器引擎 是 “容器即服務(CaaS)”的兩個例子，允許容器作為SaaS解決方案的自助服務使用
• 其他雲供應商如Amazon, Microsoft, 或 Google同時也是中介軟體的供應商。 例如，Amazon AWS提供雲訊息的服務(SQS 以及其他)，流媒體和分析 (Kinesis), 容器 (ECS), 微服務 (Lambda)以及更多。
• 大量的其他中介軟體供應商同時也提供原生雲服務。更多細節見如下文章Software AG Cloud, Talend Integration Cloud, 或 Oracle Cloud Platform.
• 這些日子以來物聯網的中介軟體是另一個顯著增長的領域。例如，看看開源的整合解決方案，如Node-RED（基於js，由IBM開源）或Flogo（基於谷歌的Go Programming Language，很快由TIBCO釋出並開源）。兩者都提供一個零程式碼環境的Web IDE構建和部署，整合和資料處理以直接使用物聯網的標準，如連線裝置MQTT, WebSockets, 或 CoaP。

最後，我想要提一下 原生雲端計算基金會(CNCF)， 它可能會在未來對本文中提及的一系列框架更加相關。該CNCF成立，目的是幫助促進開發者和操作者對部署原生雲和基於容器的應用程式服務共性技術之間的合作。創始成員包括Google, Cisco, IBM, Docker, 和 VMware。最初的兩個專案就是Kubernetes 和 Prometheus。

微服務，容器和原生雲不適合每個專案…

…但他們對我們的思想中關於IT架構有著巨大的影響。在很多新的專案中，這些概念絕對有意義並創造了很多益處，比如靈活的開發，部署，和運營。想想取捨，並充分利用原生雲架構的那些對你專案有意義的部分。現代中介軟體將利用微服務，容器和原生雲架構！無論是對於整合，API管理，事務處理，流媒體分析，業務流程管理，或其他任何形式的無論預置部署或雲中間件。

感謝你閱讀這篇廣泛的文章。我認為這對我們所有人來說都是非常有意義的，無論你是否要實現定製化的應用程式或者直接在你的專案中利用中介軟體。與往常一樣，我很歡迎任何反饋或評論，請傳送你的建議到 Email, Twitter, 或 LinkedIn。

順便說一句：這篇文章的內容第一次被討論是在2016年4月我參加以下會議的時候：JPoint in Moscow, Russia。詳細內容見如下連結: