万字长文 -- 基于业务视角的上云实践

2021 年 12 月 10 日
本文字数：12107 字
阅读完需：约 40 分钟

前言

三年前写过一系列文章 初创公司的技术选型^[1]，介绍我们初期的技术选型。经过了三年，业务发生了变化，我们的技术架构也发生了变化。技术需要不断迭代，技术的发展是为了更好的支撑业务，而不是为改而改，为新而新，为用而用。所以我会更多的从业务视角来审视我们的技术架构。

我们的业务都是部署在云平台上，做为一家初创企业，云确确实实提升了我们的效率，让我们更多专注于自己的业务开发。当然不可避免的，我们在上云和使用云的过程，也遇到了不少问题，踩了不少坑。我也希望在这一系列的文章里为大家提供实战经验，踩过的坑，以及云产品的一些另类玩法。

备注说明：本系列文章主要介绍了业务架构的云原生实现思路，虽然我们同时使用了多个云，但是为了叙述便利，云产品主要以阿里云的产品做为示例说明，使用其它云的童鞋亦可寻找同类替代产品进行实现。

业务背景

既然是业务视角，就需要业务开始说起。我们是深圳的一家创业公司，提供一站式的会员方案设计，产品研发，营销活动策划，权益供应链整合和管理，用户售后等服务，助力合作伙伴快速高效发展付费会员业务。目前累计服务超过 50 家企业，超过 300 万付费会员。简而言之，我们是一家输出付费会员体系建设能力，帮助企业做增长的商业型 SaaS 公司。

我们的业务属性，也决定了我们在业务系统设计的目标。我们的业务系统的设计目标总结下来是“四高”：高效率，高可用，高并发，高扩展。

谈谈我对这四个目标的理解。

高效率：指的是系统的部署，升级，接入，维护都是高效的，创业公司的人不像大公司能招来那么多人，所以必须保证提高每个人的人效，让大家把更多的精力投入到业务设计和开发上。

高可用：指的是系统要稳定，不能动不动就出问题，我们服务的是 B 端客户，B 端客户对可用性的要求是比较高的，我们目前设定的 SLA 是 99.9%，即全年业务不可用的累计时间不超过 8.76 个小时。

高并发：指的是系统能够承受比较高的并发量，我们的业务的终端使用者是消费者，伴随着营销活动推广，访问量也会存在突增的情况。所以整个系统从前端到后端到数据库都要能支撑比较高的并发。

高扩展：指的是系统能够水平扩展，我们目前服务的是百万级付费用户，但是未来随着业务的增长，用户量有可能达到千万级，甚至亿级。这时候要求我们的系统能够水平扩展，可以通过简单的扩容不断增加整个系统的承载能力。

业务架构

先放我们的整体的业务架构图。

从上往下看 -->

一：我们的业务服务对象是 B 端客户， C 端用户， S 端供应链，还有我们内部的运营人员和客服人员等

二：对外服务的形态有 SDK， H5，小程序和 App，所有这些都是通过统一的 API 网关接入后端服务， API 网关起到授权，鉴权，限流，审计等等作用。

三：往下是具体的业务模块，整个业务主要分成几大部分：商品管理，订单管理，会员管理，运营支撑，支付信息管理，酒店信息管理等。这些业务模块可以以微服务的方式部署

四：底层我们用了公有云和容器平台。我们的应用都做了容器化，并运行在 kubernetes 上面调度。公有云和公有云上的容器平台，不但为我们的业务提供了底层的计算能力，也为我们提供了底层的稳定性保障。

从左往右看 -->

最左边是配置中心，安全中心和日志平台，分别管理我们应用的配置，保障业务平台和底层架构的安全，采集业务日志方便审计，分析和定位。

最右边是统一发布平台和监控平台。统一发布平台负责应用的发布，即 CI/CD。监控平台负责底层服务器，网络，容器，容器平台以及业务应用等组件的全方位监控。

业务部署

代码管理

我们前端和后端的代码都是采用了阿里云的云效代码管理平台进行管理。

关于代码的管理平台，可选的方案是比较多的，比如 github， gitee, coding.net 等，之所以选择云效，主要还是看重云效和阿里云其它产品的集成做的比较好（毕竟是亲儿子）。

云效代码管理(codeup)是阿里云出品的一款企业级代码管理平台，提供代码托管、代码评审、代码扫描、质量检测等功能，全方位保护企业代码资产，帮助企业实现安全、稳定、高效的研发管理。

关于云效平台的详细介绍可以参考云效官方文档^[2]

代码管理平台的功能很多，主要讲讲我们用的比较多的功能。

代码的版本管理，包括分支管理，标签管理等
开发流程管理，包括提交 PR（pull request）, 代码评审等
持续集成，包括安全检查（敏感信息检测，依赖包漏洞检测，源码漏洞检测），通过流水线和容器镜像仓库打通等
代码权限管理，包括给各个仓库分配管理员和开发者等

这里不得不提的是云效的“流水线”功能，确实很强大。

通过流水线可以 DIY 实现各种场景需求。这里举一个例子，比如代码打标签后自动生成镜像，然后部署到 k8s 集群，目前我们在几个场景里用到了流水线，一个是前端代码通过评审后自动编译并部署到对象存储，另外一个是后端代码评审后自动生成镜像并部署到容器集群。整个过程用起来是比较丝滑的。

云效平台内置了不少流水线模板，正在探索中。

前端部署

前面已经提到前端的代码是托管在阿里云的云效代码管理平台。

前端代码编译完会上传到对象存储里（OSS），再用 CDN 关联对象存储桶，接着关联域名之后，就可以通过域名来访问了。

OSS 即对象存储，可以理解为类似网盘的产品，用来存储文件的。OSS 相关介绍^[3]
CDN 即内容分发网络，常常和 OSS 配合使用，可以快速部署 H5 网站, 而且实现成本较低。 CDN 相关介绍^[4]

相比于之前用单独用服务器挂 nginx 来部署前端应用的方式，这种部署方式有以下几个优点：

部署起来很简单，可以直接将文件拖拽到存储桶就可以完成部署
用 CDN 的好处在于前端的代码和图片下载速度会比较快，而且可用性有保障，还不影响后端的性能。
成本比单独部署服务器的成本低，不算上流量成本，CDN 和存储桶每年的费用几百块不到，比买 1 台 1 核 1G 的服务器的费用还低。而且可用性还更高。
管理起来更方便, 另外 CDN 产品自带流量监控，方便查看流量统计情况

【我们踩过的一些坑】

CDN 刷新有缓存，有时候版本发布时，需要进行强制刷新，用户访问的页面才能更新
CDN 产品故障，导致访问 H5 会自动下载网站文件，无法正常访问
OSS 有个 HTTP Referer 设置，是用在防盗链的，但是用不好，会导致用户无法正常访问文件，如果是嵌入到其它合作方的网站或者 app 里，建议不做设置

【我们的解决方案】

网站开启 HTTPS，建议全站 HTTPS，并开启强制跳转，保证页面访问的安全性，防止中间人攻击
将 OSS Bucket，配置成静态网站托管模式
设置静态资源缓存时间，缓存时间设置将有效提升资源的命中率，提升访问性能，减少回源

其它最佳实践请参考 -->

官方的 OSS 最佳实践^[5]

官方的 CDN 最佳实践^[6]

后端部署

讲完前端的部署，我们来讲后端的部署。后端的部署会比前端复杂的多，用到的云产品也更多，用到的产品包括但不限于服务器，数据库，容器平台，镜像管理，API 网关，消息队列等

代码管理

代码是用阿里云的云效代码管理平台管理。这块其实和前端是一样的，不做赘述。

镜像管理

镜像管理采用了阿里云的容器镜像产品。阿里云的镜像产品可以和代码仓库进行打通，也支持好几种代码仓库。我们平时把 dockerfile 和业务代码放在一个代码项目里，触发构建的业务容器会会自动上传到阿里云上的镜像仓库上进行管理，容器平台和镜像仓库也是打通的，会自动识别容器镜像仓库里镜像版本。

【我们踩过的一些坑】

我们是通过代码仓库触发的容器构建，在构建的时候偶尔会遇到下载依赖包卡住的情况，一直查不到是什么原因

【我们的解决方案】

生产和测试的镜像库隔离开，分别在不同的区域，避免测试和生产的上传的镜像发生互相覆盖的情况
提前构建一个包含所有依赖包的镜像做为母镜像，在这个母镜像再进行镜像构建，能加快构建进度，也减少下载依赖包卡住的情况
不希望被外部访问的镜像库，要设置成私有镜像库

容器调度

容器调度采用了阿里云的容器服务 Kubernetes 产品。

至于为什么用 kubernetes（以下简称 k8s），这里做下说明:

使用 k8s 无论是扩容实例，还是升级业务容器都很方便，对我们来说就是修改一个数字，满足我们对业务的高效率和高扩展的需求
使用 k8s 可以无缝对接阿里云的其它产品，比如 API 网关以及镜像管理等产品无缝打通
使用 k8s 可以自动调度容器，保证业务的高可用，满足我们对业务的高可用需求

当然，引入 k8s 也有带来一些问题，就是会有一定的上手成本，k8s 的功能很强大，涉及的概念庞杂，尽管阿里云对原生的 k8s 做了封装和产品化，但是对于 k8s 的初学者来说依然有不小的上手难度，需要给开发和运维人员做培训。

【我们踩过的一些坑】

内部的 coredns（k8s 的一个 dns 组件）不稳定，导致内部应用容器互相访问的时候报错
多个业务容器采集到同一个日志库下出现日志缺失的问题（这块也搞了很久，阿里云的文档里对这块的操作不好查阅，后面提工单找了几次阿里云的工程师才搞定）
资源请求（资源限制和所需资源）分配不合理，导致集群资源空闲，但是新加的容器却无法被正常调度的问题

【我们的解决方案】应用在 k8s 平台上运行起来，不仅仅是制作镜像那么就完了。其实后面还需要很多的工作。举几个例子：

要抽取配置文件，放到’配置项‘或者应用里的环境变量里进行管理
应用里开启存活检查和配置检查
和日志服务的打通，采集容器里的业务日志
定时任务的配置
服务的配置
通过创建内部负载均衡和 API 网关进行打通（这块比较复杂，限于篇幅，有机会再单独写文章）

其它的一些建议：

我们采用的托管集群，生产和测试隔离开，各部署一套集群，这样确保生产环境的安全性和可用性，避免来自测试环境的影响
资源的分配一开始可以分多一些，后面再根据实际的请求情况进行调整，可以通过自带的容器监控看到实际请求的资源

服务器

服务器用了阿里云的 ECS 产品，使用了 Centos Linux 系统。用了多台高性能的主机。

服务器这块暂时没有太多可以讲的内容，都是中规中矩的用法。

【我们的解决方案】

定期打安全补丁
测试环境和生产环境用不用的区域，严格隔离
生产环境一定要采用最严格的安全组策略，不允许从公网直接访问
用高性能的机器，多留一些冗余
如果用来做 k8s 的 node 节点，那么挂载容器的磁盘最好大一些，比如 500G
系统盘和数据盘开启定期做存储快照

数据库

数据库用了阿里云的云数据库 RDS 版和云数据库 Redis 版。

RDS 用的是 MySQL ,当然还有其它可选的,比如 PostgreSQL，PolarDB 等，最近在调研 PolarDB，是兼容 MySQL，后续可能会考虑用 PolarDB 替代 MySQL，性能上更好。MySQL 主要是用来存储我们的业务数据。性能要求比较高。

Redis 用的是高可用版，Redis 我们用的相对轻量，主要是用来做消息的传递，还有就是程序加锁的时候会用到 Redis。

为什么选择云产品，而不是自建？其实理由是很简单的。

首先使用云产品的稳定性更好，数据对一个企业而言，太重要了，容不得半点闪失，不能因为省钱，而牺牲数据可用性；
其次维护成本更低，对创业公司来讲，至少可以省掉一个运维的人力，甚至是一个运维团队的人力；
最后就是体验更好，页面化的操作很方便，也不容易出错。

中间件

中间件用的不多，主要是下面三个：

配置中心。用了阿里云的 ACM，其实就是开源软件 Nacos 的云产品版本。主要是用来集中管理和分发我们业务系统的配置，我们的开发童鞋为此还对程序做了相关的改造。
RocketMQ。用了阿里云的 RocketMQ 产品。主要是作为消息队列用于处理一些异步任务。
API 网关。用了阿里云的 API 网关产品，我们对外提供服务主要是以 API 提供的，阿里云的 API 网关提供了丰富的功能，比如鉴权，流量控制，环境隔离等。

特别的，讲下 API 网关的一些实践。

API 网关用起来后，开放外部接口给客户用的时候，会比较方便，开启鉴权即可，免去自己从头造轮子的工作
API 网关可以和容器平台无缝对接（通过 VPC 授权的方式），这样业务容器就不需要暴露在公网，避免被恶意扫描攻击
API 网关从某种程度上可以抵挡一部分的恶意流量，一些无效的请求会被挡在 API 网关这一层，不会到达业务容器
API 网关还有一些另类的用法，比如用来快速 mock 一些请求，这里用在公众号的域名校验的时候特别好用

产品组合

做的比较好的云平台有一个特点，就是各个云产品之间并非是割裂的，这些云产品之间是相互打通的，用起来会非常顺滑。

比如我们的上线流程，可以将代码管理，镜像管理和容器管理的产品打通起来。

下图是这几个产品之间的联动关系

小结

如果是前端还是后端，都可以用一连串的云产品提高部署效率。当然更多的云产品，也意味着更多的学习成本，这个是需要权衡的。

业务监控

业务部署上去了，要想知道业务是不是正常，需要怎么做？这时候监控就很重要。监控是业务的眼睛，如果没有监控，我们就会抓瞎。

一开始没有监控的时候，我们会遇到下面的场景👇：

业务系统出问题，客户总是比我们先发现，或者是用户投诉了才发现
业务系统出问题，没有足够的信息评估问题严重性
业务系统出问题，找了半天问题，不知道从何定位，从而延长了故障时间

虽然监控不是万能的，但是完善的监控，可以帮助我们及时发现系统问题，协助我们快速定位，缩短故障时间。

如何做好监控呢，我觉得可以分两个大的维度来做。

一个维度是从业务的维度出发，是业务的监控，包括但不限于业务的日志的监控，网站可用性监控，API 监控，前端页面监控
一个维度是从底层资源出发，对底层资源做监控，包括但不限于 K8S 应用监控，容器监控，服务器监控，数据库监控等

底层资源的问题会传导到业务层，底层资源如果有问题，比如说数据库挂了，反映到业务层就是一堆的连接数据库的各种报错，API 不可用等等

另外一方面，底层资源没有问题，不代表业务不会出问题，比如代码有严重 bug，这时候也是导致业务出问题，业务日志要对这种情况有反馈。

业务层监控

【业务日志监控】

前提是在写代码的时候要先能准确捕捉到报错，另外在报错的时候要能准确记录有效信息帮助定位，这点很重要（痛的领悟）。

日志的生命周期我分为三个阶段：采集-处理-监控

首先是采集阶段，我们的日志会采集到阿里云的日志服务产品 SLS(关于阿里云日志服务的描述，可以阅读这里 日志服务^[7])

其次是处理阶段，我们对日志进行切割，把对应的字段进行拆解，还有就是建立索引，这些操作，可以方便我们后期的日志检索和设置监控。

最后是监控阶段，在采集之前对日志进行分级，对重要的日志设置监控，有问题会打电话和发邮件。另外我们每次 Code Review 也会检查下日志的报错情况。及时发现我们没有遇到的错误情况。同时我们也会建立监控面板。

【API 监控】API 监控上我们目前主要监控核心 API 的接口响应的时间，很多时候业务出问题，API 接口的响应时间会有比较明显的变化。目前我们核心的几个接口响应时间基本都是在 100ms 以内。我们设定了超过一定的阀值，就会告警。 API 监控是阿里云 API 网关自带的功能。

具体的 API 网关监控配置可以参考 API 监控配置^[8]

另外 API 的监控还有一些高级的玩法,比如链接跟踪监控.这块我们也还在探索之中.

【前端页面监控】主要是获取前端访问的情况，页面的报错信息,行为轨迹. 这个对前端的监控和排障很有用.

这里我们用到的是阿里云的 ARMS,具体的，请参考应用实时监控服务 ARMS^[9]

【网站监控】主要是监控网站是否能够正常打开，网站的响应速度. 阿里云也有一个对应的产品功能，叫站点监控，大家可以自行搜索。

底层资源监控

【K8S 监控】主要监控了容器的异常事件，比如容器启动异常，调度异常等

特别的，在应用容器监控上，我们针对容器添加 readiness 和 liveness 的探针，方便做容器的健康检测。

【数据库监控】数据库的监控重点监控的数据库同步延时，CPU 使用率等等，另外一个需要重点关注的是慢查询 SQL，一般索引没加好，数据量一大，就会有一堆慢 SQL，很容易导致业务阻塞。

【服务器监控】常规的服务器告警，比如重启事件，内存使用率， CPU 使用率，磁盘使用率等，比较常规，告警阀值的设置，云监控都有对应的模板，一般用默认模板就够了，再设置下告警联系人就行了。这里不做赘述。

小结

业务上线，监控先行。监控做得好，业务才能快速稳定的发展，发版才能发的安心。但是监控的工作又不是一个简单的事情，特别是要实现 360 度的有效监控，另外监控的工作也不是一个一蹴而就的事情，需要不断的调优，不断的查漏补缺。

业务安全

单纯业务监控还不够，还要保证业务系统的安全，避免出现安全事故。安全无小事，只要出现问题，很多时候都会变成大的问题。安全体系建设也是业务系统搭建和维护里重要的一环。我在这里主要是讨论如何用云产品来构建加固自己业务的安全防线，仅供参考。

资源访问安全

我们虽然业务已经容器化，但是免不了还是需要登录到服务器上去做一些操作。这时候就需要在开发或者运维人员的电脑对服务器远程登录. 以前我们的做法是服务器打开 SSH 的 22 端口，开放公网访问，然后直接连接就行访问。虽然这样访问很方便，但随之带来的问题是我们的服务器经常被恶意进行端口扫描和攻击。

后来我们做了两个事情：

建立安全组，所有的端口均不对公网访问，让公网无法扫描到我们的业务服务器，针对个别端口，比如 22 端口设置访问白名单
登录业务服务器，必须先登录云堡垒机。云堡垒机是阿里云的一个产品（详细介绍见什么是堡垒机^[10]），它能帮助我们更安全的访问业务服务器。首先登录堡垒机会进行双因素认证，其次堡垒机可以严格的分配账号权限，最后堡垒机有操作审计功能，可以进行事后追踪。

通过这两个措施，原来的端口扫描攻击的问题也解决了，而且登录服务器也没有因此变得特别复杂。

通信链路安全

无论是接口还是网页，我们都用了 HTTPS 的访问方式。 HTTP 的方式的问题是容易被中间人攻击，就是如果在不安全的网络环境里，攻击者可以清楚的截获和篡改客户端和服务端的通信数据。

举个例子，如果你的网站是http://www.abc.com，用户连接了一个黑客部署的一个 wifi 热点，此时用户正在访问自己的会员页面和个人信息页面，此时黑客通过抓包在后台清楚的看到用户的个人信息和账户信息。但是一般情况下，用户是没有任何感知的。

为了网站的安全，一定要开启 https.

云平台的 API 网关，CDN，OSS 产品都是可以开启 https 功能的。

在开启 https 之前，你需要一个 ssl 证书，这个证书你可以免费申请，也可以付费购买，而且价格差异比较大。以下是我从云厂商页面截的一个购买页面：

SSL 证书的购买需要结合业务的情况购买，以下建议仅供参考：

有预算的买贵的通配符证书，多个域名可以共用
没预算的买便宜的，多个域名可以共用
不想花钱的用免费申请单域名证书，多用几个阿里云账号申请，每个账号好像可以申请 5 个免费证书
不想花钱还有另外一种方式就是到 https://letsencrypt.org/网站申请，然后托管到阿里云上（这个方法我没有尝试，网络上有很多教程）

病毒和攻击防护

网站的威胁和攻击目前已经多样化了，除了常规的钓鱼和端口扫描，还会有漏洞攻击，病毒攻击等等。初创企业往往没有自己的安全团队，这时候怎么办呢？后面通过一番考虑，我们决定还是"破财消灾"，购买阿里云的云安全中心产品。

这个云安全中心有哪些功能呢？我直接摘录下官方的文档：

云安全中心是一个实时识别、分析、预警安全威胁的统一安全管理系统，通过防勒索、防病毒、防篡改、镜像安全扫描、合规检查等安全能力，帮助您实现威胁检测、响应、溯源的自动化安全运营闭环，保护云上资产和本地服务器并满足监管合规要求。更多介绍请参考云安全中心文档^[11]

开启了云安全中心后，可以看到目前的业务系统和服务器被攻击的情况，有哪些漏洞需要修复，有哪些云产品配置的有问题，都一目了然。大部分的问题，安全中心都自动做了防护，但是还有一部分需要手动去处理，比如漏洞的修复，云产品配置的修改等等，不过这些在安全中心都会有操作建议，我个人觉得使用门槛是比较低的，使用体验比较 OK。

其它防护

其它的安全措施还有抵御 DDoS 的防护(参考 DDoS 高防^[12])，恶意业务流量的过滤清洗(参考 Web 应用防火墙^[13])等等，阿里云上也有对应的产品，这里不做赘述。

小结

总而言之，安全体系建设是一个长期的工作，而且是一个专业度和复杂度很高的工作，我相信仅仅只是用几个云产品是不够完善，真正要做好，还有很多事情要做，比如招聘专业的信息安全人员，对员工做安全意识培训，找外部公司做安全评估等等，当然这个不是本文的重点，不做赘述。

业务运维

除了监控，安全之外，业务系统还有一些日常的维护工作要做，比如数据备份，服务器升级等等，这样才能保证业务的长期稳定。

资源扩容

业务量上去了，使用的资源不够了，就需要对底层的资源进行升级，升级的资源包括但不限于服务器，数据库等等。

那什么时候需要进行升级，需要升级到什么配置呢？这是个问题。

一般情况下，我们会对资源的使用率进行评估，比如会先看几个月的监控数据，看看资源使用率，比如 cpu，内存，磁盘使用率等等，看下最近一段时间的使用率变化情况，再结合业务增长情况，至少留一倍的资源冗余。现在我们云产品的消耗量比较少，还没有到需要进行成本深度优化的时候，所以拿空间换时间，留足冗余，有更多时间可以响应业务的需求变化。

需要特别注意的是，服务器和数据库的升级都会涉及重启，会有一段时间的中断，虽然时间不长，一般是几分钟，但是对业务还是有一定影响，建议在业务低点，比如深夜进行升级。

还有对于服务器来讲，磁盘的替换升级比较麻烦，建议如果可以还是一步到位，省得后面替换起来麻烦。

数据备份

相比物理资源来说，数据对我们来说是更加重要的，云主机挂了，我们还能用新的替换或者等待恢复，业务就正常了。但是数据丢了，可能就找不回来了，对我们业务和用户造成的是永久的影响。

哪些需要备份呢，需要怎么备份？这是个问题。

一般需要备份的数据包括但不限于，数据库数据，磁盘数据，配置数据等。

【数据库数据备份】

一般我们这边重要的数据库都是每天进行备份，每份数据保留一周以上。而且需要异地备份。防止单数据中心出现问题后，数据备份丢失。重要数据多地备份的策略是加了双保险。比较数据是企业最宝贵的资产之一，这块的投入宁愿浪费，不能节省。

【磁盘数据备份】

磁盘这块，我们一般会对业务服务器的系统盘和数据盘进行备份，防止有时候系统崩溃了之后，有些系统配置和安装好的系统软件和补丁可以找回。我们一般会设定磁盘自动快照策略。每天做一次快照。有些不太重要的服务器就不用频繁备份。

【其它配置数据备份】

其它配置，如 Kubernetes 上的应用配置，供应商账号信息等，也需要有一个备份，这个备份可以在公司密码库里留存。

Kubernetes 软件升级

kubernetes 经常隔一段时间就会进行版本升级，相关的插件也会跟着升级版本。所以我们每隔一段时间也会对 Kubernetes 进行升级。如果有新特性，我们正好也能用上。

阿里云的 kubernetes 升级是一键傻瓜式升级，做的还比较方便，但是在升级某些关键组件，比如 dns 插件时，还是会有业务中断的情况，所以在做 kubernetes 升级的时候，建议在业务低峰操作。

SSL 证书更新替换

SSL 证书要一年一换，也有定期维护。我们涉及的 CDN 和 API 项目较多，手动替换比较麻烦，所以我们同事写了个工具调用阿里云的 API 进行批量替换，整体还是比较方便的。

云产品报障

云产品的稳定性虽然说很好，但是难免也会出问题，在我们业务上云的 3 年里，共计出现的云产品问题不下 10 次，涉及的云产品包括 CDN，OSS，数据库，数据传输，分析型数据库，Kubernenets 平台等。

云厂商的响应速度很重要。不过每次提交工单去处理还是太慢，延长了我们业务的宕机时间。后面销售拉了个专门的服务群之后，这块的响应速度更快了，问题也能得到及时的处理，整体的感知更好了。我觉得最后云厂商拼的不仅仅是产品，更是服务。

小结

总而言之，数据备份是重要不紧急的事情，是需要提前做的。资源扩容，ssl 替换，软件升级往往是紧急重要的事情，也可以提前规划。运维最重要的是意识，未雨绸缪，居安思危就对了。

业务分析

如果说运维和监控保障了业务系统的稳定，那么数据分析是可以帮助业务做增长的。那如何利用云产品做业务数据沉淀和分析呢？下面我们讲讲关于数据的沉淀，展示和分析的一些简单实践。

数据沉淀

如上图所示，我们的数据沉淀这块用了 4 个云产品。

首先我们的业务数据都是沉淀到关系型数据 MySQL（关于云数据库的介绍可以参考下面链接什么是云数据库^[14]），至于为什么选择云数据库，还不是自建 MySQL，我觉得还是运维成本的考虑，如果真的要建设一个高可用的 MySQL 数据库集群，先不说要招聘专业的人来做，需要投入的人力物力还不少，最终的成本并不会比直接用云数据库高，功能没有云数据库全，可用性没有云数据库好，评估了投入产出比，果断选择了云数据库。阿里云这边有一篇文章介绍了使用云数据库的优势，可以作为参考RDS与自建数据库对比优势

我们的数据通过 DTS，即数据传输服务这个产品直接同步到 ADS，即分析型数据库，进入分析型数据库的数据是用于数据分析和生成报表的。这里为什么用分析型数据库，而不是直接连 RDS 呢？原因是分析型数据库更快，性能是 MySQL 产品的几十倍。另外一个原因是为了做读写隔离。数据报表用分析型数据库，对数据的读取量比较大，即使把数据库搞崩了，也不会影响到主业务。

数据管理服务 DMS 可以同时管理 RDS 和 ADS。

【我们遇到的坑】

我们有一次遇到分析型数据库性能不足的情况（QPS 其实不高，扫描的表行数超过千万行，结果直接把分析型数据库的 CPU 打爆了），要进行升级，结果升级后，ADS 死活连不上，特别不稳定，一问对方工程师，说是部署 ADS 的机器出问题，磁盘满了，导致 ADS 服务也不稳定。经过积极的沟通之后，折腾了一天才把这个问题搞定。感觉 ADS 的可用性和 RDS 还是不能比，对实时性和稳定性高的业务建议还是用 RDS。对实时性要求不高，读取数据量大的任务，比如报表分析，用 ADS 还是不错的。
RDS MySQL 同步数据到 AnalyticDB MySQL，一直有一个问题没有解决，就是当 RDS 这边的数据库表里增加了 tinyint 和 double 类型的字段后，就同步不到 ADS 上，同步任务就会中断，导致数据不一致。目前每次都要登录到 ADS 上，手动把对应字段加上，再重启同步任务才行。这个问题目前云厂商那边说暂时无解。

数据可视化和分析

数据存储了，接下来就要想怎么分析，怎么展示，来挖掘和体现数据的价值了。云厂商通常都会提供一些 BI 工具，搭配数据库进行使用。以阿里云为例，它提供了一个功能强大的产品叫 QuickBI。以下是 QuickBI 的产品能力：

当然这个产品的定价也不便宜，专业版的定价打完折都要 12 万。

相信这个定价可以直接劝退很多初创企业，当然也包括我们。数据分析又是刚需需求，怎么办呢？困难总比办法多，我调研了一圈之后，发现还是有不少的开源替代品的，目前对比的产品有几个： superset，redash 和 davinci。直接上结论: davinci 体验最好，功能最全，虽然接入的数据源不如前面两个多得多，但是能接入 mysql 对我们来说已经能够覆盖 90%的场景了。

redash 我们早期也用，但是自从发现了 davinci 这个宝藏级软件，我们就果断弃坑 redash。这里重点介绍 davinci。

这里引用下 Davinci 官网的一段对 Davinci 定位的介绍

Davinci 是一个 DVaaS（Data Visualization as a Service）平台解决方案，面向业务人员/数据工程师/数据分析师/数据科学家，致力于提供一站式数据可视化解决方案。既可作为公有云/私有云独立部署使用，也可作为可视化插件集成到三方系统。用户只需在可视化 UI 上简单配置即可服务多种数据可视化应用，并支持高级交互/行业分析/模式探索/社交智能等可视化功能。（更多介绍见 Davinci 官方文档^[15]）

Davinci 是支持容器化部署的，我们通过改造将 Davinci 部署到 kubernetes 平台上。方便进行资源调度。在部署和使用 Davinci 的时候也遇到了一些坑，社区支持这块还是不够及时，不过对于一个免费的工具来讲也不能过多奢求快速响应。总体来说我们用了有将近 1 年，还是比较稳定的，而且整体的消耗的资源的成本是 QuickBI 的 50 分之一不到。

最近 Davinci 的开发团队又对 Davinci 做了重构，重新做了一个功能更强的开源可视化平台: Datart（访问链接可视化平台 Datart^[16]），给初创公司的一个福利，可谓是业界良心。