本文整理自酷家乐技术专家付铖（花名：橙子）在 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 上的协议转换，以及调用链信息存储之后的一个简单转换器，我们实现了两个调用链中间件的完全兼容，开发者最终在公司内部的调用链查询工具上，可以直接查询到串在一条链上、来自两方服务的调用链信息。
类似的，我们通过一系列尽量低成本的措施，将监控、调用链、服务发现、服务注册等体系完成了前后兼容，适配了公司内原有的基础设施，避免挑战用户认知。
另外，我们在实践中，也通过服务网格控制面板给予的高度配置化的流量管理能力，用很简单的配置完成了网格内的灰度发布。不需要额外的开发，两个配置即可实现：
- 配置根据业务需求的规则 (例如特殊 header, userid 尾号 或者 cookie 里面的值) 判断流量分类
- 给需要灰度发布的服务版本打上特殊 label，让某分类的流量只能发到特殊 label 的实例上，找不到特殊实例则走默认实例
这样配置之后即可达到，有灰度走灰度，无灰度走默认，可以进行多层灰度的灰度体系。
Istio 暴露的问题
在初步接触服务网格概念的时候，大多数人的第一个疑问就是，这不会造成性能的严重下降吗？这也一直是我们比较关注的问题。
经过长期的使用，以及多次针对性的测试之后，我们得出了如下结论：
- 对于一般场景，使用服务网格只是将原来在业务代码中的中间件逻辑和运算，转移到了服务网格体系中。这里具体的性能变化，取决于原来的中间件体系和服务网格中使用的中间件体系的性能效率，所以不同公司和不同业务下，性能到底是下降了，还是提高了，是不一定的，可以实际落地测一下才知道。如果单纯只考察 " 固定资源上限的业务领域内的性能 "，那么使用服务网格显然会有一个性能提升；
- 对于流量管理、安全管理复杂的场景，跳数上升，在大规模场景中可能有技术挑战。经过我们的测试评估，在超大规模场景中，Istio 会暴露出 Mixer 组件性能瓶颈。针对这一点，Istio 开发社区有架构优化的计划；蚂蚁金服团队在大规模落地 MOSN 的时候也有一些针对性的解决方案；也有其他团队在面临这一问题时，也可选择全部关闭或部分关闭 Mixer 功能；
Istio 的使用总结
我们针对 Istio 一年多以来的实践，可以总结的经验如下：
- 已经可以稳定用在生产环境；
- 工程架构收益 >> 性能资源损耗；
- 根据组织和业务情况推广或改造，新旧体系可并存；
- 超大规模应用，架构问题有待社区或业界解决；
为什么使用 Knative
使用 Knative 作为 Faas 或者说 Serverless 的基础设施，这是国内的技术团队较为主流的做法。大家希望从 knative 中拿到的价值主要有这样了两个：
- 免除云服务供应商锁定。相对于 AWS lambda 必须使用 AWS 上多个其他组件，造成巨大迁移壁垒，knative 至少是云服务商中立的，控制权在自己手上。
- 自动扩容和缩容至零实例。极致的弹性带来了两个直观结果: 运维成本大大降低、硬件成本降低。
到目前为止，不同的公司在如何将上述价值变现为组织能力的时候，做出了非常不同的选择。在酷家乐业务体系内，我们的思路是这样的：
- 较大的控制权，让我们能将 Knative 的能力深度绑定到我们的内部架构和流程中，自由度由我们控制，而跟云服务商无关；
- 远低于原来的运维成本，让我们可以首次把创建、修改后端的业务逻辑和计算资源的能力，直接开放给前端团队、客户、合作伙伴，让他们的后端代码运行在我们系统内；
- 通过内部设施的改造和优化，通过强化 " 按单个 API 进行部署和管理 " 策略，甚至可以进一步降低函数、API 的创建成本，达到 WebIDE 或图形化拖拽的程度，进一步赋能给更多内外部团队 (非工程师)；
- 赋能了不同职能的成员，就可以减少前台业务的人力占用，降低沟通成本，让前台业务跑得更快；
说起来很抽象，下面举一个例子帮助大家理解:：
下图左侧是一个典型的管理系统的界面（从网上找的图），左侧是菜单栏，顶部是一些通用信息，中间是大块的各个模块数据展示。在通常的微服务架构下，后端服务往往是单一职责的，例如有一个 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）。
原文链接：
评论