利用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、微服務、分佈式技術等 熱門話題，誠邀廣大技術開發者掃描下方二維碼參與報名，共享技術盛宴！