在 Kubernetes 中部署 Elasticsearch

在对应用程序进行重构和更新的过程中，往往会出现一些挑战。更新应用程序的频率越高，复杂性就越是会增加。让应用程序在容器平台上运行，并且它们之间可以互相通信和连接，是通向模块化的、灵活的微服务架构的必经之路。但是微服务的这种灵活性也让其变得更加复杂。这时就轮到 Service Mesh 发挥作用了！

Service Mesh 向企业提供了他们所需要的中心化控制面板，同时依然能够使用灵活的、基于云的应用程序开发方式。我们可以把 Service Mesh 看成是用于微服务 API 的专门的第 7 层网格，它提供身份验证、授权、安全和性能服务来优化服务之间的“east/west”流量。更重要的是，它能为你提供应用到这些策略的中心点，而不需要直接将所有这些编码到应用程序的业务逻辑中。

简单的 Service Mesh 类比

Service Mesh 就像是城市的水管网络。你的团队控制着这些管道，根据需要连接它们并设置它们之间所有的流控制。无论是何种类型或用途，又或是 Service Mesh 所支持的应用程序的需求在不断变化，数据都可以通过你的系统进行传递。

这种流量控制可以在中心位置进行，也正是在中心位置构建规则，来管理那些相互连接的数据流。这就像是在天上的巨大控制室一样，你可以在农作物需要额外资源时，给加利福尼亚州的土地浇水，又或是迈阿密那边湿的太透了，你可以排干它们。最重要的一点是，这些操作都是可以自动执行并且动态调整的。

Service Mesh 增强了可靠性和可视化能力

Service Mesh 提供从网络或服务故障处自动恢复过来的智能流量路由功能，这样就可以追踪到整个堆栈的问题，甚至能追踪到服务间的中断。

如果服务器没有响应，你的服务网格将会把它从单个服务、或者是活跃的、负载均衡的服务池中剔除掉，转移到另一个池中，该池经常会检查是否可运行。当该服务器在合理的时间范围内开始响应时，它又会被自动 push 回活跃的负载均衡池中。

通过提供服务层系统各个方面的可视化，Service Mesh 还可以用来 debug 和优化系统。这样微服务中的脏水问题（murky water）就解决了。随着时间推移，系统可以进行调整来扩展功能，满足性能和稳定性的需求。

Service Mesh 保护服务间通信

当你的团队推出应用程序的新版本，或是要将应用程序托管的集群迁移到新的数据中心时，安全团队通常需要重新颁发证书并授权给系统中新的服务器。这会花费大量的时间和精力，是推动生产改进的阻碍。

有了服务网格，将服务间通信的安全性交给网格处理，这些关注点从应用程序本身抽象了出来，由服务网格处理所有这些限制，比如哪些服务可以相互通信、哪些系统可以访问哪些服务，以及哪些用户可以访问哪些服务。因此， 升级网格中的应用程序不需要重新分配安全资源 。

这样一来，还可以让围绕网络和服务间通信的安全问题能从任何内部开发的业务逻辑中独立出来。如果网络组建出现安全漏洞，服务网格会去处理围绕安全更新的更改，而不是重新架构每个应用程序。这就消除了在进行安全更改和更新相关工作时出现的大量停机时间。

研究大型微服务环境下的服务网格

不过服务网格有一个（巨大的）潜在的缺点。它添加了额外的容器，事实上， 它让容器规模加倍了 。大多数服务网格的实现使用了 sidecar 代理，将一个代理实例和每个容器绑定的微服务耦合在一起。这样一来，它所带来的好处大于运营成本，这也意味着服务网格对于小型环境来说通常过于庞大了。

但是，如果你正在管理数十个甚至数百个独立的微服务，不妨考虑服务网格。有了服务网格，你的团队可以更好的跟踪问题，确保服务的可用性，维护路由表的正确分布。对这些大型环境，无论是在公共云、在你的企业数据中心、还是在混合云的实现上，它们是云应用程序难题的最后一块拼图，也是将你的整个产业联系在一起的关键部分。