为什么 Service Meshes，容器编排工具是云原生部署的必然选择？

【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。。Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，而不需要对服务的代码做任何改动。

独立，短暂的微服务过程带来了一些重大好处，但是保持跟踪每一个单独的微服务是一个挑战，特别是尝试去弄清楚当一个微服务下线后，剩下的服务会受到什么样的影响。最终的结果是，如果你正在一个微服务架构下运营或开发，那么你的一部分时间将会被消耗在搞清楚你的服务到底是什么。

随着微服务的采用，大型系统中存在大量服务，因此出现问题不可避免。诸如，安全，负载均衡，监控和限速这些问题，过去不得不同意解决，而现在，不得不单独为每个服务一一解决。

幸好工程师乐于这样的挑战。而且每当微服务产生新的问题时，他们都会通过新兴的微服务工具和技术来定位这些问题。也许微服务的出现只是工程师确保饭碗的智能游戏。

如今的cloud native宠儿，Kubernetes，缓解了微服务带来的许多挑战。自动调度，横向扩展和服务发现，解决了大多在微服务中构建和部署服务将遇到的问题。

Kubernetes 留下了一些尚未解决的容器化应用环境的问题。这就是 service mesh 的介入点。让我们看一下 Kubernetes 提供了什么，和 Istio 如何增强 Kubernetes 解决微服务运行环境的问题。

Kubernetes 解决了构建和部署的挑战

容器编排工具，诸如 Kubernetes，解决了许多来自于容器化应用的构建和部署的挑战。

Kubernetes 支持微服务架构，使开发者能够抽象出一组 pods 的功能，并且通过明确的 API 来曝露服务给其他开发者。Kubernetes支持四层负载均衡，但是不能解决更高层的问题，例如，七层指标，流量分流，限速和断路。

Service Mesh 解决了运行时管理流量的挑战

Service mesh 有助于解决最终用户使用应用程序时出现的许多挑战。能够监控哪些服务相互通信，他们的通信是否安全和是否能够控制你的集群中服务和服务间的通信，这是确保你的应用安全和弹性运行的关键。

通过在整个过程中生成统一的度量标准，Istio 可以在微服务架构中提供一致的视图。它消除了协调各种运行时代理发出的不同类型的度量标准的需要，或添加任意代理来收集旧的未检测应用程序的度量标准。它在您的多语言服务和集群中增加了一定程度的可观察性，这在任何其他工具的细粒度水平上是无法实现的。

Istio还增加了更深层次的安全性。Kubernetes 仅提供基本的秘密分发和控制平面证书管理，但是 Istio 提供 mTLS 功能，因此您可以对线路流量进行加密，以确保您的服务间通信是安全的。

完美的匹配

将 Kubernetes 与 Istio 配对可以为您提供两全其美的优势，而且由于Istio是在 Kubernetes 上运行的，因此两者可以无缝协作。您可以使用 Kubernetes 来管理所有构建和部署需求，Istio 负责处理重要的运行时问题。

Kubernetes 已经成熟到大多数企业都将其用于集装箱编排。目前，有74家CNCF认证的服务提供商，这证明了市场规模庞大且不断增长。我认为 Istio 是 Kubernetes 的延伸，为了解决更多挑战。

Istio 已经快速成熟，并开始在企业中更多地采用。可能在2019年，我们将看到 Istio 成为企业的服务网格标准，就像 Kubernetes 作为集装箱编排的标准一样。

原文链接： Why Service Meshes, Orchestrators Are Do or Die for Cloud Native Deployments （翻译：Sam）