严选应用的云原生演进实践 | 每周技术干货

2019年初，严选的服务数量已经近千，系统越来越庞大。为了能更好地支撑上业务的蓬勃发展，严选团队和网易数帆旗下的网易轻舟团队开启了云原生平台的共建项目，以此拉开了严选应用云原生演进的帷幕。本文主要从严选的视角介绍一下相关的实践过程。

1. 背景

Cloud Native 这个名词最近几年一直很火，Pivotal和CNCF 都出过相关的定义，但本质都是为了引导应用在业务日益复杂多变的场景下可以更好地利用云基建，做到更加敏捷高效。2019年初，严选的服务数量已经近千，系统越来越庞大。为了能更好地支撑上业务的蓬勃发展，严选团队和网易轻舟团队开启了云原生平台的共建项目，以此拉开了严选应用云原生演进的帷幕。本文主要从严选的视角介绍一下相关的实践过程。

对于严选来讲，将应用逐步演进到云原生的核心在于：“简化”，主要体现在以下三个方面：

• 以服务网格的演进，实践中间件下沉到基础设施：简化应用内的非业务逻辑。

• 通过容器化，落地不可变基础设施：简化应用所处执行环境的搭建和维护。

• 实践基于云的DevOps：简化应用在不同周期阶段内的流转复杂度。

在整体演进中，我们主要从以下几个方面去考虑实施方案：

• 标准化：一方面用于偿还部分历史遗留的技术债务；另一方面为不可变基础设施的落地做好铺垫。

• 减少源码变更：降低迁移成本，保障业务正常迭代，同时也能减少由于迁移引入的bug

• • 基础设施适配，业务弱感知完成迁移

• 高可用的平滑迁移：为线上业务的可靠性保驾护航

• • 发布平台赋能业务迁移高可用：灰度引流、版本分流

  • 基于边缘网关的混合云方案：云内外自动兜底，实现业务逐步平滑迁移上云

• 性能调优：面对由于服务网格，异地机房等带来的性能挑战

• • 引入sr-iov容器网络，降低sidecar转发带来的损耗

  • 突破istio原生性能瓶颈：利用遥测数据进行自动配置瘦身

2. 实践

应用演进的关键点基本都围绕着Heroku 提出的12-factor展开，整体的演进节奏类似于建造一座大楼。

2.1 第一阶段

“打地基”：以严选DevOps项目作为主线，在异构的底层设施上构建近似的应用执行环境，弱化业务应用对基础设施的直接感知。

• CMDB：从服务出发，管理人员、服务、资源三者之间的关系，使上层应用可以用统一的抽象概念看待云内和云外不同的底层资源和基础设施。（参见： ）

• Opera：以制品为中心，在制品上贯彻云原生“不可变基础设施”的理念，同一制品贯穿测试、回归、线上等环境的全生命周期。同时统一部署流水线，统一发布依赖、发布流程、发布脚本的编排，为应用在云内、云外不同环境下的部署行为提供相同的功能和操作习惯，降低迁移时的学习成本。

• 日志平台：提供了日志实时采集、分流、数据投递与存储的全流程能力，同时提供日志质量检查及查询分析能力，全面提升严选的数据质量与海量日志处理/分析能力，特别是对于容器环境下组件众多，依赖复杂的场景，一套高效的日志处理系统能为业务应用的日常监控、异常诊断带来必需的安全感。

• ServiceMesh：实践中间件下沉的核心抓手。严选服务端原先有基于consul+nginx 实现的简版服务网格，该架构无法与k8s、docker等云基础设施有效融合，因此在云内选用了istio作为实施标准。（参见： ）

2.2 第二阶段

“做框架”：在第一阶段的基础上，选择基础技术服务和部分B端业务应用作为落地的试点，完成服务容器化方案的框架指引。

• 工程改造指引：包含基础镜像规范、CI标准规范等，采用平台方式，逐步将这些规范收归到职能团队，避免不同研发团队的随意发挥。

• 部署验证指引：包含资源、权限申请流程、灰度验证流程规范、回收流程等，确保流程依赖的正确性，并基于标准流程构建自动化流水线，从而达到效率提升的目标。

• 流量管控（API网关，参见：）

• • 数据面：和轻舟协作，构建基于envoy的API网关，将原本严选API网关的一些能力以插件形式移植到了云原生网关中，保证了业务所需。

  • 控制面：改造原有严选的管理平台，适配轻舟API，确保用户使用习惯尽可能保持一致，同时减少了严选内部其他依赖网关的管理系统的变更。

2.3 第三阶段

“建管道”：Backing Service云化，服务治理能力深入，开始试点一些延迟敏感型的活动类业务应用改造。

• Backing Service云化

• • DB、缓存、MQ这几个核心的Backing Service切换到云内，一方面降低异地机房带来的性能损耗，另一方面也能有更高效的扩缩容流程

  • 通过严选自研的中间件可以在应用不需要重启的情况下，将应用所依赖的这些支撑服务动态地从云外资源切换到云内资源。

• 服务治理能力深化

• • Service Mesh调优：

  • • 实现热升级机制，避免sidecar更新时对业务应用的影响；

    • 增加灰度发布机制，降低网格更新时的风险；

    • 提供配置瘦身功能，降低大量节点场景下配置更新时的性能损耗。

    • 引入基于sr-iov容器网络的高性能节点

  • 强化SNest 服务门户：将底层从定义、生命周期、版本、迁移、注册、监控、所有权等多个方面的服务治理能力层统一进行包装和暴露，提升日常使用时的效率。（参见：）

• C端活动的上云试点，作为上述两个方向能力发展的验证落地，已经准备好应对双11大促的流量。

2.4 第四阶段

“搭房间”：开启线下环境的治理（该阶段和第三阶段会有部分重叠），由点到面地推进演进范围；扩大应用云化后的收益，例如：自动化地按需快速扩缩容。

• 开发环境构建

• • 纯粹的云内环境，既能为基础设施提供测试验证环境，也方便业务应用尝试云原生的改造，并且资源灵活可控。

• 回归环境构建

• • ‍完整模拟异地机房、云内云外异构基础设施的应用混布环境，提供接近线上的基础设施场景，为业务应用在大规模演进过程中保驾护航。

  • 作为严选环境治理的先锋任务，回归环境的构建在逐步试错和探索过程中前行。经历了量化目标、梳理落地方案、具体的规划集群、基建梳理、业务梳理、环境数据构造等各种环节，困难重重也获益良多。（参见：）

‍

3. 一些“收获”

如影随形的“IP地址”：应用中对ip的使用习惯几乎渗透到了每个服务，从最基本的远程调用，到简单又有效的鉴权场景，也有用于生成分布式id之类的。

• 容器化时的第一步就是先引入IPRange机制，确保类似数据库这些当前还是强依赖IP鉴权的服务能正常运作。

• 基于IP的服务调用方式，需要切换到根据域名或者依赖service-mesh机制的服务调用路由

• • 这方面严选由于很早就已经启用了服务网格的机制，因此改造代价不高，直接的IP地址主要集中在类似缓存，mq之类自身有负载均衡策略的第三方组件。

• 基于IP的服务鉴权场景，由于涉及到的服务众多，这块的改造成本是最大的。目前严选的做法是为每个服务颁发身份Token，利用服务网格的sidecar进行注入，需要鉴权的服务从原本针对ip的逻辑改为针对token的逻辑。整个token的签发和注入对上层应用都是透明的，即减轻了改造成本，也能尽量避免token的泄露。

• 其他基于ip地址构建分布式id，任务分配等场景，就只能根据服务逻辑一一进行改造了，但这些涉及到的服务不多，整体改造成本可控。

系统整体的可观测性

• 整个基础设施的复杂度提高了很多，不少环境对应用来讲变成黑盒了；一些以往登录虚拟机上进行诊断之类的习惯做法也无法沿用。

• 最常见的服务之间调用有点小问题，也不得不喊上网关或者服务网格的同事协助排除。

• 容器化后对于整个监控体系，异常诊断体系都是一场大考，很容易发现原本工具链中的盲点，不得不靠人肉先顶上。

• 严选在实践中会和轻舟做数据打通：把关键组件的日志、关键报警、k8s的重要事件等收纳到自身的监控体系内，从而丰富应用维度能感知到的信息。此外，正在和轻舟协作一起实践全链路故障的定位诊断服务。

对团队的影响

• 业务开发：现阶段最大的可感知收益在于扩缩容的效率，云内可以做到秒级的资源变更，在大促、重要活动等场景下能够快速达成资源诉求。同时对基础设施整体工具链提出了更迫切的需求。

• Infra开发：在设计上需要更深入地分层，更多地思考采用非侵入式的实现，做好中间件的“下沉“ ，并解决下沉后带来的性能损耗。

• QA：可以更灵活地调配资源用于线下环境治理，与运维配合保障各环境的一致性。同时负责在CI/CD流程中做好规范的落地，避免应用标准腐化。

• 运维：对基础设施的管控能力有所提升，从而能够在资源管控的精细化和全面自动化方面有更为广阔的提升空间。

4. 后继计划

目前严选已累积上云300+服务，每天支撑业务百亿次调用; CICD接入率99%以上，平均每天通过基于容器云的高可用的gitlab runner进行ci pipeline构建数千次，整体提升研发效能200%+。

环境治理是当前的重点，我们会进一步完善回归环境，为后继性能敏感型应用的演进提供更全面的验证环境，同时将会尝试利用服务网格特性，构建基于服务版本的测试环境治理，提升数据共用场景下的业务集群快速构建效率。

对于严选应用来讲，云原生的演进之路才刚刚走离泥泞小路，前面的路会越来越宽，也会有更大的挑战，需要不断前行！

作者简介

Saga， 网易严选基础技术部技术总监，负责严选技术中后台建设，目前专注在业务中台、DevOps等效能提升方向的体系搭建和发展。

本文转载自“严选技术团队”公众微信号