Saas應用12個架構規(guī)范分別是什么

Saas應用12個架構規(guī)范分別是什么，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、引言

如今，軟件通常會作為一種服務來交付，它們被稱為網(wǎng)絡應用程序，或軟件即服務（SaaS）。12-Factor 為構建如下的 SaaS 應用提供了方法論：

• 使用標準化流程自動配置，從而使新的開發(fā)者花費最少的學習成本加入這個項目。

• 和操作系統(tǒng)之間盡可能的劃清界限，在各個系統(tǒng)中提供最大的可移植性。

• 適合部署在現(xiàn)代的云計算平臺，從而在服務器和系統(tǒng)管理方面節(jié)省資源。

• 將開發(fā)環(huán)境和生產(chǎn)環(huán)境的差異降至最低，并使用持續(xù)交付實施敏捷開發(fā)。

• 可以在工具、架構和開發(fā)流程不發(fā)生明顯變化的前提下實現(xiàn)擴展。

這套理論適用于任意語言和后端服務（數(shù)據(jù)庫、消息隊列、緩存等）開發(fā)的應用程序。

二、十二個架構規(guī)范

1.統(tǒng)一源代碼管理系統(tǒng)

一份基準代碼（Codebase），多份部署（deploy）

在類似 SVN 這樣的集中式版本控制系統(tǒng)中，基準代碼 就是指控制系統(tǒng)中的這一份代碼庫；而在 Git 那樣的分布式版本控制系統(tǒng)中，基準代碼 則是指最上游的那份代碼庫。

基準代碼和應用之間總是保持一一對應的關系：

• 一旦有多個基準代碼，就不能稱為一個應用，而是一個分布式系統(tǒng)。分布式系統(tǒng)中的每一個組件都是一個應用，每一個應用可以分別使用 12-Factor 進行開發(fā)。

• 多個應用共享一份基準代碼是有悖于 12-Factor 原則的。解決方案是將共享的代碼拆分為獨立的類庫，然后使用 依賴管理 策略去加載它們。

2.依賴管理

顯式聲明依賴

大多數(shù)編程語言都會提供一個打包系統(tǒng)，用來為各個類庫提供打包服務，就像 Perl 的 CPAN 或是 Ruby 的 Rubygems 。通過打包系統(tǒng)安裝的類庫可以是系統(tǒng)級的（稱之為 “site packages”），或僅供某個應用程序使用，部署在相應的目錄中（稱之為 “vendoring” 或 “bunding”）

12-Factor規(guī)則下的應用程序不會隱式依賴系統(tǒng)級的類庫。 它一定通過 依賴清單 ，確切地聲明所有依賴項。此外，在運行過程中通過 依賴隔離 工具來確保程序不會調(diào)用系統(tǒng)中存在但清單中未聲明的依賴項。這一做法會統(tǒng)一應用到生產(chǎn)和開發(fā)環(huán)境。

顯式聲明依賴的優(yōu)點之一是為新進開發(fā)者簡化了環(huán)境配置流程。新的開發(fā)者可以檢出應用程序的基準代碼，安裝編程語言環(huán)境和它對應的依賴管理工具，只需通過一個 構建命令 來安裝所有的依賴項，即可開始工作，如Maven，Pip，Npm等

12-Factor 應用同樣不會隱式依賴某些系統(tǒng)工具，如 ImageMagick 或是curl。即使這些工具存在于幾乎所有系統(tǒng)，但終究無法保證所有未來的系統(tǒng)都能支持應用順利運行，或是能夠和應用兼容。如果應用必須使用到某些系統(tǒng)工具，那么這些工具應該被包含在應用之中。

3. 配置管理

在環(huán)境中存儲配置

通常，應用的 配置 在不同 部署 (預發(fā)布、生產(chǎn)環(huán)境、開發(fā)環(huán)境等等)間會有很大差異。這其中包括：

?  數(shù)據(jù)庫，Memcached，以及其他后端服務 的配置

?  第三方服務的證書，憑證，如 Amazon S3、Twitter 等

?  每份部署特有的配置，如域名等

應用程序不允許將配置存儲為代碼中的常量，這需要嚴格地將配置與代碼分離。配置在部署之間差異很大，代碼則沒有。另外，“config”的這個定義不包括內(nèi)部應用程序配置，這種類型的配置在部署之間不會有所不同，因此最好在代碼中保存

提示：對應用程序是否在代碼中正確分配了所有配置的試金石是，代碼庫是否可以隨時變?yōu)殚_源，而不用擔心泄漏任何敏感憑據(jù)。

應用程序應將配置存儲在環(huán)境變量中（通常縮寫為env vars或env）。在不更改任何代碼的情況下，可以在部署之間輕松更改Env變量; 與配置文件不同，它們幾乎沒有機會被意外地檢入代碼倉庫; 與自定義配置文件或其他配置機制（如Java系統(tǒng)屬性）不同，它們是與語言和操作系統(tǒng)無關的標準。

4. 后端服務

把后端服務(backing services)當作附加資源

后端服務是指程序運行所需要的通過網(wǎng)絡調(diào)用的各種服務，如數(shù)據(jù)庫（MySQL，CouchDB），消息/隊列系統(tǒng)（RabbitMQ，Beanstalkd），SMTP 郵件發(fā)送服務（Postfix），以及緩存系統(tǒng)（Memcached）。

類似數(shù)據(jù)庫的后端服務，通常由部署應用程序的系統(tǒng)管理員一起管理。除了本地服務之外，應用程序有可能使用了第三方發(fā)布和管理的服務。示例包括 SMTP（例如 Postmark），數(shù)據(jù)收集服務（例如 New Relic 或 Loggly），數(shù)據(jù)存儲服務（如 Amazon S3），以及使用 API 訪問的服務（例如 Twitter, Google Maps, Last.fm）。

12-Factor 應用不會區(qū)別對待本地或第三方服務。 對應用程序而言，兩種都是附加資源，通過一個 url 或是其他存儲在 配置 中的服務定位/服務證書來獲取數(shù)據(jù)。12-Factor 應用的任意 部署 ，都應該可以在不進行任何代碼改動的情況下，將本地 MySQL 數(shù)據(jù)庫換成第三方服務（例如 Amazon RDS）。類似的，本地 SMTP 服務應該也可以和第三方 SMTP 服務（例如 Postmark ）互換。上述 2 個例子中，僅需修改配置中的資源地址。

12-Factor 應用將這些都視作 附加資源 ，這些資源和它們附屬的部署保持松耦合。

5. 構建，發(fā)布，運行

嚴格分離構建和運行

基準代碼 轉(zhuǎn)化為一份部署(非開發(fā)環(huán)境)需要以下三個階段：

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

• 發(fā)布階段 會將構建的結(jié)果和當前部署所需 配置 相結(jié)合，并能夠立刻在運行環(huán)境中投入使用。

• 運行階段 （或者說“運行時”）是指針對選定的發(fā)布版本，在執(zhí)行環(huán)境中啟動一系列應用程序 進程。

12-factor 應用嚴格區(qū)分構建，發(fā)布，運行這三個步驟。 舉例來說，直接修改處于運行狀態(tài)的代碼是非常不可取的做法，因為這些修改很難再同步回構建步驟。

每一個發(fā)布版本必須對應一個唯一的發(fā)布 ID，例如可以使用發(fā)布時的時間戳（2011-04-06-20:32:17），亦或是一個增長的數(shù)字（v100）。發(fā)布的版本就像一本只能追加的賬本，一旦發(fā)布就不可修改，任何的變動都應該產(chǎn)生一個新的發(fā)布版本。這樣也便于回退到任意歷史版本，而不需要冒風險重新構建。

新的代碼在部署之前，需要開發(fā)人員觸發(fā)構建操作。但是，運行階段不一定需要人為觸發(fā)，而是可以自動進行。如服務器重啟，或是進程管理器重啟了一個崩潰的進程。因此，運行階段應該保持盡可能少的模塊，這樣假設半夜發(fā)生系統(tǒng)故障而開發(fā)人員又捉襟見肘也不會引起太大問題。構建階段是可以相對復雜一些的，因為錯誤信息能夠立刻展示在開發(fā)人員面前，從而得到妥善處理。

6. 進程

以一個或多個無狀態(tài)進程運行應用

運行環(huán)境中，應用程序通常是以一個和多個 進程 運行的。

12-Factor 應用的進程必須無狀態(tài)且 無共享 。 任何需要持久化的數(shù)據(jù)都要存儲在 后端服務 內(nèi)，比如數(shù)據(jù)庫。

內(nèi)存區(qū)域或磁盤空間可以作為進程在做某種事務型操作時的緩存，例如下載一個很大的文件，對其操作并將結(jié)果寫入數(shù)據(jù)庫的過程。12-Factor應用根本不用考慮這些緩存的內(nèi)容是不是可以保留給之后的請求來使用，這是因為應用啟動了多種類型的進程，將來的請求多半會由其他進程來服務。即使在只有一個進程的情形下，先前保存的數(shù)據(jù)（內(nèi)存或文件系統(tǒng)中）也會因為重啟（如代碼部署、配置更改、或運行環(huán)境將進程調(diào)度至另一個物理區(qū)域執(zhí)行）而丟失。

一些系統(tǒng)依賴于 “粘性 session”， 這是指將用戶 session 中的數(shù)據(jù)緩存至某進程的內(nèi)存中，并將同一用戶的后續(xù)請求路由到同一個進程。粘性 session 是 12-Factor 極力反對的。Session 中的數(shù)據(jù)應該保存在諸如 Memcached 或 Redis 這樣的帶有過期時間的緩存中。

7. 端口綁定

通過端口綁定(Port binding)來提供服務

應用有時會運行于服務器的容器之中。例如 PHP 經(jīng)常作為 Apache HTTPD 的一個模塊來運行，正如 Java 運行于 Tomcat 。

12-Factor 應用完全自我加載 而不依賴于任何網(wǎng)絡服務器就可以創(chuàng)建一個面向網(wǎng)絡的服務。互聯(lián)網(wǎng)應用 通過端口綁定來提供服務 ，并監(jiān)聽發(fā)送至該端口的請求。

還要指出的是，端口綁定這種方式也意味著一個應用可以成為另外一個應用的 后端服務 ，調(diào)用方將服務方提供的相應 URL 當作資源存入 配置 以備將來調(diào)用。

8. 并發(fā)

通過進程模型進行擴展

在 12-factor 應用中，進程是一等公民。12-Factor 應用的進程主要借鑒于 unix 守護進程模型 。開發(fā)人員可以運用這個模型去設計應用架構，將不同的工作分配給不同的 進程類型 。例如，HTTP 請求可以交給 web 進程來處理，而常駐的后臺工作則交由 worker 進程負責。

上述進程模型會在系統(tǒng)急需擴展時大放異彩。 12-Factor 應用的進程所具備的無共享，水平分區(qū)的特性 意味著添加并發(fā)會變得簡單而穩(wěn)妥。這些進程的類型以及每個類型中進程的數(shù)量就被稱作 進程構成 。

9. 易處理

快速啟動和優(yōu)雅終止可最大化健壯性

12-Factor 應用的 進程 是 易處理（disposable）的，意思是說它們可以瞬間開啟或停止。 這有利于快速、彈性的伸縮應用，迅速部署變化的 代碼 或 配置 ，穩(wěn)健的部署應用。

進程應當追求 最小啟動時間 。 理想狀態(tài)下，進程從敲下命令到真正啟動并等待請求的時間應該只需很短的時間。更少的啟動時間提供了更敏捷的 發(fā)布 以及擴展過程，此外還增加了健壯性，因為進程管理器可以在授權情形下容易的將進程搬到新的物理機器上。

另外進程 一旦接收 終止信號（SIGTERM） 就會優(yōu)雅的終止 。就網(wǎng)絡進程而言，優(yōu)雅終止是指停止監(jiān)聽服務的端口，即拒絕所有新的請求，并繼續(xù)執(zhí)行當前已接收的請求，然后退出。此類型的進程所隱含的要求是HTTP請求大多都很短(不會超過幾秒鐘)，而在長時間輪詢中，客戶端在丟失連接后應該馬上嘗試重連；對于 worker 進程來說，優(yōu)雅終止是指將當前任務退回隊列。

10. 開發(fā)環(huán)境與線上環(huán)境一致

盡可能的保持開發(fā)，預發(fā)布，線上環(huán)境相同

開發(fā)環(huán)境（即開發(fā)人員的本地 部署）和線上環(huán)境（外部用戶訪問的真實部署）之間存在著很多差異。這些差異表現(xiàn)在以下三個方面：

• 時間差異： 開發(fā)人員正在編寫的代碼可能需要幾天，幾周，甚至幾個月才會上線。

• 人員差異： 開發(fā)人員編寫代碼，運維人員部署代碼。

• 工具差異： 開發(fā)人員或許使用 Nginx，SQLite，OS X，而線上環(huán)境使用 Apache，MySQL 以及 Linux。

12-Factor 應用想要做到 持續(xù)部署 就必須縮小本地與線上差異。 再回頭看上面所描述的三個差異:

• 縮小時間差異：開發(fā)人員可以幾小時，甚至幾分鐘就部署代碼。

• 縮小人員差異：開發(fā)人員不只要編寫代碼，更應該密切參與部署過程以及代碼在線上的表現(xiàn)。

• 縮小工具差異：盡量保證開發(fā)環(huán)境以及線上環(huán)境的一致性。

將上述總結(jié)變?yōu)橐粋€表格如下：

12-Factor 應用的開發(fā)人員應該反對在不同環(huán)境間使用不同的后端服務 ，即使適配器已經(jīng)可以幾乎消除使用上的差異。這是因為，不同的后端服務意味著會突然出現(xiàn)的不兼容，從而導致測試、預發(fā)布都正常的代碼在線上出現(xiàn)問題。這些錯誤會給持續(xù)部署帶來阻力。從應用程序的生命周期來看，消除這種阻力需要花費很大的代價。

11. 日志

把日志當作事件流

日志 使得應用程序運行的動作變得透明。在基于服務器的環(huán)境中，日志通常被寫在硬盤的一個文件里，但這只是一種輸出格式。

12-factor應用本身從不考慮存儲自己的輸出流。 不應該試圖去寫或者管理日志文件。相反，每一個運行的進程都會直接的標準輸出（stdout）事件流。開發(fā)環(huán)境中，開發(fā)人員可以通過這些數(shù)據(jù)流，實時在終端看到應用的活動。

在預發(fā)布或線上部署中，每個進程的輸出流由運行環(huán)境截獲，并將其他輸出流整理在一起，然后一并發(fā)送給一個或多個最終的處理程序，用于查看或是長期存檔。這些存檔路徑對于應用來說不可見也不可配置，而是完全交給程序的運行環(huán)境管理。類似 Logplex 和 Fluentd 的開源工具可以達到這個目的。

這些事件流可以輸出至文件，或者在終端實時觀察。最重要的，輸出流可以發(fā)送到 Splunk 這樣的日志索引及分析系統(tǒng)，或 Hadoop/Hive 這樣的通用數(shù)據(jù)存儲系統(tǒng)。這些系統(tǒng)為查看應用的歷史活動提供了強大而靈活的功能，包括：

• 找出過去一段時間特殊的事件。

• 圖形化一個大規(guī)模的趨勢，比如每分鐘的請求量。

• 根據(jù)用戶定義的條件實時觸發(fā)警報，比如每分鐘的報錯超過某個警戒線。

12. 管理進程

后臺管理任務當作一次性進程運行

進程構成（process formation）是指用來處理應用的常規(guī)業(yè)務（比如處理 web 請求）的一組進程。與此不同，開發(fā)人員經(jīng)常希望執(zhí)行一些管理或維護應用的一次性任務，例如：

• 運行數(shù)據(jù)移植（Django 中的 manage.py migrate, Rails 中的 rake db:migrate）。

• 運行一個控制臺（也被稱為 REPL shell），來執(zhí)行一些代碼或是針對線上數(shù)據(jù)庫做一些檢查。大多數(shù)語言都通過解釋器提供了一個 REPL 工具（python 或 perl） ，或是其他命令（Ruby 使用 irb, Rails 使用 rails console）。

• 運行一些提交到代碼倉庫的一次性腳本。

一次性管理進程應該和正常的 常駐進程 使用同樣的環(huán)境。這些管理進程和任何其他的進程一樣使用相同的 代碼 和 配置 ，基于某個 發(fā)布版本 運行。后臺管理代碼應該隨其他應用程序代碼一起發(fā)布，從而避免同步問題。

看完上述內(nèi)容，你們掌握Saas應用12個架構規(guī)范分別是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內(nèi)容，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！