Micro service 的12個必備要素

原文自https://12factor.net/

app=Micro service

1. 1個app只有 1 份Codebase 
1. 每一個app只會有一份code, 意即如果你有個app A 但他有多份code, 它其實是分散式系統,可以切得更細.每一份不同的code都是一個獨立app才對.
2. 多個不同的app 若共用同一份code也不對, 理應是共用的code做成common Library
2. app的Dependencies定義明確且獨立
1. app會用到哪些相依性元件應該是明確定義在某一份文件裡面, 比如Ruby Gemfile or scala build.sbt, app 不該用到隱性系統層面的元件, 比如liux下的curl, cronjob 等等, 這些東西一旦換了環境或者換了版本, 會出現難以追蹤的Bug 
3. Config是app佈署在各式環境的相應設定(production/staging/development/etc..) 
1. 內容項目
1. 後端服務(database/memcached/auth service)
2. 外部服務的授權key
3. 每一份部屬的app的設定 like hostname 
2. app的config理應獨立在config檔案裡面,如果放在程式碼裡面是違背12factors規則
3. 當開放app code程式碼且不須任何授權性的考量,代表該app config做得很完善.
4.  app config有別於framework/program module類的config,這些config並不因每一份佈署有差別(會有佈署差別: hostname, credentials. etc..  )
5. config相關內容並不會紀錄在版本控制, like git
6. 12factors 理應把config真實內容放在部屬的環境變數裡面
7. 分群管理(用name space分config)的方式 like development, test, production. 會有佈署與擴張的困難
4. app應用後端服務皆為統一的附屬資源
1. 內容項目
1. data stores. like mysql/couchbase/smtp server
2. 同一的資源亦即不管是存取本地資源還是外部第三方資源,都不需要改變代碼. ex change local MySql to AWS RDS, 代碼都用jdbc url 連接,不有搬遷改變的問題
3. 附屬資源意即當後端資源有問題, 只需要佈署時卸下有問題資源, 然後接上新的備援服務,過程中都不會改變到程式碼. ex if app's database is misbehaving , just detached bad one and attached backup one
5. 確實的分別建置build與執行run階段
1. 包含項目
1. build stage意即打包程式碼成為可執行的應用 ex jar
2. release stage意即將build stage產生的可執行app結合相應佈署的config, 最後得到是可在佈署環境立即執行的app
3. run stage啟動app, 使其維持在執行狀態
2. 確實的階段分割, 確保程式碼的修改不會影響到後續的build/release/run stages
3. release stage產出的每一份可執行app理應有一個獨立的編碼, 表示每一release是不可改變(code/config),有任何改變都是新的release
4. build stage是開發者負責管理與啟動, 開發者彈性去處理錯誤與發佈補丁
5. run time stage會是自動化or系統管理者的工作. 以避免app在半夜壞掉時沒有開發者可以及時處理
6. one or more stateless app:執行app理當視為一個或者多個無狀態的程序
1. app=process:在開發階段app可能由interpreter來呈現, 到了production更複雜的執行環境下, app是一個/多個系統程序process會更好管理(因為該環境可能不只有一個app, 多種類app都統一用process視角會省去管理複雜度)
2. stand-alone and stateless: app process理應無狀態且彼此獨立, 有任何該保存的狀態資訊應當放到後端服務 ex database
3. single-transaction:記憶體與檔案系統地的應用理當單一性,意即當前使用完,不保留到未來程序使用. 如此可以避免當app轉換生命週期時,狀態不一致(因為無狀態,無local state)
4. build include all component:app會應用到的相關元件應該build stage就建置完善, 而非到runtime才去生成. 就不會有狀態問題
5. no sticky session no local state:意即不暫存使用者資料, 期許下一次的訪問更快速, 如此一來app 就有local state, 違背stateless 精神, 這方面的需求理應放在time-expiration data store like Memcached/Redis.
7. self-contained. 12factors app理當是自身健全的服務, 有別於比如php app 需要依賴Apache HTTPD模組/ Java app依賴Tomcat. app可以直接對接網路埠口port, 直接接收並處理且回應任何請求. 當app能直接處理請求, 他自己也可以成為別的app的後端服務, 透過提供對應的address like url 到其他app的config
8. process concurrency: 12 factors app用process來實現多工, app process架構符合unix process model. process model可以應用到各種不同的工作內容 like HTTP request 就是web process, background task就是worker process. 這種設計有別於比如java用thread實現多工. 只有開發者自己明白thread的狀況, 不易於管理. process model的優勢來自於share-nothing/horizontally/partitionable, 使app易於擴張.
9. disposability: 12factors app process是可以隨時啟動或者暫停, 易於擴張, 快速的佈署與程式碼的/config修改, 並且有健全的production deploy.
1. minimize startup time: app盡可能快速的可處理外部request, 保持敏捷的擴張, 也提供了服務的強健, 意即當硬體有問題時, 可以很快的置換機器
2. gracefully shut down anytime: 能夠隨時停止接收request, 並處理好剩餘任務. 即使任務是耗時的, 當新的app起來時候, 也應該無縫的恢復.
10. dev=prod: 盡可能包持development/staging/production各階段條件都一致
1. time gap: 開發到佈署產品的時間差 
2. personal gap: 開發者程式碼vs操作人員佈署
3. tool gap: 開發環境vs佈署環境