容器化時代我們應當選擇Kubernetes

張善友發表於2019-04-06

前天發的文章《基於Kubernetes 構建.NET Core 的技術體系》,有同學問.NET Core上有Spring Cloud類似的平臺嗎? .NET Core出現這麼久了,這個為雲原生應用開發而準備的系統需要Spring cloud這樣的全家桶嗎?今天寫下這篇文章的目的就是陳述一下容器化時代還需要Spring Cloud這樣的基礎設施嗎? 大家希望使用Spring Cloud的初衷都是為了實現應用的微服務化。然而對於微服務而言,有六個基本必須實現的:

  • 程式通訊
  • 服務註冊與發現
  • 負載均衡
  • 配置中心
  • 熔斷器
  • 閘道器路由

我們已經進入到容器化時代,Kubernetes成為了市場上容器編排的事實標準,而且k8S 同樣具備了微服務所需要的服務註冊與發現、負載均衡、配置中心。Spring cloud 的核心是Netflix微服務框架,非常成熟,但是在netflix oss開發初期,那個時候還沒有docker,我們現在所有的服務都是通過虛擬容器承載的。

Netflix OSS的許多內容都是在一個已經過去的年代寫出來的,那時所有東西都只能執行在AWS雲上而沒有其它選擇。關於那個年代的許多寶貴遺產和前提假設都已經被封裝到了Netflix的庫裡面,對於現在你執行的環境(比如Linux容器)已經不適用了。在Linux容器、Docker、容器管理系統等等出現之後,我們越來越看到把我們的微服務執行在Linux容器(公有云、私有云,或者都要等等)裡的巨大價值。另外,因為這些容器都是直接把這些服務打包起來,所以我們傾向於不要過多關心在容器裡面執行的到底是什麼技術(是Java?還是Node.js?或者Go?或者.NET Core?)

Kubernetes是多語言的,不僅僅針對Java平臺,而是以通用的方式為所有語言解決分散式計算問題。Kubernetes提供了配置管理、服務發現、負載均衡、跟蹤、統計、單例項、平臺級和應用棧之外的排程工作。該應用不需要任何客戶端邏輯的庫或代理程式,可以用任何語言編寫。這意味著一個平臺可以被多個團隊(包括使用SpringJava開發人員)使用,並提供多種用途:應​​用程式開發、測試環境、構建環境(原始碼執行、構建服務、依賴倉庫)等。Kubernetes解決了更廣的微服務架構問題。除了提供執行時服務,Kubernetes也可以讓你制定環境、設定資源限制、RBAC、管理應用程式生命週期、允許自動擴容和自我修復(幾乎表現得像一個抗脆弱平臺)。

  • 在K8s叢集中,沒有必要擁有Eureka。K8s中的ETCD擁有所有必要的資訊。
  • 您的應用程式將通過指定的K8s服務名稱聯絡K8s API伺服器以獲取端點資訊。
  • Kubernetes 可以解決你所遇到的問題,可能可以取代netflix的整套技術

.NET Core 就是為雲原生應用的開發而準備的平臺,.NET Core相較於他的哥哥.NET的優勢也正是我們很容易的使用C# 語言去構建高內聚低耦合的雲原生系統。藉助於K8S,service fabric, 我們很容易構建一個.NET Core的微服務生態。結合.NET Core和k8s 容器服務在騰訊雲上製作了一個教程 《.NET 微服務實戰 — 微信公眾號開發( https://cloud.tencent.com/developer/edu/major-100017)》,教程裡例子-公眾號開發雖然簡單,我只是使用這個簡單例子來闡述一個簡單的問題,雲時代的.NET 是怎麼樣的,我們要怎麼樣使用.NET Core。

相關文章