雲原生應用程序架構的五大特性（上）- 12要素應用

12要素的概念最先誕生於Heroku的工程師手中，說白了，其實就是雲原生應用程序架構的模式集合，它描述了一個應用程序的原型，最好地詮釋了採納雲原生應用程序架構的緣由。

 

經過突出陳述性配置和水平擴展的無狀態/無共享進程，以及總體上與部署環境的鬆耦合鏈接，這些模式實現了速度性、安全性和可擴展性。在當下，Cloud Foundry、Heroku和Amazon Elastic Beanstalk等雲應用程序平臺都已經爲部署12要素應用進行了優化。

 12要素視應用程序爲可獨立部署的單元，企業一般將多個可協做部署的單元稱爲一個應用，這些可協做部署的單元集合又能夠統稱爲分佈式系統。
12要素應用的核心思想以下所示一、基準代碼一份基準代碼，多份部署。每一個可部署的應用程序均被視爲在版本控制中的代碼庫來進行追蹤，相同的基準代碼可能在多個環境下部署有許多的應用程序實例。 

二、依賴顯式聲明依賴關係。應用程序經過適當的工具（如：Maven、Bundler、NPM）隔離依賴性，目的就是不依賴於部署環境。 

三、配置在環境中存儲配置。經過操做系統級的環境變量將配置信息或其餘可能存在的不一樣信息（如：開發環境、預生產環境、生產環境）應用到各個部署環境中。 

四、後端服務 把後端服務看成附加資源。數據庫、消息隊列、郵件發送服務或緩存系統等均被做爲是附加資源在不一樣環境中被同等地調用，每一個不一樣的後端服務都是一份資源 。

舉個例子，一個MySQL 數據庫是一個資源，兩個MySQL 數據庫（用來給數據分區）就是兩個不一樣的資源。12要素應用將這些數據庫都視做附加資源 ，將它們和部署環境保持鬆耦合。

 五、構建、發佈、運行嚴格分離構建和運行。基準代碼轉化爲部署(非開發環境)須要如下三個階段：

構建階段，是指將代碼倉庫轉化爲可執行包的過程。構建時會使用指定版本的代碼，獲取和打包依賴項，編譯成二進制文件和資源文件。

發佈階段，會將構建的結果和當前部署所需的配置相結合，並可以馬上在運行環境中投入使用。

運行階段，是指針對選定的發佈版本在執行環境中啓動一系列應用程序的進程。

以上全部階段都是嚴格分離的。

 六、進程以一個或多個無狀態進程運行應用。在運行環境中，應用程序做爲一個或多個無共享的無狀態進程（如：master/workers）來執行，任何須要持久化的數據都要存儲在後端服務內（例如：緩存、對象存儲等）。 

七、端口綁定經過端口綁定(Port Binding)來提供服務。具備12要素的應用可以實現徹底自我加載，不依賴於任何網絡服務器就能夠建立基於網絡的服務。互聯網應用能夠經過端口綁定來提供服務並隨時監聽全部發送至該端口的請求。 

八、並行經過進程模型進行擴展。通常而言，並行由水平向外擴展應用程序進程（儘管必要時進程也可經過內部管理線程多路傳輸工做）來實現。 

九、易處理經過快速啓動和終止來實現應用程序韌性的最大化。這包括了快速而有彈性的擴展、對變動的部署以及宕機恢復能力。 

十、開發環境與生產環境等價經過儘量地保持開發環境、預生產環境和生產環境三者的類似性來實現持續交付與部署。 

十一、日誌將日誌做爲事件流，容許執行環境經過集中式服務來收集、聚合、檢索和分析日誌，而非僅僅管理日誌文件。 

十二、管理進程將後臺管理任務看成一次性進程運行。當環境就等同於應用程序長時間運行的進程時，管理任務（如：數據庫遷移）會被做爲一次性進程而執行。

 

上述特徵很是適合須要快速部署的應用程序，由於它們極少依賴、甚至不依賴部署環境。因爲不依賴部署環境，底層雲平臺可使用自動化、簡單、統一的機制快速建立新環境及爲其部署應用程序。由此，12要素應用程序模式實現了速度的提高。
上述特徵還很是適用於瞬時性更新，以微乎其微的成本「丟棄」應用程序。因爲任何應用程序的狀態，不管是在內存中仍是別處都要被提取到某個支撐服務上，應用程序環境自己是百分之百可棄的，這就容許應用程序以一種很是簡單且自動化的方式來進行彈性擴展。在大多數狀況下，底層平臺會按所需次數對現有環境進行簡單複製並啓動進程，經過中止正在運行的進程和刪除環境實現縱向收縮，從而達到不在備份或保存上耗費功夫。由此，12要素應用程序模式實現了規模擴大。
最後，應用程序的易處理性使底層平臺能夠從故障事件中很是快速地進行自動恢復。將日誌做爲事件流大大增長了應用程序在運行時對於其底層動做的可見性，強制校驗環境和配置機制對支撐性服務的一致性管理又使得雲平臺可以提供運行時間、結構等各方面的豐富可視化功能。由此，12要素應用程序架構實現了安全性保障。