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

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

—元年科技 CTO 杨熠

元年科技业务使用 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 对比

本文转载自公众号 UCloud 技术（ID：ucloud_tech）。

原文链接：

https://mp.weixin.qq.com/s/JqN6vw5yh6uykKhz1-agTQ