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