关于腾讯云:用户案例-腾讯医疗资讯平台云原生容器化之路

44次阅读

共计 2569 个字符,预计需要花费 7 分钟才能阅读完成。

作者

yuhuliu,腾讯研发工程师,关注存储、大数据、云原生畛域。

摘要

医疗资讯业务在高速倒退过程中,造成了笼罩不同场景、不同用户、不同渠道的几十个业务,以及上千个服务。为了高效满足用户多样化的需要,医疗技术团队通过 TKE 上云,应用 Coding DevOps 平台,以及云上可观测技术,来晋升研发效率、升高经营运维老本。本文介绍咱们在上云过程中一些实际和教训,以及一些思考和抉择。

业务背景

  • stage1: 医疗资讯次要包含了医典、医生、医药等外围业务,其中医典次要提供医疗相干内容获取、医疗常识科普传递;医生满足医生和患者的互联;医药服务了宽广药企。在业务倒退过程中咱们原来基于 taf 平台构建了大量后盾服务,实现了初期业务的疾速搭建。因为业务数量较多,大量业务有多地区的述求,最终咱们在 taf 平台部署多个业务集群。这个时候公布、运维、问题排查纯靠人工阶段,效率较低。

业务上云

  • stage2: 随着业务规模的急速扩张,传统的开发、运维形式在麻利、资源、效率方面对业务迭代造成较大的制约。随着公司自研上云我的项目推动,拥抱云原生化,基于 K8s 来满足业务对不同资源多样化需要和弹性调度,基于现有成熟 devops 平台来进行麻利迭代,越来越成为业务正确的抉择。医疗后盾团队开始了整体服务上云的迁徙。
  • 上云之前,还有几个问题须要思考

​ 1:服务泛滥,代码如何治理

​ 2:上云后怎么疾速进行问题定位、排查

​ 3:监控告警平台如何抉择

​ 4:根底镜像怎么抉择

对于服务代码治理

应用 git 做代码版本控制,按业务建设项目组,每个服务应用独自的代码仓库,仓库名应用同一命名标准。

对于问题排查

调研云上有成熟的 elk 服务,业务只须要把日志放到同一目录,通过 filebeat 采集后,通过 ETL 逻辑能够把日志不便导入 Elasticsearch。这样的做法还有个长处就是能够同时反对前后端服务日志的采集,技术较为成熟,复用了组件能力,通过在申请中埋点退出 traceid,不便在全链路定位问题。

对于监控告警平台

CSIG 提供了基于日志监控的 CMS 平台,将业务日志导入到 CMS 后,能够基于上报的日志配置监控和告警,监控维度、指标业务能够本人定义。咱们采纳了主调、被调、接口名等维度,调用量、耗时、失败率等指标,满足业务监控告警诉求。基于日志的监控能够复用同一条数据采集链路,零碎架构对立简洁。

对于根底镜像

为了不便业务初期疾速上云,以及对立服务启动、数据采集上报,有必要对业务的根底镜像进行解决,事后建设对应目录,提供脚本和工具,不便业务疾速接入。这里咱们提供了不同语言、版本的根底镜像,封装了 supervisord 和 filebeat,通过 supervisord 来拉起 filebeat 和业务服务。

Devops

  • stage2: 在上云过程中,也通过和品质同学逐步完善,将开发过程中原有人工操作的步骤 pipeline 化,来进步迭代效率,标准开发流程;通过单测和自动化拨测,晋升服务稳定性。采纳对立的流水线后,开发、部署效率从原来的小时级别升高到分钟级别。

这里次要应用了 coding 平台,为了辨别不同环境,建设了开发、测试、预公布、测试四套不同流水线模板,还引入了合流机制来退出人工 code review 阶段。

在合流阶段:通过 MR HOOK,主动轮询 code review 后果,确保代码在 review 通过后能力进行下一步(不同团队可能要求不一样)。

在 CI 阶段:通过代码品质剖析,来晋升代码规范性,通过单元测试,来保障服务质量。

在 CD 阶段:通过引入人工审批和自动化拨测,进步服务稳定性。

资源利用率晋升

  • stage3:在业务整体上云后,因为不少业务有多地区部署(广州、南京、天津、香港)的述求,加上每个服务须要四套(开发、测试、预公布、正式)不同的环境,上云后咱们初步整顿,一共有 3000+ 不同 workload。因为不同业务访问量具备很大不确定性,初期基本上依照现实状态来配置资源,存在不少的节约。

为了进步资源整体利用率,咱们进行了一系列优化,大抵遵循如下标准:

这里因为 HPA 会导致业务容器动静扩缩,在进行过程中如果原有流量还在拜访,或者启动还未实现就导入流量,会导致业务的失败,因而须要须要事后开启 TKE 上 preStop 以及就绪检测等配置。

1:优雅进行,过程进行前等北极星、cl5 路由缓存过期;
入口:tke-> 工作负载 -> 具体业务 -> 更新工作负载
如果应用的服务发现是 CL5,举荐 preStop70s,北极星配置 10s 足够了

2:就绪、存活检测,过程启动实现后再调配流量;
入口:tke-> 工作负载 -> 具体业务 -> 更新工作负载,依据不同业务配置不同探测形式和工夫距离。

通过下面一系列调整优化,咱们的资源利用率大幅晋升,通过 TKE 上弹性升缩,在保障业务失常拜访同时,部分顶峰拜访资源有余的问题根本解决,防止了资源节约,也晋升了服务稳定性;但多环境问题还是会导致存在肯定损耗。

可观测性技术

  • stage4:初期应用基于日志的形式来做(log/metric/tracing),满足了业务疾速上云、问题排查效率晋升的初步述求,但随着业务规模增长,更加宏大的日志流占用了越来越多的资源,日志沉积在高峰期成为常态,CMS 告警可能和理论产生时曾经距离了半个小时,ELK 的保护老本也急剧回升。云原生的可观测技术曾经成为必要,这里咱们引入了 Coding 利用管理所举荐的可观测技术计划,通过对立的 coding-sidecar 对业务数据进行采集:

监控:云监控中台

日志:CLS

Tracing:APM

通过接入这些平台的能力,咱们的问题发现、定位、排查效率有了极大的进步,业务的经营保护老本较大升高,通过监控、和 tracing,也发现了不少零碎潜在的问题,进步了服务质量。

结尾

最初,要感激上云过程中整体开发同学的辛勤付出,以及各位研发 leader 的大力支持。

对于咱们

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

福利:

①公众号后盾回复【手册】,可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~

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

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

正文完
 0