雲端原生應用程式簡介

提示

此內容摘錄自《建構適用於 Azure 的雲端原生 .NET 應用程式》電子書，您可以在 .NET Docs 找到此電子書，或免費下載可離線閱讀的 PDF。

下載 PDF

另一天，在辦公室處理「下一件大事」。

您的行動電話響了。 這是對您友善的招聘人員，這個人每天都會打電話來通知令人興奮的新機會。

但這次不同：創業、公平和大量資金。

提及雲端、微服務和最先進的技術可讓您超越邊緣。

快速前進數週，而您現在是建構主要電子商務應用程式的設計工作階段中的新員工。 您將與領先的電子商務網站競爭。

您將如何進行建置？

如果您遵循過去 15 年的指導，則很可能會建置圖 1.1 中所顯示的系統。

圖 1-1。 傳統整合型設計

您可以建構包含所有網域邏輯的大型核心應用程式。 其包括身分識別、目錄、排序等這類模組。 其會在單一伺服器程序內直接彼此通訊。 模組會共用大型關聯式資料庫。 核心會透過 HTML 介面和行動應用程式來公開功能。

恭喜！ 您剛剛已建立整合型應用程式。

並非所有項目都不正確。 單體提供一些不同的優點。 例如，它們很容易...

• build
• 測試
• 部署
• 疑難排解
• 垂直調整

現今有許多成功的應用程式都已建立為單體。 應用程式是符合項目，而且會在反覆運算之後持續演進，並新增更多功能。

不過，在某個時間點，您會開始感到不快。 您會發現自己失去對應用程式的控制。 隨著時間的流逝，感覺會變得更加強烈，您最終會進入稱為 Fear Cycle 的狀態：

• 應用程式已變得非常複雜，以致於沒有人能理解。
• 您害怕做出改變 - 每項變更都會有意想不到且代價高昂的副作用。
• 新功能/修正程式的實作會變得很麻煩、耗時且昂貴。
• 每個版本都會盡可能地小，而且需要完整部署整個應用程式。
• 一個不穩定的元件可能會損毀整個系統。
• 新技術和架構不是選項。
• 很難實作敏捷式傳遞方法。
• 隨著程式碼基底因永無止境的「快速修正」而惡化，架構侵蝕開始了。
• 最後，「顧問」參與討論並告訴您予以重寫。

聽起來很熟悉嗎？

許多組織已採用雲端原生方法來建置系統，以解決這種整合型擔心週期。 圖 1-2 顯示套用雲端原生技術和做法所建置的相同系統。

圖 1-2。 雲端原生設計

請注意，應用程式如何分解成一組小型隔離微服務。 每項服務都是獨立的，並且封裝各自的程式碼、資料和相依性。 每項服務都部署在軟體容器中，並由容器協調器管理。 每項服務都會擁有各自的資料存放區，而不是大型關聯式資料庫，並且其類型會根據資料需求而不同。 請注意有些服務如何相依於關聯式資料庫，但其他則相依於 NoSQL 資料庫。 一項服務會將其狀態儲存至分散式快取。 請注意，所有流量如何透過 API 閘道服務路由傳送，而此服務負責將流量路由傳送至核心後端服務，並強制執行許多跨領域考慮。 最重要的是，應用程式會充分利用新式雲端平台中找到的可擴縮性、可用性和復原功能。

雲端原生運算

嗯...我們剛剛已使用「雲端原生」這個詞。 您的第一個想法可能是「這到底是什麼意思？」軟體廠商為了行銷更多東西而編造的另一個產業流行語？

幸運的是，這相當不同，希望本書將協助說服您。

在短時間內，雲端原生已成為軟體產業的推動趨勢。 這是建構大型複雜系統的新方式。 此方式充分利用新式軟體發展實務、技術和雲端基礎結構。 雲端原生會變更您設計、實作、部署和運作系統的方式。

與推動產業的持續炒作不同，雲端原生是「實際的」。 請考慮 Cloud Native Computing Foundation (CNCF)，這是 400 多家大公司的聯盟。 其能力是讓雲端原生運算跨技術和雲端堆疊無所不在。 其作為其中一個最具影響力的開放原始碼群組，會在 GitHub 中裝載許多最快速成長的開放原始碼專案。 這些專案包括 Kubernetes、Prometheus、Helm、Envoy 和 gRPC。

CNCF 會促進開放原始碼和廠商中立的生態系統。 之後，本書會呈現與技術無關的雲端原生準則、模式和最佳做法。 同時，我們會討論 Microsoft Azure 雲端中可用的服務和基礎結構，來建構雲端原生系統。

因此，什麼是雲端原生？ 請坐下、放鬆，並讓我們協助您探索這個新世界。

上一個下一個