其他
资源利用率提高67%,腾讯实时风控平台云原生容器化之路
陈建平,后台开发工程师,现就职于TEG安全平台部-业务安全中心,主要负责中心实时策略风控平台开发。
导语
水滴后台架构
自研上云实践
Monitor 监控系统与 TKE 未打通,继续采用 Monitor 指标监控系统的话将需要大量的人工介入;
应对突发流量情况需要人为进行扩缩容,过于麻烦且不及时;
TKE 支持北极星规则,原有 CL5(Cloud Load Balance 99.999%) 存在部分问题。
指标监控改造
Monitor 监控系统问题
TKE 未与 Monitor 监控系统打通,云上实例 IP 地址发生变化时需人工添加对应容器实例 IP 到 Monitor 系统中,且云场景下实例 IP 频繁变动难于维护;
Monitor 指标针对 NAT 网络模式下的容器实例指标无法实例级别的区分,NAT 网络模式下相同属性指标,不利于实例级别的指标查看;
Monitor 监控系统灵活性较差,有新的属性增加时需要申请属性 ID 并调整更新代码实现。
智研指标改造过程
智研告警通知优化
路由分发优化
路由分发问题
CL5 首次查询某一个 SID 的节点时,容易遇到以下-9998的问题。
CL5 SDK 无法进行 NAT 网络模式下的就近访问,在异地服务情况下数据请求容易出现超时情况。
迁移北极星(腾讯服务发现治理平台)改造
//***********************获取服务实例***************************
// 构造单个服务的请求对象
getInstancesReq = &api.GetOneInstanceRequest{}
getInstancesReq.FlowID = atomic.AddUint64(&flowId, 1)
getInstancesReq.Namespace = papi.Namespace
getInstancesReq.Service = name
// 进行服务发现,获取单一服务实例
getInstResp, err := consumer.GetOneInstance(getInstancesReq)
if nil != err {
return nil, err
}
targetInstance := getInstResp.Instances[0]
//************************服务调用上报*************************
// 构造请求,进行服务调用结果上报
svcCallResult := &api.ServiceCallResult{}
// 设置被调的实例信息
svcCallResult.SetCalledInstance(targetInstance)
// 设置服务调用结果,枚举,成功或者失败
if result >= 0 {
svcCallResult.SetRetStatus(api.RetSuccess)
} else {
svcCallResult.SetRetStatus(api.RetFail)
}
// 设置服务调用返回码
svcCallResult.SetRetCode(result)
// 设置服务调用时延信息
svcCallResult.SetDelay(time.Duration(usetime))
// 执行调用结果上报
consumer.UpdateServiceCallResult(svcCallResult)
容器化改造
物理机部署情况
任务创建:新增加任务情况时,需要申请新任务对应的北极星名称服务地址,将任务的 engine 进程部署在不同的物理机上启动,并手动将 engine 实例与北极星名称服务绑定,需要人工手动进行进程的启动和管理、添加和修改对应的负载均衡服务,管理复杂,运维成本高。
任务升级:任务程序升级过程,需要将任务对应的所有 engine 进程程序进行更新,并重启所有相关的 engine 进程。
任务扩缩容:任务进行扩容过程,需要进行在物理机上部署并启动新的 engine 进程,再将新进程实例加入到对应的北极星名称服务中;任务进行缩容过程,需要将缩容进程先从北极星名称服务中剔除,再对相应 engine 进程进行暂停。服务扩缩容流程类似于服务升级过程。
TKE 平台部署情况
任务创建:新增加任务情况时,需要申请新任务对应的北极星名称服务地址,再在 TKE 平台进行任务对应 engine 应用实例创建。
任务升级:任务程序升级过程,更新任务对应 engine 实例镜像版本即可。
任务扩缩容:任务进行扩缩容过程,在 TKE 平台页面通过设置 HPA(Horizontal Pod Autoscaler) 自动调应用实例的扩缩容。
云原生成熟度提升经验
对不同的业务类型进行服务划分,CPU 密集型服务创建核数大的 Pod 服务,IO 密集型服务(目前主要应对瞬时流量业务情况,网络缓冲区易成为瓶颈)创建核数偏小的 Pod 服务, 如 CPU 密集型业务单 Pod 取4核,而瞬时突发流量服务单 Pod 取0.25核或0.5核 。 容器服务采用 HPA 机制,业务接入时根据业务请求量预估所需的 CPU 和内存资源,由预估的 CPU 和内存资源设置 Pod 服务的 Request 值,通常保持 Request 值为 Limit 值的50%左右。
自研上云效果
上云资源申请流程更加简单快速,上云前机器申领搬迁、虚拟 IP 申请、机器转移等流程周期一周左右,上云后资源申请周期缩短为小时级别。 机器资源利用率提高67%,上云前 CPU 利用率约36%,上云后 CPU 利用率59.9%。 应对突发流量无需人工进行扩缩容操作,通过 HPA 机制可完成扩缩容,从人工扩缩容周期15分钟左右缩短到一两分钟。 业务策略部署上线周期可由2小时缩短至10分钟。
互动赢好礼
精读文章,回答问题赢好礼
Q1: 业务上云过程中,有什么可以提升资源使用率的经验?
Q2: 业务上云过程中,有哪些服务无状态化改造经验?8月21日上午12点,由作者选出回答最佳的2位读者,送出可爱蓝鹅一只。
往期精选推荐