第 2 期:从微服务架构到 Istio——架构升级实践分享

《Istio 大咖说》第 2 期,2021 年 6 月 2 日,嘉宾潘天颖,话题《从微服务架构到 Istio——架构升级实践分享》。

节目信息

本期简介

云原生赛场已经进入了下半场的比拼,Istio 作为服务网格赛道上的明星选手,社区活跃度和用户知名度都位列前茅。但是国内环境下 Istio 的落地实践却并不多。是什么阻碍了 Istio 的落地,到底 Istio 好不好用?到底什么情况下使用 Istio 利大于弊?本次我们将站在企业用户角度上,邀请了潘天颖分享 Istio 在小电科技的完整落地经验,讲述为什么要从传统微服务架构迁移至服务网格架构,其中遇到的困难与解决方法,以及针对 Istio 的改进方案。

Istio 大咖说 第二期

扫描上图中的二维码可以跳转到《Istio 大咖说》的 B 站直播间,或者直接访问:https://live.bilibili.com/23095515 点个关注,不迷路。

你还可以扫描上图中的二维码在腾讯文档中参与直播互动,我们将会在直播最后送出由机械工业出版社赞助的《Quarkus 实战》和《Knative 实战》书籍。

听众收益

  • 了解 Istio 现状以及使用 Istio 的利弊分析

  • 讲述一次完整的服务迁移至 Istio 实践,可供借鉴

  • 了解一些在使用 Istio 中经常会遇到的典型 Issue 以及解决方案

Q&A 整理

请问刚参加工作的应届生,工作涉及istio中的envoy,请问应届生应该如何提前学习Envoy?

答:需要多了解下网络知识,还有云原生社区的Envoy中文文档可以学习,也可以参加社区的翻译活动。

在 service 特别多的时候,比如几万个 service,sidecar 是否会占用过多内存?如果是的话,可以有什么解决思路?

答:可以通过将应用按业务组进行分组,将相互依赖的应用分开部署到不同的namespace中,然后配置sidecar配置进行配置收拢,使应用只关心特定namespace中的服务配置,个别服务通过网关调用。毕竟很难有应用会依赖几万个svc的。

我们想上Istio,请教下有什么坑?Istio1.10版本。建议上吗?架构为 SpringCloud。

答:本次分享应该回答了问题,这里很难回答。

请问针对使用dubbo框架开发的应用来说,上Istio有什么建议?老师对aeraki这个项目怎么看?Istio对于支持dubbo以及其它协议这块有什么好的支持方式?

答:可以考虑升级下dubbo 3.0.0,istio目前已经支持dubbo协议,但是由于dubbo数据包attachment在整个数据体的最后,反序列化成本较高,需要关注下性能。还有一点是一般dubbo服务sdk比较难去掉,和 Istio功能重合太大了。不太了解aeraki这个项目。社区可以邀请项目的人来分享。

IRA开源吗?

答:这个服务通过istio的configController机制完成,代码量不大,目前还没开源。

Mesh外的服务怎么访问Mesh内的服务?走Mesh的Ingess gateway 吗?

答:分享中已经提到,我们通过register-helper sidecar容器,保留了迁移过程中mesh外服务通过注册中心访问网格内服务的能力。完成迁移后可以将该sidecar去掉。当然网格外的服务通过ingress也是能够访问网格内的服务的。

请问接入Istio需要开发介入什么操作变更,当前架构为Spring Cloud,注册中心为nacos/eureka,95%应用在Kubernetes上,现在需要用到流量控制,ingress gateway,熔断,限流等功能。

答:如果迁移设计的比较完美,其实可以做到开发零介入。比如我们的实践,大多数java服务只需要引入一个java架包就可以。这个包中你可以将原来java服务底层的register sdk屏蔽,并且去除loadbalace逻辑,保留上层的接口。减少开发的接入成本,也方便Istio的推广。

上网格后springcloud consumer是否需要手动修改每个provider地址为Kubernetes service name?

答:这个建议是要替换的。但是有很多比较优雅的方式,详细见分享。

能分享下目前用wasm主要做了哪些事么?稳定性和性能方面怎么样?

答:对流量打标处理,方便后续进行route分发。由于是使用在sidecar而不是ingress上,性能上面并没有问题。稳定性需要使用者来保证了,wasm插件切不可出错,否则会影响所有流量。

目前Istio控制面管理不友好,如果不通过自研方案的话有什么推荐么?yaml方面,目前看没有很好的gui配置。

答:社区比较主流的有kiali,如果企业支持,可以参考下一些企业支持版的Istio版本,比如GetIstio。

什么样的业务或者场景适合上Istio,运维工程师该注意那些点,是否有很好的方案供参考,运维如何和开发配合完善推进上Istio,我们的业务是支付打款相关的,目前是.Net。

答:Istio适不适合其实和业务关系不大,和历史技术架构关系比较大。运维工程师和开发接受Istio架构需要比较大的学习成本。如果对这个有信心,那么并没有大问题。至于.Net还是其他语言关系并不大,毕竟Istio是语言无关的。