基于云的技术架构设计实践 - 第 1 篇

作者：hackstoic

2021 年 12 月 02 日
本文字数：3723 字
阅读完需：约 12 分钟

业务部署

开篇的时候，先分析了业务的情况和设计了业务架构。这一篇讲讲如何针对业务需求进行技术部署和相关的技术选型。

代码管理

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

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

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

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

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

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

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

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

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

前端部署

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

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

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

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

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

【我们踩过的一些坑】

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

【我们的解决方案】

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

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

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

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

后端部署

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

代码管理

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

镜像管理

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

【我们踩过的一些坑】

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

【我们的解决方案】

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

容器调度

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

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

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

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

【我们踩过的一些坑】

内部的 kube-dns（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 网关的一些实践。