贝壳上云 & 云上架构

2022 年 5 月 13 日
本文字数：3372 字
阅读完需：约 11 分钟

1.概念解释和行业背景

首先解释下什么是容器化，上云和云原生，纯粹个人通过大白话让大家更直观的理解，官方解释网上随便搜

容器化：应用以镜像作为产物在研发流程流转，运行在容器环境内，并通过 k8s 调度。最大的体感是容器内没有重启概念，取而代之的“销毁重建”，容器内应用的 IP 每次部署会更改。

上云：通是上腾讯云，阿里云等云厂商，利用云计算和服务减少公司运维成本，利用云产品减少自建成本。

云原生：广义因云而生的软硬一体化。建设方对容器内应用提供云化的基础设施如日志，监控，链路，定时任务，磁盘等；应用方对应用微服务，无状态化，构建部署分离，代码与配置分离。双方合作基于 K8s 实现应用的弹性调度，资源的定义和交付。官方解释有早期的 12factors，和后面的微服务，容器化，devops，持续交付，mesh，声明式 api 等，这些理解起来比较晦涩后面会详细解释。

贝壳上“云”：我们上云以上三个概念都包含，首先我们肯定是容器化，而不是虚机容器，大家部署的是镜像；二我们是云么，相比阿里云，腾讯云等我们还远，但是我们是 follow 这个概念设计，你会在贝壳云平台得到类似阿里云提供的一切开发应用工具平台环境等，只是我们的体验和能力面向我们内部，不需要大厂那么体系化。三，我们是云原生么？是，至少大部分是，建设方的能力建设都是基于 K8s，涉及的 deployment，service，etcd，crd，operator 等 k8s 耳熟能详的组件，日志基于 loki，监控基于 k8s 集群，定时任务是 k8s 的 conjob，贝壳应用上云也要满足一系列标准。

在这次上云运动之前，贝壳也有了多个 k8s 集群，他们主要是解决自己一些场景需求，并没有推动全公司应用搬到这个 k8s 上，建设容器，推动让应用上云才是最困难的点，类似拆迁建楼和在已经有的地建新楼，难度要大很多。

个人理解：

云的存在对“人”的研发，测试，运维带来的质的改变-需求的流转上线——人

云的存在对“微服务”的运行环境，效率，稳定，质的改变-应用的生命周期管理——货

云的存在对“环境”的一致性，开发，测试环境搭建，组装的改变-环境的生命周期管理——场

二行业上云概述

非官方哈，个人渠道了解，阿里再 16 年实现了应用容器，有过一次上云（容器化），19 年提出“上云”，是自己的基础设施，日志，消息队列等使用阿里云的产品，一方面验证阿里云的能力，给之足够的宣传，另一方面享受之提供较好的用户体验，内部的中间件能力强大，体验较弱。美团也经过两次上云，总体印象因为纯 Java 系，整体业务上云成本不高。滴滴 redis 存储容器化做的较好，中通，也在进行中，因为他们有统一的 java 语言和构建部署流程，所以上云成本还好，平安是从上到下推，业务线需要抽离配置文件重新构建发布，还是一致认可需要公司层面从上到下推才行。一些互联网公司之所以积极拥抱云，主要还是弹性能力，如果贝壳也总需要运营活动，也会早几年就开始上容器。

2. 贝壳上云

2.1 上云现状

2021 1-4 月：完成基于 k8s 的云上建设，满足应用上云基本条件

2021 4-6 月：尝试各语言构建镜像，发布到建好的 k8s 上，性能压测，和老系统切流验证，应急预案，问题排查，已有系统监控，日志，注册，配置等融合，用户使用习惯和数据尽量透明。

2021 6-7 月：推广各业务线试用，优化反馈，实现内，外业务线双 100 应用云上

2021 7 月 30 日：关闭传统方式资源申请入口，新应用必须上云，意义重大。

2021 8-9 月：一些标准化度较高比如司南业务线，标注度高，keboot 微服务框架统一上云成本较低，运营活动多新家居业务线，需要弹性能力，上云较积极。

2021 9-10 月：没有继续推广，反而停下来建设能力，优化上云体验，500+的线上应用问题排查和观察

now：部署 1000+，引流 650+，每月 100+应用上云。

future：2022 年全量应用上云。

老板视角的业务线上云进度：

我们通过柱状图实时记录各业务线上云进度。

员工视角的自己名下上云进度：

2.2 Keboot 对上云起的作用

早期建设 keboot 是为了解决大家使用的开发组件随意五花八门，没有专人维护，导致线上频发组件不兼容故障，小白用户开箱即用很快进入业务研发。统一 keboot 也能对基础设施统一提供帮助，因为集成了默认的基础设施的地址和使用 sdk，面向“配置"编程，关于 keboot 能再写篇文章，毕竟 19 年都在全公司推进使用和升级。Keboot 相比上云代码改造较多，所以验证成本，出问题的解决成本较大，但很多问题能在上线前发现。上云对代码改造较少（前提你已经是 keboot 项目），但对研发的构建，部署，查看日志监控习惯改变较大。

在统一框架，统一基础设施后开始服务治理体系能力建设，让升级 keboot 的用户能开箱即用享受监控，链路，摘流，诊断等能力，“上云也是一种手段”最终目标还是服务的治理，云上的服务治理的建设和接入成本都较低。毕竟他是面向集群的而不是面向 sdk，sdk 会带来各语言的维护成本成倍增加。所以上云前以服务云为代表的服务治理平台的建设并不浪费，也更好的体现了上云的价值，比如 ketrace 的接入直接在镜像发布时集成，上云即有链路能力，无需一一推进接入。

再者云上的一些能力需要通过 keboot 落地，比如 kafka 隔离，eureka 流量亲和，redis 超时，云上摘流等问题，我们可以通过升级 keboot 框架来让用户低成本接入，keboot 相当于我们和用户的防腐层。

同时 keboot 可以减少上云成本，我只要让 keboot 选用的组件兼容容器环境，而不用对用户使用的各种组件做兼容，keboot 项目上云升级 keboot2+以后的版本，就能实现云上的构建部署，同时也能兼容传统应用环境，这对我们建设方和业务方都有很大帮助。

当然云上后，keboot 应该更轻更薄，里面集成的服务治理能力能抽出到 k8s 容器层面解决。

2.2 如何解决上云成本

此话题针对业务没动力享用云上弹性能力，只考虑成本和稳定性的用户。

早期上云通过详细的上云 wiki 但是用户总会忘记或步奏没有按标准执行，导致发布到线上服务不稳定，比如必须的 readiness 和 liveness 没配，日志采集路径没配等，为了防止此类发生，我们做了个上云流程，让用户严格从此流程流转操作，没经过验证无法进行到下一步，同时运维，研发，架构，测试等多方根据你的上云阶段介入做自己的事情，通过企微通知，各司其职，应用按上云标准流转到云上，最后完成老应用下线，才算整个上云完成

总体汇总了拆解了成本重灾区，让用户选择或填入的项从 41 减少到 9 处，尽量自动带入，减少用户判断和决策。早期之所以填入项多，是为了兼容多语言并且出问题能够调整配置，但发现为了这 5%的 case，让另外 95%的上云用户都要理解这些底层概念，不太合理。目前我们目标是让小白用户无人指导的情况下 1 人日内完成上云，目前熟练的人即时原来复杂的流程也能半天内完成，我们主要解决全公司自助上云的能力建设。