為什么要云原生（Cloud Native）

Cloud表示應用程序位于云中，而不是傳統的數據中心；Native表示應用程序從設計之初即考慮到云的環境，原生為云而設計，在云上以最佳姿勢運行，充分利用和發揮云平臺的彈性+分布式優勢。

了解了為什么要云原生以后，接下來，我們看看到底什么是云原生？

云原生的定義(1.0)

云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。

這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。

容器

有效的將單個操作系統的資源劃分到孤立的組中，以便更好的在孤立的組之間平衡有沖突的資源使用需求，這種技術就是容器技術。

Docker 是目前被最官方使用的。提到它就離不開Kubernetes(管理容器集群)。他們兩個對于初學者來說就好像兩座大山，但其實如果你明白他們解決的問題和場景，或許你會覺得原來他們已經“很簡單”了。作為運維已經基本算是必備技能了，而對于開發來說，繁重的開發壓力或許也是讓大家沒有更多精力從全方位了解一個新的領域的重要原因吧。如果在開發時可以屏蔽一些偏運維的技能，或許將是個不錯的選擇。

服務網格

處理服務間通信的基礎設施層，用于在云原生應用復雜的服務拓撲中實現可靠的請求傳遞。

兩大王者Istio和Linkerd，他們是云原生解決方案和微服務架構中必不可少的組成部分（只需要其中之一即可）。他們提供了如服務發現、負載均衡、故障恢復、指標和監控等功能，甚至連A/B 測試、金絲雀發布、限流、訪問控制和端到端身份驗證都被涵蓋進去了。雖然他們很強大，但近兩年異軍突起的Dapr或許會給大家帶來新的可能性。

微服務

把一個服務拆成N個小的服務就是微服務，NO！！！

我有一個單體，只要我把業務分成不同的類庫，到時候給他們套個Web API的殼跑起來，就是微服務，NO！！！

微服務通常需要按領域科學拆分，目的是為了每個切分的領域可以自主開發，獨立部署。

正因為獨立部署成服務，由類庫間調用就要轉向服務調用，所以需要標準的通信協議。

引入了標準的通信協議，所以不同的語言只要遵循協議，也就沒有語言占山為王一說了（要硬說沒有也不是，畢竟單一語言的經驗積累比并行多個語言還是要容易的，可不同的語言也有他們自身的優勢）。

最后組合在一起形成了一個新的應用（所以微前端的概念也可以插進來了）。

這不還是拆就完事兒了？NO！！！

微服務將會帶來新的挑戰：

• 如何解決通信相關的問題，比如性能，瞬態故障，網絡阻塞，安全性等

• 如何讓服務可以彈性伸縮，比如程序崩潰，流量瞬間增大，部署等

• 如何解決分布式的挑戰，比如大量數據，分布式事務，跨服務查詢等

• 如何存儲密鑰或敏感信息？

.NET不會替你解決這些挑戰，但它會幫你。比如.NET 6和.NET 7的更新，正在為支持云原生而做的努力。這些應該被開發者們看到，并大膽的去嘗試，去體驗。

不可變基礎設施

基礎設施在部署了之后決不會被修改。一臉懵逼?≡(▔﹏▔)≡

說一下優點，它可以保證基礎設施具有更高的一致性和可靠性，更簡單，可預測的部署過程。那來反推一下，如果基礎設施部署后人為變更了，那自動化過程就可能會受到阻礙，比如雪花服務器。

聲明式API

描述目標狀態，而不是指令

聲明式API相當于是我只需要告訴服務 會議室空調是26度，至于是要打開空調還是調整溫度這個由服務來自行完成。在我們設計的絕大多數服務都會直接提供 打開空調API，設置溫度API，所以聲明式API和命令式API其實是有本質的區別的。

Java比.NET更有優勢？

Java的確起步的早，但今日的.NET已經不是以前的.NET了。.NET最近幾個大版本的更新中，針對云原生技術的挑戰已經開始發力解決了。甚至在一些方面實現了反超，這讓使用.NET構建云原生應用成為更優解變得可能。

更多內容，讓我們來?MASA Framework實戰課程?來了解一下吧。

眾多?.NET領域大咖?帶你走進.NET云原生的世界。

從0開始解決中大型電商項目帶來的挑戰！

我們在?開課圓桌?等你！