利用UK8S落地微服务,加速元年科技业务迭代 | U刻
技术分享/

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

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

    “使用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、微服务、分布式技术等热门话题,诚邀广大技术开发者扫描下方二维码参与报名,共享技术盛宴!