为什么比以往更容易交付更小，更快的应用程序组件

在本系列的第1部分中，我谈到了什么是微服务以及它们与传统构建的系统（monoliths）的区别。第二部分是关于Linux容器的强大功能 - 它们如何彻底改变软件开发并为微服务提供动力以改变整个行业。在基于微服务的应用程序采用基于容器的基础架构时，我将介绍三个对您至关重要的概念：

• 记录和监控
• 零停机持续交付
• 动态服务注册表

我将首先概述容器，容器管理器以及容器与微服务的关系。

容器和微服务：完美的一对

除非您对云技术和云原生应用程序开发完全陌生，否则您可能听说过Linux容器以及过去几年引爆的基于容器的项目。但是如果你还没有，可以将Linux容器视为轻量级虚拟机，可以更灵活地使用，更快地集成，并且更容易分发。领导此项收费的项目之一是Docker。自2012年推出以来，Docker团队（现在的公司）提供了一种通过Linux容器构建，打包和分发云原生应用程序的简单方法。

容器与虚拟机有何不同？每个虚拟机（如下图左侧所示）运行自己的客户机操作系统实例，并包含自己的库和二进制文件。容器（如右图所示）是隔离的，共享底层主机操作系统和库，同时只打包必要的应用程序二进制文件。

“许多行业领导者正在转向基于容器的基础架构，无论是在云端还是在本地，都能获得极大的收益。”

容器作为Linux系统上的最小资源集运行，并且打包的应用程序通常不超过几百兆字节。基于虚拟机的应用程序通常至少要大三到四个数量级（几十千兆字节）。您可以轻松地了解容器如何适应微服务范例，更小更快 - 第1部分中的两个微服务原则。

许多行业领导者正在转向基于容器的基础架构，无论是在云端还是在本地，都可以获得极大的收益。其中一个主要收获是Docker和其他类似的Linux容器技术很容易集成到持续集成和连续交付管道中：根据最近自筹资金的Docker研究，平均而言，Docker用户的软件发送频率是其七倍。像Gilt Groupe这样的公司已经拥抱微服务和集装箱化基础设施，有时每天运送软件100次。能够快速推动代码更改，自动重建最小尺寸的Docker镜像，并从公共代码库管理大量这些部署的图像，从而通过公司的交付管道获得令人印象深刻的速度。

Docker容器的另一个好处是这些打包应用程序的可移植性，称为Docker镜像。 Docker镜像可以跨环境和构建管道无缝移动。例如，BBC新闻（英国广播公司的一个部门）表示，其基于Docker的基础设施的持续集成工作速度提高了60％以上。能够在整个交付流程中移动相同的代码 - 最大限度地减少每个阶段的软件配置需求并在此过程中具有可预测的硬件资源需求 - 通过开发，测试和生产来加快应用程序的速度。公司能够看到效率的提高，因为他们的系统组件在每个Docker镜像中都是模块化的。您无需在每次需要时配置软件。你只需启动一个容器实例，就可以了。

Docker是一个代码的运输容器系统，可以轻松地通过Linux容器进行软件开发和交付。 Docker充当引擎，可以将任何有效负载封装为轻量级，便携式自给自足的容器。这些容器可以使用标准操作进行操作，并且几乎可以在任何硬件平台上运行。

如果您是容器和Docker的新手，请参阅相关链接，了解有关Docker和Linux容器的一般介绍材料。如果您对Docker有经验并希望在云中亲自动手使用Docker，那么IBM Cloud Kubernetes Service是一种企业级容器服务，您可以立即免费使用它。您可以使用自己的私有注册表来存储所有映像，访问支持的中间件的IBM公共注册表，托管交付管道集成以及访问150多种IBM Cloud™服务。您可以比以往更快地在Docker容器中运行应用程序。

更快更小：容器作为软件开发的纳米机器人

您可以开始了解容器对于微服务如此重要的原因 - 作为架构风格的关键支持技术之一 - 您也可以开始看到容器的管理同样重要。正如您在第1部分中所了解的那样，我们不是按比例放大，而是在微服务中扩展。我们只是获得了同一类型的另一个微服务运行时，而不是向微服务运行时添加更多RAM。需要更多内存？得到第三个实例。这种方法适用于每个只有一个容器实例的几个服务，但是对于拥有计算机技能和大家庭知识的人来说，当您远程管理数十台服务器时，它可能会很快失控。

想想您需要多快管理100多个单独的实例。如果你从构成你的应用程序的一些微服务开始 - 比如说五个或六个 - 每个应该至少有三个容器实例支持每个微服务。所以马上，你就是18个集装箱实例。假设您添加了另一个微服务，或者您的应用程序非常成功，您需要为某些服务扩展到5到10个容器实例。在一个美好的一天，你很容易接近超过100个容器实例来管理。

值得庆幸的是，许多开源项目可以满足这一需求。例如，Kubernetes，Apache Mesos和fleet使用基于基础结构的特定于域的语言，可以轻松地从单个控制台或命令行管理数千个容器实例。

这种管理概念紧紧地强化了第1部分中与牛相比较的概念。我们的想法是，我们通过持续集成/持续交付流程部署的所有容器都是不可变的。部署后，您无法更改它们。相反，如果您需要更改或更新，请启动一个新的容器集群，并应用正确的更新并拆除旧的容器。管理1,000头牛比1000只宠物要容易得多。不要误会我的意思：我们都喜欢我们的宠物，但如果您想要快速创新并为您的客户创造价值，并为您的企业带来收益，您就无法花费所有必要的时间来为每只宠物提供所有宠物它需要温柔的爱护。诸如Kubernetes，Apache Mesos以及诸如IBM Cloud Kubernetes服务之类的托管和托管容器服务等项目使您可以集成交付管道和图像注册表，从而快速，轻松地管理基础架构的所有阶段，即高效率的牛群。

另外，应该注意的是，虽然某些容器服务仍然使用虚拟机作为Docker主机，但这些仍应被视为牛。这些虚拟机在资源和​​集成管理功能方面更加强大，但它们通常被认为是牛，因为它们是由基于容器的工作负载的需求动态管理的。

微服务结构：你最好的打击Whack-A-Mole的借口

到目前为止，我已经讨论了为什么更多的容器更好以及如何大规模处理通用基础设施。现在您对容器开发和与宠物说再见的概念感到满意，您需要开始考虑开发应用程序并将其投入生产。

这让我了解了对基于微服务的应用程序开发至关重要的三个关键要素：

• 记录和监控
• 零停机持续交付
• 动态服务注册表

您想从第一天开始考虑这些功能，但不一定要立即解决。

在讨论这些功能时，您还将了解为什么集成的微服务结构（例如IBM Cloud及其相关服务）使您的微服务架构的管理变得更加容易。

记录和监控

如果您为应用程序和服务提供生产级支持，那么您的第一个问题应该始终是“出现问题时我该怎么办？”请注意，在该问题中甚至没有提示“if”。组件将失败，版本将更改，第三方服务将中断。如何保持一定的理智水平，以及为用户提供所需的正常运行时间？这是一个问题。

正如我之前所说，你希望你的容器是不可变的。出于这个原因，大多数IT组织不提供对容器实例的系统级访问 - 没有SSH，没有控制台，没有任何东西。那么你怎么知道你无法改变的黑匣子里面发生了什么？这是第二个问题。

值得庆幸的是，这个问题已经通过ELK stack-Elasticsearch，LogStash和Kibana的概念得到了解决。

这三个独立的组件提供了聚合日志，通过聚合日志搜索自由格式，以及基于日志和跨平台监控活动创建和共享仪表板的功能。这是一个很棒的功能 - 比登录到个人计算机和运行sed，grep和awk的sysadmin工具箱要好得多。您可以全面访问所有日志的中央存储库。您可以跨系统和微服务关联事件，因为您通常会看到事件和ID在您的系统中传播并遇到类似问题。

您可以通过多种方式与ELK堆栈集成，无论您是在云中运行还是在本地运行：通过托管服务，开源变体以及通常构建在平台即服务产品中的选项（如IBM Cloud Kubernetes）例如，服务。在IBM Cloud上的容器运行时内部，您可以访问功能齐全的多租户ELK堆栈，该堆栈自动从Docker基于容器的运行时接收日志，使您可以查看和搜索这些运行时事件，同时还为您提供预配置的Kibana-基于仪表板的开箱即用。如果您希望开始使用容器，这是一个关键功能，它使IBM Containers成为基于容器的微服务的卓越选择。

零停机持续交付

现在你很自在地知道当天空开始下降时该做什么（当然你希望它永远不会发生），你可以继续快速部署你所有惊人的应用程序更新。考虑到一些大型公司每周部署数十，数百或数千次应用程序，您不得不怀疑停机时间。当然，这些公司每次推出新版本时都没有应用程序中断 - 如果他们这样做了，他们就永远不会失败。

这些公司已经掌握了零停机部署。这可以被称为许多东西，通常有多种颜色，从红黑到蓝绿等等，但它们都回归到同样的原则：即使通过丰富的更新，您的应用程序始终可用，无论如何，因为计划停机造成的网站中断对您或您的用户不利。

现在使用第1部分中描述的整体结构，避免计划停机对于每个参与者而言都是危险，耗时，昂贵且耗费精力。需要大量资源的多个镜像图像是非常难以管理的，导致深夜，在一个假设的“非工作时间”窗口，当大量的出汗完成同时使新版本和旧版本下降 - 更不用说计算如果需要回滚或者在直接负责的团队控制范围之外出现问题，该如何处理旧版本。

借助微服务和基于容器的应用程序，即使没有完全删除，这些担忧也会被最小化，尤其是当今IBM Cloud上提供的一些关键服务。通过将组件分解为更小的组件，您可以在对整个系统产生最小影响的情况下部署它们，同时在特定时间保持更多组件以防止中断。较小的团队可以更有效地管理更多应用程序，因为部署的每个版本都可以自动监控维护其正常运行时间，从而降低人工注意力和计算资源的成本。

动态服务注册表

本部分的最后一个主题是动态服务注册表的概念。本主题包括您可能已经知道的服务发现或服务代理的概念。这两个概念无论如何都不尽相同，但它们足够接近这一方法。

既然您将创建数千个容器实例来支持所有应用程序中的微服务，那么应用程序中的其他组件将如何理解正在发生的事情？他们如何知道他们可以使用哪些其他微服务来进行服务呼叫？他们将如何回应对他们的服务电话？

服务发现和服务代理之间的区别取决于您是想自己进行搜索还是让其他人为您处理。作为类比，假设您需要送货服务。您是否希望从单个提供商（例如美国邮政服务（USPS））或多服务清算中心（如Staples）查询服务。

例如，如果我想运送一个包裹，我可以去USPS网站，为我要找的邮局输入几个参数，找回选项列表，选择一个，然后去那里运送我的包。这是服务发现的概念：我使用一个众所周知的可用服务端点注册表，这些服务端点在服务联机并脱机时更新。通过REST API，调用应用程序可以查询服务发现服务，以确定特定服务调用可用的服务类型和数量，直至该请求服务的特定版本。

如果我不想成为我选择运送包装的地方的人 - 我只想说，“把这个包裹拿到地址标签上的内容” - 我可以把它带到Staples。然后Staples根据我提供的所有信息为我的包装选择最具成本效益的运输选项。我正在把这个包带到一个知名的服务提供商那里，让它为我处理我的包的路由。这是服务代理的概念：您调用一个众所周知的端点，并根据预先建立的规则或元数据将该调用自动转发到提供对服务请求的实际响应的支持服务。

优先考虑服务发现优于服务代理，反之亦然，但实际上归结为偏好或实施经验/要求。一些开源服务发现产品，如etcd和Consul，提供分布式服务注册表，您可以使用它们注册，标记和检测所有可用的服务实例。甚至还有像Registrator这样的很酷的项目，只要创建Docker容器，它就会自动将您的服务注册到其中一个端点。

一些比较流行的服务代理项目支持以下关键参数：从长远来看，服务代理方法需要更少的网络跃点才能获得最终的支持服务。 Netflix Hystrix项目是最大和最受欢迎的服务代理项目之一。 Hystrix是一个基于Java™技术的库，它超越了简单的服务代理，但在服务代理库中提供了许多服务质量改进。

显然，这两种模式对于自动管理服务实例并使其成为可用微服务基础架构的一部分非常重要。 IBM Cloud将很快拥有自己的多租户服务发现服务（如果您在阅读本文时尚未拥有它） - 无需管理服务发现服务，这可能是少数几项。想象一下，自动注册所有容器实例，无论是手动启动它们，推送它们通过IBM Cloud的Delivery Pipeline，还是与Jenkins等内部部署管道集成。

结论

您已经在这里看到容器如何加速推动云原生应用程序开发。与以往相比，更小，更快的应用程序组件可以更快，更轻松地交付，具有比以往更多的内置管理功能。在托管服务（例如IBM Cloud Kubernetes Service）上部署容器以及所有支持的微服务功能（包括日志记录和监视，主动部署和服务发现），可以轻松地将下一步从现有的整体块中移除到云。

我们正朝着更智能的模块化系统发展，这些系统从头到尾更加自动化，集成度更高。这些将按照自己的进度发展，自我意识到基础设施中可用的内容，让它知道什么不是，并在需要改变时告知它。所有这些功能和更多功能将在本系列的一些即将发布的系列文章中介绍。

原文 ：https://developer.ibm.com/tutorials/cl-ibm-cloud-microservices-in-action-part-2-trs/

            http://pub.intelligentx.net/