什麼是雲原生？是炒做仍是軟件開發的將來？

21CTO導讀：最近有很多有關雲原生態開發的討論，它能夠解決啥事？或者這是另外一種技術時尚？繼續閱讀本文，能夠得到一些技術看法。

很長一段時間以來，雲原生Cloud Native就成了軟件開發中熱門的話題之一。一些開發人員認爲它只是炒做，在失去吸引力後在一段時間就後消失；而對於另外一部分人的觀點認爲，這就是軟件開發的將來。

不管將來還會帶來什麼，雲原生軟件確是軟件行業最大的趨勢之一。它在改變着咱們思考軟件開發，部署和運營軟件產品的方式。

那麼，究竟什麼是「雲原生」？

雲原生的不一樣定義

Cloud native不只僅是雲提供商並使用它來運行現有的應用程序。它會影響應用程序的設計，實現，部署和操做。

提供流行的Spring框架和雲平臺的軟件公司Pivotal將雲原生描述爲：

「雲原生是一種構建和運行應用程序的方法，可充分利用雲計算模型的優點。」

來源：什麼是雲原生應用程序？ - Pivotal

雲原生計算基金會是一個旨在建立和推進雲原生編程範式採用的組織，它將雲原生定義爲：

「雲原生計算使用開源技術棧：

1. 容器。每一個部分（應用程序，進程等）都打包在本身的容器中。這有利於再現性，透明度和資源隔離。

2. 動態編排。主動安排和管理容器以優化資源利用率。

3. 微服務爲導向。應用程序被拆分爲微服務。這將顯著提升應用程序的總體靈活性和可維護性。「

   
   

來源：常見問題（FAQ） - Cloud Native Foundation

你們看，這兩種定義有些類似，但從略微不一樣的角度來看這個主題。咱們能夠將雲原生的定義歸納爲如下詞句：

「將軟件應用程序構建爲微服務，並在容器化和動態調度平臺上運行，利用雲計算模型優點的部署方式。」

老實說：「利用雲計算模型的優點」聽起來確實不錯，但若是是雲的新手，咱們仍然想知道這究竟是什麼，以及它如何影響實施與部署軟件的方式。這至少是我第一次閱讀有關雲原生計算的感覺。

咱們來看看雲原生的不一樣部分。

容器

容器的基本思想是將軟件與執行它所需的一切打包到一個可執行的軟件包中，例如Java VM，Application服務器和應用程序自己。而後，你能夠在虛擬化環境中運行此容器，並將包含的應用程序與其環境隔離開來。

這種方法的主要好處是應用程序獨立於環境，而且容器具備高度可移植性。你能夠在開發，測試或生產環境上輕鬆運行相同的容器。若是應用程序設計還支持水平擴展，還能夠啓動或中止容器的多個實例，還能夠根據當前用戶需求添加或刪除應用程序的實例。

Docker是目前最受歡迎的容器實現。它的確很是受歡迎，以至於Docker和容器這兩個術語常常互換使用。但請記住，Docker項目只是容器概念的一個實現，能夠在未來被進行替換。

若是你想嘗試Docker，應該從免費的社區版開始。咱們將它安裝在本地桌面上，就能夠開始構建本身的容器定義並將第一個應用程序部署到容器中。當你完成部署後，能夠將容器交給一個質量保障的同事，將其部署到生產環境中去。

若是你的應用程序在測試或生產環境中工做，或者須要更新某些依賴項，也不用再擔憂——容器包含應用程序所需的全部內容，你只需啓動它便可。

管絃樂做曲家

將包含全部依賴項的應用程序部署到容器中只是第一步。它解決了咱們之前的部署問題，但若是想從雲平臺中充分受益，那麼開發者還將面臨新的挑戰。

根據系統的當前負載啓動附加或關閉正在運行的應用程序節點，這作到並不是易事。

你須要：

• 監控系統，

• 觸發容器的啓動或關閉，

• 確保全部必需的配置參數都到位，

• 平衡活動應用程序實例之間的負載量，

• 在容器之間共享身份驗證機密。

手動完成這些操做須要花費不少精力，而且對於系統負載的意外調整反應也會比較慢。開發者須要擁有適當的工具來自動完成這些工做。這就是構建不一樣解決方案的原：一些流行的工具備Docker Swarm，Kubernetes，Apache Mesos和亞馬遜的ECS。

微服務

如今咱們已經有了全部基礎架構和管理工具，是時候討論雲原生引入系統架構的變化了。

將雲原生應用程序構建爲微服務系統，相信你已經據說過這種架構方法了 。

這種架構風格的通用概念是將一個由多個相對較小的應用程序組成系統，它被稱之爲微服務。它們之間協同工做提供系統的總體功能。

每一個微服務都實現了一個功能，具備明肯定義的邊界和API，可由相對較小的團隊開發和管理、操做。

這種方法提供以下幾個好處：

微服務的好處

首先，實現和理解一種功能較小的應用程序要容易得多，不用再構建一個要完成全部任務的大型應用程序。這不只加快了開發速度，讓服務適應變動或新需求變得更容易。開發者須要關注看似微小變化的意外反作用，以便專一於手頭的開發任務。

微服務還讓人們可以有更有效地擴展。咱們在前面談到容器時，說到能夠簡單地啓動另外一個容器來處理用戶請求的增長，這稱爲水平縮放。對於每一個無狀態應用程序，你均可以這樣作，這與其應用大小無關。只要應用程序不保留任何狀態，你就能夠將用戶的下一個請求發送到任何可用的應用程序實例中。

即使如此，咱們仍然可使用單體應用程序來實現。但擴展微服務系統的成本一般要低不少。開發者只須要擴展支持大負載的微服務便可。若是系統能夠處理得好當前負載，咱們就不須要添加服務的任何其它實例。

咱們用笨重的應用就作不到這一點。好比須要擴展一個功能的容量，則須要啓動完整應用的新實例。這可能看起來也不是什麼大問題，但在雲環境中，別忘了須要爲硬件資源的使用付費。即便你只用應用的一小部分，仍然須要爲其餘未使用的部分獲取額外的資源。

微服務可以讓你更有效地使用雲資源，並有效減小云服務商的帳單。

引入微服務的挑戰

一般就是這樣，人們沒法免費得到架構風格的好處。

微服務從服務自己中消除了一些複雜性，並提供了更好的可擴展性，若是你如今正在構建一個分佈式系統，微服務會增長系統級別的複雜性。以下圖：

爲了儘量下降這種額外的複雜性，你應該避免微服務之間存在任何的依賴關係。

若是現象不可避免，須要確保相關服務相互發現，並有效地實現其通訊。開發者還須要處理反映緩慢或不可用的服務，以使它們不要影響系統總體。

系統的分佈式特性也使得在生產中監視和管理系統變得困難。

運營者如今須要監控微服務系統而再也不是幾個總體系統，而且對於每一個服務，可能有多個並行運行的實例。人們須要監控更多應用程序實例。咱們能夠經過使用Retrace，K8s等工具從全部系統來收集信息。

構建微服務

咱們並不須要使用特定的框架或技術棧來構建微服務。

它讓開發變得容易多了。它爲開發者提供了許多即用型功能，這些功能通過了充分測試，而且已在生產環境中使用過。

好比在Java中，有許多不一樣的選項可用。兩個流行的是Spring Boot和Eclipse Microprofile。Spring Boot將Spring框架與其它幾個框架/庫集成在一塊兒，以應對微服務架構的更多挑戰。

Eclipse Microprofile遵照相同的理念，但它使用Java EE架構，即多個Java EE應用程序服務器協同工做，它提供了一組規範和多個可互換的技術實現。

小結

雲原生計算的思想和概念，引入了實現避免複雜，高度可擴展系統的新方法。即使 你沒有在雲平臺上託管應用程序，這些新想法也會影響你未來開發應用程序的方式。

容器技術使分發應用程序變得更加容易。你在開發過程當中能夠和團隊成員之間共享應用程序，也可在不一樣環境中測試運行。執行完全部測試後，你能夠輕鬆地將同一容器部署到生產環境中。

微服務提供了一種構建系統的新方法。雖然引入了新的挑戰，但它將咱們的注意力轉移到每一個組件的設計上。這樣能夠有效改善封裝，讓人們實現可維護的組件，更好地快速適應新的產品需求。

若是你決定用容器在生產中運行微服務系統，須要一個幫助管理系統的編排解決方案，那還有kubernates，jenkins等工具。

微服務如此神奇，讓咱們一塊兒發現更多。