简介： 考拉海购的整个云化革新是从 2019 年 10 月份开始的，过后的惟一指标就是短时间内疾速实现迁徙。在不到 4 个月的工夫里，考拉团队惟一思考的是如何以最快的速度完成使命，云原生是咱们抉择的最合适的一条路。

前言

考拉海购的整个云化革新是从 2019 年 10 月份开始的，过后的惟一指标就是短时间内疾速实现迁徙。在不到 4 个月的工夫里，考拉团队惟一思考的是如何以最快的速度完成使命，云原生是咱们抉择的最合适的一条路。

实际历程

本篇次要从第三阶段的云产品接入和第四阶段运研模式的降级来谈谈考拉海购的实际过程。

云产品接入

1. 云原生产品定义

云原生实质上是一套技术体系和方法论。随着容器技术、可继续交付、编排零碎等技术的倒退，同时在开源社区、散布式微服务等理念的带动下，利用上云曾经是不可逆转的趋势。真正的云化不仅仅是基础设施和平台的变动，利用自身也须要做出扭转。在架构设计、开发方式、利用运维等各个阶段基于云的特点，面向开源和标准化，建设全新的云化的利用，即云原生利用。

云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。依据 CNCF 的定义，云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。阿里云提供了音讯队列产品，如音讯队列 RocketMQ 版、音讯队列 Kafka 版等，利用实时监控服务 ARMS，微服务引擎 MSE，利用高可用服务 AHAS，性能测试 PTS，函数计算 FC 等中间件云原生产品，为考拉海购从传统利用向云原生利用演进，打下了松软的根底。

2. 心路历程

咱们在云产品的接入过程中，大抵在心态上经验了三个阶段。

1）第一阶段：很好、很弱小，接入效率杠杠的

这部分次要是在 2019 年 10 月 – 2020 年 3 月之前，那时候接入的都是数据库、Redis，以及 ASI 这种产品，绝对用户比拟多，整体比较稳定，与开源产品基本上齐全兼容，迁徙工具及周边建设都比较完善，所以迁徙起来十分安稳，基本上改变一部分点就能够了。

2）第二阶段：云产品真丰盛，要啥都有

以前很多组件还是咱们本人保护的，然而随着连贯实例的减少，读写的次数多了，时不时呈现宕机。那时候据说微服务引擎 MSE 很好用，它提供一站式微服务能力加持，包含微服务依赖组件托管、无侵入的微服务治理，更快捷、稳固、低成本的运行微服务。咱们找了下 MSE 的兄弟，他们拍着胸口说没问题，产品运行之后真的就没呈现过那些问题了。

像这样的例子还很多，那时候的感触是，只有真正体系化地去应用云原生产品，你才会对云原生的价值有更粗浅的感触。

3）第三阶段：磨合适应

随着考拉海购开始接入团体的业务平台，供应链也开始和团体进行交融，咱们也进一步发展云化的历程。过程中也有挑战，不过在克服重重困难后，咱们如期完成了各项的革新，并且十分安稳的度过了几次大促，云原生产品十分好地撑持了考拉海购业务的增长。

3. 接入的过程

1）接入策略

因为云产品和考拉海购自建的产品有肯定的能力差异，所以咱们建设了一整套产品评估和接入试验田机制来保障整个接入的有序及性能的可迁移性，正是这套机制的良好运行，咱们整个的稳定性失去了保障，在整个根底大变动中都没有呈现大的故障。

咱们的整个保障流程如下图:

2）权限计划

接入云产品面临的第一个问题是，云账号，云产品资源权限怎么治理？阿里云自身提供了 RAM 产品，作为治理用户身份与资源拜访权限的服务。那么 RAM 账号如何何员工身份关联？

• 是为每个产品申请一个子账号，所用人共用该子账号？
• 还是为每个人申请一个 RAM 子账号，独自为每个人治理资源权限？
• 或者为利用申请一个子账号，通过员工的利用权限来和子账号的资源权限做关联？

考拉海购有几百人，计划 2 和 3 都面临着很高的子账号生命周期以及资源权限的治理老本，所以咱们初期在应用这些中间件云产品时，出于简略思考，都采纳了第一个计划——申请一个子账号，开发一起用。

其带来的问题就是资源权限粒度太粗，比方应用任务调度（SchedulerX) ,  登录到控制台就能够操作所有利用的所有工作，这对于平安生产来说，自身就是一件很危险的事件。所以为了利用平安，咱们向中间件云产品提的第一个需要，基于 RAM 提供按利用粒度做资源受权的能力。

考拉海购用户在登录云控制台时，感知不到 RAM 账号。在基于 RAM 云产品  STS（Security Token Service）的能力，封装了一层简略的云控制台跳转长期受权，在生成 STS Token 时，依据 BUC 获取以后用户，并生成和指定一个额定的权限策略，限度该用户操作云资源（利用）的权限。登录页面如下图：

SchedulerX 也基于 STS 的能力，通过 RoleSessionName 来和员工身份关联，实现权限治理操作。当然，这个只是临时的计划，能帮考拉海购解决一部分问题，最终的解决方案还是要靠全局来解，这部分当前咱们再谈。

3）音讯计划

迁徙指标：

考拉海购音讯体系基于音讯队列 Kafka、音讯队列 RabbitMQ，在其上自研了事务音讯核心和提早音讯产品满足业务丰盛的音讯需要。通过调用云上音讯队列 RocketMQ 产品，发现其能完满的兼容、反对考拉海购现有的残缺的音讯体系，可能提供足够的性能保障、稳固行保障，并且额定提供反对了音讯轨迹和音讯查问的性能，对业务应用上更加敌对。

施行过程：

整体迁徙波及考拉海购上百工程，无奈进行对立工夫上的安顿革新，所以针对考拉海购的场景，制订了横跨数月的迁徙计划。并研发 SDK，实现了音讯双写、topic 映射，反对压测音讯等多项考拉海购特有的性能场景。让业务同学无需投入大量人力。降级 SDK 减少几行配置就能够实现音讯的双写。

• 阶段一：所有业务进行音讯双写革新。
• 阶段二：所有业务进行音讯双读革新。
• 阶段三：进行音讯总体收尾阶段，业务方切换成独自单写状态，至此齐全剥离考拉海购原有的音讯体系。

4）RPC 计划

RPC 次要波及 RPC 框架以及服务注册核心。考拉海购应用 RPC 框架 Dubbok (Dubbo 外部分支）+ Nvwa ( 考拉自研注册核心），而团体应用 HSF + ConfigServer。

因为后期业务有和团体微服务互通的需要，基于 HSF 自身兼容 Dubbo 协定，阿里云 EDAS 团队为咱们提供了 Dubbo ConfigServer 注册核心的扩大，考拉利用在引入该扩大包之后，注册 CS 以及从 CS 订阅，能够十分方便快捷地和团体 HSF 利用互相调用。

紧接着，咱们开始应用 Dubbo3.0，基于 Dubbo 内核重构 HSF3.0，降级之后，原考拉 Dubbo 利用具备 HSF 的全副个性，能够和团体服务无缝互通。然而作为一个新的 SDK，在性能以及性能上必然面临着很大的挑战。咱们后期在考拉海购场景下，引入该 SDK 进行了长达一个月的功能测试，解决了近 40 个性能问题。同时也在压测时，针对性能问题，解决了调用延时、注册核心推送及缓存的问题。同时考拉海购 Dubbo 注册核心扩大等也要去反对 Dubbo3.0，最终经验了双十一大规模验证。

同时咱们采纳双注册、双订阅的模式，也为将来考拉海购自研注册核心的迁徙下线打下基础。待所用利用降级之后，就能够批改为只连 CS 的连贯串，而后下线 Nvwa。同时，考拉海购也迁徙到云原生产品微服务引擎 MSE 上，特别感谢阿里云 MSE 团队为对齐原考拉治理平台 Dubbo 相干性能作出的反对。

5）SchedulerX 计划

挑战：

云上 ScheduleX 定时工作瓶体和考拉海购的 kschedule 定时工作平台，通过调研比拟，发现 ScheduleX 能够说是 kschedule 的架构升级版，除了满足根底的定时调度，分片调度之外，还反对了更大规模的任务调度。对于整体迁徙来说，最大的难点在于如何迁徙同步考拉海购 13000+ 的定时工作，期间每一个工作都须要在代码中进行手动革新，在平台上进行配置。人力耗费微小。

迁徙计划：

• 自研同步工具进行 13000+ 定时工作同步以及报警信息同步，解决了业务同学海量的人肉操作。
• 自研考拉海购云原生管控平台进行定时工作权限信息同步，保障数据迁徙后的安全性。

6）环境隔离计划

微服务场景下，环境治理是一个比拟大的问题，环境隔离实质上是为了最大化利用测试环境的资源，晋升需要测试的效率。考拉原来基于 Dubbo 的路由策略，开发了一套环境路由逻辑。思维是基于骨干环境加我的项目环境的策略，只须要部署需要波及变更的利用，流量通过携带我的项目标签，优先路由到我的项目环境，如果没有部署，则复用骨干环境的服务和资源。因而骨干环境的稳固以及我的项目环境的路由是测试环境治理的重中之重。

迁徙到阿里云之后，阿里云其实有一套相似的计划，基于 SCM 路由，达到同样的成果，如下图所示：

然而性能上 SCM 不反对考拉海购的 RPC 框架 Dubbok 以及音讯框架，不过得益于 ARMS 优良的插件包机制，咱们将 HSF 的 scm 插件通过代码加强的形式打包成插件，移植到了 Dubbok 上，具备了 Aone SCM 计划的能力。通过 JVM 参数和公布平台联合，在后期充沛测试以及和 QA 开发同步的根底上，咱们在一周之内切换到团体的 SCM 计划上。后续考拉海购根本以骨干环境 + 我的项目环境的形式进行需要迭代开发。

7）高可用组件计划

AHAS 限流：

对于限流来说有三个关键点：一是接入，须要在利用代码或者根底组件中埋点，从而可能收集 metrics 以及进行相应限流操作；二是限流能力，规定配置与下发；三是监控与报警。

AHAS 和考拉海购原限流组件（NFC) 面向用户应用层面基本一致，提供注解、API 显示调用、Dubbo filter、http filter 等形式，在迁徙时仅须要替换对应的 API 即可，因为组件 API 绝对简略，因而接入老本还是比拟低的。同时 AHAS 也提供了 JavaAgent 接入能力，不需批改代码即可接入。

在能力方面，AHAS 比原考拉的的组件更加欠缺，提供了基于零碎负载的爱护以及熔断降级。本来有个需要是集群限流的性能，AHAS 团队很给力，在 618 之前上线了该性能让咱们用了起来。在监控报警方面提供了实时的秒级监控，TopN 接口展现等性能，很欠缺。也有流控主动触发报警，通过钉钉的形式。

AHAS 故障演练 ：

考拉海购利用部署在 ASI，Ahas-Chaos 通过 K8s 对外提供的 Operator 能力，在业务无感的状况实现了接入，并顺利的参加到了团体 527 联结演练当中。

8）压测链路革新计划

考拉本来曾经有了一套全链路压测的影子计划。其外围次要分为两个局部：

• 全链路压测标透传
• 流量拦挡以实现影子路由、服务 Mock 等

迁徙第一步是要先接入利用实时监控服务 ARMS；迁徙第二步则是接入性能测试 PTS，反对 ARMS 和考拉组件，接管考拉原有的影子路由逻辑。

ARMS 和 PTS 自身都是应用 JavaAgent 的形式，通过字节码加强来实现对各个根底组件的埋点，这种操作的益处是接入成本低，业务感知小。最终咱们顺利完成了全链路压测的革新。

9）同城双活计划

考拉海购在迁徙到团体机房后，一段时间内还存在自建、云产品和团体组件三者共存的状况，基于现状，咱们设计了一套自有的双活及 SPE 计划。

线上失常状态：

基于 DNS 和 Vipserver 的同机房优先，既能反对日常的流量随机，也能反对单机房流量隔离。

单机房压测下状态：

基础设施即代码 (IaC)

1. 什么是 IaC

Infrastructure as Code ——基础设施即代码，是一种应用新的技术来构建和治理动静基础设施的形式。它把基础设施、工具和服务以及对基础设施的治理自身作为一个软件系统，驳回软件工程实际以结构化的平安的形式来治理对系统的变更。

我的了解就是，通过将软件的运行环境、软件的依赖，及软件的代码进行统一化的治理（变更，版本等），并提供相似 BaaS 化的解耦形式，使得软件不被某个特定环境绑定，能够在任意环境疾速复制运行。

2. 实际内容

1）构建部署体系

咱们在考拉原有的利用 DevOps 体系之上，联合 IaC & GitOps 理念，对利用的构建、部署、配置加载、日常运维等方面基于 AppStack & IaC 做了革新，相干的构建、部署、利用动态配置全副迁徙到利用 git 源码中。借助于 git 对利用所有相干配置进行托管，配置的版本迭代绝对于之前的模式更加的清晰，同时也能很无效的保障利用源码、构建配置、容器配置、动态配置的版本一致性。

2）轻量化容器

以本次云原生革新为契机，咱们将考拉原有的容器镜像体系与团体规范进行了对标革新，比拟大的变动就是将原有的启动用户从 AppOps 批改为了 admin。

另一方面，咱们引入了轻量化容器。作为云原生的根底之一，容器层的隔离能力是一大卖点。考拉海购整体进行了切换，实现了轻量化容器的革新，整体将 pod 分成了利用容器、运维容器，以及自定义容器几类，整个部署变得更加的轻量级，也更加易于掌控。

革新后的部署状态见下图。

3）CPU-share

上图的模式是 CPU-set，即容器会绑定一部分 CPU，运行时也只会应用绑定的 CPU，这种形式在失常的宿主机上运行的效率是最高的，因为缩小了 CPU 的切换。考拉海购的部署全副切换到了 CPU-share 模式，即在同一个 NUMA chip 下，该容器能够应用该 chip 下所有的 CPU（CPU 工夫片总数不会超过 limit 配置），这样只有该 chip 下有闲暇的 CPU，就会使抢占不会太强烈，能大大提高运行的稳定性。

最终在大促峰值压测的验证中，神龙机的 CPU 在 55% 以下都能放弃一个比较稳定的运行状态，进而保障了整体服务的稳定性，资源也失去了更充沛的利用 。

4）镜像配置拆散

镜像配置拆散指的是将利用的容器镜像和利用依赖的配置（动态配置、公布配置）隔离开独立寄存。这样做的目标是可能最大水平地复用利用镜像，缩小利用镜像的构建次数进步构建部署效率；同时，迁徙到 AppStack 后利用代码回滚时也会主动回滚动态配置，不须要业务手动去动态配置核心回滚动态配置，极大升高了业务回滚的危险。

另外当镜像和配置拆散后，镜像能够在任何环境进行部署，而不用依赖对应环境的配置。这样的话，咱们公布流程就能够从面向变更，调整为面向制品，上线的即是测试的镜像。

3. 施行策略

1）自动化

IaC 迁徙中工作较重的是配置迁徙，环境迁徙及整体标准化，进步迁徙效率将极大放慢 IaC 迁徙的速度，也会给业务开发迁徙过程中的心态带来踊跃影响。

• 构建公布配置寄存在考拉旧有的部署平台上，动态配置寄存在自研的配置核心上。旧有部署平台首先买通考拉的配置核心和团体 gitlab 代码仓库，再依据标准化的 service.cue 模板主动将旧有的部署核心和配置核心的各类配置间接创立到业务的代码中，主动实现 IaC 配置迁徙工作，大大节约了业务迁徙工夫进步了迁徙效率。
• 咱们积淀出了一套云原生环境的 API，具备了云原生环境以及云原生流水线的自动化创立、批改以及删除能力，也进步了业务接入效率。

IaC 自动化迁徙性能上线后，均匀每个利用大概只须要 1 分钟的工夫就能够实现各类配置的迁徙、云原生环境、云原生流水线的创立，全程无需业务接入。在实现上述的配置映射及重建后，利用只须要简略的进行构建公布，而后解决局部因为兼容问题导致的启动不失常，即实现了 IaC 的迁徙，整体老本比拟低。

2）接入反对

IaC 的接入不同于中间件的降级，波及到利用的整个公布、部署体系的变动，并且以后阶段 AppStack 的稳定性不算特地高，所以咱们采取的接入策略是我的项目室关闭接入，全程提供技术支持，保障业务可能第一工夫解决问题，进步业务参与度和幸福感，也能在第一工夫收集问题，助力咱们优化接入流程，比方后期业务须要手动创立流水线，到前面咱们通过 API 主动给须要迁徙的业务创立对应的流水线。

而业务迁徙 IaC 的实现又有两个阶段，两个阶段咱们采纳了不同的接入模式，通过在不同的阶段，采纳不同的反对形式，达到业务稳固疾速接入的指标。

双十一之前 ：

• 项目组出一人常驻我的项目室反对
• 每周一到周五，都有不同部门的开发到会议室专一迁徙
• 每天上午培训相干常识，下午、早晨进行利用切换

双十一之后 ：

• 项目组出三人常驻我的项目室反对
• 每周只迁徙固定的部门，由部门派出固定的人实现该周的全副迁徙工作
• 培训放在每周一上午

两者的差别次要是后期平台的稳固水平，及业务研发的相熟度比拟低，所以接入绝对比拟审慎，更多的是以一种验证，及推广的心态来，后续绝对稳固之后，整体就是以平推的模式来进行接入。

成绩

1. 无重大故障产生

考拉海购的云原生革新周期很长，不论是 618 和 双 11 这样的大促，或是每月的会员日等一般大促，在我的项目组成员的通力协作下，没有因为云原生革新引起的重大故障产生。

2. 交融问题喜人

• 解决考拉海购和团体利用部署的差别，齐全兼容以后团体的模式，在部署层面与团体技术体系实现对齐。
• 解决考拉海购外部调用和团体调用的差别。
• 实现 SPE 和双活建设，容灾体系进一步和团体对齐。

3. 效力晋升、老本节约

• 迁徙有状态容器，每批次部署缩小 100 秒，解决 IP 变更导致的启动失败问题。
• 配置和代码做到了强绑定，后续回滚的时候再也不须要关系动态配置的回滚。
• 从日常容量到大促容量从各个利用别离扩容，到 0.5 人日实现全站扩容到基准水位。
• 服务器数量缩小 250 台。

4. 欠缺云产品性能

• 推动解决云产品易用性、稳定性问题，丰盛云上中间件产品的场景丰盛度。
• 推动云原生过程中的平安生产、账号等问题的解决。

将来，Mesh 是发力方向之一

技术下沉是互联网倒退的大趋势 。在微服务时代，Service Mesh 应运而生。尽管引入 Mesh 代理，会带来肯定性能损耗和资源开销，以及 Mesh 服务实例的运维和治理老本。然而其屏蔽了分布式系统的诸多复杂性，让开发者能够回归业务，聚焦真正的价值：

1. 专一业务逻辑，通过 Mesh 屏蔽分布式系统通信的复杂性 (负载平衡、服务发现、认证受权、监控追踪、流量管制等)。
2. 语言无关，服务能够用任何语言编写。
3. 解耦基础设施，对利用通明，Mesh 组件能够独自降级，基础设施能够更快的降级迭代。

考拉海购这一年来始终在动摇的进行云原生化革新，尽管过程中碰到了十分多的挑战，然而咱们从未狐疑过这一方向的正确性，并在每一次解决问题之后播种到了更多的业务价值。往年 双 11，整个云原生降级帮忙考拉缩小了 250 台服务器，并积淀出一套残缺的 IaaS + PaaS 上云落地实际计划。考拉在云上的研发效率也有了大幅晋升，例如应用阿里云直播核心服务，考拉疾速实现了海内直播服务从 0 到 1 的搭建。此外，“爬树 TV”、“Like 社区”等新性能也相继上线。

随着云原生革新的继续倒退，云原生带来的红利也越来越显著。我置信当业务跟基础设施进一步解耦，有一天会实现业务与基础设施无关，业务研发只须要关怀本人的业务，再也不必为运行环境而苦恼，进而在运研效率上取得微小的晋升。

作者简介

张洪箫（花名：伏见） 阿里巴巴新批发高级技术专家，领有 10 年开发测试运维教训，在基础架构和研发效力畛域有十分丰盛的教训，踊跃的拥抱云原生，推崇继续、疾速、高质量的软件交付形式。
原文链接
本文为阿里云原创内容，未经容许不得转载