Istio在UAEK中的实践改造之路

经过分析定位，发现Telemetry内存上涨的原因是数据通过各种后端Adapter消费的速率无法跟上Envoy上报的速率， 导致未被Adapter处理的数据快速积压在内存中。我们随即去除了Istio自带的并不实用的stdio日志搜集功能，这一问题随即得到极大缓解。幸运的是，随着Istio1.0的发布，Telemetry的内存数据积压问题得到解决，在相同的测试条件下，单个Telemetry实例至少能胜任3.5W QPS情况下的数据搜集上报。

问题、希望与未来

历经重重问题，一路走来，一个生产环境可用的ServiceMesh终于在UAEK环境上线了。在这一过程中，也有部门内其他团队受UAEK团队影响，开始学习Istio的理念并尝试在项目中使用Istio。然而，目前的现状离我们的初心依然存在差距。

Istio依然在高速迭代中，无论是Istio本身还是Envoy Proxy，每天都在演进更新。每一次版本更新，带来的都是更为强大的功能，更为简练的API定义，同时也带来了更复杂的部署架构。从0.7.1到0.8，全新的路由规则v1alpha3与之前的API完全不兼容，新的virtualservice与原先的routerule截然不同，给每位使用者构成了不少麻烦。

如何完全避免升级Istio给现网带来负影响，官方依然没有给出完美平滑的升级方案。此外，从0.8到1.0虽然各个组件的性能表现有显著提升，但从业内反馈来看，并没令所有人满意，Mixer的Check缓存机制究竟能多大程度缓解Policy的性能压力依然需要观察。

值得一提的是，我们发现的不少bug同时也在被社区其他开发者发现并逐一解决。令我们开心的是，UAEK团队不是信息孤岛，我们能感受到Istio官方社区正在努力高速迭代，始终在致力于解决广大开发者关心的种种问题，我们提交的issue能在数小时内被响应，这些，都让我们坚信，Istio是一个有潜力的项目，会向Kubernetes一样走向成功。

从UAEK接入用户的经验来看，用户需要正确地使用好Istio离不开前期深入的Istio文档学习。UAEK后续需致力于要简化这一过程，让用户能傻瓜化、界面化、随心所欲地定制自己的路由规则成为我们下一个愿景。

UAEK团队始终致力于改革UCloud内部研发流程，让研发提升效率，让运维不再苦恼，让所有人开心工作。除了继续完善ServiceMesh功能，下半年UAEK还会开放更多的地域和可用区，提供功能更丰富的控制台，发布自动化的代码管理打包持续集成(CI/CD)特性等等，敬请期待!

作者介绍

陈绥，UCloud资深研发工程师，先后负责监控系统、Serverless产品、PaaS平台ServiceMesh等开发，有丰富的分布式系统开发经验。

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!