Envoy

之前，已为大家介绍过 Istio 第一主打功能--- 连接服务 。 凡是产生连接关系，就必定带来安全问题，人类社会如此，服务网格世界，亦是如此。 今天，我们就来谈谈Istio第二主打功能---保护服务。 那么，便引出3个问题： Istio 凭什么保护服务？ Istio 具体如何保护服务？ 如何告诉 Istio 发挥保护能力？ Istio凭什么保护服务？ 将单体应用程序分解为一个个服务，为大型软件系统的开发和维护带来了诸多好处，比如更好的灵活性、可伸缩性和可复用性。但这也带来了一些安全问题： 为了抵御中间人攻击，需要对流量进行加密 为了提供灵活的服务访问控制，需要 mTLS（双向的安全传输层协议）和细粒度的访问策略 要审计谁在什么时候做了什么，需要审计工具 Istio 尝试提供全面的安全解决方案来解决这3个问题。 如上图所示， Istio 安全的三大目标是： 默认安全（Security by default）：应用程序代码和基础结构，无需更改。 深度防御（Defense in depth）：与现有安全系统集成，提供多层防御。 零信任网络（Zero-trust network）：在不受信任的网络上，构建安全解决方案。 为了实现这3个目标，Istio 安全功能提供了4大守护系统： 强大的身份（Identity）系统 健壮的策略（Policy）系统 认证，授权和审计（AAA

Istio架构及其组件概述 Istio 架构总体来说分为控制面和数据面两部分。 控制面是 Istio 的核心，管理 Istio 的所有功能，主要包括Pilot、Mixer、Citadel等服务组件; 数据面由伴随每个应用程序部署的代理程序Envoy组成，执行针对应用程序的治理逻辑。常被称为“Sidecar”。Sidecar 一般和业务容器绑定在一起（在Kubernets中自动注入方式到业务pod中），来劫持业务应用容器的流量，并接受控制面组件的控制，同时会向控制面输出日志、跟踪及监控数据。 Istio 的主要组件及其相互关系大致如图所示（摘自《云原生服务网格Istio》）。 结合上图我们来理解Istio的各组件的功能及相互之间的协作方式。 1. 自动注入：在创建应用程序时自动注入 Sidecar代理Envoy程序。在 Kubernetes中创建 Pod时，Kube-apiserver调用控制面组件的 Sidecar-Injector服务，自动修改应用程序的描述信息并注入Sidecar。在 真正创建Pod时，在创建业务容器的Pod中同时创建Sidecar容器。 2. 流量拦截：在 Pod 初始化时设置 iptables 规则，基于配置的iptables规则拦截业务容器的Inbound流量和Outbound流量到Sidecar上。而应用程序感知不到Sidecar的存在，还以原本的方式

前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。另外在本文最后，介绍蚂蚁金服在 Service Mesh 和 API Gateway 融合的这个最新领域的一些开创性的实践和探索，希望给大家一个更有体感的认知。 备注1：为了节约篇幅，我们将直奔主题，假定读者对 Service Mesh 和 API Gateway 已有基本的了解。 备注2: 这边文章更关注于梳理整个脉络，内容不会展开的特别细，尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后，还想更深入的了解细节，请继续阅读文章最后的参考资料和推荐阅读。 原本清晰的界限：定位和职责 首先，Service Mesh 和 API Gateway 在功能定位和承担的职责上有非常清晰的界限： Service Mesh：微服务的网络通信基础设施，负责（系统内部的）服务间的通讯； API Gateway： 负责将服务以 API 的形式暴露（给系统外部），以实现业务功能； 如上图所示： 从功能和职责上说： 位于最底层的是拆分好的原子微服务，以服务的形式提供各种能力； 在原子微服务上是（可选的）组合服务

云原生计算基金会（CNCF）正式发布GA版本的gRPC-Web，这是一个JavaScript客户端库，使Web应用程序能够直接与后端gRPC服务通信，不需要HTTP服务器充当中介。这意味着你现在可以通过.proto文件来定义客户端和服务器端数据类型和服务接口，轻松构建真正的端到端gRPC应用程序架构。gRPC-Web为Web开发提供了REST之外的另一个选择。 \\ 基础 \\ gRPC-Web让你能够使用.proto来定义客户端Web应用程序和后端gRPC服务器之间的服务“契约”，并自动生成客户端JavaScript（你可以选择Closure编译器或使用更为广泛的CommonJS）。你可以不用再为这些事情操心：创建自定义JSON序列化和反序列化逻辑、处理HTTP状态代码（可能因​​REST API而异）、Content-Type协商等。 \\ 从更广泛的架构角度来看，gRPC-Web让端到端的gRPC成为可能。如下图所示： \\ \\ 在左侧，一个客户端应用程序通过Protocol Buffers与一个gRPC后端服务器通信，然后这个服务器也通过Protocol Buffers与其他的gRPC后端服务器通信。在右侧，Web应用程序通过HTTP与后端REST API服务器通信，然后这个服务器又通过Protocol Buffers与其他后端服务通信。 \\ 需要明确指出的是

前言 使用 API 网关作为内部服务面向客户端的单一入口，是一种普遍采用的架构模式。企业组织通过良好定义的 API 将内部系统向内部和外部用户公开，通常都会采用 API 网关来处理横向的关注点，包括访问控制、速率限制、负载均衡等等，来实现安全可控的 API 开放。而被广泛实践的微服务架构在提供高度灵活性和弹性的同时，也给 API 网关带来了更多的挑战。 阿里云云服务总线（Cloud Service Bus）新推出微服务网关服务（CSB Micro Gateway），针对微服务架构下 API 开放的特点，提供能与微服务环境的治理策略无缝衔接的网关服务，实现高效的微服务 API 开放。 API 网关的作用 API 网关典型作用 相信许多人都熟悉 API 网关的概念。作为内部服务面向客户端的单一入口，API 网关有两个最典型的作用： 1、内外解耦：对客户端屏蔽内部服务的动态多样化实现细节，如技术框架、拆分粒度、接口结构、实例状态等 2、切面控制：让内部服务能专注在业务逻辑上，集中处理横向的关注点，如路由、安全、限流、日志、监控等 API 网关使用类型 实际使用中，对应 API 网关所在位置和针对场景的不同，可分成两种类型： 1、企业级网关：位于企业组织的外围，面对外部的 API 消费者或服务提供者。通常将企业自身的数据和能力 API 化，对外开放，也有允许外部服务入驻的情况。总的来说

工作中用了容器？熟悉这些出自云原生计算基金会的项目吗？ 随着用容器来开发应用的实践变得流行， 云原生应用 也在增长。云原生应用的定义为： “云原生技术用于开发使用打包在容器中的服务所构建的应用程序，以微服务的形式部署，并通过敏捷的 DevOps 流程和持续交付工作流在弹性基础设施上进行管理。” 这个定义提到了构成云原生应用的不可或缺的四个元素： 容器 微服务 DevOps 持续集成和持续交付 (CI/CD) 尽管这些技术各有各自独特的历史，但它们之间却相辅相成，在短时间内实现了云原生应用和工具的惊人的指数级增长。这个 云原生计算基金会（CNCF） 信息图呈现了当今云原生应用生态的规模和广度。 云原生计算基金会项目 我想说，瞧着吧！这仅仅是一个开始。正如 NodeJS 的出现引发了无数的 JavaScript 工具的爆炸式增长一样，容器技术的普及也推动了云原生应用的指数增长。 好消息是，有几个组织负责监管并将这些技术连接在一起。 其中之一是 开放容器倡议 Open Containers Initiative（OCI），它是一个轻量级的、开放的治理机构（或项目），“它是在 Linux 基金会的支持下形成的，其明确目的是创建开放的行业标准的容器格式和运行时。” 另一个是 CNCF，它是“一个致力于使云原生计算普及和可持续发展的开源软件基金会”。 通常除了围绕云原生应用建立社区之外

3 月，跳不动了？>>> SOFA:Channel/ ，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。 本文根据 SOFAChannel#13 直播分享整理，主题：云原生网络代理 MOSN 多协议机制解析。 大家好，我是今天的讲师无钩，目前主要从事蚂蚁金服网络代理相关的研发工作，也是 MOSN 的 Committer。今天要和大家分享的是《云原生网络代理 MOSN 多协议机制解析》，并介绍对应的私有协议快速接入实践案例以及对 MOSN 实现多协议低成本接入的设计进行解读。 我们将按以下顺序进行介绍： 多协议机制产生的背景与实践痛点； 常见的协议扩展思路初探； SOFABolt 协议接入实践；（重点） MOSN 多协议机制设计解读；（重点） 后续规划及展望； 其中第三点「接入实践」是今天分享的重点，希望能给大家就「如何在 MOSN 中快速扩展私有协议接入」有一个具体的感受。另外「MOSN 如何实现多协议框架」也是很多人关心和问题，我们将摘选几个技术功能，对其背后的设计思考进行解读。 MOSN 简介 云原生网络代理 MOSN 定位是一个全栈的网络代理，支持包括网络接入层(Ingress)、API Gateway、Service Mesh 等场景，目前在蚂蚁金服内部的核心业务集群已经实现全面落地，并经受了

3 月，跳不动了？>>> 本文翻译自 https://www.tigera.io/blog/running-istio-on-kubernetes-in-production-part-i/，作者 Alexander Lukyanchenko，发表于2019年5月。 什么是 Istio ？ Istio 是一种服务网格（service mesh）技术，它为网络添加了一个抽象层。它拦截 K8S 集群中的全部或部分流量，并对其进行处理。它支持哪些操作呢？ 例如，设置智能路由（ smart routing ）或实现断路器（ circuit breaker ）或金丝雀部署（ Canary deployment ）。此外， Istio 还可以限制外部交互，并控制群集和外部网络之间的所有路由。此外，它支持设置策略规则以控制不同微服务之间的交互。最后，我们可生成一个完整的网络交互图，采用统一度量，并对应用程序完全透明。 Istion 的详细介绍可以访问其官方文档 https://istio.io/docs/concepts/ 。本文中，我会介绍基于 Istio 的微服务之间交互的基本原理，你将会看到 Istio 是一个非常强大的能解决很多问题的工具。我还会尝试着回答一些初学者经常问到的问题。我相信这些能帮助你高效地使用 Istio 。 在安装 Istio 之前，我想介绍一些基本概念

3 月，跳不动了？>>> 作者 | 宿何 阿里云高级开发工程师 导读 ：疫情期间，“卡”成了很多人线上体验的关键词。线上预约购买口罩时，突然不能付款了；在线选课，被提示请求过多，系统无法响应；在线办公/教学时，图像或声音卡住了……这些可用性下降的场景严重的影响了用户体验，也降低了公司的工作效率。面对“卡”住了的情况 ，作为开发者的我们，需要预先通过一些手段来提前对不稳定的因素进行防护，同时在突发流量的情况下，也要具备快速止损的能力。 近年来，微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化，服务之间的依赖关系变得越来越复杂，业务系统也面临着巨大的高可用挑战。 如何保障服务的可用性？这是一个非常庞大的话题，涉及到方方面面，其中一个重要的手段就是流控降级。 为什么要进行流控降级？ 流量是非常随机性的、不可预测的。前一秒可能还风平浪静，后一秒可能就出现流量洪峰了（例如 双11 零点的场景）。 然而我们的系统容量总是有限的，如果突如其来的流量超过了系统的承受能力，就可能会导致请求处理不过来，堆积的请求处理缓慢，CPU/Load 飙高，最终导致系统崩溃。因此，我们需要针对这种突发的流量来进行限制，在尽可能处理请求的同时来保障服务不被打垮。 一个服务常常会调用别的模块，可能是另外的一个远程服务、数据库，或者第三方 API 等。 例如，支付的时候

用于Istio中的流量管理的核心组件是 Pilot ，它管理和配置在特定Istio服务网格中部署的所有Envoy代理实例。它允许您指定要用于在Envoy代理之间路由流量的规则，以及配置故障恢复功能（如超时，重试和断路器）。它还维护网格中所有服务的规范模型，并使用它来让Envoys通过其发现服务了解网格中的其他实例。 每个Envoy实例根据从Pilot获取的信息以及对其负载平衡池中其他实例的定期运行状况检查来维护 负载平衡信息 ，从而允许它在遵循其指定的路由规则的同时智能地在目标实例之间分配流量。 交通管理的好处 使用Istio的流量管理模型实质上解耦了流量和基础架构扩展，让运营商通过Pilot指定他们希望流量遵循的规则，而不是哪些特定的pod / VM应该接收流量 - 飞行员和智能Envoy代理负责其余的工作。因此，例如，您可以通过Pilot指定您希望特定服务的5％流量转到金丝雀版本，而不管金丝雀部署的大小，或根据请求的内容将流量发送到特定版本。 用Istio进行交通管理 将流量从这样的基础设施扩展中分离，允许Istio提供存在于应用程序代码之外的各种流量管理功能。除了用于A / B测试，逐步推出和金丝雀版本的动态 请求路由之外 ，它还使用超时，重试和断路器处理 故障恢复 ，最后使用 故障注入 来测试跨服务的故障恢复策略的兼容性。这些功能都是通过服务网格上部署的Envoy