爱豆吧!

idouba@beta.

Istio灰度发布实践 –《云原生服务网格Istio》书摘05

本节书摘来自华为云原生技术丛书《云原生服务网格Istio:原理,实践,架构与源码解析》一书实践篇的第10章灰度发布实践。更多内容参照原书,或者关注容器魔方公众号。作者:star 目前一些大型的互联网或金融行业的公司,都有自己的发布系统。但是对一些初创公司,从零开始构建这样一套系统并不简单,有一定的门槛。利用Istio提供的流量路由功能可以很方便地构建一个流量分配系统来做灰度发布和AB测试。 预先准备: 将所有流量都路由到各个服务的v1版本 在开始本章的实践前,先将frontend、advertiseme Read more →

Sidecar Injector自动注入的原理 –《云原生服务网格Istio》书摘04

本节书摘来自华为云原生技术丛书《云原生服务网格Istio:原理,实践,架构与源码解析》一书原理篇的第6章透明的Sidecar机制,6.1.1小节Sidecar Injector自动注入的原理。更多内容参照原书,或者关注容器魔方公众号。 Sidecar注入 我们都知道,Istio的流量管理、策略、遥测等功能无须应用程序做任何改动,这种无侵入式的方式全部依赖于Sidecar。应用程序发送或者接收的流量都被Sidecar拦截,并由Sidecar进行认证、鉴权、策略执行及遥测数据上报等众多治理功能。 如图6-1 Read more →

Istio灰度发布 –《云原生服务网格Istio》书摘03

本节书摘来自华为云原生技术丛书《云原生服务网格Istio:原理,实践,架构与源码解析》一书原理篇的第3章非侵入的流量治理,第3.1.4小节灰度发布原理。更多内容参照原书,或者关注容器魔方公众号。 3.1.4 灰度发布 在新版本上线时,不管是在技术上考虑产品的稳定性等因素,还是在商业上考虑新版本被用户接受的程度,直接将老版本全部升级是非常有风险的。所以一般的做法是,新老版本同时在线,新版本只切分少量流量出来,在确认新版本没有问题后,再逐步加大流量比例。这正是灰度发布要解决的问题。其核心是能配置一定的流量策略,将 Read more →

Istio通过Prometheus收集遥测数据–《云原生服务网格Istio》书摘06

本节书摘来自华为云原生技术丛书《云原生服务网格Istio:原理,实践,架构与源码解析》一书原理篇的第4章可扩展的策略和遥测中1.4.1小节Prometheus适配器。更多内容参照原书,或者关注容器魔方公众号。 Prometheus适配器 Prometheus应该是当前应用最广的开源系统监控和报警平台了,随着以Kubernetes为核心的容器技术的发展,Prometheus强大的多维度数据模型、高效的数据采集能力、灵活的查询语法,以及可扩展性、方便集成的特点,尤其是和云原生生态的结合,使其获得了越来越 Read more →

Pilot的设计亮点–《云原生服务网格Istio》书摘02

本节书摘来自华为云原生技术丛书《云原生服务网格Istio:原理,实践,架构与源码解析》一书架构篇的第14章司令官Pilot,第4节Pilot的设计亮点。更多内容参照原书,或者关注容器魔方公众号。作者:中虎 作为Istio数据面的司令官,Pilot控制中枢系统,它的性能好坏直接影响服务网格的大规模可扩展、配置时延等。如果Pilot的性能低,配置生成效率也低,那么它将难以管理大规模服务网格。比如,服务网格拥有成千上万服务及数十万服务实例,配置生成的效率很低,难以满足服务及Config更新带来的配置更新 Read more →

Istio服务熔断 –《云原生服务网格Istio》书摘01

本节书摘来自华为云原生技术丛书《云原生服务网格Istio:原理,实践,架构与源码解析》一书中的第3章非侵入的流量治理,第3节Istio流量治理的原理3.1.2小节服务熔断。更多内容参照原书,或者关注容器魔方公众号。 熔断器在生活中一般指可以自动操作的电气开关,用来保护电路不会因为电流过载或者短路而受损,典型的动作是在检测到故障后马上中断电流。“熔断器”这个概念延伸到计算机世界中指的是故障检测和处理逻辑,防止临时故障或意外导致系统整体不可用,最典型的应用场景是防止网络和服务调用故障级联发生,限制故障 Read more →

2019年元旦忆我的咕咚队友

2018,我和我的咕咚队友的故事。2019,我和我的咕咚队友的故事,还将继续。整理手机里的文字,告别和纪念逝去的2018,迎来2019,多些勇气和力量。 一百天,老太太离开我们整整一百天了,可能是过去的几十年里最难过最漫长的一百天。又一次踏上回家路。大清早四点多起床,背了一个空包就钻进了往机场的出租车。再也不用琢磨包里塞点老太太没有吃过的东西。包里空的,心里更空, 这段时间一直就心里空空的,乱乱的。莫名的会发脾气,也莫名的会忘东西。考勤纪律很严格的我厂里居然一个月里有好几次忘了打卡。 有几次奇怪的梦里 Read more →

Istio 调用链埋点原理剖析—是否真的“零修改”?

发在Infoq上的一篇文章,答疑当前大家工作中碰到的Istio调用链的问题,最终澄清了观点,并推动社区修改了说法,避免误解。 前言 在 Istio 的实践中最近经常被问到一个问题,使用 Istio 做调用链用户的业务代码是不是完全 0 侵入,到底要不要修改业务代码? 看官方介绍: Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. 是不用修改任何代码即可做各种治理。实际使用中应用程序不做任何修改,使用 Istio 的调用链输出总是断开的,这到底是什么原因呢? 对以上问题关注的人比较多,但是貌似说的都不是特别清楚,在最近的 K8S 技术社区的 Meetup 上笔者专门做 Read more →

Istio调用链埋点原理剖析—是否真的“零修改”分享实录(下)

接上文Istio调用链埋点原理剖析—是否真的“零修改”分享实录(上) Isito调用链** 调用链原理和场景 正如Service Mesh的诞生是为了解决大规模分布式服务访问的治理问题,调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器,可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用上链路上出现问题都比较复杂,如何定位就比单进程的一个服务打印一个异常栈来找出某个方法要困难的多。需要有一个类似的调用链路的跟踪,经一次请求的 Read more →

Istio调用链埋点原理剖析—是否真的“零修改”分享实录(上)

前言 大家好,我是zhangchaomeng,来自华为Cloud BU,当前在做华为云应用服务网格。今天跟大家分享的主题是Istio调用链相关内容。通过剖析Istio的架构机制与Istio中调用链的工作原理来解答一个大家经常问道的一个问题:Istio是否像其官方文档中宣传的一样,对业务代码完全的无侵入,无需用做任何修改就可以完成所有的治理能力,包括调用链的埋点? 关于这个问题,可以提前透漏下,答案是让人有点沮丧的,得改点。在Isito中你不用在自己的代码里使用各种埋点的SDK来做埋点的逻辑,但是必须要 Read more →