微服务和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管理，事务处理，流媒体分析，业务流程管理，或其他任何形式的无论预置部署或云中间件。
