容器化時代我們應當選擇Kubernetes
前天發的文章《基於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提供了配置管理、服務發現、負載均衡、跟蹤、統計、單例項、平臺級和應用棧之外的排程工作。該應用不需要任何客戶端邏輯的庫或代理程式，可以用任何語言編寫。這意味著一個平臺可以被多個團隊（包括使用Spring
的Java
開發人員）使用，並提供多種用途：應用程式開發、測試環境、構建環境（原始碼執行、構建服務、依賴倉庫）等。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。