基于代理的服务网格
本文是我给service mesh社区翻译的一篇文章，原文地址
基于代理的服务网格是一种新兴技术，通过使用专用代理在容器编排级别提供横切式的基础设施功能，如服务发现，负载平衡，断路器，度量监控，分布式跟踪等，从而简化分布式微服务系统的构建。 通过消除服务中的样板代码，可自由地使用任何技术和任何编程语言。
如果想建立一个分布式的微服务系统，通常必须寻找一组提供服务发现，负载平衡和断路器的组件或框架，然后必须专门制定服务来适配这些组件或框架。 通常这些组件或框架或多或少与特定语言或框架相关联。
例如Netflix OSS与Spring Cloud Netflix一起使用则非常容易。 只需在Spring Boot应用中添加一些注解，即可启动Zuul代理和Eureka服务器。 通过添加另一组不同的注解，则可以将微服务标记为Eureka客户端，且在注册后即可使用。 如果您需要调用下游服务则使用Feign。 并且可以使用Hystrix来保护下游调用。
然而，只要离开了Java / Spring Boot领域，事情就会变得复杂起来。
如果需要使用C ++或Go来编写服务，则需要自行构建与Netflix OSS的集成。 这会产生更多的样板代码，每次使用一种新的语言到技术栈时都必须这样做一遍。
服务网格
容器和容器编排技术的兴起使得新的基础架构成为了可能，使我们能够摆脱服务发现/负载平衡/断路器框架的束缚。 这个新的基础设施就是“服务网格” - 当说它新的时候，我的意思是在撰写本文时它甚至还没有维基百科页面。
那服务网格是什么呢？ 服务网格是一个基础架构层 - 主要是一个代理集合，每个逻辑服务都有一个代理 - 与Docker Swarm或Kubernetes等容器编排解决方案集成，并提供服务发现，负载平衡，断路器，故障注入，安全，监控，跟踪以及更多以非侵入性的方式提供的开箱即用功能。
由于服务网格在容器级别运行，它并不关心使用什么技术或编程语言来编写微服务。 你可以将微服务使用Java，C ++，Rust，Go，NodeJS来编写简单HTTP服务器，这些都已不再重要。
可以将服务网格有效地视为分布式容器化应用基础架构级的面向切面编程。 服务网格中的代理就像AOP中的一个切面。 它们包裹了一个容器化的微服务，就像AspectJ切面可以包裹和测试java方法一样，通过分离横切关注点来简化系统。
乾坤内境
以非侵入方式免费获得所有这些是很酷的，但它是如何工作的？ 让我们逐一展开：
服务发现和负载均衡
服务网格将hook到编排层 - Docker Swarm或Kubernetes - 并在每次启动和停止容器时收到通知。
当启动第一个带有“service1”实例的容器时，服务网格将创建一个代理并应用iptables配置，该配置将捕获所有到“service1”的流量并对其进行管理。 随着更多的“service1”实例出现，服务网格将被通知，并将新实例添加到代理的配置中。
当流量流入时，代理将提供：
- 通过配置软件定义网络来解析主机名“service1”到自身的服务发现
- 通过将传入请求平均分配给可用服务实例来实现负载平衡
这两个功能有效地取代了Netflix OSS技术栈中的Eureka和Ribbon。
断路器
断路是一种快速失败机制。 如果底层服务实例变慢并且在配置的时间内没有对调用响应，则断路器将使请求失败，并向客户端返回适当的错误码。 客户端然后可以重试并最终到达更具响应力的实例。 这提供了更好的用户体验。
通常情况下，响应慢的实例将被标记为非活动状态，并在接收任何流量之前一段时间后才能恢复。
同样在服务网格中，位于服务的所有实例前的代理充当了断路器。 这有效地取代了Netflix OSS技术栈中的Hystrix断路器。
故障注入
分布式云原生应用必须设计为容错的。 应用在云中运行的硬件可能随时出现故障，可以取出机器进行定期维护，任何服务的任何实例可能随时无响应。 当这样的事件下游服务的实例故障时，应用必须优雅地处理这种情况，且不降低用户体验，或者最低限度地降低。
但由于这种情况在云环境中随机发生，因此很难在受控环境中再现并研究其对系统的影响。 这将是一件非常有用的事情。
为了解决这个问题，Netflix的优秀人士提出了“混乱猴子”和整套相关工具，但这些工具不易部署和运维。
通过服务网格，通过代理配置可以实现相同的功能。 可以为每种服务引入两种随机扰动：
- 延迟一定比例的请求以观察在分布式系统上增加服务延迟的影响，确保系统作为一个整体能够处理它。
- 传入请求按百分比失败与随机错误代码，并确保系统可以存活。
在典型工作负载期间将这些扰动转移到不同程度时测量系统吞吐量和终端用户感知延迟，以确定哪些下游服务非常关键，哪些不是。
限速，配额，监控和追踪
服务网格代理处理所有到达服务的流量，它知道什么是正确的，哪里出了问题，它可以强制使用策略，如配额和限速。
代理能注意到每个失败和SLA违规。 这使它成为监控服务性能的理想场所。
因为从前端微服务到最后一个下游服务的每个调用都通过代理，所以这也是实现跟踪的理想场所。
一个好的服务网格可以自动安装诸如Prometheus和Zipkin等监控和跟踪基础设施部分，以及Grafana等可视化工具。
当前服务网格现状
当今在服务网格领域有两个玩家：Linkerd和Istio。
Linkerd首当其冲，它是一个更成熟，经过生产验证的解决方案。 它最为人民所知的是被一家全新的在线英国银行Monzo用于生产环境中。
另一选择Istio，则是新兴的挑战者。 它尚未达到生产质量，但速度非常快，并从一开始就得到Google云平台的支持。 它建立在Lyft开发的Envoy代理之上。
- 版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！
