中間件和微服務(wù),Docker以及原生云架構(gòu)的關(guān)系
微服務(wù)和Docker的發(fā)展勢頭
微服務(wù)和容器的主要目標(biāo)是縮短軟件開發(fā)時間,以及實現(xiàn)開發(fā)、部署以及運維的更大靈活性。為什么它過去幾個月的發(fā)展勢頭這么猛?因為幾乎所有科技巨頭企業(yè)如亞馬遜,谷歌,F(xiàn)acebook,Netflix都在這里激烈競爭。
微服務(wù)就像是一個面向服務(wù)的架構(gòu)(SOA):這是一種架構(gòu)和供應(yīng)商技術(shù)分別獨立的設(shè)計理念。因此,目前并沒有明確的界定標(biāo)準(zhǔn)或規(guī)范。你永遠需要在和其他人討論之前定義你所理解的微服務(wù)術(shù)語。每個人都有不同的定義。在這篇文章中微服務(wù)是被開發(fā),部署和獨立縮放的服務(wù)。它們可以不針對任何技術(shù)來提供業(yè)務(wù)或整合邏輯。有些供應(yīng)商提供建立微服務(wù)的特殊支持(我們將在后面的文章中看到的),但基本上不涉及任何特定的技術(shù)支持。
關(guān)于微服務(wù)架構(gòu)的討論最早是一篇由Martin Fowler在2014寫的著名文章開始的,該文章的廣泛應(yīng)用起始于NetFlix的一系列豐富的開源微服務(wù)應(yīng)用框架。稍后我們會回來介紹更多細(xì)節(jié),本文章的很多內(nèi)容都是受到了Netflix杰出和詳細(xì)的技術(shù)博客帖子的啟發(fā)。
容器依賴其上運行的操作系統(tǒng)。容器的實現(xiàn)是基于Linux內(nèi)核的資源隔離功能,如內(nèi)核namespaces(隔離的應(yīng)用程序運行環(huán)境,包括進程樹,網(wǎng)絡(luò),用戶ID,以及安裝的文件系統(tǒng)),以及cgroup(提供資源限制,包括CPU,內(nèi)存, I / O和網(wǎng)絡(luò)),和一個有聯(lián)合能力的文件系統(tǒng)如AUFS和其他。這允許獨立容器在單個Linux實例中運行,避免了初始化以及維持虛擬機的開銷。
相比于虛擬機,容器的主要特點是標(biāo)準(zhǔn)化包裝,可移植性,基于按需創(chuàng)建的目的從而達到較低的啟動和占用時間,可重復(fù)性,更好的資源利用率,更好地融入發(fā)展中的生態(tài)系統(tǒng)整體(如持續(xù)集成/持續(xù)交付)。容器化的應(yīng)用程序可以在任何環(huán)境隨意創(chuàng)建和運行,無論是你的筆記本電腦,測試系統(tǒng)上,預(yù)生產(chǎn)和生產(chǎn)系統(tǒng)。而這一切完全不需要改變?nèi)萜饕约叭萜鲀?nèi)的應(yīng)用程序的任何內(nèi)容。
在微服務(wù)對立面,也有幾個容器軟件的特殊實現(xiàn)方式。但是大多數(shù)的發(fā)展勢頭都已經(jīng)被Docker拋在了后面。Docker的生態(tài)系統(tǒng)在日益增長。這必將在未來幾年更加鞏固,同時它也將變得比今天更加成熟。其他關(guān)于Docker技術(shù)的例子還有如, CoreOS’ rkt (Rocket) 及 Cloud Foundry’s Garden / Warden。請注意,所有這些容器的概念并不是什么新鮮事,早在UNIX系統(tǒng)中就已經(jīng)存在多年,比如Solaris Zones。
還有一些其他的商業(yè)案例如VMware Photon Platform / vSphere Integrated Containers 或者Microsoft’s Windows Server containers / Hyper-V containers or VMware Thinapp。
這里我們有一個非常好的關(guān)于Docker以及容器的概括介紹:Docker, the Future of DevOps,另外”The Open Container Initiative (OCI)”則是在2015年中期建立的一個全球性的,廠商無關(guān)的標(biāo)準(zhǔn)。許多軟件供應(yīng)商都是該委員會成員,包括Amazon, Intel, Docker, Facebook, IBM, Microsoft, Oracle, Pivotal, 和 VMware,以上只是眾多官方支持者的一部分。
一個原生云架構(gòu)
微服務(wù)和容器其獨立的服務(wù)以及靈活的部署僅僅是基礎(chǔ)需求。下面的章節(jié)會討論更多針對原生云架構(gòu)的附加需求。請注意,每節(jié)中我們都列出了很多可用的框架例子,這不代表它們是完整的列表。
- 原生云架構(gòu)實現(xiàn)了:
- 服務(wù)可擴展性
- 服務(wù)彈性
- 高可用性
- 自動負(fù)載均衡和故障切換
- DevOps
- 公有云、私有云及混合云通用
- 廠商無關(guān)的部署
- 快速升級
- 更高的利用率并降低基礎(chǔ)設(shè)施成本
- 更高的效率和靈活性
有了這一切,你可以專注于創(chuàng)新和解決您的業(yè)務(wù)問題,而不是在“靜態(tài)和僵化的傳統(tǒng)架構(gòu)”的大量技術(shù)問題中浪費時間。要知道,原生云意味著你可以不僅僅在公共云中部署軟件。私有云或混合云的部署也包含在云原生的定義中!
持續(xù)集成和持續(xù)交付
持續(xù)集成(CI) 和持續(xù)交付(CD) 需要很多不同的東西自動構(gòu)建,部署和運行微服務(wù)。 這包括用于自動測試和部署,內(nèi)部和外部的服務(wù)發(fā)現(xiàn)以及微服務(wù)和容器的分布式配置腳本。
自動化測試和部署腳本
持續(xù)集成CI 和持續(xù)交付CD始于數(shù)年前。你的包的構(gòu)建,測試和部署服務(wù)全部自動化完成。這提高了生產(chǎn)率,生產(chǎn)效率和產(chǎn)品質(zhì)量。下面是被用于CI / CD創(chuàng)建腳本的主要框架和工具:
- 自動構(gòu)建管理: Apache Ant, Apache Maven, Gradle, …
- 持續(xù)集成: Jenkins, Bamboo, …
- 持續(xù)交付: Chef, Puppet, SaltStack, Ansible, …
服務(wù)發(fā)現(xiàn)
我們使用了大量不同的獨立服務(wù)以及每個服務(wù)都有數(shù)量龐大分布式實例在工作。內(nèi)部服務(wù)發(fā)現(xiàn)框架用來實現(xiàn)定位服務(wù)實現(xiàn)負(fù)載均衡和故障切換目的。因此,我們需要每個服務(wù)提供者在可用時向服務(wù)發(fā)現(xiàn)者登記注冊。從而使消費者能夠基于注冊發(fā)現(xiàn)服務(wù)并連接使用它。
關(guān)于如何使用服務(wù)注冊中心有很多可選項,例如Netflix’ Eureka, Apache Zookeeper,Consul, Etcd。許多稍后討論的框架還包括隱式服務(wù)注冊。在本文中分類各種不同的框架并不是件簡單的事情,很多時候各種特性是相互重疊的。
除了內(nèi)部服務(wù)發(fā)現(xiàn)外,外部服務(wù)發(fā)現(xiàn)框架用于暴露內(nèi)部微服務(wù)接口給外界(其可以是公共互聯(lián)網(wǎng),合作伙伴或其他內(nèi)部部門)。這通常被稱為“Open API initiative”或“API Management”,并作為打包和API的自配置的入口(例如,在本例中的微服務(wù)),貨幣化和安全執(zhí)法網(wǎng)關(guān)(如認(rèn)證,授權(quán),限流)。為API管理一些相關(guān)的選項有:
- JBoss apiman: 開源的,底層的編碼框架,可以利用其它Redhat的JBoss項目
- Apigee: 專注于API 管理市場的競爭者
- Akana (former SOA Software): 專注于API 管理市場的競爭者
- CA’s Layer7: 強大的安全網(wǎng)關(guān),可以利用其他CA產(chǎn)品
- TIBCO’s Mashery: 強大的門戶網(wǎng)站和社區(qū),可以利用其他TIBCO產(chǎn)品
- 應(yīng)用TIBCO API Exchange Gateway滿足高級安全和路由要求
請參閱下面文章的有關(guān)使用案例和“Open API”產(chǎn)品分類詳細(xì)信息:API管理如何改變云計算,大數(shù)據(jù),物聯(lián)網(wǎng)的游戲規(guī)則。
動態(tài)分布式配置管理
在原生云架構(gòu)存在著大量敏捷和動態(tài)的變化以適應(yīng)分布式的微服務(wù)和容器,你無法手工管理和配置它們。服務(wù)被設(shè)計以適應(yīng)失敗,重生并迅速更新。因此,你需要自動化的配置管理以設(shè)置分布式節(jié)點上的新容器快速且自動配置。一些所需的功能如下:
- 運行期動態(tài)自適應(yīng)(例如,改變特定實例的服務(wù)行為,數(shù)據(jù)庫連接或者是日志層級)
- 基于復(fù)雜的請求或部署上下文改變多維屬性
- 基于請求上下文啟用或者停用特性(例如,顯示特定的用戶界面或者是特定的地區(qū)或者設(shè)備)
- 改變云的設(shè)計模式行為(詳見后續(xù)章節(jié)中的“彈性設(shè)計模式”)
動態(tài)分布式配置管理的兩個相關(guān)的框架是Netflix’ Archaius和 Spring Cloud Config. 這些框架使用動態(tài)配置的輪詢和回調(diào)機制(特定IP地址和主機)以適應(yīng)彈性和不斷變化的云的本地環(huán)境,因為傳統(tǒng)的推送模式無法在其中正常工作。
可擴展性和故障切換
一個原生云架構(gòu)的主要特點就是根據(jù)負(fù)載彈性伸縮和SLA的能力。這需要先進的集群管理,以及服務(wù)器端和客戶端彈性的負(fù)載平衡和設(shè)計模式。
集群管理(計劃和編制)
靈活的開發(fā)和部署是微服務(wù)和容器的一個關(guān)鍵優(yōu)勢。包括添加新功能以及舊功能的裁剪。零宕機和故障切換是必需的,同時你也需要保證高效的資源利用率。
集群管理器是專為故障切換和高可擴展性而設(shè)計。 它被用于自動編排容器調(diào)度和管理主機,包括每個主機的規(guī)則和約束應(yīng)用。
很多種集群管理框架已經(jīng)實現(xiàn),尤其是針對Docker。下面是一些最相關(guān)的實施案例(更詳細(xì)地討論在這里):
- Docker Swarm: 一個Docker原生框架,使用Docker API,可以很容易地利用其他Docker框架,如Docker Compose,它必須與其他框架如ETCD,Consul或ZooKeeper結(jié)合
- CoreOS Fleet: 基于systemd直接構(gòu)建的底層框架,經(jīng)常被用于作為高層解決方案的底層基礎(chǔ)架構(gòu)
- Kubernetes: 來自Google的開源項目并且得到了眾多其他公司的支持包括IBM, Red Hat和Microsoft。Kubernetes是結(jié)合了復(fù)雜的功能和相對簡單的安裝/配置的一個偉大組合。它不同于其他一些先進的集群管理器,你甚至可以通過一個簡單的“docker run”命令就將它設(shè)置在本地計算機上。如果你在云平臺上安裝它,那么它也可以利用平臺的特定功能,例如在AWS上它可以使用亞馬遜的ELB,或者它也可以利用Google云平臺的Google LB。
- Mesos’ Marathon: 基于強大(且復(fù)雜)的Apache Mesos之上的一個編排框架,一個“分布式系統(tǒng)內(nèi)核”。Mesos被用于大規(guī)模多用途的不同框架之上的封裝(如Apache Hadoop, containers via Marathon, batch processing via Chronos).
負(fù)載均衡(服務(wù)端和客戶端)
原生云上有眾多服務(wù)器隨時在生生滅滅。由此基于微服務(wù)和容器的負(fù)載均衡需要變得更加錯綜復(fù)雜。只是基于公共的IP地址和主機負(fù)載分布是不夠的了。如基于幾個因素的加權(quán)負(fù)載均衡概念能夠提供更卓越的彈性,如流量,資源使用情況或錯誤的條件。
傳統(tǒng)的服務(wù)器側(cè)負(fù)載平衡多年來用于在多個服務(wù)器之間分發(fā)網(wǎng)絡(luò)或應(yīng)用流量以增加應(yīng)用程序的容量和可靠性。著名的例子是F5公司的Big-IP產(chǎn)品或亞馬遜的AWS彈性負(fù)載均衡(ELB)服務(wù)。它們用于所謂的邊緣業(yè)務(wù),即外部服務(wù)的消費者分別導(dǎo)入為最終用戶的網(wǎng)絡(luò)流量。
此外,許多微服務(wù)架構(gòu)也包括客戶端負(fù)載平衡,以避免不必要的服務(wù)間的通信。因此一些框架,如Netflix Ribbon也嵌入到客戶端LB到每個微服務(wù)。這降低了通信的跳轉(zhuǎn),而不再需要在內(nèi)部的微服務(wù)之間服務(wù)通信多層跳轉(zhuǎn),我們稱之為所謂中間層或核心服務(wù)。
韌性設(shè)計模式
所有原生云架構(gòu)的新概念都需要新的設(shè)計模式來提供一個可重復(fù)的通用方案來解決經(jīng)常出現(xiàn)的問題。韌性設(shè)計模式通過實現(xiàn)高延時寬容,容錯和故障恢復(fù)邏輯可以防止連鎖故障,允許快速失敗和快速恢復(fù).
其中一個著名的模式就是Circuit Breaker用來檢測故障并封裝邏輯從而防止故障持續(xù)性重復(fù)發(fā)生 (在維護,臨時的外部系統(tǒng)故障或系統(tǒng)意外的困難期間)。Akka framework就是對這個模式的很好的解讀和實現(xiàn)。Netflix Hystrix也提供了一個復(fù)雜的實現(xiàn)用于在分布式系統(tǒng)中達到延時和容錯的目的。“Application Resiliency Using Netflix Hystrix”就是Ebay Tech發(fā)布的一個非常好的文章用于解釋他們?nèi)绾卫盟鼇韺崿F(xiàn)云模式的。
我們已經(jīng)有大量的云計算模式出現(xiàn)(未來將會更多)。例如,Kubernetes的技術(shù)博客所解釋的“Patterns for Composite Containers”,例如“Sidecar容器”,“大使容器”或“適配器容器”。
容器解決方案堆棧
正如你在上面的章節(jié)所看到的,目前已經(jīng)有很多可用的框架和工具鏈,而且它們的數(shù)量還在每月增長。這可能會提醒許多讀者Apache Hadoop的故事,它不太成熟的框架,及其生態(tài)系統(tǒng)令人難以置信的增長速度。今天的Docker也是如此。因此,一些“解決方案堆棧”正在興起,以幫助用戶入門以及管理使用一個單一(和有商業(yè)支持的)容器堆棧的所有挑戰(zhàn),就像眾所周知的Hadoop環(huán)境曾經(jīng)遇到的一樣。 容器解決方案堆棧的幾個例子是Tectonic(Kubernetes + CoreOS平臺),Docker數(shù)據(jù)中心,Mantl 或者 HashiCorp’s Nomad。 更多方案可能將在未來幾個月出現(xiàn)。
至此,我們已經(jīng)討論了幾個概念,框架和模式,以利用容器和微服務(wù)實現(xiàn)云計算的本地架構(gòu)。但是,你也需要某種云平臺用以部署和運行這一切。
私有,公共和混合云平臺
一個云平臺可以是私有云,公共云或者混合云,它提供了一種自助服務(wù)和靈活的云計算基礎(chǔ)設(shè)施(基礎(chǔ)設(shè)施作為一種服務(wù),即IaaS)。在云基礎(chǔ)設(shè)施之上,你需要一個平臺(平臺作為一種服務(wù),即PaaS),由此你可以部署和運行你的容器。下圖顯示了兩者的主要特點:

大多數(shù)企業(yè)選擇成熟可用的云產(chǎn)品,如Amazon Web Services,Microsoft Azure或開源OpenStack的IaaS和PaaS的平臺,如Red Hat’s OpenShift(這是基于Docker和Kubernetes的)或Cloud Foundry(提供開源并且由幾個供應(yīng)商提供的增強版本如IBM with Bluemix 或 Pivotal)。
使用現(xiàn)有的PaaS平臺的主要優(yōu)勢是一個原生云架構(gòu)的主要需求,如靈活的可伸縮性,容器編排,動態(tài)服務(wù)發(fā)現(xiàn),負(fù)載平衡或動態(tài)分布式配置管理外的即裝即用的支持。因此,你應(yīng)該在基于上面所討論的各種不同架構(gòu)建立自己的平臺之前評估不同的PaaS平臺。大多數(shù)平臺隱式利用了這些框架的其中一種或另一種。
在討論了所有這些原生云架構(gòu)的需求和可用的框架細(xì)節(jié)后,現(xiàn)在讓我們來看看為何說這一切和中間件都是相關(guān)的。
中間件的聯(lián)系(一體化,API管理,事務(wù)處理)
在進一步之前,我需要澄清:微服務(wù),容器和原生云架構(gòu)并不適合所有的場景。請記住:這里引入了很多新的概念和復(fù)雜性。“微服務(wù)不是免費的午餐”!
因為整合是大多數(shù)中間件項目取得成功的關(guān)鍵,因此在下面的段落中我會格外注重平臺集成。無論是云,移動,大數(shù)據(jù)或物聯(lián)網(wǎng)等趨勢,都不可能在沒有和IT架構(gòu)很好的融合下生存。
企業(yè)服務(wù)總線(ESB)是在許多企業(yè)作為自定義應(yīng)用程序,商業(yè)現(xiàn)有軟件,遺留應(yīng)用程序,數(shù)據(jù)庫和云服務(wù)之間的戰(zhàn)略整合平臺。然而,并非每一個ESB部署都需要是原生云。在銀行,零售商,航空公司,電信公司和其他執(zhí)行關(guān)鍵任務(wù)的公司,部署一個具有高性能,高可用性和容錯性的ESB中心仍可能是未來幾十年的最佳選擇。
在另一方面來說,ESB并不是個像你可能認(rèn)為的那樣復(fù)雜的,中央控制并且重量級的野獸。這在5至10年前可能是真實的(這也是其中一個多個SOA項目在那段時間失敗的原因之一)以及它在今天對于某些供應(yīng)商來說仍然是真實情況。但總的來說(并且對許多廠商都是如此)企業(yè)服務(wù)總線在2016年已經(jīng)是一個成熟,穩(wěn)定,易于使用的組件,它應(yīng)提供:
- 集成
- 編排和服務(wù)協(xié)同
- API和商業(yè)服務(wù)
- 消息
- 獨立部署
- 可擴展性和輕量級平臺
- 自動化
根據(jù)你的需求,你應(yīng)該能夠決定你需要什么樣的原生云以及是否能夠利用微服務(wù)及容器(包括所有的利弊)。不只是選擇這些概念,也包括你真正需要的工具和功能。
中間件范例
說了這么多,讓我們來看看幾個不同的中間件的例子,以及你可能會如何利用微服務(wù),容器和原生云架構(gòu)為此服務(wù):
- 集成: 構(gòu)建(微)服務(wù),并使用ESB的集成功能的API; 整合和協(xié)調(diào)不同(微)服務(wù)(構(gòu)建復(fù)合服務(wù))
- API管理: 通過API暴露,發(fā)布和貨幣化微服務(wù)給內(nèi)部,外部合作伙伴或公共世界。
- 事務(wù)處理: 實時處理關(guān)聯(lián)分布的微服務(wù)事件增加商業(yè)價值(如欺詐檢測,交叉銷售和預(yù)測性維護)
上述所有的中間件組件:
- 需要敏捷性和靈活性
- 控制和利用其他微服務(wù)
- 必須支持微服務(wù)特征本身(容器, CI / CD, elastic 彈性伸縮性等) 適配到原生云架構(gòu),并允許快速變化
讓我們回過頭來看整合平臺的例子和ESB。如果你需要一個更靈活,原生云集成的解決方案,而不是傳統(tǒng)的,更核心的ESB部署,那么你有三種選擇(這里不關(guān)心品牌或產(chǎn)品名稱):
基于PaaS集成中間件
這非常類似于預(yù)置部署ESB用于實施“核心服務(wù)”,例如: 中央部分,往往是復(fù)雜和關(guān)鍵任務(wù)的服務(wù)。開發(fā)是在傳統(tǒng)的IDE上完成。然而,關(guān)鍵的區(qū)別在于,該解決方案是原生云即它支持容器和微服務(wù)。你可以使用這種集成中間件開發(fā)被本地部署到PaaS平臺上,如Cloud Foundry或OpenShift上的集成應(yīng)用。一些供應(yīng)商提供了一個供應(yīng)商無關(guān)的解決方案,在那里你可以部署集成應(yīng)用程序到任何地方,而不依賴于特定的云平臺或供應(yīng)商。
你可以開發(fā)不同更敏捷,快速變化并且提供網(wǎng)絡(luò)擴展性的的“原生云服務(wù)”:
- 集成應(yīng)用程序和服務(wù): 創(chuàng)建商業(yè)化的web APIs提供后端web 服務(wù)如ERP,CRM,利用如SOAP,SAP,Oracle,IBM MQ等企業(yè)的技術(shù)管理訂單系統(tǒng)。
- 功能微服務(wù)化: 創(chuàng)建應(yīng)用只需專注于業(yè)務(wù)功能,而無需理解底層代碼復(fù)雜性
- API協(xié)同服務(wù): 圖形化的協(xié)同API充分利用PaaS的集成工具(如流程編排,數(shù)據(jù)映射器或連接器)
市場上對于部署基于PaaS平臺的原生云上創(chuàng)建集成應(yīng)用并沒有很多可選項。
TIBCO的 BusinessWorks Container Edition 是一個供應(yīng)商無關(guān)的配套例子支持CloudFoundry, Docker, Kubernetes, AWS ECS, 等。 JBoss Middleware Services 允許其中間件應(yīng)用程序(包括JBoss Fuse和A-MQ)在OpenShift上部署。
云集成中間件 (iPaaS)
一個IPaaS云集成中間件是基于云,使用web瀏覽器而不是桌面IDE的,并且支持執(zhí)行集成腳本流程,有集成的開發(fā)和生命周期管理,有應(yīng)用流程管理和監(jiān)控,協(xié)同基本的云功能例如多租戶,彈性和自我配置。iPaaS能和預(yù)置部署的ESB或基于PaaS平臺上的集成中間件緊密合作。
iPaaS工具提供了直觀的基于Web的集成,它的目的在于提供給用戶一些技術(shù)理解。例如,如何創(chuàng)建和部署REST服務(wù)或配置連接和開放API的政策。它通常用來構(gòu)建“邊緣服務(wù)”,有時也被稱為“微流”它可能會更頻繁地發(fā)生變化,它也往往不是關(guān)鍵任務(wù)。
一些iPaaS解決方案的示例如下:Dell Boomi, Informatica Cloud, MuleSoft Anypoint Platform,SnapLogic, Jitterbit, 以及 TIBCO Cloud Integration.
更詳細(xì)的介紹,包括iPaaS的利弊可以在這里找到:“iPaaS: 什么是云技術(shù)以及為什么它這么重要”.
SaaS云集成中間件 (iSaaS)
這種SaaS解決方案提供了企業(yè)用戶一個直觀的基于Web的用戶界面,即“Citizen Integrator”,從而根據(jù)do-it-yourself (DIY)原則無需技術(shù)知識即可完成個人集成。 Citizen Integrators通過配置,而無需開發(fā)開發(fā)或從頭構(gòu)建他們新的集成流程即可構(gòu)建新的集成。例如,企業(yè)用戶創(chuàng)建一個自動流程通過從SaaS服務(wù),如Salesforce或Marketo和他的微軟Excel表自助服務(wù)來同步他的數(shù)據(jù)。
iSaaS整合是預(yù)置部署,PaaS和iPaaS集成有明顯的互補性。對于沒有戰(zhàn)略和關(guān)鍵任務(wù)的企業(yè),它們也應(yīng)該被視為“邊緣業(yè)務(wù)”。但對于具體的業(yè)務(wù)用戶來說非常重要。iSaaS解決方案的例子有如下:SnapLogic, TIBCO Simplr, 或 IFTTT.
混合集成平臺(HIP)
一個成功的關(guān)鍵是,你可以在不同的平臺間傳輸內(nèi)容。Gartner稱之為混合集成平臺(HIP)。不同的組件共享元數(shù)據(jù),一個單一的IDE和統(tǒng)一運營管理。卓越的集成能力以及API管理組件對于敏捷開發(fā),部署和運維也是非常重要的。
例如,你可能希望開發(fā)一個基于PaaS的編排服務(wù)集成解決方案,并希望稍后移植它到預(yù)置集成平臺版本。 或者你可能想用iPaaS中間件定義一個REST服務(wù)(基于“合同第一條原則”)以及模擬它在預(yù)定義后實現(xiàn)的預(yù)置ESB上的接口服務(wù)。同樣的服務(wù)也需要通過API暴露給合作者或者公共訪問者。
更多的中間件框架和供應(yīng)商
最后,我想強調(diào)某些其他框架和供應(yīng)商,它們可能會與實現(xiàn)你的原生云微服務(wù)相關(guān),但在文章中還未提及的:
WSO2 Jave微服務(wù)框架 是基于廠商開源中間件之上的低層次的編碼框架一個很好的例子。
Amazon EC2 容器服務(wù) (ECS) 和 Google 容器引擎 是 “容器即服務(wù)(CaaS)”的兩個例子,允許容器作為SaaS解決方案的自助服務(wù)使用
其他云供應(yīng)商如Amazon, Microsoft, 或 Google同時也是中間件的供應(yīng)商。 例如,Amazon AWS提供云消息的服務(wù)(SQS 以及其他),流媒體和分析 (Kinesis), 容器 (ECS), 微服務(wù) (Lambda)以及更多。
大量的其他中間件供應(yīng)商同時也提供原生云服務(wù)。更多細(xì)節(jié)見如下文章Software AG Cloud, Talend Integration Cloud, 或 Oracle Cloud Platform.
這些日子以來物聯(lián)網(wǎng)的中間件是另一個顯著增長的領(lǐng)域。例如,看看開源的集成解決方案,如Node-RED(基于js,由IBM開源)或Flogo(基于谷歌的Go Programming Language,很快由TIBCO發(fā)布并開源)。兩者都提供一個零代碼環(huán)境的Web IDE構(gòu)建和部署,集成和數(shù)據(jù)處理以直接使用物聯(lián)網(wǎng)的標(biāo)準(zhǔn),如連接設(shè)備MQTT, WebSockets, 或 CoaP。
最后,我想要提一下 原生云計算基金會(CNCF), 它可能會在未來對本文中提及的一系列框架更加相關(guān)。該CNCF成立,目的是幫助促進開發(fā)者和操作者對部署原生云和基于容器的應(yīng)用程序服務(wù)共性技術(shù)之間的合作。創(chuàng)始成員包括Google, Cisco, IBM, Docker, 和 VMware。最初的兩個項目就是Kubernetes 和 Prometheus。
微服務(wù),容器和原生云不適合每個項目…
…但他們對我們的思想中關(guān)于IT架構(gòu)有著巨大的影響。在很多新的項目中,這些概念絕對有意義并創(chuàng)造了很多益處,比如靈活的開發(fā),部署,和運營。想想取舍,并充分利用原生云架構(gòu)的那些對你項目有意義的部分?,F(xiàn)代中間件將利用微服務(wù),容器和原生云架構(gòu)!無論是對于集成,API管理,事務(wù)處理,流媒體分析,業(yè)務(wù)流程管理,或其他任何形式的無論預(yù)置部署或云中間件。