从技术视角看考拉海购的云原生之路

前言

---

考拉海购的整个云化改造是从 2019年10月份开始的，当时的唯一目标就是短时间内快速完成迁移。在不到 4 个月的时间里，我们唯一考虑的是如何以最快的速度完成使命，云原生恰巧是我们选择的一条路。

实践历程

---

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

云产品接入

---

云原生产品定义

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

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

心路历程

我们在云产品的接入过程中， 大致在心态上经历了三个阶段。

1、第一阶段：很好、很强大，接入效率杠杠的

这部分主要是在 2019年10月-2020年3月之前，那时候接入的都是数据库、Redis，以及 ASI 这种产品，相对用户比较多，整体比较稳定，与开源产品基本上完全兼容，迁移工具及周边建设都比较完善，所以迁移起来非常平稳，基本上改动一部分点就可以了。

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

以前很多组件还是我们自己维护的，但是随着连接实例的增加，读写的次数多了，时不时出现宕机。那时候听说微服务引擎 MSE 很好用，它提供一站式微服务能力加持，包括微服务依赖组件托管、无侵入的微服务治理，更快捷、稳定、低成本的运行微服务。我们找了下 MSE 的兄弟，他们拍着胸口说没问题，产品运行之后真的就没出现过那些问题了。

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

3、第三阶段：磨合适应

随着考拉海购开始接入集团的业务平台，供应链也开始和集团进行融合，我们也进一步开展云化的历程。过程中也有挑战，不过在克服重重困难后，我们如期完成了各项的改造，并且非常平稳的度过了几次大促，云原生产品非常好地支撑了考拉海购业务的增长。

 

接入的过程

1、接入策略

由于云产品和考拉海购自建的产品有一定的能力差异，所以我们建立了一整套产品评估和接入试验田机制来保证整个接入的有序及功能的可迁移性，正是这套机制的良好运行，我们整个的稳定性得到了保障，在整个基础大变动中都没有出现大的故障。

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

2、权限方案

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

1）是为每个产品申请一个子账号，所用人共用该子账号？

2）还是为每个人申请一个 RAM 子账号，单独为每个人管理资源权限？

3）或者为应用申请一个子账号，通过员工的应用权限来和子账号的资源权限做关联？

考拉海购有几百人，方案2和3都面临着很高的子账号生命周期以及资源权限的管理成本，所以我们初期在使用这些中间件云产品时，出于简单考虑，都采用了第一个方案——申请一个子账号࿰