不止是上云，更是上岸-低调大师

不止是上云，更是上岸

2021-12-03 504

作者

常耀国，腾讯SRE专家，现就职于PCG-大数据平台部，负责千万级QPS业务的上云、监控和自动化工作。

背景

BeaconLogServer 是灯塔 SDK 上报数据的入口，接收众多业务的数据上报，包括微视、 QQ 、腾讯视频、 QQ 浏览器、应用宝等多个业务，呈现并发大、请求大、流量突增等问题，目前 BeaconLogServer 的 QPS 达到千万级别以上，为了应对这些问题，平时需要耗费大量的人力去维护服务的容量水位，如何利用上云实现 0 人力运维是本文着重分析的。

混合云弹性伸缩

弹性伸缩整体效果

首先谈一下自动扩缩容，下图是 BeaconLogServer 混合云弹性伸缩设计的方案图

弹性伸缩方案

资源管理

先从资源管理讲起，目前 BeaconLogServer 节点个数是8000多个，需要的资源很大，单独依靠平台的公共资源，在一些节假日流量突增的时候，可能无法实现快速的扩容，因此，经过调研123平台（PAAS 平台）和算力平台（资源平台），我们采用了混合云的方式，来解决这个问题。分析 BLS 业务场景，流量突增存在下面两种情况：

日常业务负载小幅度升高，时间持续较短
春节业务负载大幅度升高，并持续一段时间针对上述的业务场景，我们采用三种资源类型来应对不同场景，具体如下表所述：

类型	场景	set
公共资源池	日常业务	bls.sh.1
算力平台	小高峰	bls.sh.2
专用资源池	春节	bls.sh.3

日常业务我们使用公共资源池+算力资源，当业务的负载小幅度上升的话，使用算力资源快速扩容，保障服务的容量水位不超过安全阈值。面对春节负载大幅度升高，这时需要构建专有资源池来应对春节的流量升高。

弹性扩缩容

上文阐述了资源的管理，那么针对不同的资源，何时开始扩容，何时开始缩容？

BeaconLogServer 日常的流量分布是 123 平台公共资源：算力平台=7:3。目前设置的自动扩容的阈值时60%，当 CPU 使用率大于60%，平台自动扩容。弹性扩缩容依赖的是 123 平台的调度功能，具体的指标设置如下：

类型	CPU自动缩容阈值	CPU自动扩容阈值	最小副本数	最大副本数
123平台公共资源池	20	60	300	1000
算力平台	40	50	300	1000
123平台专有资源池	20	60	300	1000

可以看到算力平台自动缩容阈值较大，自动扩容阈值较小，主要考虑算力平台是应对流量突增的情况，而且算力平台资源经常替换，因此优先考虑先扩容或缩容算力平台的资源。最小副本数是保障业务所需的最低资源需求，如果少于这个值，平台会自动补充。最大副本数设置1000，是因为 IAS 平台（网关平台）一个城市支持的最大 RS 节点数是1000。

问题及解决

方案推进的过程中，我们也遇到了很多问题，挑选几个问题和大家分享一下。

1）首先从接入层来讲，之前接入层业务使用的是 TGW ， TGW 有一个限制，就是RS的节点不能超过200个，目前 BeaconLogServer 的节点是8000多个，继续使用 TGW 需要申请很多个域名，迁移耗时多且不便于维护。我们调研接入层 IAS ， IAS 四层每个城市支持的节点个数是1000个，基本可以满足我们的需求，基于此，我们设计如下的解决方案如下：

总体上采用“业务+地域”模式分离流量。当集群中一个城市的 RS 节点超过500个就需要考虑拆分业务，例如公共集群的节点超出阈值，可以把当前业务量大的视频业务拆分出来，作为一个单独的集群；如果是一个独立集群的业务节点超出阈值，先考虑增加城市，把流量拆分到新的城市。如果无法新增城市，此时考虑新增一个 IAS 集群，然后在 GLSB 上按照区域把流量分配到不同的集群。

2）同一个城市不同的资源池设置不同的 set，那么IAS如何接入同一个城市不同 set 呢？北极星本来有[通配组功能]，但是 IAS 不支持 set 通配符功能实际上，我们推动 IAS 实现了通配组匹配，例如使用 bls.sh.% 可以匹配 bls.sh.1 , bls.sh.2 , bls.sh.3 。注意， IAS 通配符和北极星的不一样，北极星使用的是***， IAS 在上线的时候发现有用户使用*做单独匹配，所以使用%来表示通配符。

3）资源管理这块遇到的难点是 IAS 四层无法使用算力资源的节点，后面在经过沟通，打通了 IAS 到算力资源的。这里的解决方案是使用 SNAT 能力。

此方案的注意事项

只能绑定 IP 地址，无法拉取实例，实例销毁也不会自动解绑，需要通过控制台或 API 主动解绑（已跨账号，拉取不到实例）
如果是大规模上量：过哪些网关、哪些容量需要评估、风险控制，需要评估

单机故障自动化处理

单机故障处理效果

单机故障自动化处理，目标是实现0人力维护，如下图是我们自动化处理的截图。

单机故障处理方案

单机故障主要从系统层面和业务层面两个维度考虑，详情如下：

维度	告警项
系统层面	CPU
系统层面	内存
系统层面	网络
系统层面	磁盘
业务层面	ATTA Agent不可用
业务层面	队列过长
业务层面	发送atta数据成功率

针对单机故障，我们采用的是开源的 Prometheus +公司的 Polaris（注册中心）的方式解决。Prometheus 主要是用来采集数据和发送告警，然后通过代码把节点从 Polaris 摘除。

至于告警发生和告警恢复的处理，当告警发生的时候，首先会判断告警的节点个数，如果低于三个以下，我们直接在 Polaris 摘除节点，如果大于3个，可能是普遍的问题，这时候我们会发送告警，需要人工的介入。当告警恢复的时候，我们直接在平台重启节点，节点会重新注册 Polaris 。

ATTA Agent 异常处理

如图所示，处理流程是两条线，告警触发和告警恢复，当业务异常的时候，首先判断当前异常节点的数量，保证不会大范围的摘掉节点。然后在北极星摘除节点。当业务恢复的时候，直接重启节点。

问题及解决

主要的难点是 Prometheus Agent 的健康检查和 BeaconLogServer 节点的动态变化，对于第一个问题，目前主要是由平台方负责维护。对于第二个问题，我们利用了定时脚本从 Polaris 拉取节点和 Prometheus 热加载的能力实现的。

总结

此次上云有效的解决了自动扩缩容和单机故障这两块的问题，减少了手动操作，降低了人为操作错误风险，提升系统的稳定性。通过此次上云，也总结了几点：

迁移方案：上云之前做好迁移方案的调研，特别是依赖系统的支持的功能，降低迁移过程因系统不支持的系统性风险。
迁移过程：做好指标监控，迁移流量之后，及时观测指标，出现问题及时回滚。

关于我们

更多关于云原生的案例和知识，可关注同名【腾讯云原生】公众号~

福利：

①公众号后台回复【手册】，可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~

②公众号后台回复【系列】，可获得《15个系列100+篇超实用云原生原创干货合集》，包含Kubernetes 降本增效、K8s 性能优化实践、最佳实践等系列。

③公众号后台回复【白皮书】，可获得《腾讯云容器安全白皮书》&《降本之源-云原生成本管理白皮书v1.0》

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！

微信关注我们

原文链接：https://my.oschina.net/u/4534936/blog/5340151

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

JuiceFS 数据读写流程详解

对于文件系统而言，其读写的效率对整体的系统性能有决定性的影响，本文我们将通过介绍 JuiceFS 的读写请求处理流程，让大家对 JuiceFS 的特性有更进一步的了解。写入流程 JuiceFS 对大文件会做多级拆分（参见 JuiceFS 如何存储文件），以提高读写效率。在处理写请求时，JuiceFS 先将数据写入 Client 的内存缓冲区，并在其中按 Chunk/Slice 的形式进行管理。Chunk 是根据文件内 offset 按 64 MiB 大小拆分的连续逻辑单元，不同 Chunk 之间完全隔离。每个 Chunk 内会根据应用写请求的实际情况进一步拆分成 Slices；当新的写请求与已有的 Slice 连续或有重叠时，会直接在该 Slice 上进行更新，否则就创建新的 Slice。 Slice 是启动数据持久化的逻辑单元，其在 flush 时会先将数据按照默认 4 MiB 大小拆分成一个或多个连续的 Blocks，并上传到对象存储，每个 Block 对应一个 Object；然后再更新一次元数据，写入新的 Slice 信息。显然，在应用顺序写情况下，只需要一个不停增长的 Sli...

2021-12-03

463

2019年9月，美团外卖技术团队联合多个研发部门正式推出了React2X，面向所有的前端研发人员，特别是按业务领域划分的团队，为大家提供一个完整的、开放的多终端容器无关化（Containerless）研发框架。研发同学可以通过React2X框架快速创建、开发、构建、部署项目，在人力消耗最小的前提下，以期在不同终端上达到相对最佳的性能体验，并且能大幅降低因容器升级带来的替换和改造成本，让代码同构的复用率最大化。终端容器无关化（Containerless）：与服务无关化（Serverless）的概念类似，即在保持顶层业务研发语言不变更的情况下，在下层可以兼容性地升级、替换终端容器的能力，让用户无需关心终端容器的运维，只要将精力聚焦到业务逻辑上的技术。一、前言 React2X是一款面向多终端、跨平台、容器无关化研发框架。在整个美团前端技术栈日益规范的趋势下，React技术栈在我们技术体系环节中的地位变得越来越重要。在广告、营销这些推广属性的业务上，在各个终端（包括美团App、美团外卖App、大众点评App，以及站外的微信小程序、百度小程序、头条&抖音小程序等其他终端）实现“一次开...

2021-12-03

539

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。