容器扩展的未来是服务网格的八个原因

微服务对于开发速度非常有帮助，但是这些架构的复杂性在于微服务所依赖的服务到服务通信。

目前，至少有三种不同的架构选项可用于扩展容器化微服务。 每个都基于 - 所有规模都是基于 - 基于代理的负载均衡器。 每种情况都有其各自的挑战。 其中一些问题源于一个简单的事实，即容器环境内部的规模通常依赖于 IP 表及其与传统网络层（即 IP 和 TCP）之上的任何事物的有限流畅性。

所有这些代理都提供相同的核心功能：扩展分布在整个容器环境中的服务。 令人疯狂的是，服务是短暂的构造。 它们实际上并不存在 – 除了定义它们的资源（配置）文件。 基于 IP 表的扩展解决方案的问题在于，这些服务是第 7 层（HTTP）构造，通常作为单个 API 调用而不是整个application的“后端”。

我们知道，applications从客户端来看可能是一个单一的、整体的结构。 实际上，它们由许多不同的（分布式）微服务组成。 其中一些服务纯粹是内部的，旨在供其他服务使用。 这意味着在容器化环境内存在大量的服务到服务的通信。

在这些环境中您需要 L7（HTTP）路由，因为一切都是通过 HTTP/HTTP2 的 API。 您还需要一致的安全立场、身份验证和策略实施。 采用基于 IP 表的方法不会发生上述任何情况。

通常情况下，开源会来拯救我们。 为了应对这些挑战，已经出现了几种开源服务网格。 与许多开源项目一样，这些服务网格（如Istio ）正在通过Aspen Mesh等项目进行扩展，提供企业级解决方案的功能（和支持）。

这些扩展的努力主要集中于解决组织在容器中部署微服务时遇到的八个挑战。

以下是八个挑战以及服务网格如何克服它们：

1. 构建——这是服务网格面临的挑战之一，除了将策略与 CI/CD 工具链集成并确保配置的声明性模型以便将服务网格视为代码基础设施之外。
2. 测试和集成——服务网格可以通过确保开发、测试、生产等之间的策略一致性来提供帮助。 一些组织正在寻求彻底消除分阶段部署。 这种方法在过去效果很好，但它是导致部署过程延迟的障碍之一。  这些人正在寻找一种将服务直接部署到生产中并采用流量控制和回滚机制来应对故障的方法。  
3. 版本控制——服务网格可以充当基本的 API 网关，根据 API 版本等变量路由流量，甚至可以翻译版本以提供帮助，度过 API 版本过渡期。 客户端升级（尤其是对于消费者领域的应用程序）并不总是可以强制的，这意味着会收到多个版本的请求。 服务网格可以将对旧 API 版本的请求转换为最新版本，以帮助减少维护同一 API 的多个版本的成本和负担。
4. 部署——凭借其流畅使用 HTTP 的能力，服务网格是实现蓝/绿部署、金丝雀测试和流量控制的理想场所。
5. 日志记录——分布式日志记录始终是一个问题，在实例生存期变化很大的环境中，这个问题就更加严重了。 服务网格提供了一个通用的、集中的位置来实现日志记录以及执行请求跟踪等功能的能力。
6. 监控——规模的核心在于监控。 虽然applications可以实现某些功能（重试、断路等）来应对服务不可避免的故障，但这给application带来了不应该承担的负担。 服务网格承担了服务到服务通信的负担并提供了监控场所。 目标是关注生产中的 MTTD 和 MTTR，因为生产运行很困难并且故障是不可避免的。
7. 调试——系统越复杂，调试就越困难。 服务网格可以帮助进行根本原因分析，使用分析和遥测提供统计数据和故障前通知，并隔离容器而不是杀死它们，以便可以彻底检查它们。 当失败是由于缓慢的内存泄漏导致的情况时这尤其有用。
8. 网络——网络对于容器来说仍然至关重要，或许比在较不复杂的环境中更为重要。 从网络中抽象出服务的想法意味着有许多活动部件你不想在每个服务中实现： 服务发现、SSL 和证书管理、断路器、重试、健康监测等。 微服务的目标是“本地编码，小规模编码”。 引入包含网络相关功能的需求会导致微服务膨胀并带来额外的架构和技术债务。 服务网格承担这些功能并提供所需的规模和安全性，而不会阻碍开发。

服务网格是一个令人兴奋的演变，它将云和容器的现代原理与坚实的规模基础结合在一起。 随着 2018 年容器的采用率不断提高以及对企业级规模和支持的需求不断增加，预计服务网格将获得发展动力。