本文探讨了Linux容器如何通过Docker等技术推动微服务的普及，强调了容器在软件开发中的灵活性、速度和可移植性优势。文章介绍了记录和监控、零停机连续交付和动态服务注册表作为容器化微服务的关键概念，阐述了容器如何与微服务架构相辅相成，促进更快、更频繁的软件发布。IBM Containers等服务为企业提供了管理和运行基于容器的微服务解决方案。
在本系列的 第1部分中，我讨论了微服务的确切含义以及它们与传统构建的系统（整体式）的区别。 第二部分是关于Linux容器的功能-它们如何彻底改变软件开发并推动微服务向整个行业转移。 在将基于容器的基础结构用于基于微服务的应用程序时，我将介绍三个关键的概念，这些概念对于您至关重要：
- 记录和监控
- 零停机连续交付
- 动态服务注册表
我将首先概述容器，容器管理器以及容器与微服务的关系。
容器和微服务：完美的一对
除非您对云技术和本机应用程序开发完全不熟悉，否则您可能听说过Linux容器和基于容器的项目在过去几年中引起了轰动。 但是，如果您没有，请考虑将Linux容器看作是轻量级虚拟机，可以更灵活地使用，更快速地集成并且更容易地分发。 负责这项工作的项目之一是Docker。 自2012年推出以来，Docker团队（现在是公司）提供了一种通过Linux容器构建，打包和分发云原生应用程序的简单方法。
容器与虚拟机有何不同？ 每个虚拟机（如下图左侧所示）运行自己的来宾操作系统实例，并包含自己的库和二进制文件。 容器（如右图所示）是隔离的，它们共享底层的主机OS和库，同时仅打包必要的应用程序二进制文件。
“许多行业领导者正在迁移到基于容器的基础架构，无论是在云中还是在内部部署中，以获取极大的收益。 ”
容器在Linux系统上作为最小的资源集运行，并且打包的应用程序通常不超过几百兆字节。 基于虚拟机的应用程序通常至少要大三到四个数量级（数十个千兆字节）。 您可以轻松地看到容器如何变得更小 ， 更快 ，如何适应微服务范式- 第1部分中的两个微服务原则。
许多行业领导者正在迁移到基于容器的基础架构，无论是在云中还是在内部部署中，以获取最大收益。 一项主要收益是，Docker和其他类似的Linux容器技术易于集成到持续集成和持续交付管道中：根据最近一项自筹资金的Docker研究，平均而言，Docker用户的软件发布频率是后者的七倍。 像Gilt Groupe这样的公司已经采用了微服务和容器化基础架构，有时每天发送软件多达100次。 快速推送代码，自动重建最小尺寸的Docker映像以及通过通用代码库管理大量已部署映像的能力可通过公司的交付管道以惊人的速度运行。
Docker容器的另一个好处之一就是这些打包应用程序的可移植性，即Docker映像。 Docker映像可以在环境之间和通过构建管道无缝移动。 例如，BBC新闻（英国广播公司的一个部门）表示，其持续集成工作在基于Docker的基础架构中的运行速度提高了60％以上。 在整个交付管道中移动相同代码的能力-最大限度地减少了每个阶段对软件配置的需求，并且在整个过程中具有可预测的硬件资源需求-从而比以往任何时候都更快地加快了开发，测试和生产的速度。 由于每个Docker映像中的系统组件都是模块化的，因此公司能够看到这些效率的提高。 您不需要每次都配置软件。 您只需启动一个容器实例，就可以使用了。
Docker是一个用于代码的运输容器系统，可简化通过Linux容器进行软件开发和交付的过程。 Docker充当引擎，使任何有效负载都可以封装为轻巧，可移植的自足容器。 这样的容器可以使用标准操作进行操作，并且可以在几乎任何硬件平台上一致地运行。
如果你是新来的容器和码头工人，看到相关信息的链接，对一般泊坞窗和Linux容器伟大的介绍材料。 如果您具有Docker的丰富经验并想在云中亲身体验Docker，那么IBM Containers for Bluemix是一项企业级容器服务，您可以立即免费开始使用。 您将拥有自己的私有注册表来存储所有图像，访问受支持的中间件的IBM公共注册表，托管的交付管道集成以及对150多种Bluemix™服务的访问。 您可以使应用程序在Docker容器中运行的速度比以往更快。
更快，更小：容器作为软件开发的纳米机器人
当您开始看到容器为什么对微服务如此重要时（作为体系结构样式的关键启用技术之一），您还可以开始看到容器的管理同样重要。 如您从第1部分所知，我们没有扩大规模，而是在微服务中扩大规模。 无需向微服务运行时添加更多的RAM，我们只需获得另一种相同类型的微服务运行时。 需要更多RAM？ 获取第三个实例。 这种方法仅适用于每个具有一个容器实例的几个服务，但是正如任何具有计算机技能和大家庭的人都知道的那样，当您远程管理数十台服务器时，它会很快失去控制。
考虑一下您将需要多快的时间来管理100多个个体实例。 如果您从构成应用程序的少量微服务开始（例如五个或六个），则每个微服务应至少具有三个支持每个微服务的容器实例。 因此，马上就可以使用18个容器实例。 假设您添加了另一个微服务，或者您的应用程序确实成功，并且某些服务需要扩展到5到10个容器实例。 在美好的一天，您可以轻松地访问100多个容器实例进行管理。
幸运的是，许多开源项目都可以满足这一确切需求。 例如， Kubernetes ， 阿帕奇Mesos和车队可以很容易地从单个控制台或命令行管理数以千计的容器实例，采用基于基础设施的领域特定语言。
该管理概念紧密地加强了第1部分中的“牛与宠物”的概念。 这个想法是，我们通过持续集成/持续交付过程部署的所有容器都是不可变的。 部署它们后，您将无法更改它们。 相反，如果您需要更改或更新，请使用已应用正确的更新来启动一个新的容器集群，并拆除旧的容器。 管理1000头牛比管理1000头宠物要容易得多。 不要误会我的意思：我们都喜欢我们的宠物，但是如果您想快速创新并为您的客户创造价值，并为您的业务带来收益，那么您将无法花费所有的时间将每只宠物全部饲养所需的温柔爱心护理。 诸如Kubernetes，Apache Mesos和Fleet之类的项目，以及诸如IBM Containers之类的托管容器服务，都可以集成您的交付管道和图像注册表，以快速，轻松地管理基础设施的各个阶段，成为高效率的牛。
顺便说一句，应该注意的是，尽管某些容器服务仍将虚拟机用作Docker主机，但仍应将其视为牛。 这些虚拟机在资源和集成管理功能方面更加强大，但是由于它们由基于容器的工作负载的需求动态管理，因此仍被普遍认为是牛。
微服务架构：您最好的借口，而不是打W鼠
到目前为止，我已经讨论了为什么更多的容器更好，以及如何大规模处理通用基础架构。 既然您已经适应了开发容器并与宠物道别的概念，那么您就需要开始考虑开发应用程序并将其投入生产。
这使我了解到对基于微服务的应用程序开发至关重要的三个关键元素：
- 记录和监控
- 零停机连续交付
- 动态服务注册表
您想从一开始就考虑所有这些功能，但不必立即解决它们。
当我讨论这些功能时，您还将看到为什么集成的微服务结构（例如Bluemix及其相关服务）使管理微服务体系结构变得如此容易。
记录和监控
如果您为应用程序和服务提供生产级支持，则第一个问题应该始终是：“出问题时我该怎么办？” 注意，在该问题中甚至没有暗示“ if”。 组件将发生故障，版本将发生变化，第三方服务将中断。 您如何才能保持一定的卫生水平以及用户所需的正常运行时间？ 这是第一个问题。
如前所述，您希望容器是不可变的。 因此，大多数IT组织不提供对容器实例的系统级访问-没有SSH，没有控制台，什么也没有。 那么，您应该如何知道无法更改的黑匣子内部发生了什么？ 这是第二个问题。
幸运的是，这个问题已经通过ELK堆栈的概念（ Elasticsearch ， LogStash和Kibana）解决了 。
这三个独立的组件提供了汇总日志，通过汇总日志搜索自由格式以及基于日志和跨平台监视的活动创建和共享仪表板的功能。 这是一项强大的功能-比登录到单台计算机并运行sed ， grep和awk的sysadmin工具箱要好得多。 您具有对所有日志的中央存储库的全功能访问权限。 您可以关联系统和微服务之间的事件，因为通常会看到事件和ID在系统中传播并遇到类似的问题。
无论是在云中还是本地运行，您都可以通过多种方式与ELK堆栈集成：通过托管服务，开放源代码变体以及通常作为平台即服务产品内置的选件-例如IBM Containers 。 在Bluemix上的容器运行时内部，您可以访问功能齐全的多租户ELK堆栈，该堆栈会自动从基于Docker容器的运行时接收日志，为您提供对这些运行时事件的可见性和可搜索性，同时还为您提供了基于Kibana的预配置仪表板开箱即用。 如果您想开始使用容器，那么这是一项关键功能，它使IBM Containers成为基于容器的微服务的绝佳选择。
零停机连续交付
既然您已经放心了，您将了解天空开始下降时的处理方式（当然，您希望它永远不会发生），您可以继续快速部署所有惊人的应用程序更新。 考虑到一些大型公司每周要部署数十，数百或数千次应用程序，那么您就不得不考虑停机时间。 当然，这些公司每次推出新版本时都不会出现应用程序中断的情况；如果这样做，他们永远都不会崩溃。
这些公司已经掌握了零停机时间部署。 这可以被称为许多事物，通常具有从红黑到蓝绿等各种丰富多彩的变体，但是它们都归结为相同的原理：无论如何，即使通过大量更新，您的应用程序始终可用，因为计划内停机造成的网站中断对您或您的用户不利。
现在，使用第1部分中描述的整体式工具，避免计划中的停机是危险的，耗时的，昂贵的，并且使所涉及的每个人都很疲惫。 需要大量镜像资源的大量镜像是很难管理的，并且导致了深夜，在所谓的“非工作时间”窗口中，当大量工作耗费大量精力同时又将新版本升级和旧版本降低时，更是如此-更不用说计算了如果需要回滚或在直接负责的团队无法控制的范围内出了什么问题，该如何处理旧版本。
通过微服务和基于容器的应用程序，这些担忧（即使没有完全消除）也可以最小化，尤其是在当今Bluemix上提供了一些关键服务的情况下。 通过将组件分解成更小的组件，您可以在对整个系统造成最小影响的情况下部署它们，同时在某些时候保持更多组件的状态以防止中断。 Bluemix上提供的一项新服务Active Deploy提供了此功能，并已预先集成到Delivery Pipeline中。 较小的团队可以更有效地管理更多的应用程序，因为部署的每个版本都可以自动监督其正常运行时间，从而节省了人力和计算资源。
动态服务注册表
本期的最后一个主题是动态服务注册表的概念。 本主题包括您可能已经知道的服务发现或服务代理的概念。 这两个概念在任何方面都不相同，但是它们足够接近，可以用这种方法进行介绍。
现在，您将创建成千上万个支持所有应用程序中的微服务的容器实例，应用程序中的其他组件将如何理解正在发生的事情？ 他们将如何知道可以使用哪些其他微服务来进行服务调用？ 他们将如何响应对他们的服务电话？
服务发现和服务代理之间的区别在于您是要自己进行搜索还是让其他人为您进行搜索。 打个比方，假设您需要运输服务。 您要从单个提供商（例如美国邮政服务（USPS））还是从多服务票据交换所（例如Staples）查找服务。
例如，如果我要寄送包裹，我可以转到USPS网站，为我要寻找的邮局类型输入几个参数，取回选项列表，选择一个，然后去寄送我的包裹包。 这就是服务发现的概念：我使用一个众所周知的可用服务端点注册表，该注册表在服务联机和脱机时更新。 通过REST API，调用应用程序可以查询服务发现服务，以确定可用于特定服务调用的服务类型以及数量，直至该请求服务的特定版本。
如果我不想成为选择将包裹寄至何处的人，我只想说：“把包裹拿到地址标签上的字样”，就可以拿到订书钉上。 然后，Staples将根据我提供的所有信息为我的包裹选择最具成本效益的送货方式。 我将包裹带到一家知名的服务提供商，并让它为我处理包裹的路由。 这就是服务代理的概念：调用一个众所周知的终结点，然后根据预先建立的规则或元数据自动将该呼叫转发到支持服务的实际支持服务。
有很多理由认为服务发现优先于服务代理，反之亦然，但这实际上取决于偏好或实现经验/要求。 一些开源的服务发现产品，例如etcd和Consul ，提供了分布式服务注册表，您可以使用它们注册，标记和心跳所有可用的服务实例。 甚至还有一些很酷的项目，例如Registrator ，它们都会在创建Docker容器后自动将您的服务注册到这些端点之一。
从长远来看，某些较流行的service-proxy项目支持以下关键论点：service-proxy方法需要较少的网络跃点才能到达最终的支持服务。 Netflix Hystrix项目是最大，最受欢迎的服务代理项目之一。 Hystrix是基于Java™技术的库，它超越了简单的服务代理，但在服务代理库中提供了许多服务质量改进。
显然，这两种模式对于自动管理服务实例并使它们成为可用的微服务基础结构的一部分都很重要。 Bluemix很快将拥有自己的多租户服务发现产品（如果您在阅读本文时尚不具备），则无需管理服务发现服务，这可能很少。 想象一下，自动注册所有容器实例，无论您是手动旋转它们，通过Bluemix Delivery Pipeline推动它们，还是与诸如IBM UrbanCode Deploy或Jenkins之类的本地管道集成。
结论
您已经在这里看到了容器如何加速对云原生应用程序开发的推动。 借助前所未有的内置管理功能，可以比以往更快，更轻松地交付更小，更快的应用程序组件。 在受管理的服务（例如IBM Containers）上部署容器以及所有支持的微服务功能（包括日志记录和监视，Active Deploy和服务发现），可以轻松地将下一步从您的现有整体转移到云中。
我们正在朝着更智能，模块化的系统发展，该系统从头到尾更加自动化和集成化。 这些将以自己的步调发展，对基础架构中的可用内容具有自我意识，知道哪些不可用，以及何时需要进行更改。 所有这些功能以及更多功能将在本系列的后续系列文章中介绍。
543
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
