微服务，容器和云原生架构的中间件世界的现状
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）。
非常好我支持^.^
(0) 0%
不好我反对
(0) 0%