数人云联合ServiceComb社区，并由ServiceMesh社区支持，开启meetup系列活动 Building Microservice 第2期 北京站 ：微服务，从架构到发布，已经开始报名啦，点击阅读原文快来报名~
作者：Emil Kirschner
翻译：张晔
原文：Proxy Based Service Mesh
地址：
基于代理的服务网格是一种新兴技术，通过使用专用代理在容器编排级别提供横切式的基础设施功能，如服务发现、负载平衡、断路器、度量监控、分布式跟踪等，从而简化分布式微服务系统的构建。 通过消除服务中的样板代码，可自由地使用任何技术和任何编程语言。
如果想建立一个分布式的微服务系统，通常必须寻找一组提供服务发现、负载平衡和断路器的组件或框架，然后必须专门制定服务来适配这些组件或框架。 通常这些组件或框架或多或少与特定语言或框架相关联。
例如 Netflix OSS 与 Spring Cloud Netflix 一起使用则非常容易。 只需在 Spring Boot 应用中添加一些注解，即可启动 Zuul 代理和 Eureka 服务器。 通过添加另一组不同的注解，则可以将微服务标记为 Eureka 客户端，且在注册后即可使用。 如果您需要调用下游服务则使用 Feign。 并且可以使用 Hystrix 来保护下游调用。
然而，只要离开了 Java / Spring Boot 领域，事情就会变得复杂起来。
如果需要使用 C ++ 或 Go 来编写服务，则需要自行构建与 Netflix OS S的集成。 这会产生更多的样板代码，每次使用一种新的语言到技术栈时都必须这样做一遍。
服务网格
容器和容器编排技术的兴起使得新的基础架构成为了可能，使我们能够摆脱服务发现/负载平衡/断路器框架的束缚。 这个新的基础设施就是“服务网格” —— 当说它新的时候，我的意思是在撰写本文时（2017年11月），它甚至还没有维基百科页面。
那服务网格是什么呢？ 服务网格是一个基础架构层 ，主要是一个代理集合，每个逻辑服务都有一个代理 ， 与 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 的优秀人士提出了 “Chaos Monkey” 和整套相关工具，但这些工具不易部署和运维。
通过服务网格，通过代理配置可以实现相同的功能。 可以为每种服务引入两种随机扰动：
延迟一定比例的请求以观察在分布式系统上增加服务延迟的影响，确保系统作为一个整体能够处理它。
传入请求按百分比失败与随机错误代码，并确保系统可以存活。
在典型工作负载期间将这些扰动转移到不同程度时测量系统吞吐量和终端用户感知延迟，以确定哪些下游服务非常关键，哪些不是。
限速，配额，监控和追踪
服务网格代理处理所有到达服务的流量，它知道什么是正确的，哪里出了问题，它可以强制使用策略，如配额和限速。
代理能注意到每个失败和 SLA 违规。 这使它成为监控服务性能的理想场所。
因为从前端微服务到最后一个下游服务的每个调用都通过代理，所以这也是实现跟踪的理想场所。
一个好的服务网格可以自动安装诸如 Prometheus 和 Zipkin 等监控和跟踪基础设施部分，以及 Grafana 等可视化工具。
当前服务网格现状
当今在服务网格领域有两个玩家：Linkerd 和 Istio。
Linkerd 首当其冲，它是一个更成熟，经过生产验证的解决方案。 它最为人民所知的是被一家全新的在线英国银行 Monzo 用于生产环境中。
另一选择 Istio，则是新兴的挑战者。 它尚未达到生产质量，但速度非常快，并从一开始就得到 Google 云平台的支持。 它建立在 Lyft 开发的 Envoy 代理之上。
推荐阅读实用指南 | 基于Kubernetes, GRPC 和 Linkerd 构建可扩展微服务万字长文 | 如何构建安全的微服务应用，先要解决这两个问题实例 | 当Istio遇见Jaeger，如何解决端到端分布式追踪问题？微服务架构之思维三部曲：What、Why、How倍道而进：Conduit 0.3 正式从 experimental 升级到 alpha，实现生产指日可待
ServiceMesh中文社区：
ServiceMesh中文社区（servicemesh.cn）已上线，Istio、Conduit官方文档翻译版已在社区发布，欢迎大家登录浏览。社区翻译小组志愿者招募中，有兴趣的私信小数即可~
ServiceMesh交流群：
添加xiaoshu062，备注：服务网格，即可加入Service Mesh交流群。