Envoy

作者 | 王夕宁 阿里巴巴高级技术专家 参与阿里巴巴云原生公众号文末留言互动，有机会获得赠书福利！ 本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书，文章介绍将集群外部的客户端连接到集群内运行的服务，以及如何从集群内的服务访问集群外部的任何服务，即通常所说的南北向流量管理。其中介绍了 Istio 在南北向流量方面的路由控制能力，引出 Istio 网关的概念及其工作原理。 本文文末汇集并整理了近期 Istio 的相关问题并特邀王夕宁老师进行解答，希望能够对大家有所帮助~ Istio 网关 网络社区中有一个术语 Ingress，是指入口请求到集群内服务的流量管理。Ingress 指的是源自本地网络之外的流量，指向本地集群网络中的端点。此流量首先路由到公开的入口点，以便通过执行一些本地网络的规则和策略来确认哪些流量被允许进入。如果流量未通过这些入口点，则无法与集群内的任何服务连接。如果入口点允许流量进入，则将其代理到本地网络中的合适节点。Istio 对入口流量的管理是由 Istio 网关进行的。 Istio 网关的工作原理 传统上，Kubernetes 使用 Ingress 控制器来处理从外部进入集群的流量。使用 Istio 时，情况不再如此。Istio 网关用新的 Gateway 资源和 VirtualServices 资源来控制入口流量

Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构组研发工程师陈鹏，线上主题分享《多点生活在 Service Mesh 上的实践 -- Istio + Mosn 在 Dubbo 场景下的探索之路》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。 前言 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。 今天主要给大家分享一下 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。 首先我们从三个方面入手： 为什么需要 Service Mesh 改造； 探索 Istio 技术点； Dubbo 场景下的改造； 为什么需要 Service Mesh 改造 说到为什么需要改造，应该先说一下 Service Mesh 和传统微服务架构的一些特点。 微服务 微服务一般有这些模块： 安全； 配置中心； 调用链监控； 网关；

系列文章: 总目录索引： 九析带你轻松完爆 istio 服务网格系列教程 目录 1 前言 2 邀约 3 Envoy 线程模型 4 监听器连接负载均衡 1 前言 如果你对博客有任何疑问，请告诉我。 2 邀约 你可以从 b 站搜索 “九析”，获取免费的、更生动的视频资料： 3 Envoy 线程模型 Envoy 是单进程内包含多线程的架构设计。单进程内部包含两种线程-主线程（master thread）和工作线程（worker thread）。主线程的作用是控制、协调任务；工作线程的作用是执行监听、过滤和转发。如下图所示： Envoy 进程启动时会开启监听端口（listener），一旦监听器接受了客户端的连接，此连接的生命周期就会绑定到 Envoy 内的一个工作线程上。由此可知，Envoy 被设计成多个单线程并行，100% 无阻塞的模式。对于大多数工作负载，我们建议将工作线程的数量配置为等于计算机上硬件线程的数量。查看 Linux 操作系统最大进程数命令为： sysctl kernel.pid_max 或 cat /proc/sys/kernel/pid_max 4 监听器连接负载均衡 默认情况下，Envoy 工作线程之间相互独立且并无联系，这意味着所有工作线程都独立尝试在监听器上接受连接，并依靠内核在线程之间做负载均衡。对于大多数工作负载，内核对这些连接的负载均衡处理会非常出色。但是

Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务监控的区别。 本文根据5月14日晚，G7 微服务架构师叶志远的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。 前言 谈到 Service Mesh，人们总是想起微服务和服务治理，从 Dubbo 到 Spring Cloud (2016开始进入国内研发的视野，2017年繁荣)再到 Service Mesh (2018年开始被大家所熟悉)，正所谓长江后浪推前浪，作为后浪，Service Mesh 别无选择，而 Spring Cloud 对 Service Mesh 满怀羡慕，微服务架构的出现与繁荣，是互联网时代架构形式的巨大突破。Service Mesh 具有一定的学习成本，实际上在国内的落地案例不多，大多是云商与头部企业

Sentinel 是阿里巴巴开源的，面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统自适应保护等多个维度来帮助开发者保障微服务的稳定性。Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀、冷启动、消息削峰填谷、集群流量控制、实时熔断下游不可用服务等，是保障微服务高可用的利器，原生支持 Java/Go/C++ 等多种语言，并且提供 Istio/Envoy/SOFA MOSN 全局流控支持来为 Service Mesh 提供高可用防护的能力。 近期， Sentinel Go 0.4.0 正式发布，带来了 热点参数流控特性 ，可以自动识别统计传入参数中的“热点”参数值并分别进行流控，对于防刷、热点商品访问频次控制等场景非常有用，是高可用流量防护中重要的一环。下面我们来了解一下热点参数流控的场景和原理。 热点流量防护介绍 流量是随机的，不可预测的。为了防止被大流量打垮，我们通常会对核心接口配置限流规则，但有的场景下配置普通的流控规则是不够的。我们来看这样一种场景——大促峰值的时候，总是会有不少“热点”商品，这些热点商品的瞬时访问量非常高。一般情况下，我们可以事先预测一波热点商品，并对这些商品信息进行缓存“预热”，以便在出现大量访问时可以快速返回而不会都打到 DB 上。但每次大促都会涌现出一些“黑马”商品，这些“黑马

最近在了解service mesh相关，从而了解到了Istio。简述一下这两个概念，接下来有时间会继续整理相关技术文档分享。 首先，什么是Service Mesh？ Service Mesh，服务网格，在现在微服务流行的趋势下， 服务越来越多，用 术语服务网格来描述组成此类应用程序的微服务网络及其之间的交互的情况再形象不过。随着服务网格的大小和复杂性的增长，它变得越来越难以理解和管理。它的要求可以包括发现，负载平衡，故障恢复，指标和监视。服务网格通常还具有更复杂的操作要求，例如A / B测试，速率限制，访问控制和端到端身份验证等。 什么是Istio？ Istio， 一个开源 服务网格 平台，它可以控制 微服务 之间数据的共享方式。其附带的 API 可以将 Istio 集成 到任何日志记录平台、遥测或策略系统中。在设计上，Istio 可以在多种环境中运行：企业本地、云托管、 Kubernetes 容器 ，或 虚拟机 上运行的服务等。 Istio 的架构分为数据平面和控制平面两部分。在数据平面中，通过在环境中部署 sidecar 代理，即可为服务添加 Istio 支持。该 sidecar 代理与微服务并存，用于将请求路由给其他代理，或从其他代理那路由请求。这些代理共同构成了一个网格网络，可拦截微服务之间的网络通信。控制平面则负责管理和配置代理来路由流量。此外，控制平面还可配置组件

Istio 组件常用端口 端口 协议 使用者 描述 8060 HTTP Citadel GRPC 服务器 8080 HTTP Citadel agent SDS service 监控 9090 HTTP Prometheus Prometheus 9091 HTTP Mixer 策略/遥测 9876 HTTP Citadel, Citadel agent ControlZ 用户界面 9901 GRPC Galley 网格配置协议 15000 TCP Envoy Envoy 管理端口 (commands/diagnostics) 15001 TCP Envoy Envoy 传出 15006 TCP Envoy Envoy 传入 15004 HTTP Mixer, Pilot 策略/遥测 - mTLS 15010 HTTP Pilot Pilot service - XDS pilot - 发现 15011 TCP Pilot Pilot service - mTLS - Proxy - 发现 15014 HTTP Citadel, Citadel agent, Galley, Mixer, Pilot, Sidecar Injector 控制平面监控 15020 HTTP Ingress Gateway Pilot 健康检查 15029 HTTP Kiali Kiali 用户界面

Apache RocketMQ 的 Service Mesh 开源之旅 作者 | 凌楚 阿里巴巴开发工程师 导读：自 19 年底开始，支持 Apache RocketMQ 的 Network Filter 历时 4 个月的 Code Review（Pull Request），于本月正式合入 CNCF Envoy 官方社区（RocketMQ Proxy Filter 官方文档），这使得 RocketMQ 成为继 Dubbo 之后，国内第二个成功进入 Service Mesh 官方社区的中间件产品。 Service Mesh 下的消息收发 主要流程如下图： 图 1 简述一下 Service Mesh 下 RocketMQ 消息的发送与消费过程： Pilot 获取到 Topic 的路由信息并通过 xDS 的形式下发给数据平面/Envoy ，Envoy 会代理 SDK 向 Broker/Nameserver 发送的所有的网络请求； 发送时，Envoy 通过 request code 判断出请求为发送，并根据 topic 和 request code 选出对应的 CDS，然后通过 Envoy 提供的负载均衡策略选出对应的 Broker 并发送，这里会使用数据平面的 subset 机制来确保选出的 Broker 是可写的； 消费时，Envoy 通过 request code 判断出请求为消费

系列文章: 总目录索引： 九析带你轻松完爆 istio 服务网格系列教程 目录 1 前言 2 邀约 3 上章总结 4 监听器 4.1 TCP 监听器 4.2 UDP 监听器 1 前言 如果你对博客有任何疑问，请告诉我。 2 邀约 你可以从 b 站搜索 “九析”，获取免费的、更生动的视频资料： 3 上章总结 上节介绍了 Envoy 的基础配置信息，如下图所示： 上面配置信息重点介绍了两块内容，管理信息（admin 部分）和静态配置信息（static_resources 部分）。管理信息包括 Envoy 的 web 管理控制台。在用 Docker 运行时可对外开放 9901 端口（并对所有客户端可见，即 address 为 0.0.0.0）。关于如何运行 Envoy 可参考我上一篇文章，轻松完爆就是。运行后的结果如下图所示： 从上图可知，对外服务端口 9901 已经开启。打开浏览器访问，如下图所示： 静态配置信息主要包括两部分内容，分别是监听器（listener，今天介绍的主角）和集群（cluster），如下图所示： listener 是 Envoy 对外提供的监听端口，默认 10000。客户端通过此端口可以与 Envoy 建立通讯，获取连接（connection）。此外，在监听器上还可设置过滤器链（filter_chains），链上设置多过滤器，这样的设置可保证对进入 Envoy

作者 | 凌楚 阿里巴巴开发工程师 导读 ：自 19 年底开始，支持 Apache RocketMQ 的 Network Filter 历时 4 个月的 Code Review（ Pull Request ），于本月正式合入 CNCF Envoy 官方社区（ RocketMQ Proxy Filter 官方文档 ），这使得 RocketMQ 成为继 Dubbo 之后，国内第二个成功进入 Service Mesh 官方社区的中间件产品。 Service Mesh 下的消息收发 主要流程如下图： 图 1 简述一下 Service Mesh 下 RocketMQ 消息的发送与消费过程： Pilot 获取到 Topic 的路由信息并通过 xDS 的形式下发给数据平面/Envoy ，Envoy 会代理 SDK 向 Broker/Nameserver 发送的所有的网络请求； 发送时，Envoy 通过 request code 判断出请求为发送，并根据 topic 和 request code 选出对应的 CDS，然后通过 Envoy 提供的负载均衡策略选出对应的 Broker 并发送，这里会使用数据平面的 subset 机制来确保选出的 Broker 是可写的； 消费时，Envoy 通过 request code 判断出请求为消费，并根据 topic 和 request code 选出对应的