QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

酷家乐的 Istio 与 Knative 实践

  • 2020-01-11
  • 本文字数:3389 字

    阅读完需:约 11 分钟

酷家乐的 Istio 与 Knative 实践

本文整理自酷家乐技术专家付铖(花名:橙子)在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。


相关活动内容请参考: https://www.servicemesher.com/blog/service-mesh-meetup-hangzhou-20191228/


自酷家乐技术团队自 2018 年上半年开始在部分业务使用 Istio 作为服务网格组件以来,我们实践了很多服务网格的技术特性,并与相关业务结合起来;在 2019 年下半年,也开始初步尝试使用 Knative 搭建内部团队的 Faas(函数即服务基础设施),并已经在内部实验性使用。期间积累了一手的实践经验,当然也踩了不少坑。本次分享,我们的重点内容是 Istio 和 Knative 组件的价值,我们是如何在酷家乐实际的场景中落地的,以及使用下来发现的问题是什么。



COOHOM(酷家乐英文名)是 Istio 认证用户

为什么使用服务网格



我们认为,服务网格带来的最大价值,莫过于将大部分中间件抽到了业务代码之外。中间件的载体从原来的业务上的依赖包,变成了跟业务无关的"边车(Sidecar)"。


有了这一隔离和抽象,业务代码和中间件终于可以各自独立维护,免于"同床异梦"了。以下几种情况,可以在很大程度上避免:


  • 中间件团队需要给各种不同的语言和终端开发齐全的中间件依赖,有的业务团队就算想尝试使用新的语言,也必须等待中间件配套。随着业务代码和中间件隔离,只要业务团队愿意,他们可以切换自己业务的实现;

  • 当中间件团队有一些大型更新需要全量推广时,需要挨个找业务团队“协调”、“推进”。道理同上,隔离后可以单独变更,理论上做到对业务透明;

  • 部分 Bug 归属不清。在某些情况下,查错更清晰;

应用 Istio

对于一个已经有些年份的中型创业公司,任何变化和升级都不是一夜之间完成的,使用服务网格也不例外。所以我们在应用服务网格时候,重点关注如何将服务网格体系与非服务网格体系做打通、兼容。


例如,我们通过一个双向的 Gateway,去识别两个服务体系内的服务地址,完成服务注册与发现的兼容。



又例如,针对调用链收集(链路追踪),在服务网格体系内我们使用了开箱即用的 jeager,通过在双向 Gateway 上的协议转换,以及调用链信息存储之后的一个简单转换器,我们实现了两个调用链中间件的完全兼容,开发者最终在公司内部的调用链查询工具上,可以直接查询到串在一条链上、来自两方服务的调用链信息。



类似的,我们通过一系列尽量低成本的措施,将监控、调用链、服务发现、服务注册等体系完成了前后兼容,适配了公司内原有的基础设施,避免挑战用户认知。


另外,我们在实践中,也通过服务网格控制面板给予的高度配置化的流量管理能力,用很简单的配置完成了网格内的灰度发布。不需要额外的开发,两个配置即可实现:


  1. 配置根据业务需求的规则(例如特殊 header, userid 尾号 或者 cookie 里面的值)判断流量分类

  2. 给需要灰度发布的服务版本打上特殊 label,让某分类的流量只能发到特殊 label 的实例上,找不到特殊实例则走默认实例


这样配置之后即可达到,有灰度走灰度,无灰度走默认,可以进行多层灰度的灰度体系。


Istio 暴露的问题

在初步接触服务网格概念的时候,大多数人的第一个疑问就是,这不会造成性能的严重下降吗?这也一直是我们比较关注的问题。


经过长期的使用,以及多次针对性的测试之后,我们得出了如下结论:


  • 对于一般场景,使用服务网格只是将原来在业务代码中的中间件逻辑和运算,转移到了服务网格体系中。这里具体的性能变化,取决于原来的中间件体系和服务网格中使用的中间件体系的性能效率,所以不同公司和不同业务下,性能到底是下降了,还是提高了,是不一定的,可以实际落地测一下才知道。如果单纯只考察"固定资源上限的业务领域内的性能",那么使用服务网格显然会有一个性能提升;

  • 对于流量管理、安全管理复杂的场景,跳数上升,在大规模场景中可能有技术挑战。经过我们的测试评估,在超大规模场景中,Istio 会暴露出 Mixer 组件性能瓶颈。针对这一点,Istio 开发社区有架构优化的计划;蚂蚁金服团队在大规模落地 MOSN 的时候也有一些针对性的解决方案;也有其他团队在面临这一问题时,也可选择全部关闭或部分关闭 Mixer 功能;


Istio 的使用总结

我们针对 Istio 一年多以来的实践,可以总结的经验如下:


  • 已经可以稳定用在生产环境;

  • 工程架构收益 >> 性能资源损耗;

  • 根据组织和业务情况推广或改造,新旧体系可并存;

  • 超大规模应用,架构问题有待社区或业界解决;

为什么使用 Knative

使用 Knative 作为 Faas 或者说 Serverless 的基础设施,这是国内的技术团队较为主流的做法。大家希望从 knative 中拿到的价值主要有这样了两个:


  • 免除云服务供应商锁定。相对于 AWS lambda 必须使用 AWS 上多个其他组件,造成巨大迁移壁垒,knative 至少是云服务商中立的,控制权在自己手上。

  • 自动扩容和缩容至零实例。极致的弹性带来了两个直观结果: 运维成本大大降低、硬件成本降低。


到目前为止,不同的公司在如何将上述价值变现为组织能力的时候,做出了非常不同的选择。在酷家乐业务体系内,我们的思路是这样的:


  1. 较大的控制权,让我们能将 Knative 的能力深度绑定到我们的内部架构和流程中,自由度由我们控制,而跟云服务商无关;

  2. 远低于原来的运维成本,让我们可以首次把创建、修改后端的业务逻辑和计算资源的能力,直接开放给前端团队、客户、合作伙伴,让他们的后端代码运行在我们系统内;

  3. 通过内部设施的改造和优化,通过强化"按单个 API 进行部署和管理"策略,甚至可以进一步降低函数、API 的创建成本,达到 WebIDE 或图形化拖拽的程度,进一步赋能给更多内外部团队(非工程师);

  4. 赋能了不同职能的成员,就可以减少前台业务的人力占用,降低沟通成本,让前台业务跑得更快;


说起来很抽象,下面举一个例子帮助大家理解::


下图左侧是一个典型的管理系统的界面(从网上找的图),左侧是菜单栏,顶部是一些通用信息,中间是大块的各个模块数据展示。在通常的微服务架构下,后端服务往往是单一职责的,例如有一个 API 获取用户信息,一个 API 获取该用户的菜单栏权限,以及各个不同的数据模块提供的本模块数据 API。这会导致一个前端页面需要调用十几个乃至几十个不同的后端请求。如果要优化这一点,产出一个按照业务逻辑聚合起来的 API,免不了前端后端工程师走一遍确认需求-协商 API 定义-分头开发-等待双方均完成开发-联调-测试-上线才能完成。如果我们能把上述活动变成只需一个人可以独立完成,则可以大大减少沟通成本和时间成本。这就是我们希望带给内部团队、外部客户和合作伙伴的价值。


落地 Knative

在实际落地中,我们推进比较谨慎,目前只限定在聚合层 API 的实现上,运行时也只支持了 Nodejs。



(图中 F 代表 Function,S 代表 Service 也就是传统微服务)


通过几个月来的研究使用,我们基本摸清了现在版本(v0.9)下 Knative 的一些性能数据:



在万全的情况下(镜像预热,镜像文件极小,使用启动速度最快的运行时),从调用触发到新的 pod 拉起来并服务这个调用请求,也仍然需要 3.6 秒。在 HTTP API 的场景下,我们认为这个冷启动时间还未达到我们的预期。故在使用中,目前建议采用 pod 预热,pod 共用或者驻留一个 pod 的形式来规避。另外,Knative 社区也在积极处理这个问题,他们单独设立了一个 project 来追踪冷启动时间问题,这个项目的目标是将冷启动时间减少到一秒以内。


我们认为,Knative 大规模落地,还存在以下几个问题:


  • 尚未发布 1.0 版本,不能说 Production-ready;

  • Queue-proxy 这一 Sidecar 资源占用有点多,需要瘦身;

  • 冷启动时间需要缩短;

Knative 使用总结

4 个多月的 Knative 实践,我们认为:


  • 它是一个非常有发展前景的开源组件,胜过其他的 Serverless 框架;

  • 深入掌握后可谨慎使用;

  • 目前社区规模尚小,开发者和使用者都需要扩容;


分享内容到这里就结束了。笔者最后想谈的一点是:云原生坡长雪厚,前景广阔,值得投资。在业务型团队中,要不断去发掘云原生落地释放出来的技术红利,帮助业务,促进业务,而不是为了落地而落地。

本期分享视频回顾

https://tech.antfin.com/community/activities/1056/review/963


作者介绍


酷家乐技术专家付铖(花名:橙子)先后负责酷家乐户型图、渲染引擎等模块,目前负责酷家乐国际站的研发。在业务开发过程中推动和布道云原生技术,并在部分业务落地了 Istio 服务治理和基于 Knative 的 Serverless 基础设施。


本文转载自公众号 ServiceMesher(ID:ServiceMesher)。


原文链接


https://mp.weixin.qq.com/s/LN4_lkHzGGYa3GrFa7osuQ


2020-01-11 10:004330

评论

发布
暂无评论
发现更多内容

2024年首期OpenHarmony繁星计划师资培训在东莞圆满举办

新消费日报

秒级响应,显著增效:明日控股携手奇点云,打造大宗贸易的数据中台标杆

极客天地

Nop入门:极简数据访问层开发

canonical

mybatis 低代码 ORM graphql

听GPT 讲Rust源代码--compiler(30)

fliter

在线 cURL 参数对比工具,让你的开发工作更加高效

秦少卫

curl 接口工具 调试工具 请求参数对比 参数格式化

Programming Abstractions in C阅读笔记:p258-282

codists

HDFS 小文件合并最佳实践

冰心的小屋

NameNode 海量小文件

Ableton Live如何设置中文?ableton live 11 mac中文破解版 永久可用

Rose

mac音乐制作软件 Ableton Live 11破解版 Ableton Live 11中文版

物流快递电子面单对接规则指南

快递鸟

电子面单

点赞!HashData连续三年获评数据猿“最具投资价值企业奖”

酷克数据HashData

【豆瓣9.1】《大数据处理框架Apache Spark设计与实现(全彩)》PDF

程序员李木子

【新手视频】在线快速搭建AI原生应用

AI大咚咚

百度 AI rag AI原生应用 Agent构建

【豆瓣8.4】《RabbitMQ实战指南》PDF

程序员李木子

C# 面向对象编程解析:优势、类和对象、类成员详解

小万哥

C# 程序人生 编程语言 软件工程 后端开发

最强GTD时间管理工具OmniFocus Pro 3 for Mac最新激活版 附注册机 兼容M1/M2

Rose

苹果软件 OmniFocus 下载 Mac任务管理器 OmniFocus Pro 3 GTD时间管理

上市难不上市更难,谁能佐证中国企服的光明前途?

ToB行业头条

产品经理需要掌握哪些技能?一文弄懂PM的方方面面!附知识图谱

彭宏豪95

产品经理 产品设计 PM 在线白板 团队协同

Nop入门:极简服务层开发

canonical

gRPC 低代码 graphql SpringBoot3

Programming Abstractions in C阅读笔记:p254-p257

codists

Atlassian 停服 Bitbucket?三步快速迁移至极狐GitLab

极狐GitLab

hazel mac破解版 自动化文件清理工具 含hazel激活码 兼容m1 m2

Rose

苹果软件资源 Hazel 下载 Mac自动清理工具 Hazel Mac破解版

文心一言 VS 讯飞星火 VS chatgpt (187)-- 算法导论14.1 4题

福大大架构师每日一题

福大大架构师每日一题

【Linux技术专题】「夯实基本功系列」带你一同学习和实践操作Linux服务器必学的Shell指令(深入Kill指令探索)

码界西柚

Linux Shell 2024年第二十二篇文章 技术指令

酷家乐的 Istio 与 Knative 实践_软件工程_付铖_InfoQ精选文章