[[353361]]

【51CTO.com快譯】不可否認，在近十年間，云計算的相關應用得到了蓬勃的發展。根據Gartner的統計和預測，全球公共云服務市場在2019年已經達到了2278億美元，而今年它將持續增長17%，并達到2664億美元(請參見--https://www.gartner.com/en/newsroom/press-releases/2019-11-13-gartner-forecasts-worldwide-public-cloud-revenue-to-grow-17-percent-in-2020#:~:text=The%20worldwide%20public%20cloud%20services,research%20vice%20president%20at%20Gartner.)。像Airbnb、Netflix和Uber之類，以云服務為基礎的明星企業，利用云原生(Cloud Native)技術，在競爭對手之前更快地搶占了市場，甚至重塑了所在的行業。可見，理解并選擇正確的云原生技術，將有助于提高應用與服務的開發速度，減少維護工具的復雜性，并能提高有限基礎設施的利用率。本文將向您介紹13種云原生工具，以方便您打造本企業的云原生屬性。

什么是原生云?

云原生計算基金會(Cloud Native Computing Foundation，CNCF)提供的官方定義為：云原生技術是在公共云、私有云、以及混合云的動態環境中，讓組織能夠構建和運行具有可擴展性的應用程序。這些應用包括：容器、服務網格、微服務、恒定架構(immutable infrastructure)、以及聲明性API等。這些技術使得松耦合的系統具有一定云端彈性、可管理性和可觀察性。憑借著其自動化的技術特點，開發人員可以在不增加工作量的情況下，頻繁地、可預見性地進行各種變更與迭代。簡而言之，云原生的目標就是根據業務所需，快速、敏捷地向用戶交付軟件產品，并降低IT的整體成本。

云原生的價值

云原生技術具有以下三方面的優勢：

• 速度：云原生應用程序可以快速地被開發和部署，從而加快了產品面市的時間。許多云服務提供商都帶有云原生組件，這讓托管此類應用變得非常簡單。此外，由于云計算原生工具嚴重依賴抽象，這使得抽象更加通用，開發團隊不再需要依附整個公司的共享運行時，來運行自己的服務。因此，組織需要處理的開銷也就更少。
• 可擴展性和可用性：原先僅能夠處理上百個客戶的云原生應用，可以被無縫地擴展到服務數百萬個客戶，以滿足實時的資源需求。這比傳統的靜態調整資源要更加節省成本。此外，自動化故障轉移和藍綠部署等技術，也融入到了云原生工具中。
• 質量：云原生應用程序的開發往往是基于恒定性和解耦性的。這使得應用程序不但健壯、易于維護，而且具有較高的軟件質量。由于時下流行的云原生技術是開源的，而且得到了CNCF的支持，因此軟件開發公司可以避免被某個云供應商所鎖定，并能夠在開發工作中持續得到社區的維護和支持。

基于上述優勢，許多像Microsoft、Google和Amazon之類的大型組織,都在最小化運營成本的同時，享受到了云計算的巨大紅利。

如何實現云原生

為了將應用遷移到云原生系統中，您往往需要用到如下結構化方法中的一種：

• 垂直：選擇一個非關鍵性任務的服務，然后對其啟用云原生技術，并實施遷移。
• 水平：專注于某個單獨的云原生功能，如持續集成(CI)或持續交付(CD)，將其部署到所有現有的服務中。

注意：選擇某個非關鍵性的任務系統，對于降低風險、以及最大限度地提高遷移成功率來說，都是至關重要的。

云原生工具

以下便是業界常用的云原生工具列表。各大公司通過使用它們，實現了更快的產品交付，更少的摩擦，以及更低的開發與維護成本。

1.微服務

微服務能夠將產品的功能劃分為多個可以被單獨部署的單元。例如，在傳統的非云原生(pre-cloud-native)部署中，通常只有一個網站服務來管理各種API和客戶間的交互。但是通過使用微服務，您可以將該網站分解成為包括賬號服務和用戶服務在內的多個服務。據此，您可以單獨地對這些服務進行開發、部署和擴展。

同時，微服務通常是無狀態的，它給開發團隊利用云原生工具提供了各種靈活性。

推薦技術： Node.js(https://nodejs.org/)

替代技術： Kotlin(https://kotlinlang.org/)，Golang(https://golang.org/)

2.持續集成/持續部署

持續集成/持續部署(CI/CD)是一種基礎架構組件，它支持自動化的測試執行(和可選的部署)，拉取式請求合并，以及版本控制事件。CI/CD使得公司能夠實現諸如：單元測試、靜態分析、以及安全分析等質量門。而且，作為云原生生態系統中的基礎工具，CI/CD也可以提高工程效率，并減少錯誤的數量。

推薦技術： Gitlab CI/CD(https://docs.gitlab.com/ee/ci/)

替代技術： Github Actions(https://github.com/features/actions)

3.容器

容器是云原生生態系統的核心。它通過簡化開發人員的操作，來提高交付速度和產品質量。通過使用帶有Docker工具的容器，開發團隊可以指定目標系統的依賴性，同時提供統一且通用的執行層面。而通過該層面，團隊只需著眼于Kubernetes之類容器編排等單個基礎設施。

同時，工程團隊可以將容器的鏡像存儲在容器的注冊表中，以提供漏洞分析和細粒度的訪問控制。該領域的熱門服務包括：Docker Hub(https://hub.docker.com/)、Google Container Registry(https://cloud.google.com/container-registry)、Quay(https://quay.io/)。

推薦技術： Docker(https://www.docker.com/)

替代技術： Podman(https://podman.io/)，LXD(https://linuxcontainers.org/lxd/introduction/)

4.容器編排(Container Orchestration)

上面提到的容器編排是一種用于啟動和管理大量容器的工具。它并不需要特定于語言或團隊的部署策略，而是允許用戶指定某個或某組容器鏡像進行配置。編排的最后是將這些規范轉換為運行的工作流。因此，開發團隊可以只維護一個用于執行任何一種OCI規范(https://github.com/opencontainers/runtime-spec/blob/master/spec.md)的容器。

推薦技術： Kubernetes(https://kubernetes.io/)

替代技術： Google Cloud Run(https://cloud.google.com/run)

5.基礎設施即代碼

基礎設施即代碼是一種在版本控制的基礎上實施云端配置的策略。過去，公司通常需要通過管理面板，來手動配置和管理云端資源。不過，這樣會導致團隊很難跟蹤各種手動更改。而基礎設施即代碼則是通過將云端資源定義為代碼，并將其納入版本控制之中，來解決該問題。也就是說，我們可以在代碼中對基礎設施的配置進行更改，并通過公司的部署過程進行升級，其中可以包括同行評審(peer reviews)、CI和CD等。而版本控制則會提供一套審核日志，來顯示誰、何時更改了哪些資源。

推薦技術： Terraform(https://www.terraform.io/)

替代技術： Pulumi(https://www.pulumi.com/)

6.密碼管理

像密碼、私鑰和API憑據等密碼管理，對于云原生解決方案來說是必不可少的。它們需要被加密后，存儲到相應的配置中。成熟的解決方案往往是通過頒發臨時的數據庫憑據或循環憑據，來保障密碼管理的安全性。由于容器化服務可以實現水平方向擴展，并且可以被安排在許多不同的機器上，因此我們需要為云原生應用程序配置一套合適的密碼管理方案，以免增加密碼泄漏的風險暴露面。

推薦技術： Vault(https://www.vaultproject.io/)

替代技術： Sealed Secrets(https://github.com/bitnami-labs/sealed-secrets)

7.證書

對于基于容器的解決方案來說，許多不同的服務可能會在同一臺物理機器上運行。如果數據沒有被加密，那些已經獲得了主機網絡訪問權限的攻擊者，就能夠輕松地讀取到各個服務之間的所有通信。通過TLS進行安全通信不僅是一種最佳實踐，而且是必不可少的。當然，自動化更新云原生證書的解決方案，會比手動部署要可靠得多。

推薦技術： cert-manager(https://github.com/jetstack/cert-manager)

替代技術： Google managed certificates(https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs)

8 .API網關

API網關在實際應用中往往被作為反向代理，提供了類似于Apache(https://httpd.apache.org/)和NGINX(https://www.nginx.com/)之類傳統反向代理產品的功能。此外，API網關還支持：

• gRPC、HTTP/2和Websockets等協議
• 動態配置
• 雙向TLS
• 路由
• 提供諸如速率限制和電路中斷等云服務彈性功能
• 提供各類監控指標的可見化

推薦技術： Ambassador(https://github.com/datawire/ambassador)

替代技術： Kong(https://konghq.com/)

9.日志

作為可觀察性(https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html)的基礎，日志記錄對于開發團隊來說是再熟悉不過了。云原生工具在日志方面強調的是受監控指標的時序性，旨在以成本效益的方式，獲悉事件發生的原委。同時，日志對于云端應用的開發調試與觀察，也是必不可少的“剛需”。

推薦技術： EFK(https://www.cncf.io/blog/2020/07/27/logging-in-kubernetes-efk-vs-plg-stack/)

替代技術： Loki(https://github.com/grafana/loki)

10.監控

上面提到的時序日志往往來自于監控系統。該系統通過聚合監控數據，以避免存儲所有的事件。也就是說，云原生系統需要通過成本效益的方式，來了解系統在如下方面的狀態：

• 進行了多少次操作?
• 操作的結果是成功還是失敗?其狀態代碼是什么?
• 操作耗時多久?
• 重要資源(如：隊列深度或線程池)的數值是多少?

您可以為受監控的指標分配不同的維度，以深入了解單個主機、操作系統、以及版本等方面的性能。

推薦技術： Prometheus(https://prometheus.io/)/Grafana(https://prometheus.io/docs/visualization/grafana/)

替代技術： Datadog(https://www.datadoghq.com/)

11.警報

警報是日志監控的結果，它會將系統出現的問題、以及對應的時序指標，通知到操作人員。例如，當系統的HTTP 500系列狀態代碼增加、或請求等待時間延長時，此類警報會及時發送到運營團隊處。對于云原生系統而言，出現問題并不可怕，可怕的是大家不知道問題出在哪里。因此，警報的作用是不言而喻的。

推薦技術： Prometheus Alertmanager(https://prometheus.io/docs/alerting/latest/alertmanager/)

替代技術： Grafana Alerts(https://grafana.com/docs/grafana/latest/alerting/)

12.追蹤

為了減少在啟動和擴展服務上的開銷，開發團隊往往會在服務發布之前，分配給云服務更多的資源。支持團隊可以通過監控和跟蹤各個服務之間的通信，來了解用戶的最終狀態，以及用戶在使用過程中，每個階段的耗時和資源使用率。據此，當出現性能問題時，團隊可以及時捕獲到錯誤信息。因此，作為觀察和調試工具的深化，云原生技術的跟蹤功能，可以讓團隊更快地診斷問題，進而顯著地減少宕機時間。

推薦技術： Jaeger(https://www.jaegertracing.io/)

替代技術： Zipkin(https://zipkin.io/)

13.服務網格

作為上述功能的綜合，云服務網格可以提供動態路由、負載平衡、服務發現、網絡策略，以及包括斷路器(https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker)和重試機制(https://docs.microsoft.com/en-us/azure/architecture/patterns/retry)在內的云服務彈性功能。我們可以將服務網格視為云計算原生架構在負載平衡方面的一種進化。

推薦技術： Istio(https://istio.io/)

替代技術： Consul(https://www.consul.io/)

小結

通過靈活地選用上述云原生工具，我們可以適當地提高云服務產品的交付速度，增加服務的可用性與性能，以及保持企業的競爭優勢。您不必一蹴而就，完全可以從某個單一技術入手，以充分利用它給云端業務帶來的顯著好處與提升。

原文標題：How to Become a Cloud-Native Company and 13 Tools to Get You There， Kentaro Wakayama

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】