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