爲什麼選擇雲原生？

在本文中，咱們將介紹何爲雲原生、雲原生應用的優點、雲原生應用的基本要素以及在雲原生應用中如何管理數據。

---

 

01 何爲雲原生

數據在爆炸增加，客戶們的需求日益增長，而做爲開發者的你必須儘快知足他們。

經過雲原生程序，你能夠完全利用微服務、容器、編排及自動化。在存儲、stream及APIs之間靈活自如的數據訪問，能夠幫助你得到彈性、擴展性和雲計算的適應力。

雲原生應用是爲雲環境而設計的，以便可以利用其獨特的伸縮能力。雲原生應用一般由幾個鬆散耦合的服務組成。

雲原生應用充分利用了前文提到的雲計算技術，從而提高了開發週期的速度、靈活性和創新能力。有了這些，軟件開發過程當中的迭代次數變得更容易預期和掌控。

---

 

02 雲原生應用的優點

根據雲原生計算基金會(Cloud Native Computing Foundation, aka, CNCF)：「在像是公有云、私有云和混合雲這樣的現代且快速變化的環境中，雲原生技術使得企業具備開發和運行可擴展應用的能力。

容器(container)、服務網格(service meshes)、微服務(microservices)、不可變基礎設施(immutable infrastructure)以及聲明式API(declarative APIs)都簡化了這一過程。」

其優點包括「鬆散耦合的系統具備良好的從故障中恢復的能力，而且易於管理和觀測。當這些系統與可信賴的自動化技術結合，工程師們能夠最大限度地減小重複勞動，常常性地、可預見性地創造重大改變。」

• 從故障中恢復：應用能夠在硬件、網絡和軟件出現瑕疵時繼續工做。
• 易於管理：應用很是容易配置，並能快速適應不斷變化的運維條件和環境。
• 易於觀測：應用埋點來收集指標數據(metrics)和日誌(logs)，從而提供可指導行動的重要信息。
• 常常性的改變：模塊化的應用可讓開發者對單獨模塊快速作出增量改變。
• 可預見性的改變：應用和配置都支持源代碼管理，從而保證部署和配置改變的可審計性及可重複性。
• 最少的重複勞動：應用的部署和管理是自動化的，這不只減小了運維人員的工做量，也使得運維人員能夠更全面地管理系統。

開發雲原生應用，開發者須要從企業文化和工做流程、系統總體架構、全棧的技術選擇這三方面有一個思惟的轉變。

不管你是正要爲你的初創公司推出第一款app，仍是正要改造一個傳統的單體應用使之適應現代需求，雲原生應用所能提供的量身定作的、個性化的體驗都會助你一臂之力。

採用雲原生應用可使你的終端客戶和企業客戶感到愉悅，而且他們可以以他們可能歷來沒想到過的方式充分利用他們所擁有的數據。

---

 

03 雲原生應用的基本要素

微服務

這些小的、鬆散耦合的服務有助於提高開發生命週期中的敏捷性(agility)和獨立性。多種無狀態應用的實例提供從故障中恢復的能力、具備彈性的伸縮能力以及低風險的系統演進。

編程語言和架構

開發團隊能夠自由選擇最適用於他們應用的功能的工具。當訪問數據源時，多種選項可供選擇，包括從底層drivers、抽象驅動和訪問語言的框架，直至更高層的多種數據API。

函數

業務邏輯能夠經過簡單的函數來表達。藉助於無服務器架構(Serverless)的框架或者雲服務商的Serverless平臺，這樣的函數不要求完整的操做系統，能夠比微服務的部署和伸縮容易得多。

APIs

像是REST、GraphQL和gRPC這些定義良好的接口，是由微服務以及第三方「做爲服務(as a services)」的相關產品提供的。這些接口提高了開發速度，並促進了開發團隊的合做。

數據

數據庫、數據服務、流(streaming)以及消息平臺使得數據能夠在不一樣的微服務和持久層間流動。

容器

微服務常常被打包和部署成Docker images，從而實現可遷移性，並優化資源的開銷。

編排

容器由像是Kubernetes這樣的編排框架進行管理，從而實現自動化的部署、運維、伸縮以及大規模應用的從故障中恢復的能力。

監控

分佈式應用會暴露出新的故障域(fault domains)，因此團隊每每會使用相似Prometheus的中心監測系統，從而能夠在一個視圖監控整個系統。

安全

安全層傳輸協議(TLS)、OAuth、OIDC、JWTs、網絡身份提供者(identity providers)、API網關以及自動的容器修補提供了新機制來應對攻擊面(attack surface)的安全風險。

持續集成/持續交付工具

應用的代碼和所需的基礎架構（稱爲「基礎架構即代碼」）會由像是Git這樣的源代碼管理系統託管，從而經過自動化的開發、測試、生產的流程，實現快速迭代。

---

 

04 在雲原生應用中如何管理數據

考慮到可用的設計選擇和數據存儲方案的多樣性，其實有多種方法能夠用來管理數據。咱們觀察到，這其中包括了幾種最多見的模式。

• 無狀態微服務與外包的數據持久化機制

微服務一般將存儲狀態的責任外包給一個持久化的機制，好比一個專門的塊存儲卷(block storage volume)、一個分佈式的數據庫集羣，或是一個數據服務。不論使用哪一種存儲策略，微服務中的每個服務都應該控制其自身數據的訪問權。

• 經過APIs、驅動以及架構來訪問數據

當與Cassandra這樣的分佈式數據庫交互時，最簡單的訪問數據的辦法就是經過GraphQL、REST、或gRPC中描述的API。這種交互模式適用於前端應用、無服務器架構(serverless functions)或是微服務。

須要更多控制與後臺數據庫交互的微服務能夠直接用驅動，或是像Spring、Quarkus、Django、Vue.js這樣的框架來輔助數據交互。

• 經過streaming和變更數據捕獲來管理數據流

雲原生架構也須要解決數據在服務和APIs之間的流動問題。數據有可能來自streaming以及像Kafka這樣的消息系統，流向爲微服務提供數據的權威來源的Cassandra系統。

變更數據捕獲(Change Data Capture, aka, CDC)能夠實現數據從Cassandra向其它服務或用於進一步分析處理的數據湖流出。

 

References：

　　　　https://www.datastax.com/cloud-native