云計算敏捷團隊的 10 個最佳實踐工具
2022-10-19 19:08 云物互聯 閱讀(322) 評論(0) 收藏 舉報前言
2020 年以來,隨著國家在 “新基建” 領域的政策導向,推動云計算自 2017 年后再次迎來了新一輪的發展機遇。同時,由于新冠疫情黑天鵝從根本上沖擊了企業的業務模式乃至經營安全,促進企業加速完成數字化轉型,也對云計算的應用效能提出了新的需求。
我們觀察到,隨著企業數字化轉型的進一步深化,云計算和云原生技術已經成為了 CIO 和 CDO 們首要考慮的業務增長因素之一。隨之的,也有越來越多傳統領域的企業主們開始著手組建專業的云 IT 團隊。可以說,在后疫情的今天,依托于企業上云的數字化轉型需求比以往任何時候都更加強烈。作為云計算敏捷研發團隊中的一員,筆者也正在親身經歷著這場變革,并希望可以通過文章的形式來記錄下一些心得與經驗,拋磚引玉。
工欲善其事,必先利其器。本篇就先從我認為的 10 個云計算敏捷團隊最佳實踐工具說起。
1. Docker
在實踐 Container 之前,當我們要部署或更新一個應用程序時,就要運維同事對物理服務器進行頻繁的配置修改。這并不是一件容易的工作,尤其在分布式軟件架構要求的大規模服務器場景中,除了工作量繁重之外,往往需要面對較高的人為失誤導致的故障風險。現在,我們將這種 IT 模式歸類為一種 “可變基礎設施” 范式,即:在交付軟件的時候,需要連帶著對硬件服務器進行相應的適配變更。
相對的,Container 提出的是一種 “不可變基礎設施” 范例,這意味著當我們采用 Container 的方式進行軟件交付時,可以不對物理服務器進行任何更改。這得益于 Container 的本質是一種操作系統虛擬化技術(OS-level virtualization),其帶來的好處包括:更高的運行環境兼容性,以及更簡單且可預測的部署過程,可以有效緩解甚至完全防止可變基礎架構中常見的問題,例如:配置漂移和雪花服務器。
Container 技術的誕生最早可追溯到 1979 年 Unix 引入的 chroot 技術,但直到 2013 年,dotCloud 公司(后改名 Docker)推出 Docker 技術并提出 “Build, Ship and Run” 和 “Build?once, Run?anywhere” 的口號后,才真正掀起了 IT 行業對 Container 技術的熱情。
雖然,隨著 Container 技術的發展,Docker 早已經不是唯一的選擇。Docker 公司甚至一度將企業業務線(Docker Enterprise)打包出售給了 Mirantis。但好在 Docker 公司及時轉型專注于開發者群體,在開發者業務線(Docker Developer Desktop)上穩住了陣腳,至今仍是最受到敏捷開發團隊歡迎的實踐工具之一。

2. Kubernetes
伴隨著 Container 技術成長起來的還有 Container Orchestration 技術,目前 Kubernetes 已經是該領域的事實標準。如果我們將 Container 類比為 Linux 上的 Application,那么 Kubernetes 就是云原生時代的 Linux 操作系統。
最初,Google 開源 Kubernetes 項目的初衷就是為了提供一種方便、快速、優雅地 Containers 編排平臺。通過將 Kubernetes 提供的 “容器編排能力” 和 Container 提供的 “不可變基礎設施能力” 有機的結合起來,使得底層基礎設施更加標準化,用戶可以不必操心底層資源管理的問題,在降低了復雜度的同時還有助于提升資源的利用率。
近年來,隨著 Kubernetes 技術的成熟以及 Microservice architecture 生態的完善,我們不再局限于將 Kubernetes 作為一個 Containers 的編排平臺,而是進一步地將 Kubernetes 定位為一個 “Platform for Platform” 項目,即:“用來構建分布式系統的分布式系統”。在開發微服務架構應用時,將 Kubernetes 作為基礎設施層底座進行打包和整體交付,以此來實現了更高層次的基礎設施抽象層。

3. 騰訊云 Serverless
Serverless Computing(無服務器計算)是當前最重要的云原生技術發展方向之一,是一種從底層開始的技術變革,被業界認為是繼虛擬化、容器技術之后的第 3 代通用計算平臺。而 FaaS(Function as a Service,函數即服務)和 BaaS(Backend as a Service,后端即服務)則是由 Serverless 技術所衍生出來的 2 個主流云服務模式。
據 Gartner 統計,2020 年全球有 20% 的企業采用了 Serverless 技術部署。在關注到這一趨勢后,我們就開始考慮如何將 Serverless 技術應用于新型業務創新以及 IT 研發管理創新之上,并在騰訊云 SCF (Serverless Cloud Function,云函數)服務中得到了驗證。

在傳統的研發模式中,當我們的研發人員需要擴展一個新的基于 RESTful API 的微服務組件時,往往需要全局考慮到編程語言的選擇、Web 開發框架的版本、運行時環境的設置、底層資源的利用率、性能以及高可用集群橫向擴展的部署配置等等一系列的因素。在以往,這是行之有效的一套方法論,但顯然,也存在著開發周期長,開發小組之間的溝通協作成本高,需求變更慢的情況。
針對這些問題,我們評估并確定了可以通過 Serverless 來進行優化,并基于騰訊云 Serverless Framework 一站式開發平臺和工具來完成了架構改造。Serverless 因為其提供的是 Function-let(函數式)的計算單元,所以非常適用于 Stateless(無狀態)業務類型,將微服務架構中的無狀態代碼邏輯(e.g. 外部系統資源對接程序),通過簡單的代碼實現即可快速上線一個功能,無需再花費一個較長的周期。

另外,在傳統的業務部署場景中,運維人員需要根據以往的數據經驗對流量洪峰發生的時間進行預測,并提前通過手動的方式對云 IT 資源作擴容部署。然而,在需求變化越來越快的今天,這種僵化的 IT 資產管理方式已經不再適用。
所以,針對此類具有時間周期特性的高并發請求業務,我們利用騰訊云 Serverless 基于事件觸發的自動伸縮機制進行優化。實現了只有當業務請求到達時,才會啟動相應的進程來進行響應,能夠更加隨心所欲的去應對流量洪峰。
從上述兩個方面可以看出,騰訊云 Serverless 從根本上改變了我們的 IT 研發模式。通過 Serverless 我們可以更加低成本且高效的去探索新型業務場景、對 MVP(最小可用模型)進行快速驗證。更重要的是,在整個 Serverless 服務體驗中,用戶只需為 “真正的業務資源” 付費,而不需要為周邊的基礎設施付費,真正的實現了云計算的核心價值就是 “敏捷、彈性和按需付費”。
- Serverfull:需要研發人員和運維人員一起負責將服務上線且保證服務穩定。
- Serverless:重新定義了服務邊界,讓研發人員更少的關心服務資源,專注于業務本身,并且擺脫運維工作的困擾。

4. Minikube
在以往,應用程序交付是運維團隊的專屬工作,現如今隨著 DevOps 的實踐價值被得到了證明,越來越多的企業也開始將運維團隊轉型為運維開發部門。同樣,越來越多程序員的工作平臺也從最初的 Windows 遷移到了 Linux 再遷移到了現在的 Kubernetes 之上。
但是,Kubernetes 作為一個分布式的平臺系統,想掌握和運行它顯然存在一定的門檻。針對這一問題,Kubernetes 社區推出了 Minikube 項目,作為一種專為學習者和云原生開發者打造的輕量化 Kubernetes 集群管理工具。通過 Minikube,開發者完全可以基于自己的開發機器來運行一套 Kubernetes 運行環境,并支持 Kubernetes 的大部分功能,極大的幫助研發人員節省了搭建研發調試環境的時間。

5. Helm
如果我們將 Container 類似為 Linux 上的 Application,將 Kubernetes 類似為 Linux 本身,那么 Helm 就是 Linux 上的 Application Software Package 管理工具了(e.g. CentOS yum or Ubuntu apt etc..)。
在 Kubernetes 中部署一個應用程序,往往涉及多個 Kubernetes Resources 之間的共同協作。例如:當我們部署一個 WordPress 應用時,可能會使用到 Deployment(執行部署)、Service(提供服務發現)、Secret(配置 WordPress 的用戶名和密碼)、PV/PVC(提供持久化存儲服務)等多種 Resources API。更甚的,WordPress 還會依賴 MariaDB 等等其他應用。隨著 Micro-services 架構的流行,在 Kubernetes 之上部署的 Applications 實際上已經變得非常復雜,再通過原始的 YAML 方式進行部署顯然不現實。
Helm 就是解決 Micro-services Application 在 Kubernetes Cluster 上進行便捷安裝、卸載和更新的實踐工具。使用戶能夠簡單高效地查找、下載、安裝指定的應用。當我們向客戶交付一個云原生應用時,必然會使用 Helm 工具進行打包,以及來提供更優雅的部署體驗和最佳運維實踐。

6. Ansible
在云計算環境中,一個現代化的自動化的運維工具能夠有效的幫助團隊管理和使用一個相對復雜且大規模的 IT 基礎設施集群,包括:全面的部署自動化以及云計算環境中的快速服務器配置等等。
Ansible 就是目前最佳的 IT 自動化運維工具之一。相比于其他自動化運維工具,Ansible 的主要特點有 2 個:首先,Ansibel 的底層基于 OpenSSH 實現,所以無需在客戶主機和目標主機安裝任何代理程序,所以也不存在由于卸載了代理程序故障導致的主機失聯問題。這一特性,使得 Ansible 可以被應用于幾乎任何能夠被 SSH 的服務器;其次,Ansible 通過 Playbook(劇本)的方式來組織代碼邏輯,具有非常優秀的 “模塊化” 編程理念,通過對 Playbook YAML Module 的編寫,開發者可以重復利用不同的功能模塊來靈活實現一個復雜的功能。

7. EFK
隨著 Micro-services 應用軟件的復雜度越來越高,特別是部署到云上之后,再想登錄到大規模分布式部署的各個節點上查看各個進程模塊的日志信息,幾乎是不可行的。不僅僅是效率低下,更因為出于安全性的考慮,云主機或服務器不能隨意讓工程師直接訪問。而且在云原生的環境中,Pod 的彈性擴展和漂移特性都讓分布式系統的日志查看更加困難。
所以在云原生時代,我們需要一個集中式的日志審計系統來幫助完成日志收集、過濾、檢索的工具。甚至還可以進行基于大數據的統計和分析,用于支撐閉環的智能運維。
EFK 就是一個面向分布式系統的集中式日志解決方案,由 Elasticsearch、Fluentd 和 Kibana 這 3 款開源軟件產品的首字母縮寫,簡稱為 EFK Stack。

8. Swagger/OpenAPI
Swagger Specification 是一種 API Specification(API 規范),2015 年,SmartBear Software 將 Swagger Specification 捐贈給 Linux Foundation,并改稱為 OpenAPI Specification,簡稱(OAS)。
OpenAPI Specification 本質上是一種 RESTful API 的 API Description Format(描述格式),允許用戶用于描述整個 API。OpenAPI 規范可以用 YAML 或 JSON 編寫,包括:
- 每個 API 的可用端點(e.g. /users)和操作(e.g. GET /users,POST /users)。
- 操作參數每個操作的輸入和輸出。
- 認證方式。
- 聯系信息,許可證,使用條款和其他信息。
在敏捷團隊的實踐中,基于 API 的協作至關重要,Swagger/OpenAPI 可以基于規范的方式來支撐 Design First 的 API 協作模式,快速拉通各微服務組件之間的協同研發。
Design-First 具有很多好處:
- 提高開發效率。開發團隊將根據 API 規范進行并行開發和對接工作,而無需等待接口邏輯開發完畢。
- 降低接口開發的成本,無需修改代碼邏輯即可輕松地修改 API 規范,因為 API 描述語言(如:OpenAPI)與編碼語言無關。
- 開發人員更加專注于設計 API 規范,對比 Code-First 可以描寫更多 API 的細節,如:校驗規則、范例數據等,同時開發人員對 API 的全局一致性、擴展性、規范性也有更好的把控。
- 在聯調開發的過程中可以提前發現和解決問題,避免問題在開發完畢后修改的成本過高。
- 由于 API 描述更加標準化,可以方便做更多的 API 生態延伸,比如基于 API 規范生成 Mock API Server,開發 API 自動化測試代碼,接入 API 網關等。
另外,Swagger/OpenAPI 結合 Mock API Server 可以實現自動生成 Mock API,通過提供真實 API 響應的范例數據來模擬真實的 API 服務,并且支持路由及參數校驗。

9. K1s
K1s 是一個非常有趣且實用的 Kubernetes 儀表盤工具,它的本體只有短短的 50 多行 Bash 代碼,可能是世界上最小的 Kubernetes Dashboard。正式因為 K1s 這種非常極致的 Unix-like 美學,所以受到了 Linux Shell Terminal 用戶的喜愛。并且由于 K1s 極致的輕巧,幾乎不占用任何資源,所以在本就資源非常緊張的開發環境中很實用。
K1s 可以展示所有或任意 Namespaces 中的 Resource List,打開 Shell 并輸入 k1s CLI 即可完成實現 Kubernetes 資源信息查看和實時監視。下圖是一個官方提供的使用效果,分別實時監視著 Deployment、ReplicasSet 和 Pod 資源的運行狀態。

10. Wireshark
云計算研發中大部分的棘手問題都是網絡導致的,Wireshark 作為一款功能強大的數據報文分析實用工具,幾乎是我們每次遇見網絡問題必定使用的工具。
Wireshark 可以截取各種網絡數據包,并顯示數據包詳細信息,常用于開發測試過程中各種問題定位。例如:隨著 HTTP/2 協議的應用越來越廣泛,我們也將微服務 APIGW 的 HTTP Server 升級成了 HTTP/2 版本。
在 API 調試的過程中,我們經常需要面對分析 API 信令的情況。但由于 HTTP/2 采用的是二進制分幀層(Binary Framing)實現,會將每個請求和響應分割成為更小的幀,并對它們進行了二進制編碼。所幸的是,新版本的 Wireshark 能夠支持解析 HTTP/2 數據報文,有效的支持了我們的 API 研發工作。

浙公網安備 33010602011771號