Envoy

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 点击下载《不一样的 双11 技术：阿里巴巴经济体云原生实践》 本文节选自《不一样的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片即可下载！ 作者 杨宁（麟童） 阿里云基础产品事业部高级安全专家 刘梓溪（寞白） 蚂蚁金服大安全基础安全安全专家 李婷婷（鸿杉） 蚂蚁金服大安全基础安全资深安全专家 简介 零信任安全最早由著名研究机构 Forrester 的首席分析师约翰.金德维格在 2010 年提出。零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新的建议。 其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础。诸如 IP 地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以身份为中心进行访问控制。 目前落地零信任概念包括 Google BeyondCorp、Google ALTS、Azure Zero Trust Framework 等，云上零信任体系，目前还是一个新兴的技术趋势方向，同样的零信任模型也同样适用于 Kubernetes，本文重点讲解一下 Kubernetes 下零信任安全架构的技术分析。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 导读：随着Service Mesh在最近一年进入人们的视野，Envoy 作为其中很关键的组件，也开始被广大技术人员熟悉。本文作者所在公司已经从 nginx 迁移到 Envoy。 随着我们下一代产品发布，我们将代理软件从 nginx 切换到 Envoy 。 我们很早就开始关注 Envoy。 公司的一些人之前在 Twitter 工作，其中一些人和 Matt Klein 一起组建了 Twitter 的边缘代理 TFE。 我们知道 Lyft 正在计划建立一个基于 TFE 的开源代理模型，我们对此很感兴趣。 不幸的是，我们刚开始做自己产品的时候它还没有准备好，所以起初我们还是使用 nginx。 我们很高兴看到 Envoy 的最初功能集合中包含了大量灵活运用微服务的想法。 我们更加兴奋地看到它的社区已经成型并且技术已经成熟。 现在 Envoy 提供的功能(相比于 nginx)可以使我们能够更快地为客户提供新功能。当然，Envoy 的功能路线图也非常令人兴奋。 选择代理 在启动Turbine Labs时，我们就知道负载均衡将成为我们基础架构的关键组成部分。 在2015年秋季的时候，代理软件并不是我们今天看到的样子。 我们选择 nginx 是因为它轻巧，经过大量生产环境测试，开源，相对来说易于扩展，并且拥有蓬勃发展的用户群体。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、Envoy的工作模式 Envoy的工作模式如图所示，横向是管理平面。 Envoy会暴露admin的API，可以通过API查看Envoy中的路由或者集群的配置。 例如通过curl http://127.0.0.1:15000/routes可以查看路由的配置，结果如下图，请记住路由的配置层级，后面在代码中会看到熟悉的数据结构。 routes下面有virtual_hosts，里面有带prefix的route，里面是route entry，里面是weight cluster，对于不同的cluster不同的路由权重，再里面是cluster的列表，有cluster的名称和权重。 再如通过curl http://127.0.0.1:15000/clusters可以得到集群也即cluster的配置，这里面是真正cluster的信息。 在另外一面，Envoy会调用envoy API去pilot里面获取路由和集群的配置，envoy API的详情可以查看https://www.envoyproxy.io/docs/envoy/v1.8.0/api-v2/http_routes/http_routes中的API文档，可以看到route的配置详情，也是按照上面的层级组织的。 当Envoy从pilot获取到路由和集群信息之后

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文分析的istio代码版本为0.8.0，commit为0cd8d67，commit时间为2018年6月18日。 本文为 Service Mesh深度学习系列 之一： Service Mesh深度学习系列part1—istio源码分析之pilot-agent模块分析 Service Mesh深度学习系列part2—istio源码分析之pilot-discovery模块分析 pilot总体架构 首先我们回顾一下pilot总体架构，上面是 官方关于pilot的架构图 ，因为是old_pilot_repo目录下，可能与最新架构有出入，仅供参考。所谓的pilot包含两个组件：pilot-agent和pilot-discovery。图里的agent对应pilot-agent二进制，proxy对应Envoy二进制，它们两个在同一个容器中，discovery service对应pilot-discovery二进制，在另外一个跟应用分开部署的单独的deployment中。 discovery service ：从Kubernetes apiserver list/watch service 、 endpoint 、 pod 、 node 等资源信息，监听istio控制平面配置信息（Kubernetes CRD），

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 　　Envoy 源码分析－－LDS 　　 　　LDS 是 Envoy 用来自动获取 listener 的 API。 Envoy 通过 API 可以增加、修改或删除 listener。 　　 　　先来总结下 listener 的更新语义如下： 　　 　　每个 listener 必须有一个唯一的名称。如果没有提供名称，Envoy 会生成一个 UUID 来作为它的名字。要动态更新 listener，管理服务必须提供一个唯一名称。 　　 　　当 listener 被添加，在接收流量之前，会先进入 “预热” 阶段。 　　 　　一旦 listener 被创建，就会保持不变。因此，listener 更新时，会创建一个全新的 listener（同一个侦听套接字）。这个新增加的 listener 同样需要一个 “预热” 过程。 　　 　　当更新或删除 listener 时，旧的 listener 将被置于 “draining（驱逐）” 状态，和整个服务重新启动时一样。在删除侦听器并关闭任何其余连接之前，侦听器拥有的连接将在一段时间内优雅关闭（如果可能的话）。逐出时间通过 --drain-time-s 设置。 　　 　　相同名称的 listener 必须要有相同的配置地址。 　　 　　接下来是对 lds 进行源码分析

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Dispatcher 在Envoy的代码中 Dispatcher 是随处可见的，可以说在Envoy中有着举足轻重的地位，一个 Dispatcher 就是一个 EventLoop ，其承担了任务队列、网络事件处理、定时器、信号处理等核心功能。在 Envoy threading model 这篇文章所提到的 EventLoop ( Each worker thread runs a “non-blocking” event loop )指的就是这个 Dispatcher 对象。这个部分的代码相对较独立，和其他模块耦合也比较少，但重要性却不言而喻。下面是与 Dispatcher 相关的类图，在接下来会对其中的关键概念进行介绍。 Dispatcher 和 Libevent Dispatcher 本质上就是一个 EventLoop ，Envoy并没有重新实现，而是复用了Libevent中的 event_base ，在Libevent的基础上进行了二次封装并抽象出一些事件类，比如 FileEvent 、 SignalEvent 、 Timer 等。Libevent是一个C库，而Envoy是C++，为了避免手动管理这些C结构的内存，Envoy通过继承 unique_ptr 的方式重新封装了这些libevent暴露出来的C结构

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Istio is the future！基本上，我相信对云原生技术趋势有些微判断的同学，都会有这个觉悟。其背后的逻辑其实是比较简单的：当容器集群，特别是K8S成为事实上的标准之后，应用必然会不断的复杂化，服务治理肯定会成为强需求。 Istio的现状是，聊的人很多，用的人其实很少。所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。 阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单Istio问题的排查过程，权当抛砖。 二分之一活的微服务 问题是这样的，用户在自己的测试集群里安装了Istio，并依照官方文档部署bookinfo应用来上手Istio。部署之后，用户执行kubectl get pods命令，发现所有的pods都只有二分之一个容器是READY的。 # kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 1/2 Running 0 1m productpage-v1-5cb458d74f-28nlz 1/2 Running 0 1m ratings-v1-76f4c9765f-gjjsc 1/2 Running 0 1m reviews-v1

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一,服务治理要做什么 以下是服务治理的整体拓扑图 1,可见性 可见性是指可以通过图形化,查看各种指标,包括系统级别,(CPU,内存,网络,磁盘), 接口级别(接口调用量,响应时间等) 主要包括 1.1运行指标 1.2 分布式追踪 1.3 日志 1.4 服务依赖 2,可管理性 3,健壮性 4,安全性 来源： oschina 链接： https://my.oschina.net/original123/blog/3142576

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 点击下载《不一样的 双11 技术：阿里巴巴经济体云原生实践》 本文节选自《不一样的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片即可下载！ 作者 | 方克明（溪翁）阿里云中间件技术部技术专家 导读 ：云原生已成为整个阿里巴巴经济体构建面向未来的技术基础设施，Service Mesh 作为云原生的关键技术之一，顺利完成在 双11 核心应用严苛而复杂场景下的落地验证。本文作者将与大家分享在完成这一目标过程中我们所面临和克服的挑战。 部署架构 切入主题前，需要交代一下在 双11 核心应用上落地的部署架构，如下图所示。在这篇文章中，我们主要聚焦于 Service A 和 Service B 之间 RPC 协议的 Mesh 化。 图中示例说明了 Service Mesh 所包含的三大平面：即数据平面（Data Plane）、控制平面（Control Plane）和运维平面（Operation Plane）。数据平面我们采用的是开源的 Envoy（上图中的 Sidecar，请读者注意这两个词在本文中可以互换使用），控制平面采用的是开源的 Istio（目前只使用了其中的 Pilot 组件），运维平面则完全自研。 与半年前落地时不同，这次 双11 核心应用上落地我们采用了 Pilot 集群化部署的模式，即

上周给大家分享了一篇 必读！Istio Service Mesh中的流量管理概念解析 ，这次再给大家分享一篇Istio中重要功能和概念——授权（authorization）与鉴权（authentication）的解析。 将单体应用程序分解为微服务可提供各种好处，包括更好的灵活性、可伸缩性以及服务复用的能力。但是，微服务也有特殊的安全需求： 为了抵御中间人攻击，需要流量加密。 为了提供灵活的服务访问控制，需要双向 TLS 和细粒度的访问策略。 要审核谁在什么时候做了什么，需要审计工具。 Istio Security 尝试提供全面的安全解决方案来解决所有这些问题。 本页概述了如何使用 Istio 的安全功能来保护您的服务，无论您在何处运行它们。特别是 Istio 安全性可以缓解针对您的数据，端点，通信和平台的内部和外部威胁。 Istio 安全概述 Istio 安全功能提供强大的身份，强大的策略，透明的 TLS 加密以及用于保护您的服务和数据的身份验证，授权和审计（AAA）工具。 Istio 安全的目标是： 默认安全 : 应用程序代码和基础结构无需更改 深度防御 : 与现有安全系统集成，提供多层防御 零信任网络 : 在不受信任的网络上构建安全解决方案 访问我们的Mutual TLS Migration docs，开始在部署的服务中使用Istio安全功能。 请访问我们的安全任务