在服务治理中,流量管理是一个广泛的话题,一般情况下,常用的包括: 动态修改服务访问的负载均衡策略,比如根据某个请求特征做会话保持: 同一个服务有多版本管理,将一部分流量切到某个版本上: 对服务进行保护,例如限制并发连接数.限制请求数.隔离故障服务实例等: 动态修改服务中的内容,或者模拟一个服务运行故障等. 在Istio中实现这些服务治理功能时无须修改任何应用的代码.较之微服务的SDK方式,Istio以一种更轻便.透明的方式向用户提供了这些功能.用户可以用自己喜欢的任意语言和框架进行开发,专注于自

流量治理是一个非常宽泛的话题,例如: ● 动态修改服务间访问的负载均衡策略,比如根据某个请求特征做会话保持: ● 同一个服务有两个版本在线,将一部分流量切到某个版本上: ● 对服务进行保护,例如限制并发连接数.限制请求数.隔离故障服务实例等: ● 动态修改服务中的内容,或者模拟一个服务运行故障等. 在Istio中实现这些服务治理功能时无须修改任何应用的代码.较之微服务的SDK方式,Istio以一种更轻便.透明的方式向用户提供了这些功能.用户可以用自己喜欢的任意语言和框架进行开发,专注于自己的业务

一.负载均衡算法原理与实战 负载均衡算法(load balancing algorithm),定义了几种基本的流量分发方式,在Istio中共有4种标准负载均衡算法. •Round_Robin: 轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求. •Random: 随机算法,将所有的请求随机分发给健康的实例 •Least_Conn: 最小连接数,在所有健康的实例中任选两个,将请求发给连接数较小的那一个实例. 接下来,我们将根据以上几个算法结合APM(应用性能管理)的监控拓扑图来实

一.负载均衡算法原理与实战 负载均衡算法(load balancing algorithm),定义了几种基本的流量分发方式,在Istio中一共有4种标准负载均衡算法. •Round_Robin: 轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求. •Random: 随机算法,将所有的请求随机分发给健康的实例 •Least_Conn: 最小连接数,在所有健康的实例中任选两个,将请求发给连接数较小的那一个实例. 接下来,我们将根据以上几个算法结合APM(应用性能管理)的监控拓扑图来

Istio 1.0.1作为8月份的版本已经发布,主要修复了1.0版本发布以来发现的一些关键Issue.官网的release note(https://istio.io/about/notes/1.0.1/)列出了Istio1.0和1.0.1的差别. Istio涉及的组件和CRD较多,Istio 1.0 中包含了 51 个 CRD,组件包括pilot,galley,policy,telemetry,citadel和许多插件,对想快速试用Istio的同学来说比较困难. Istio 1.0.1允许部署

前言 在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移.这两个方面的功能都是Istio流量治理的一部分.今天将继续带大家了解Istio的另一项功能,关于请求超时的管理. 首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理. 下面先简单的介绍一下Bookinfo这个样例应用整体架构,以便我们更好地理解Istio是如何实现请求超时,对于老司机可以直接跳过这部分. Bookinfo应用由四个单独的微服务构成,用来演示多种 Istio

在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移.这两个方面的功能都是Istio流量治理的一部分.今天将继续带大家了解Istio的另一项功能,关于请求超时的管理. 首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理.看过idou老师前面文章的老司机应该都已经对Bookinfo这个实例驾轻就熟了,当然还存在部分被idou老师的文采刚吸引过来的新同学. 下面先简单的介绍一下Bookinfo这个样例应用整体架构,以便我们更好地理解I

前言 文章Istio技术与实践01: 源码解析之Pilot多云平台服务发现机制结合Pilot的代码实现介绍了Istio的抽象服务模型和基于该模型的数据结构定义,了解到Istio上只是定义的服务发现的接口,并未实现服务发现的功能,而是通过Adapter机制以一种可扩展的方式来集成各种不同的服务发现.本文重点讲解Adapter机制在Kubernetes平台上的使用.即Istio on Kubernetes如何实现服务发现. Istio的官方设计上特别强调其架构上的可扩展性,即通过框架定义与实现解耦的

调用链原理和场景 正如Service Mesh的诞生是为了解决大规模分布式服务访问的治理问题,调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题.大量的服务调用.跨进程.跨服务器,可能还会跨多个物理机房.无论是服务自身问题还是网络环境的问题导致调用上链路上出现问题都比较复杂,如何定位就比单进程的一个服务打印一个异常栈来找出某个方法要困难的多.需要有一个类似的调用链路的跟踪,经一次请求的逻辑规矩完整的表达出来,可以观察到每个阶段的调用关系,并能看到每个阶段的耗时和调用详

Istio作为当前服务网格(Service Mesh)领域的事实标准,流量治理(Traffic Management)是其最为基础也最为重要的功能.本文将结合源码对Istio流量治理的实现主体——组件Pilot进行深入地分析.(本文参考的代码为位于Istio repo的master分支,commit为b8e30e0) 1. 架构分析 在应用从单体架构向微服务架构演进的过程中,微服务之间的服务发现.负载均衡.熔断.限流等流量治理需求是无法回避的问题.在Service Mesh出现之前,通常的做法是

1.Istio介绍? 官方文档:https://istio.io/docs/concepts/what-is-istio/ 中文官方文档:https://istio.io/zh/docs/concepts/what-is-istio/ Github地址:https://github.com/istio/istio/releases 1.1 Istio是什么? 官当解释: An open platform to connect, secure, control and observe servic

两年前Service Mesh(服务网格)一出来就受到追捧,很多人认为它是微服务架构的最终形态,因为它可以让业务代码和微服务架构解耦,也就是说业务代码不需要修改就能实现微服务架构,但解耦还不够彻底,使用还是不方便,虽然架构解耦了,但部署还没有解耦. 无法根据不同环境或客户需要选择合适的Service Mesh框架. 无法做到在开发环境不用学习和使用Service Mesh,生产环境按需开启. 插件式 Service Mesh架构实现思路 目前成熟的ServiceMesh框架也有许多,但是对于用户

一.背景 现有的 ServiceMesh 框架有很多,如 Istio.linkerd等.对于用户而言,在测试环境下,需要达到的效果是快.开箱即用.但在生产环境下,可能又有熔断.延时注入等需求.那么单一的 ServiceMesh 框架无法同时满足用户不同的需求. 在之前的 Rainbond 版本中,Rainbond 支持了多种不同的应用治理模式,作为应用级的插件,实现了Istio 治理模式的切换. 本文将对Rainbond 实现Istio治理模式进行原理解析. 二.基本原理 动态准入控制 首先我们

作者 陈计节,企业应用云原生架构师,在腾讯企业 IT 负责云原生应用治理产品的设计与研发工作,主要研究利用容器集群和服务网格等云原生实践模式降低微服务开发与治理门槛并提升运营效率. 摘要 给需要快速解决问题的集群管理员: 在 TKE Stack 中正确安装 Istio CNI 有两种方式:如果你的 TKE Stack 集群所使用 Galaxy 版本可以支持 cniVersion 0.3.1,请以默认的方式安装 Istio CNI:否则请使用以"网卡插件"的方式安装 Istio CNI,

作者 尹烨,腾讯专家工程师, 腾讯云 TCM 产品负责人.在 K8s.Service Mesh 等方面有多年的实践经验. 导语 对于很多后端服务业务,我们都希望得到客户端源 IP.云上的负载均衡器,比如,腾讯云 CLB 支持将客户端源IP传递到后端服务.但在使用 istio 的时候,由于 istio ingressgateway 以及 sidecar 的存在,后端服务如果需要获取客户端源 IP,特别是四层协议,情况会变得比较复杂. 正文 很多业务场景,我们都希望得到客户端源 IP.云上负载均衡器

Kubernetes 作为基础平台,提供了强大的容器编排能力.但是在其上部署业务和服务治理上,仍然会面对一些复杂性和局限性.在服务治理上,已经有许多成熟的 ServiceMesh 框架用于扩充其能力,如 Istio.Linkerd.Dapr 等.本文将主要介绍如何使用 Istio 扩充 Kubernetes 灰度发布的能力. 而在部署上,则会利用开源项目 Rainbond 作为基础平台来进行实践.Rainbond 是一个云原生应用管理平台,它使用以应用为中心的设计模式.基于这一设计模式抽象出了标

Istio的工作机制 Istio的工作机制和架构,分为控制面和数据面两部分.控制面主要包括Pilot.Mixer.Citadel等服务组件:数据面由伴随每个应用程序部署的代理程序Envoy组成,执行针对应用程序的治理逻辑. 通过一个动态场景来了解工作机制,即观察frontend服务对 forecast 服务进行一次访问时,在 Istio 内部都发生了什么,以及 Istio 的各个组件是怎样参与其中的,分别做了哪些事情. 带圆圈的数字代表在数据面上执行的若干重要动作.虽然从时序上来讲,控制面的配置

活动总结 2019年4月21日是一个斜风细雨.微风和煦的美好日子,由长沙.NET技术社区.腾讯云云加社区.微软Azure云技术社区.中国.NET技术社区.长沙柳枝行动.长沙互联网活动基地(唐胡子俱乐部)等多家单位共同主办的长沙开发者技术大会暨长沙.NET社区成立大会在今天顺利召开,参加这次活动的开发者超过了200余人,同时这次活动现场的实况也在腾讯云云加社区的官方首页上进行了同步直播,据后期统计数据显示,有超过两千位观众通过线上直播的方式观看了本次盛会.      本次活动主办单位: 长沙.NE

9 月 19 日,CODING 和中国 DevOps 社区联合举办的深圳第九届 Meetup 在腾讯大厦 2 楼多功能圆满结束.本次沙龙以 「DevOps 转型与实践」 为主题,4 位来自互联网.金融.零售行业的知名世界 500 强企业技术大咖,在现场分享了他们对于 DevOps 转型实践的见解和经验.80 多位观众与讲师们也进行了深入的技术探讨,共同探讨在 DevOps 潮流下,企业可能面临的新机遇和挑战. CODING 一直致力于让所有开发者都能有机会倾听最具前沿的 DevOps 技术分享,

蒋彪,腾讯云高级工程师,10+年专注于操作系统相关技术,Linux内核资深发烧友.目前负责腾讯云原生OS的研发,以及OS/虚拟化的性能优化工作. 导语 云原生场景,相比于传统的IDC场景,业务更加复杂多样,而原生 Linux kernel 在面对云原生的各种复杂场景时,时常显得有些力不从心.本文基于一个腾讯云原生场景中的一个实际案例,展现针对类似问题的一些排查思路,并希望借此透视Linux kernel的相关底层逻辑以及可能的优化方向. 背景 腾讯云客户某关键业务容器所在节点,偶发CPU sys