| description |
|---|
《Istio 大咖说》第 2 期，2021 年 6 月 2 日，嘉宾潘天颖，话题《从微服务架构到 Istio——架构升级实践分享》。 |
- 时间：2021 年 6 月 2 日晚 8 点
- 主持人：宋净超（Tetrate）
- 嘉宾：潘天颖（小电科技）
- 嘉宾介绍：小电科技工程师，云原生爱好者，Kubernetes contributor，Apache committer。
- 直播间：https://live.bilibili.com/23095515
- 视频回放：https://www.bilibili.com/video/BV1QQ4y1X7hP/
- 幻灯片归档：GitHub
云原生赛场已经进入了下半场的比拼，Istio 作为服务网格赛道上的明星选手，社区活跃度和用户知名度都位列前茅。但是国内环境下 Istio 的落地实践却并不多。是什么阻碍了 Istio 的落地，到底 Istio 好不好用？到底什么情况下使用 Istio 利大于弊？本次我们将站在企业用户角度上，邀请了潘天颖分享 Istio 在小电科技的完整落地经验，讲述为什么要从传统微服务架构迁移至服务网格架构，其中遇到的困难与解决方法，以及针对 Istio 的改进方案。
扫描上图中的二维码可以跳转到《Istio 大咖说》的 B 站直播间，或者直接访问：https://live.bilibili.com/23095515 点个关注，不迷路。
你还可以扫描上图中的二维码在腾讯文档中参与直播互动，我们将会在直播最后送出由机械工业出版社赞助的《Quarkus 实战》和《Knative 实战》书籍。
- 了解 Istio 现状以及使用 Istio 的利弊分析
- 讲述一次完整的服务迁移至 Istio 实践，可供借鉴
- 了解一些在使用 Istio 中经常会遇到的典型 Issue 以及解决方案
请问刚参加工作的应届生，工作涉及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 jar包就可以。这个包中你可以将原来java服务底层的register sdk屏蔽，并且去除loadbalace逻辑，保留上层的接口。减少开发的接入成本，也方便Istio的推广。
上网格后springcloud consumer是否需要手动修改每个provider地址为Kubernetes service name?
答：这个建议是要替换的。但是有很多比较优雅的方式，详细见分享。
能分享下目前用wasm主要做了哪些事么？稳定性和性能方面怎么样？
答：对流量打标处理，方便后续进行route分发。由于是使用在sidecar而不是ingress上，性能上面并没有问题。稳定性需要使用者来保证了，wasm插件切不可出错，否则会影响所有流量。
目前Istio控制面管理不友好，如果不通过自研方案的话有什么推荐么？yaml方面，目前看没有很好的gui配置。
答：社区比较主流的有kiali，如果企业支持，可以参考下一些企业支持版的Istio版本，比如TSB。
什么样的业务或者场景适合上Istio，运维工程师该注意那些点，是否有很好的方案供参考，运维如何和开发配合完善推进上Istio，我们的业务是支付打款相关的，目前是.Net。
答：Istio适不适合其实和业务关系不大，和历史技术架构关系比较大。运维工程师和开发接受Istio架构需要比较大的学习成本。如果对这个有信心，那么并没有大问题。至于.Net还是其他语言关系并不大，毕竟Istio是语言无关的。