域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

寫(xiě)在前面

要出發(fā)周邊游(以下簡(jiǎn)稱(chēng)要出發(fā))是國(guó)內(nèi)知名的主打「周邊游」的在線旅行網(wǎng)站，以國(guó)內(nèi)各大城市為中心，覆蓋其周邊旅游市場(chǎng)，提供包含酒店、門(mén)票、餐飲等在內(nèi)的 1 – 3 天短途旅行套餐。為了降低公司內(nèi)部各個(gè)業(yè)務(wù)模塊的耦合度，提高開(kāi)發(fā)、交付及運(yùn)維效率，我們?cè)?2017 年就基于 Spring Cloud 完成了公司內(nèi)部業(yè)務(wù)微服務(wù)化的改造，并在 2019 年實(shí)現(xiàn)了 Spring Cloud 至 UCloud UK8S 平臺(tái)的遷移。

本文從要出發(fā)的業(yè)務(wù)架構(gòu)、Prometheus JVM 監(jiān)控、基于 HPA 的峰值彈性伸縮、基于 Elastic 的APM鏈路跟蹤及 Istio 服務(wù)治理 等方面介紹了我們基于UCloud UK8S的 Spring Cloud 改造實(shí)踐。

Why K8S and Why UK8S

Spring Cloud 作為當(dāng)下主流的微服務(wù)框架，在功能層面為服務(wù)治理定義了智能路由、熔斷機(jī)制、服務(wù)注冊(cè)與發(fā)現(xiàn)等一系列的標(biāo)準(zhǔn)，并提供了對(duì)應(yīng)的庫(kù)和組件來(lái)實(shí)現(xiàn)這些標(biāo)準(zhǔn)特性，對(duì)微服務(wù)周邊環(huán)境提供了最大力度的支持。

改造前，Spring Cloud 的業(yè)務(wù)架構(gòu)如下：服務(wù)發(fā)現(xiàn)部分采用了 Spring Cloud 的 Eureka 組件，熔斷器組件采用了 Hystrix，服務(wù)網(wǎng)關(guān)使用了Zuul 和 Spring Cloud Gateway(歷史原因)，分布式配置主要采用了 Spring Cloud Config(部分小組使用了Apollo)，并通過(guò) Feign 實(shí)現(xiàn)了客戶(hù)服務(wù)端的負(fù)載均衡。

但 Spring Cloud 也有一些不可避免的缺點(diǎn)，如基于不同框架的不同組件帶來(lái)的高應(yīng)用門(mén)檻及學(xué)習(xí)成本、代碼級(jí)別對(duì)諸多組件進(jìn)行控制的需求與微服務(wù)多語(yǔ)言協(xié)作的目標(biāo)背道而馳。

在我們內(nèi)部，由于歷史原因，不同小組所使用的 API 網(wǎng)關(guān)架構(gòu)不統(tǒng)一，且存在多套 Spring Cloud，給統(tǒng)一管理造成了不便;Spring Cloud 無(wú)法實(shí)現(xiàn)灰度發(fā)布，也給公司業(yè)務(wù)發(fā)布帶來(lái)了一定不便。更重要的是，作為一家周邊游網(wǎng)站，我們經(jīng)常會(huì)舉行一些促銷(xiāo)活動(dòng)，面臨在業(yè)務(wù)峰值期資源彈性擴(kuò)縮容的需求 ，僅僅依靠 Spring Cloud 也無(wú)法實(shí)現(xiàn)資源調(diào)度來(lái)滿(mǎn)足業(yè)務(wù)自動(dòng)擴(kuò)縮容的需求。

在決定向 UCloud UK8S 轉(zhuǎn)型時(shí)，我們也考慮過(guò)使用 Kubespray 自建 K8S 集群，并通過(guò) Cloud Provider 實(shí)現(xiàn) K8S 集群與云資源的對(duì)接，例如使用 Load Balance、Storage Class、Cluster Autoscaler(CA) 等，但在這種情況下，新增 Node 節(jié)點(diǎn)需要單獨(dú)去部署安裝 Cloud Provider，給運(yùn)維工作帶來(lái)了一定的復(fù)雜性。

UCloud UK8S 實(shí)現(xiàn)了與內(nèi)部 UHost 云主機(jī)、ULB 負(fù)載均衡、UDisk 云盤(pán)等產(chǎn)品的無(wú)縫連接，我們能夠在 UK8S 集群內(nèi)部輕松創(chuàng)建、調(diào)用以上產(chǎn)品。在峰值彈性的場(chǎng)景下，也能夠通過(guò) UK8S 內(nèi)部的 CA 插件，實(shí)現(xiàn) Node 級(jí)別的資源自動(dòng)擴(kuò)縮容，極大提升了運(yùn)維效率 。通過(guò)其 CNI 插件，UCloud UK8S 與 UCloud 自身 VPC 網(wǎng)絡(luò)相連接，無(wú)需采用其他開(kāi)源網(wǎng)絡(luò)解決方案，降低了網(wǎng)絡(luò)復(fù)雜度 ;而 UK8S 原生無(wú)封裝的特質(zhì)，也給了更大的改造空間，并且能夠在出現(xiàn)故障時(shí)自己快速排查定位解決 。

整體業(yè)務(wù)架構(gòu)

從 Spring Cloud 到 UCloud UK8S 的過(guò)程，也是內(nèi)部服務(wù)模塊再次梳理、統(tǒng)一的過(guò)程，在此過(guò)程中，我們對(duì)整體業(yè)務(wù)架構(gòu)做了如下改動(dòng)：

1. 去掉原有的 Eureka，改用 Spring Cloud Kubernetes 項(xiàng)目下的 Discovery。Spring Cloud 官方推出的項(xiàng)目 Spring Cloud Kubernetes 提供了通用的接口來(lái)調(diào)用Kubernetes服務(wù)，讓 Spring Cloud 和 Spring Boot 程序能夠在 Kubernetes 環(huán)境中更好運(yùn)行。在 Kubernetes 環(huán)境中，ETCD 已經(jīng)擁有了服務(wù)發(fā)現(xiàn)所必要的信息，沒(méi)有必要再使用 Eureka，通過(guò) Discovery 就能夠獲取 Kubernetes ETCD 中注冊(cè)的服務(wù)列表進(jìn)行服務(wù)發(fā)現(xiàn)。

2. 去掉 Feign 負(fù)載均衡，改用 Spring Cloud Kubernetes Ribbon。Ribbon 負(fù)載均衡模式有 Service / Pod 兩種，在 Service 模式下，可以使用 Kubernetes 原生負(fù)載均衡，并通過(guò) Istio 實(shí)現(xiàn)服務(wù)治理。

3. 網(wǎng)關(guān)邊緣化。網(wǎng)關(guān)作為原來(lái)的入口，全部去除需要對(duì)原有代碼進(jìn)行大規(guī)模的改造，我們把原有的網(wǎng)關(guān)作為微服務(wù)部署在 Kubernetes 內(nèi)，并利用 Istio 來(lái)管理流量入口。同時(shí)，我們還去掉了熔斷器和智能路由，整體基于 Istio 實(shí)現(xiàn)服務(wù)治理。

4. 分布式配置 Config 統(tǒng)一為 Apollo。Apollo 能夠集中管理應(yīng)用在不同環(huán)境、不同集群的配置，修改后實(shí)時(shí)推送到應(yīng)用端，并且具備規(guī)范的權(quán)限、流程治理等特性。

5. 增加 Prometheus 監(jiān)控，特別是對(duì) JVM 一些參數(shù)和一些定義指標(biāo)的監(jiān)控，并基于監(jiān)控指標(biāo)實(shí)現(xiàn)了 HPA 彈性伸縮。

Kubernetes 化后業(yè)務(wù)架構(gòu)將控制平面和數(shù)據(jù)平面分開(kāi)。Kubernetes Master天然作為控制平面，實(shí)現(xiàn)整套業(yè)務(wù)的控制，不部署任何實(shí)際業(yè)務(wù)。數(shù)據(jù)平面中包含了基于 Java、PHP、Swoole、.NET Core 等不同語(yǔ)言或架構(gòu)的項(xiàng)目。由于不同語(yǔ)言對(duì)機(jī)器性能有著不同要求，我們通過(guò) Kubernetes 中節(jié)點(diǎn) Label，將各個(gè)項(xiàng)目部署在不同配置的 Node 節(jié)點(diǎn)上，做到應(yīng)用間互不干擾。

基于 Prometheus 的 JVM 監(jiān)控

在 Spring Cloud 遷移到 Kubernetes 后，我們?nèi)孕枰@取 JVM 的一系列底層參數(shù)，對(duì)服務(wù)的運(yùn)行狀態(tài)進(jìn)行實(shí)時(shí)監(jiān)控。Prometheus 是目前較為成熟的監(jiān)控插件，而 Prometheus 也提供了 Spring Cloud 插件，可以獲取到 JVM 的底層參數(shù)，進(jìn)行實(shí)時(shí)監(jiān)控。

我們?cè)O(shè)置了響應(yīng)時(shí)間、請(qǐng)求數(shù)、JVM Memory、JVM Misc、Garbage Collection 等一系列詳盡的參數(shù)，為問(wèn)題解決、業(yè)務(wù)優(yōu)化提供可靠的依據(jù)。

基于 HPA 的峰值彈性伸縮

要出發(fā)作為一家周邊游服務(wù)訂購(gòu)平臺(tái)，在業(yè)務(wù)過(guò)程中經(jīng)常會(huì)涉及到景區(qū)、酒店門(mén)票搶購(gòu)等需要峰值彈性的場(chǎng)景 。Kubernetes 的 HPA 功能為彈性伸縮場(chǎng)景提供了很好的實(shí)現(xiàn)方式。

在 Kubernetes中，HPA 通常通過(guò) Pod 的 CPU、內(nèi)存利用率等實(shí)現(xiàn)，但在 Java 中，內(nèi)存控制通過(guò) JVM 實(shí)現(xiàn)，當(dāng)內(nèi)存占用過(guò)高時(shí)，JVM 會(huì)進(jìn)行內(nèi)存回收，但 JVM 并不會(huì)返回給主機(jī)或容器，單純基于 Pod / CPU 指標(biāo)進(jìn)行集群的擴(kuò)縮容并不合理。我們通過(guò) Prometheus 獲取 Java 中 http_server_requests_seconds_count(請(qǐng)求數(shù))參數(shù)，通過(guò)適配器將其轉(zhuǎn)化成 Kubernetes API Server 能識(shí)別的參數(shù)，并基于這一指標(biāo)實(shí)時(shí)動(dòng)態(tài)調(diào)整 Pod 的數(shù)量。

UCloud UK8S 產(chǎn)品也提供了自身的集群伸縮插件，通過(guò)設(shè)置伸縮組，并匹配相應(yīng)的伸縮條件，能夠及時(shí)創(chuàng)建相應(yīng)的云主機(jī)作為 Node 節(jié)點(diǎn)，方便我們?cè)跇I(yè)務(wù)高峰時(shí)期更快速高效地拉起資源 。

基于 Elastic 的APM鏈路跟蹤

微服務(wù)框架下，一次請(qǐng)求往往需要涉及到多個(gè)服務(wù)，因此服務(wù)性能監(jiān)控和排查就變得復(fù)雜;不同服務(wù)可能由不同的團(tuán)隊(duì)開(kāi)發(fā)，甚至使用不同的編程語(yǔ)言來(lái)實(shí)現(xiàn);服務(wù)有可能部署在幾千臺(tái)服務(wù)器，橫跨多個(gè)不同的數(shù)據(jù)中心。

因此，就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問(wèn)題的工具，以便發(fā)生故障的時(shí)候，能夠快速定位和解決問(wèn)題。

目前市面有很多開(kāi)源的APM組件，Zipkin、Pinpoint、Skywalking等等。我們最終選擇了基于Elastic開(kāi)源的apm-server。正是由于市面上有太多的監(jiān)控開(kāi)源項(xiàng)目，但是各項(xiàng)目之間無(wú)法很好的互通。 而Elastic通過(guò)filebeat收集業(yè)務(wù)日志，通過(guò)metricbeat監(jiān)控應(yīng)用服務(wù)性能，通過(guò)apm-server實(shí)現(xiàn)服務(wù)間的tracing，并把數(shù)據(jù)統(tǒng)一存放在es，很好的將logging、metrics、tracing整合到一起，打破了各項(xiàng)目之間的壁壘，能夠更快速的協(xié)助運(yùn)維及開(kāi)發(fā)定位故障，保障系統(tǒng)的穩(wěn)定性。

Istio 服務(wù)治理

基于應(yīng)用程序安全性、可觀察性、持續(xù)部署、彈性伸縮和性能、對(duì)開(kāi)源工具的集成、開(kāi)源控制平面的支持、方案成熟度等考慮，我們最終選擇了 Istio 作為服務(wù)治理的方案，主要涉及以下幾個(gè)部分：

1. Istio-gateway 網(wǎng)關(guān)：Ingress Gateway 在邏輯上相當(dāng)于網(wǎng)格邊緣的一個(gè)負(fù)載均衡器，用于接收和處理網(wǎng)格邊緣出站和入站的網(wǎng)絡(luò)連接，其中包含開(kāi)放端口和TLS的配置等內(nèi)容，實(shí)現(xiàn)集群內(nèi)部南北流量的治理。

2. Mesh 網(wǎng)關(guān)：Istio內(nèi)部的虛擬Gateway，代表網(wǎng)格內(nèi)部的所有Sidecar，實(shí)現(xiàn)所有網(wǎng)格內(nèi)部服務(wù)之間的互相通信，即東西流量的治理。

3. 流量管理：在去除掉 Spring Cloud 原有的熔斷、智能路由等組件后，我們通過(guò)對(duì) Kubernetes 集群內(nèi)部一系列的配置和管理，實(shí)現(xiàn)了 http 流量管理的功能。包括使用 Pod簽對(duì)具體的服務(wù)進(jìn)程進(jìn)行分組(例如 V1/V2 版本應(yīng)用)并實(shí)現(xiàn)流量調(diào)度，通過(guò) Istio 內(nèi)的 Destination Rule 單獨(dú)定義服務(wù)負(fù)載均衡策略，根據(jù)來(lái)源服務(wù)、URL 進(jìn)行重定向?qū)崿F(xiàn)目標(biāo)路由分流等，通過(guò) MenQuota、RedisQuota 進(jìn)行限流等。

4. 遙測(cè)：通過(guò) Prometheus 獲取遙測(cè)數(shù)據(jù)，實(shí)現(xiàn)灰度項(xiàng)目成功率、東西南北流量區(qū)分、服務(wù)峰值流量、服務(wù)動(dòng)態(tài)拓?fù)涞谋O(jiān)控。

總結(jié)

目前我們已將旗下「云客贊」社交電商 App 全部遷移至 UK8S，開(kāi)發(fā)語(yǔ)言包括Java、PHP-FPM、NodeJS 等等。結(jié)合CI/CD，能快速實(shí)現(xiàn)服務(wù)迭代以及新項(xiàng)目上線，大大提升了開(kāi)發(fā)以及運(yùn)維的工作效率;通過(guò)完善的日志、監(jiān)控、鏈路跟蹤及告警系統(tǒng)，能夠快速的定位故障，并且根據(jù)遙測(cè)數(shù)據(jù)提前預(yù)判峰值，通過(guò)HPA實(shí)現(xiàn)服務(wù)自動(dòng)伸縮，科學(xué)的分配資源，大大降低了計(jì)算資源成本;通過(guò)Istio服務(wù)治理，很好的實(shí)現(xiàn)了流量的管理，并且基于此輕松的實(shí)現(xiàn)了灰度發(fā)布。

接下來(lái)，我們將更加豐富CI/CD流水線，加入單元測(cè)試、代碼掃描、性能測(cè)試等提升測(cè)試效率;引入chatops豐富運(yùn)維手段;借助Istio實(shí)現(xiàn)多云管理進(jìn)一步保障業(yè)務(wù)的穩(wěn)定性。

作者：王瓊，「要出發(fā)周邊游」運(yùn)維架構(gòu)師兼運(yùn)維經(jīng)理，負(fù)責(zé)公司云原生落地和企業(yè)容器化改造。2016年開(kāi)始接觸K8S，在K8S以及Service Mesh領(lǐng)域持續(xù)深耕，致力于搭建生產(chǎn)級(jí)可用的容器服務(wù)平臺(tái)。

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！