一种微服务结构：您拒绝玩打地鼠游戏的最佳借口目前为止，我谈论了为什么容器越多越好，以及如何大规模地处理通用的基础架构。在熟悉开发容器的概念并告别宠物后，需要开始考虑开发您的应用程序并将它们部署到生产中。
这涉及到 3 个
您希望从一开始就考虑所有这些功能，但没有必要立即解决它们。
在我讨论这些功能的过程中，您还会看到为什么一种集成的微服务结构（比如 Bluemix 和它的相关服务）使得微服务架构的管理变得更容易。
记录和监视如果为应用程序和服务提供生产级支持，您的第一个问题始终应该是 “我在遇到故障时该怎么办？”请注意，这个问题中甚至没有暗示 “如果”。组件将会出错，版本将会改变，第三方服务将会中断。您如何保持清醒的头脑，为您的用户提供他想要的正常运行时间？这是第一个问题。
正如我之前说过的，您希望您的容器不可变。出于这个原因，大多数 IT 组织都没有提供系统级的容器实例访问权限 — 没有 SSH，没有控制台，什么都没有。那么您如何能够知道一个无法更改的黑盒中发生了什么？这是第二个问题。
幸运的是，这个问题已被 ELK 堆栈 的概念解决— 、 和 。
这 3 个不同的组件提供了聚合日志，在聚合的日志中自由搜索，以及基于日志和所监视的活动在整个平台上创建和共享仪表板的功能。这是一种非常好的功能 — 比登录到各个计算机来运行一个包含 sed、grep 和 awk 的系统管理工具箱好得多。您拥有访问某个包含所有日志的中央存储库的完整权限。您可以跨系统和微服务来关联事件，因为您通常会看到事件和 ID 在您的系统中流动并遇到类似的问题。
您可以通过许多方式来集成 ELK 堆栈，无论是在云中还是在内部运行：通过托管服务、开源变体，以及常常内置于平台即服务产品中的选项（比如 ）。在 Bluemix 上的容器运行时的内部，您能够访问一个功能健全的、多租户的 ELK 堆栈，该堆栈自动从基于 Eocker 容器的运行时接收日志，为您提供了这些运行时事件的可视化和可搜索性，同时还为您提供了一个预先配置的、开箱即用的、基于 Kibana 的仪表板。如果您正在考虑开始使用容器，这是一项使 IBM Containers 成为基于容器的微服务的优秀选择的关键能力。
零宕机时间持续交付确信您知道在出现故障时（当然您希望这绝不会发生）该怎么做之后，即可快速地部署您的所有引入注目的应用程序更新。想想那些一周部署应用程序数十、数百或数千次的大型公司，您必须了解宕机时间。当然，这些公司不会每次推送新版本时都会发生应用程序中断 — 如果是这样，他们绝不会发展壮大。
这些公司已逐渐掌握零宕机时间部署。零宕机时间部署可能具有许多名称，而且常常具有包含颜色的不同叫法，从红黑到蓝绿等，但它们都遵循相同的原则：您的应用程序始终可用，无论通过何种方式，甚至通过冗余的更新，因为计划性宕机时间导致的网站中断对您或您的用户都没有好处。
 IBM Cloud Services：Active Deploy通过一个新的 IBM Cloud 服务 Active Deploy 的演示，进一步了解零宕机时间部署。IBM 研究员 Jason McGee 与 IBM 杰出工程师 Daniel Berg 谈论了 Cloud Foundation Services 和 DevOps，讨论了在下一次滚动部署或升级时实现零宕机时间需要执行的操作的详细细节。Active Deploy 现在可在 Bluemix 上获得。
现在使用 中描述的单体系统，避免计划性宕机时间很危险、非常耗时、非常昂贵，而且会让每个参与者筋疲力尽。需要庞大的资源集的多个镜像映像的情况非常难以管理，而且会导致员工在本应 “休息的时间” 挥汗如雨，忙于上线新版本和关闭旧版本 — 更别提确定如果需要回滚或某个不在直接负责团队控制范围内的东西出错，需要如何处理旧版本。
借助微服务和基于容器的应用程序，这些担忧被最大限度减少（如果未完全消除），尤其是借助 Bluemix 上如今提供的一些关键服务。通过将您的组件分解为小得多的部分，您可以在部署它们时将对整体系统的影响降到最低，同时在某些时段保持更多部分正常运行来预防中断。Bluemix 上提供的新服务 提供了此功能，而且已预先集成到交付管道中。较小的团队可以更高效地管理更多的应用程序，因为每个部署的版本都拥有自动监督功能来保持其正常运行，所以对人类关注和计算资源的需求更少。
动态服务注册表本期的最后一个主题是动态服务注册表的概念。本主题包含以下概念：您可能已知道的称为服务发现 或服务代理。这两个概念绝不相同，但它们非常接近，以至于可包含在这类方法中。
创建数千个为您的所有应用程序中的微服务提供支持的容器实例后，您的应用程序中的其他组件如何了解工作的进展？它们如何知道它们可对其他哪些微服务执行服务调用？它们如何响应对它们的服务调用？
服务发现与服务代理之间的区别可归纳为，您希望自行执行搜索还是让其他人为您处理。打个比方，假设您需要一个运输服务。您希望寻找来自单个提供商（例如 US Postal Service (USPS)）还是来自一个多服务集散中心（比如 Staples）的服务。
 例如，如果我想寄送一个包裹，我可以访问 USPS 网站，输入两个针对我寻找的快递公司种类的参数，获得一个选项列表，挑选一个，然后进入其中寄送我的包裹。这是服务发现的概念：我使用了一个著名的可用服务端点注册表，在服务上线和下线时它都会更新。通过 REST API，调用应用程序可以查询服务发现服务来确定哪种和多少类型的服务可用于一次特定的服务调用，下钻到请求的服务的一个特定版本。
 如果我不想选择我想将包裹寄往何处 — 我只想 “将这个包裹发往地址标签上显示的地址” — 我可将它交给 Staples。Staples 然后基于我提供的所有信息，为我的包裹选择最富有成本效益的运输选项。我将包裹交给了一个著名的服务提供商，让它为我处理包裹的运输路线。这是服务代理的概念：您调用一个已知的端点，该调用会基于预先建立的规则或元数据而自动转发到对服务请求提供实际响应的支持服务。
 对于更喜欢服务发现还是服务代理，有一些不错的观点，但归根结底取决于偏好或实现体验/需求。一些开源服务发现产品（比如 和 ）提供了分布式服务注册表，您可以使用它们来注册、标记和检测您的所有可用的服务实例。甚至还有一些不错的项目（比如 ）会在创建 Docker 容器后，自动将您的服务向其中一个端点注册。
一些更流行的服务代理项目支持一个重要的观点，那就是从长远来看，服务代理方法找到最终的支持服务所需要的网络跃点更少。一个最大型和最流行的服务代理项目是 Netflix 项目。Hystrix 是一个基于 Java™ 技术的库，它超越了简单的服务代理，而在一个服务代理库中提供了大量服务质量改进。
显然，这两种模式对自动管理服务实例和将它们融入到可用的微服务基础架构中都很重要。Bluemix 很快将拥有自己的多租户服务发现产品（如果在您阅读本文时还没有该产品） — 消除您管理服务发现服务（这可能是一件棘手的事）的需求。想象自动注册您的所有容器实例，无论您是手动建立它们，通过 Bluemix Delivery Pipeline 推送它们，还是与一个内部部署的管道（比如 或 ）集成。 |
