傻瓜教程：什么是云原生應(yīng)用程序？
我們通常都會在設(shè)想什么是一個Cloud Native Appliction，這也是我們?yōu)槭裁床煌５厝y試、學(xué)習(xí)各種云服務(wù)，學(xué)習(xí)、使用docker的原因。本文介紹的云原生應(yīng)用的出發(fā)點，可能和我們的有著異曲同工的地方，可能在某些方面說的還是比較抽象，但是通過圖片，我們還是可以清晰明白在非云應(yīng)用往云生應(yīng)用的發(fā)展框架是什么，會帶來什么樣的好處等等，以及如何處理好不同域間容量、數(shù)據(jù)、狀態(tài)的關(guān)系。
最近有試著描述“現(xiàn)代應(yīng)用程序”或“現(xiàn)代工作負載”。
Twelve-Factor App就是一個很好的嘗試。
這是一個很好的方法來描述這樣的工作量但我認為這些概念需要降低一個數(shù)量級使普通人正常理解他們。
這就是我想要在這個博文上做的。我們將省略一些重要的細節(jié)通過這樣做但沒關(guān)系。
讓我直接點：在(我的意思是非常)高水平云本機應(yīng)用程序是一個應(yīng)用程序,該應(yīng)用程序有一個明確的“基礎(chǔ)設(shè)施”和“數(shù)據(jù)”之間的分離。至少在我看來,設(shè)計一個云本機應(yīng)用程序沒有畫這個明確的分離。
我用數(shù)據(jù)作為一個非常松散的術(shù)語。你可能正在考慮一個“基于數(shù)據(jù)”(哪個都行)但這真的應(yīng)該包括“配置”。
另一種方法來描述這種分離可能是“容量”和“狀態(tài)”。不僅僅是這樣。
讓我們立刻開始用一幅畫來描述這一概念：
請注意這兩個域的特征。
基礎(chǔ)設(shè)施容量沒有你需要或想要保護的自己的狀態(tài)(至少在本地存儲中)。
這是完全無狀態(tài),你可以通過自動化輕松地(反復(fù))創(chuàng)建它,因此,它不需要有彈性。
另一方面承載了你的持久性的域(在每一個可能的形狀和形式)具有完全不同的特征,因為它需要可靠的、高可用性、耐用和這一切。
此時,您可能想知道這是如何不同與傳統(tǒng)模式相比在3層web應(yīng)用程序。在我看來，云本機應(yīng)用程序在隔離傳統(tǒng)“應(yīng)用層”與傳統(tǒng)的“數(shù)據(jù)層”將envelope推到極端。
基礎(chǔ)設(shè)施容量域
這就是虛擬機(又名實例)實時托管原生云應(yīng)用的代碼。他們完全是無狀態(tài)的，他們是一群vm所有相同配置(基于角色)和整個生命周期的自動化。在這樣一個環(huán)境中傳統(tǒng)IT概念通常關(guān)聯(lián)到虛擬機甚至沒有任何意義。下面是一些例子。
- 不安裝這些服務(wù)器(傳統(tǒng)方法)，因為它們是由自動生成腳本由外部事件或政策觸發(fā)(如基于用戶需求自動定量前端層)
- 不操作這些服務(wù)器，原因同上。
- 不記錄這些服務(wù)器做什么和如何提供它們，因為代碼生成文檔。
- 不備份這些服務(wù)器，因為他們沒有狀態(tài)。如果你失去了服務(wù)器,你重新實例這些服務(wù)器，從頭開始。
- 你沒有這些服務(wù)器從一個地方遷移到另一個,因為同樣的原因。你重新實例這些服務(wù)器，從頭開始。
- 你不用云平臺級別提供高可用性來保護這些服務(wù)器。沒有任何保護,如果他們失敗了,你重新實例服務(wù)器。
- 你不需要為這些服務(wù)規(guī)劃基礎(chǔ)設(shè)施的大小,你只需為任何給定的時間點上的消費。
你配置基礎(chǔ)設(shè)施的本質(zhì)與運行代碼中的一部分一樣。你聽說過“基礎(chǔ)設(shè)施及代碼”的概念嗎?這就是了。
現(xiàn)今，相當(dāng)常見的看到實現(xiàn)這類模式被用于實現(xiàn)配置工具組合，然后切換到配置管理工具。
這個想法是為了提供虛擬機,讓配置工具給客人創(chuàng)建適當(dāng)?shù)膫€性和角色。
AWS Cloudformations，HashiCorp Terraform，VMware Application Director，RightScale CMP這些都是專注于可編程初始化實例的幾個例子。
Puppet, Chef, Ansible (等等) 是配置管理工具，專注于通過自動化確保實例融合，給定一致的配置和狀態(tài)。
截至2014年底，這幾乎是目前的狀況(和***實踐)。
然而幾個新趨勢和模式在上升。他們可能最終收斂匯聚,在某種程度上,你可以看作為一種趨勢。
***個被稱為不變的工作負載。目前為止,我們已經(jīng)討論了被稱為可變負載,這意味著他們的配置可以改變加班一樣配置管理工具配置和重新配置他們需要讓他們收斂到一個理想的最終狀態(tài)。換句話說云本機應(yīng)用程序當(dāng)前的***實踐建議提供一個基礎(chǔ)模板和在操作系統(tǒng)核心模板，確保核心模板使用特定的配置。不變工作量的哲學(xué)表明，實例相對應(yīng)的應(yīng)該是不變的,如果你需要重新配置一個實例(如更新應(yīng)用程序代碼)，你應(yīng)該摧毀這個實例并重新立即部署它***的配置到模板中。
第二個趨勢是朝著簡化整個堆棧包括這些工作負載。目前常見的做法是使用虛擬機作為一個占位符，用于運行時(例如AWS EC2實例或VMware虛擬機)。這些天有一所新學(xué)校的想法說虛擬機太大，太臃腫和云本機應(yīng)用程序太重，容器是一個更好的方式來打包和部署云本機應(yīng)用程序。我相信你聽說過Docker和相關(guān)的動量(或者說是科技泡沫?)。這也很符合另一個趨勢(微服務(wù))，這一個博文不夠說了。
有趣的是，許多人也認為這種容器化趨勢只是某個東西更大(呃,或者說更小?)的過渡。
援引：Invent 2014 AWS介紹了一項新服務(wù)，被稱為Lambda云本機應(yīng)用程序。這個可以允許開發(fā)人員編寫代碼并把代碼作為數(shù)據(jù)的一部分。當(dāng)數(shù)據(jù)發(fā)生變化時,事件觸發(fā)代碼運行。沒有虛擬機,沒有選擇的容器，代碼只是突然地運行起來。換句話說，基礎(chǔ)設(shè)施沒有簡化，它只是消失了。
下圖描述了圖形化這一概念:
你可以想象這些概念將會話通向PaaS-ish模型。
#p#
數(shù)據(jù)和狀態(tài)域
現(xiàn)在將自己傳送到另一個維度。
轉(zhuǎn)換思維。
持久性和彈性問題。很多很多問題。
有幾件事,屬于這個域。
最重要的一個就是在哪持有用戶數(shù)據(jù)。想想傳統(tǒng)的(關(guān)系型)數(shù)據(jù)庫但也可能是一個存儲庫的非結(jié)構(gòu)化數(shù)據(jù)(例如對象存儲、NoSQL)。往往這些服務(wù)是由云提供商提供管理服務(wù)。并沒有什么會阻止其他人寫云本機應(yīng)用程序部署和管理他們自己的數(shù)據(jù)庫(關(guān)系型或非關(guān)系型)，通常是利用諸如AWS RDS或AWS DynamoDB等管理服務(wù)。
這方法(有價值可選)的優(yōu)點是，你有你的持久性和可靠性保證而不是花時間讓自己發(fā)生。
***，一個云提供商用一個完全自動化的方式管理成百不一定上千的實例比一個人兼DBA特別是一個開發(fā)人員，要好很多。
這些云托管服務(wù)的特點是，他們(通常)和水平呈線性比例關(guān)系。
以對象存儲為例，您可以在主宰***(或觀念上的)的數(shù)據(jù)量。
想想諸如AWS DynamoDB等服務(wù),你只需要訂閱這個服務(wù)形成SLAs，云提供商將根據(jù)SLA管理所需的容量(后臺)。
傳統(tǒng)的關(guān)系數(shù)據(jù)庫(盡管管理，如AWS RDS)通常不提供這種感覺***的可伸縮性，因為他們常常向外擴展(但不超出)和基于云實例支持管理數(shù)據(jù)庫大小才有的實際限制。
取決于你的選擇將會有一個變量的基礎(chǔ)設(shè)施和核心操作過程的可視性,但所有這些解決方案減輕很多負擔(dān)的持久性域的可伸縮、高可用性和彈性。
第二組持久性,屬于這個域的描述是基礎(chǔ)設(shè)施,隨著應(yīng)用程序棧,需要部署、推廣和運營。我把它叫做基礎(chǔ)結(jié)構(gòu)狀態(tài)。
這樣描述：
- 核心基礎(chǔ)設(shè)施應(yīng)該像什么樣的(又名“基礎(chǔ)設(shè)施及代碼”)
- 實例化應(yīng)用程序的存儲庫
- 應(yīng)用程序配置。
題外話： Twelve-Factor App聲明中描述將應(yīng)用程序代碼從應(yīng)用程序配置中分離是一個***實踐。通過這樣做你可以實例化不同的環(huán)境(開發(fā)、測試、分期、生產(chǎn))通過簡單地指向一個不同的應(yīng)用程序配置。模塊化(各級)規(guī)則在云本機應(yīng)用程序。
這種持久性的第二組數(shù)據(jù)和狀態(tài)域可以以不同的方式實現(xiàn)。這可能是一個(或多個)：
- 一組AWS Cloudformations模板描述如何建模你的基礎(chǔ)設(shè)施容量
- Puppet, Chef, Ansible, Saltstack或是Terraform，聲稱讓你的虛擬機在運行時通過給定的配置集中起來
- 服務(wù)如GitHub托管應(yīng)用程序的“代碼”
注意基礎(chǔ)設(shè)施狀態(tài)只是概念上的用戶數(shù)據(jù),它們共享相同的需求(一致、可靠、耐用等)。然而這些服務(wù)可以在物理上分開。
雖然最近用一個云提供商一起把所有這些環(huán)境(基礎(chǔ)設(shè)施容量域和數(shù)據(jù)和狀態(tài)域)放在一起是相當(dāng)普遍的，大家也可以認為他們是松散耦合的環(huán)境(如基礎(chǔ)設(shè)施容量由兩個云提供商,業(yè)務(wù)數(shù)據(jù)托管在第三個云提供商和基礎(chǔ)設(shè)施狀態(tài)托管在其他地方)。
讓我們一起把它們組裝起來
如果你試圖把所有上述成更詳細的圖片，云本機應(yīng)用程序?qū)⒖雌饋硐袷沁@樣。
在根據(jù)上述每個基礎(chǔ)設(shè)施狀態(tài)邏輯的描述實例化(和運營)每個基礎(chǔ)設(shè)施，在運行時，應(yīng)用程序部署在開始消費和交互用戶數(shù)據(jù)(如數(shù)據(jù)庫、對象存儲等)。
這張照片缺少的(在許多其他事物)是可伸縮性這兩個域的性質(zhì)。這是另一個云平臺的核心原則,在這篇文章中我不不涉及過多。這兩種環(huán)境中可以根據(jù)外部觸發(fā)自然增長和收縮(如越來越多的應(yīng)用程序用戶或越來越多組數(shù)據(jù)管理)。
因此應(yīng)用程序所有者將根據(jù)實際的，正在被應(yīng)用程序使用的，資源支付相關(guān)費用。
#p#
你今天站在哪里?
我們已經(jīng)描述了一個云本機應(yīng)用程序的外觀。
但是，你處于什么位置?
很有可能，除非你是Netflix風(fēng)格組織，你不在我所說的范圍內(nèi)。
很有可能你的工作負載可能看起來或多或少是這樣的：
你還記得 Pets and Cattle的故事嗎?
我不再重復(fù)了。你可以閱讀一下那個博客。
還要注意為何你沒有形成基礎(chǔ)設(shè)施容量和數(shù)據(jù)之間的關(guān)系。更不用說基礎(chǔ)設(shè)施的狀態(tài)了。
95%的組織(完全編造的數(shù)字，但我覺得差不了多遠)本質(zhì)上是處理一群寵物，通過名字召喚，都有自己的獨特的個性和狀態(tài)(在本地保存)，當(dāng)他們死的時候你會哭的很兇。
傳統(tǒng)的(即不是云原生的)應(yīng)用程序時,您需要安裝，操作，文檔，備份，遷移和保護您的工作負載。這與你在云本機應(yīng)用程序上做的完全相反。
除此之外，沒有特定的分離容量和狀態(tài)。所有工作負載的狀態(tài)保存在本地磁盤上的每個實例。
在***的情況下，狀態(tài)一直備份到一個Word或Excel文檔。如果(或者當(dāng)?)工作負載的接近滿負荷，操作員通常會手動地通過一個簡單的模板根據(jù)Word / Excel“使用說明書”重裝一次。
其中的一些工作負載也以數(shù)據(jù)庫或文件的形式托管用戶數(shù)據(jù)。他們需要額外的照顧，這很復(fù)雜，甚至以后的可靠性和可伸縮性。
一個很好的試金石：看看您正在運行的舊的應(yīng)用程序或云本機應(yīng)用程序是不是如下。
在周一早上11點邀請我到你的數(shù)據(jù)中心，關(guān)閉并摧毀20%的生產(chǎn)實例。
如果您的應(yīng)用程序部署自我修復(fù)本身沒有任何需要你的部分，如果有最小的不中斷你的終端用戶體驗，那么你正在運行一個合適的云本機應(yīng)用程序。
相反，如果你是像“噢，我的天你做了什么?我有一個星期的工作現(xiàn)在在我的面前!”這樣的，所有你的手機瘋狂地響了，那么歡迎來到還有剩下的95%的人的現(xiàn)實世界。
記住，自動化和自愈是云本機應(yīng)用程序的一個重要宗旨。我記得會見過一個客戶，一個應(yīng)用程序(計算容量和數(shù)據(jù))分布在數(shù)據(jù)中心的架構(gòu)只為了保留一個完整的站點不中斷。他們告訴我，不幸的是，如果一個數(shù)據(jù)節(jié)點壞了，它將花費數(shù)周，也許不是數(shù)月手動重建環(huán)境。如果你問我，那這不是云。
結(jié)論
還有許多其他云本機應(yīng)用程序的特點,這里我不贅述了。如果你是一個高級的開發(fā)人員加入到這個行列中，你***立刻先把Twelve-Factor App 的說明讀一遍。
在這篇文章中我想笨一點方式讓這些概念被更多的人明白(特別是沒有云或開發(fā)人員背景的聽眾)。
總而言之，我認為強分離容量和狀態(tài)是其中一個強大的云咒語，把大多數(shù)優(yōu)勢(和改變?)與傳統(tǒng)IT相比較。
這種分離是一個在任何級別的一個真正的云的基礎(chǔ)設(shè)施都是的核心原則。在這篇文章中，我利用一個大圖提到了全部的復(fù)雜的云本機應(yīng)用程序。
然而,即使你把云環(huán)境的最小的原子單元(即一個實例)，分離容量和狀態(tài)仍然是核心。看看亞馬遜是如何描述由一個EC2實例與一對EBS磁盤(即持久的磁盤)組成的一個基本的工作負載：
在一個小得多的規(guī)模它傳達了這篇文章我試圖傳達的同樣的信息(圖形化)。云中的各級模塊化是核心。
題外話:具有諷刺意味的是，EC2默認為臨時的磁盤，那么云本機應(yīng)用程序模式(在實例級不需要狀態(tài)存儲)。然而，為了更好地服務(wù)傳統(tǒng)非云本機應(yīng)用程序，亞馬遜引入一個EBS(單一實例級別持久性)的概念。一個可以稱為在持久的磁盤anti-cloud模式的實例。我將因為這點拋棄它。
***,正如你可能已經(jīng)猜到了，在這篇文章中你所讀到的關(guān)于云本機應(yīng)用程序會引入其他流行語如：敏捷，DevOps，持續(xù)性開發(fā)、持續(xù)性部署和更多更多。
事實上,沒有一個正確設(shè)計云本機應(yīng)用程序沒有辦法，做到這些的。
Massimo。
