介绍：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（SecurityTokenService）的能力，封装了一层简单的云控制台跳转临时授权。生成STSToken时，根据BUC获取当前用户，生成并指定额外的权限策略。限制用户操作云资源（应用）的权限。登录页面如下图所示：SchedulerX也是基于STS的能力，通过RoleSessionName关联员工身份，完成权限管理操作。当然，这只是临时解决方案，可以帮助考拉海购解决一些问题。最终的解决方案还是要看大局。我们稍后会谈到这部分。3）消息方案迁移目标：考拉海购消息系统基于消息队列Kafka和消息队列RabbitMQ，在其上自主研发交易消息中心和延时消息产品，满足丰富的业务消息需求。调用云消息队列上的RocketMQ产品后发现，其完美兼容并支持考拉海购现有的完整消息体系，能够提供充分的性能保障，稳定的运行保障，另外还支持消息跟踪和消息查询等功能对商业用途更友好。实施过程：整体迁移涉及考拉购物数百个项目，无法统一安排改造。因此，针对考拉购物场景，制定了跨越数月的迁移计划。并开发了SDK实现消息双写、主题映射、支持消息压测等考拉海购独有的功能场景。让商科学生不需要投入大量的人力。升级SDK，增加几行配置，实现消息双写。第一阶段：所有业务进行消息双写改造。Phase2：所有业务转化为双读消息。Phase3：消息总关闭阶段，业务端切换到单写状态，考拉海购原有的消息系统被完全剥离。4）RPC方案RPC主要涉及RPC框架和服务注册中心。考拉海购采用RPC框架Dubbok（Dubbo内部分支）+Nvwa（Kolala自研注册中心），而集团采用HSF+ConfigServer。由于前期需要和集团微服务互通，基于HSF本身兼容Dubbo协议，阿里云EDAS团队为我们提供了DubboConfigServer注册中心的扩展。引入该扩展包后，考拉应用可以在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）环境隔离方案在微服务场景下，环境治理是一个比较大的问题。环境隔离的本质是最大限度地利用测试环境的资源，提高需求测试的效率。Koala最初基于Dubbo的路由策略开发了一套环境路由逻辑。思路是基于主干环境加项目环境的策略。只有需求发生变化的应用才需要部署，流量会携带project标签优先路由到项目环境。如果没有部署，骨干环境的服务和资源会被复用。因此，骨干环境的稳定性和项目环境的路由是测试环境治理的重中之重。迁移到阿里云后，阿里云其实也有类似的解决方案，基于SCM路由，达到同样的效果，如下图：但是在功能上，SCM不支持考拉海购的RPC框架Dubbok和消息框架，但它的好处是由于ARMS优秀的插件封装机制，我们通过代码增强将HSF的scm插件封装成一个插件，移植到Dubbok，具备了AoneSCM解决方案的能力。通过JVM参数和发布平台的结合，我们在前期全测和QA开发同步的基础上，在一周内切换到集团的SCM解决方案。后续考拉海购基本都是以主干环境+项目环境的形式进行需求迭代开发。7）高可用组件方案AHAS限流：限流有3个关键点：一是接入，需要嵌入到应用代码或基础组件中，以便收集指标并进行相应的限流操作;流量能力、规则配置和下发；三是监测报警。AHAS和考拉海购原装限流组件（NFC）在面向用户的使用上基本一致。他们提供注解、API显示调用、Dubbo过滤器、http过滤器等，迁移时只需要替换相应的API即可。因为组件API比较简单，所以访问成本还是比较低的。同时AHAS还提供了JavaAgent访问能力，无需修改代码即可访问。在能力方面，AHAS比原来的Koala组件更完备，提供基于系统负载的保护和保险丝降级。本来是有集群限流功能需求的。AHAS团队帮了大忙，618之前就推出了这个功能给我们使用。在监控告警方面，提供实时秒级监控、TopN界面展示等功能，非常完善。还有流量控制，通过钉钉自动触发报警。AHAS故障演练：考拉海购应用部署在ASI。Ahas-Chaos利用K8s提供的Operator能力，在没有任何业务意识的情况下完成接入，并成功参加集团527联合演练。8）压测链路改造方案考拉本来就有一套全链路压测的影子方案。其核心主要分为两部分：全链路压测标准透传流量拦截实现影子路由、服务mock等。第一个迁移步骤是接入应用实时监控服务ARMS；第二步迁移，接入Performance测试PTS，支持ARMS和Koala组件，承接Koala原有的shadow路由逻辑。ARMS和PTS都使用JavaAgent方法，通过字节码增强完成各个基础组件的嵌入。这种操作的好处是接入成本低，业务感知小。最终，我们顺利完成了全链路压测改造。9）同城双活解决方案考拉海购迁移到集团机房后，自建、云产品和集团组件共存了一段时间。基于目前的情况，我们设计了一套自己的双活和SPE方案。在线正常状态：基于DNS和Vipserver，优先选择同机房，既可以支持日常流量随机性，又可以支持单机房流量隔离。单机房压力测试现状：InfrastructureasCode(IaC)1.什么是IaCInfrastructureasCode——InfrastructureasCode是一种利用新技术构建和管理动态基础设施的方式。它将基础设施、工具和服务以及基础设施本身的管理视为一个软件系统，采用软件工程实践以结构化和安全的方式管理系统的变更。我的理解是，通过统一管理软件的运行环境、软件依赖、软件代码（变更、版本等），并提供类似BaaS的解耦方式，使软件不会受到特定环境的影响。绑定，可以在任何环境下快速复制和运行。2.实践内容1）搭建部署系统在考拉原有的应用DevOps体系的基础上，结合IaC&GitOps的理念，在应用构建、部署、配置加载、以及日常操作和维护，所有相关的构建、部署、应用静态配置都迁移到应用git源码中。借助git托管应用的所有相关配置，配置的版本迭代比之前的模式更加清晰，也能有效保证应用源码、构建配置、容器配置、静态等的版本一致性配置。2）轻量级容器以本次云原生化改造为契机，我们对考拉原有的容器镜像系统进行了团体标准的对标改造。比较大的改动是将原来的启动用户从AppOps改为admin。另一方面，我们引入了轻量级容器。作为云原生的基础之一，容器层的隔离能力是一大卖点。考拉海购整体切换，完成轻量级容器改造，将pod整体划分为应用容器、运维容器、自定义容器。整个部署变得更加轻量级和更易于控制。修改后的部署形式如下图所示。3）CPU-share上图中的模式是CPU-set，即容器会绑定一部分CPU，运行时只使用绑定的CPU。这种方法在普通主机上运行时效率最高，因为减少了CPU切换。考拉海购的部署全部切换为CPU-share模式，即在同一个NUMA芯片下，容器可以使用该芯片下的所有CPU（CPU时间片总数不会超过限制配置），所以只要有空闲的CPU，就会避免抢占过于激烈，大大提高运行的稳定性。最后在大促的峰值压力测试的验证中，神龙机的CPU在55%以下时可以保持相对稳定的运行状态，从而保证了整体服务的稳定性，充分利用了资源。4）镜像配置分离镜像配置分离是指应用的容器镜像与应用所依赖的配置（静态配置和发布配置）隔离独立存储。这样做的目的是为了最大化应用镜像的复用，减少应用镜像的构建次数，提高构建和部署的效率。同时，迁移到AppStack后回滚应用代码时，静态配置会自动回滚，业务无需手动去静态配置。配置中心回滚静态配置，大大降低业务回滚风险。此外，当镜像和配置分离时，镜像可以部署在任何环境中，而不依赖于相应环境的配置。这样我们的发布流程就可以从面向变更调整为面向产品，上线的就是测试的镜像。3.实施策略1)IaC自动化迁移最重要的任务是配置迁移、环境迁移和整体标准化。提高迁移效率会大大加快IaC迁移的速度，也会对业务开发迁移过程中的心态产生积极的影响。构建发布配置存放在考拉老部署平台，静态配置存放在自研配置中心。老部署平台先对接考拉的配置中心和群gitlab代码仓库，然后根据标准化的service.cue模板，自动创建老部署中心和配置中心的各种配置直接进入业务代码，自动完成IaC配置迁移工作大大节省了业务迁移时间，提高了迁移效率。我们针对云原生环境开发了一套API，具备自动创建、修改、删除云原生环境和云原生管道的能力，同时也提高了业务接入的效率。IaC自动迁移功能上线后，平均每个应用仅需1分钟左右即可完成各种配置的迁移、云原生环境的创建、云原生流水线的创建，无需用于业务访问。完成以上配置映射和重建后，应用只需要简单的构建和发布，然后解决一些兼容性问题导致的异常启动，即完成IaC的迁移，整体成本比较低。2）接入支持IaC的接入不同于中间件的升级，涉及应用的整个发布和部署系统的变更，而现阶段AppStack的稳定性不是特别高，所以接入策略我们采用的是项目室封闭接入，全程提供技术支持，保证业务能第一时间解决问题，提高业务参与度和幸福感，同时也第一时间收集问题，帮助我们优化接入流程。例如，早期的业务需要手动创建流水线。未来我们会通过API为需要迁移的服务自动创建相应的流水线。业务迁移IaC的实现有两个阶段。在两个阶段，我们采用了不同的接入方式，在不同的阶段采用不同的支持方式，以达到服务接入稳定、快速的目的。双11前：项目组有驻场人员在项目室支援。每周一到周五，不同部门的开发人员每天上午到会议室重点传授相关知识，下午和晚上切换应用。双十一后：项目组三个人进驻项目室，支持每周只有固定部门的迁移，部门派固定人员完成一周所有的迁移工作培训，每周一上午上线。两者的区别主要在于前期平台的稳定性和业务研发。熟悉程度比较低，所以接入比较谨慎，更多是基于一种验证和推广的心态。后续相对稳定后，整体接入以平推模式为主。取得的成绩1、无重大故障发生。考拉网的云原生转型周期很长。无论是618、双11这样的大促，还是月度会员日这样的普惠，在项目组成员的全力配合下，没有出现云原生改造的重大失败。2.整合成果喜人。解决了考拉海购与集团应用部署的差异，完全兼容集团现有模式，在部署层面与集团技术体系对接。解决考拉海购内部通话和群组通话不一致的问题。完成SPE和双活建设，灾备体系进一步与集团对接。3.提效节约成本迁移有状态容器，每次批量部署减少100秒，解决因IP变更导致启动失败的问题。配置与代码强绑定，后续回滚不再需要回滚静态配置。从日扩容到大促扩容，分别对每个应用进行扩容，0.5人天完成全站扩容到基线水平。减少250台服务器。4、完善云产品功能，推动云产品易用性和稳定性问题的解决，丰富云中间件产品的场景丰富度。推动解决云原生过程中的安全生产、账号等问题。未来Mesh是发展方向之一。技术下沉是互联网发展的大势所趋。微服务时代，ServiceMesh应运而生。虽然引入Mesh代理会带来一定的性能损失和资源开销，以及Mesh服务实例的运维和管理成本。但它屏蔽了分布式系统的诸多复杂性，让开发者回归业务，关注真正的价值：关注业务逻辑，通过Mesh屏蔽分布式系统通信的复杂性（负载均衡、服务发现、认证授权、监控和跟踪）、流量控制等）。语言无关，服务可以用任何语言编写。基础设施解耦，对应用透明，Mesh组件可单独升级，基础设施升级迭代更快。考拉海购今年一直在坚定地进行云原生转型。虽然过程中遇到了很多挑战，但我们从来没有怀疑过这个方向的正确性，每次解决问题后都有更多的收获。很大的商业价值。今年双11，整个云原生升级帮助考拉减少了250台服务器，沉淀了一整套IaaS+PaaS云实施方案。考拉在云端的研发效率也得到了大幅提升。例如，利用阿里云直播中心服务，考拉从0到1迅速完成了海外直播服务的搭建。此外，“爬树TV”、“点赞社区”等新功能也相继上线。其他。随着云原生转型的不断深入，云原生带来的红利越来越显着。我相信当业务和基础设施进一步解耦的时候，总有一天业务会和基础设施无关。业务研发只需要关心自己的业务，不用再担心运行环境，将大大提高运研效率。作者简介张红晓（本名：伏见），阿里巴巴新零售行业资深技术专家。拥有10年的开发、测试、运维经验，在基础设施和研发业绩方面有着丰富的经验。、快速、高质量的软件交付方式。原文链接本文为阿里云原创内容，未经允许不得转载
