微服務，容器和云原生架構的中間件世界的現狀
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也提供了一個復雜的實現用于在分布式系統中達到延時和容錯的目的?！癆pplication Resiliency Using Netflix Hystrix”就是Ebay Tech發布的一個非常好的文章用于解釋他們如何利用它來實現云模式的。
我們已經有大量的云計算模式出現（未來將會更多）。例如，Kubernetes的技術博客所解釋的“Patterns for Composite Containers”，例如“Sidecar容器”，“大使容器”或“適配器容器”。
容器解決方案堆棧
正如你在上面的章節所看到的，目前已經有很多可用的框架和工具鏈，而且它們的數量還在每月增長。這可能會提醒許多讀者Apache Hadoop的故事，它不太成熟的框架，及其生態系統令人難以置信的增長速度。今天的Docker也是如此。因此，一些“解決方案堆?！闭谂d起，以幫助用戶入門以及管理使用一個單一（和有商業支持的）容器堆棧的所有挑戰，就像眾所周知的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）。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%