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

相關推薦