云服务 利用 UK8S 落地微服务,加速元年科技业务迭代

ucloudcn · 2019年05月17日 · 5820 次阅读

“使用 UK8S,开发者可以像使用普通云服务器一样迅速搭建 K8S 环境。在享受 K8S 带来的便利的同时,能够让开发人员集中注意力在业务实现的细节,而不必在基础架构搭建上浪费太多的精力。UCloud 为此提供的专业、快速的服务和响应机制帮助我们成功的将整个环境从自建 K8S 平滑迁移到 UK8S。UCloud 的 UK8S 如同其它的基础服务一样稳定,使我们相信‘让专业的人做专业的事’,选择 UCloud 作为我们的云服务提供商是我们在技术选型上做出的正确选择之一。”

—元年科技 CTO 杨熠

写在开始

本文主要介绍 UK8S 在公有云场景中的实践案例,后续即将推出在混合云模式下的案例分享。

元年科技业务使用 UK8S 的效果

业务上引入 UK8S 落地微服务,目的并非是节约云主机资源,而是节省人工成本,使得开发人员可更专注于业务实现;可降低系统耦合度、研发难度,从而更高效合理的调度主机集群资源;提高团队整体交付效率,实现时间成本的节约,最终转化为业务迭代的加速。

关于元年科技

自 2000 年成立起,一直专注于以管理会计为核心的管理咨询和管理信息化领域,致力于成为“中国管理会计领航者”,帮助中国企业实现财务转型和管理精细化。

元年科技的专业服务和软件平台涵盖企业运营以及管理的四个层面:以管理会计为核心,支持企业分析模拟、决策支持和管理控制;以财务共享为核心,推动财务转型、提升企业运营效率;基于商业智能平台和大数据,实现客户分析、销售分析、运营分析;以企业信息化规划和互联网转型为核心,提供集团管控体系、组织和流程优化等咨询服务。

云快报的业务场景和架构

云快报是元年科技旗下一款商旅及支出管理 SaaS 产品。采用云计算和移动互联网技术开发,凝聚了众多行业、企业费用管理的最佳实践,满足广大企业提升业务能力、规范业务行为、管控业务费用的核心需求,同时集成了同程、艺龙、滴滴、京东等互联网消费平台, 将差旅申请、消费和报销流程打通,此外还整合发票查验、智能记账、多种财务接口,让企业的费用管控更高效,更清晰透明。

该产品中的 商城业务采用巨石与微服务结合的架构模式 ,包含商城端以及商城服务端两部分内容。商城端目前仍使用传统巨石结构, 也正在改造中,主要负责买卖双方的管理,涵盖商户管理、购物商城、管理后台等服务。由于云快报中接入的商户并未实际在商城中开店,遂引入对接端的概念,完成对远端商户的真实下单操作。

商城用户在购物商城中下单并完成支付后,对接端将订单通过 API 服务提交至商城服务端进行真实下单,商城服务端采用微服务架构, 每类服务之间既相互独立又维持协作的关系。此外,针对搜索服务,云快报选择将微服务架构与 Solr 结合的方式,实现供应电商系统中商品的定时同步,以及推送至 Solr 中提供搜索服务。

图:云快报商城业务架构图

引入 K8S,解决业务痛点

微服务架构下,元年科技开发人员发现使用 K8S 比原先云主机部署模式在如下场景中可更为有效的解决问题。

痛点一:新服务的上线以及原有服务的更新过程繁杂

一方面,若要在既有云主机上发布全新的服务,需考虑不同类型语言要求不一致的问题,从基础环境到启动脚本,内容十分零散,整个发布过程相当复杂;另一方面,若要更新已存在的服务,脚本语言可使用热更新,但编译类语言又面临同样的困境。

常规做法是由 nginx 在服务前面做一个负载的代理,人工操作切换负载来保证非中断服务方式的更新,但当服务数量较多时,人工操作负担大。

K8S 下可利用容器技术的自包含自描述解决多种编程语言更新的问题,并实现零散发布内容的整合;此外,使用 K8S 的应用编排能力进行发布,可解决微服务架构下复杂的多应用依赖发布的问题,同时还可降低误操作概率。

痛点二:动态服务迁移操作难度大

图:动态服务迁移示意图

由于云主机资源的限制,为了给特定服务提供资源升级的空间,常常需要动态的将其余正在执行的服务迁移至新的云主机。如上图所示,服务 11 要由 0.5 核 CPU 升级为 1 核 CPU,此时需要把服务 07 和 12 迁移至别的节点中,再对服务 11 进行升级操作。

未使用 K8S 的情况下,为了防止业务中断,通常会将服务 07 和服务 12 在节点 05 中进行部署,更改服务发现后再将节点 02 中资源清除。而 K8S 中只需更改服务 07 和 12 的 nodeSelector,即可将服务 07 和 12 实现迁移,在保障服务不中断的前提下快速满足服务 11 的扩容需求。

痛点三:线上服务健康检查复杂度高

为了保证线上服务的存活,需安装多类别的检测监控软件,安装软件工作量大,并且只能作为报警提醒,无法协助后续处理。

利用 K8S 的健康检查机制,可以通过请求服务的健康检查接口来检测服务的工作状态,并根据响应码判识状态是否正常,若处于非正常状态,K8S 会自动执行 Pod 的销毁重建,保障服务正常工作。

痛点四:服务之间的调用和发现配置工作多

图:服务调用与发现示意图

实际应用中,会需要服务之间的内部调用。但不同环境下,调用相同的服务由于内部 IP 无法固定,需要额外增加多个配置文件,且每个环境下对应一套,服务数量较多时,配置工作繁重。

而 K8S 的服务发现基于 Service 加 DNS 解析实现,完成服务发现的同时具备负载。如上图所示,服务 16 访问服务 18 的时候会先由 K8S 内部的 DNS 来获取服务 18 的 Service 代理 IP,再访问服务 18-proxy。

痛点五:单个服务完全消耗云主机资源

原有的部署模式下,单台云主机上同时运行多个服务,并且没有对每个服务的 CPU、内存以及磁盘 IO 进行限制,导致出现单个服务负载过高,将整台主机资源耗尽,从而主机卡住的情况,此时再扩展新的资源部署服务,整个恢复过程较为漫长。

K8S 中可对服务的 CPU、内存使用量进行限制,有效减少运行在同一台主机上服务资源争抢问题。

由自建 K8S 迁移至 UK8S

元年科技业务中共有两套 K8S 集群,一套是运行在线下内网环境中的自建 K8S 集群,直接使用 Rancher 搭建和管理,另一套运行在 UCloud 公有云环境中,先前也是自建的 K8S 集群。考虑到 UK8S 相较于自建 K8S 集群有如下几点优势,最终选择从自建 K8S 集群迁移至 UK8S。

表:UK8S 与自建 K8S 对比

—END —

欢迎扫描下方二维码,加入 UCloud K8S 技术交流群,和我们共同探讨 Kubernetes 前沿技术。(如显示群人数已加满,可添加群主微信 zhaoqi628543,备注 K8S 即可邀请入群。)

TIC 2019 报名火热进行中,欢迎加入我们共同探讨 Kubernetes 的技术实践!UCloud 实验室负责人叶理灯将于 技术专场 A 带来更多 Kubernetes 技术干货。除此之外,技术专场还汇集了 Serverless、微服务、分布式技术等 热门话题,诚邀广大技术开发者扫描下方二维码参与报名,共享技术盛宴!

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请 注册新账号