工作中需要開發面對大小客戶的網站（爛大街的需求），考慮後臺架構（怎麼建項目），之前的Leader隨口說了個方案：不是有看docker嗎，做成分佈式的、一個容器一個客戶網站，一個客戶網站一個數據庫；網站代碼都一樣但配置文件不同，連接哪個數據庫就是哪個客戶的數據，開發也簡單。實際嘗試了下這裏面其實是有很多問題的（打包發佈就很麻煩、與前臺的接口也很麻煩、各數據庫的數據劃分和相互查詢更加麻煩），但是順着他給的思路，瞭解到了Multi-Tenant和Multi-Instance概念，不過還是這篇Gianpaolo 2006: SaaS Simple Maturity Model 最直接清楚。
06年提出的成熟度模型到現在好像已經是基礎概念，借用上面鏈接原圖：
和其他一些blog介紹：
SaaS-Architecture-and-The-SaaS-Maturity-Model
saas-architecture-maturity-model
簡單翻譯：
1. Level 0: (Ad-hoc / Custom) 或（Chaos/完全混亂狀態） ：給每個客戶各自定製軟件服務，每增加一個客戶都新寫一套代碼和運行一個新實例；
2. Level 1: (Configurable) 或（Managed Chaos/管理着的混亂狀態）：給每個客戶提供同一套的軟件（代碼相同）、通過軟件配置來區分各客戶服務，每增加一個客戶仍然需要運行一個新的軟件實例；
3. Level 2: (Configurable, Multi tenant) 或（Multi-Tenant, Highrise/多租戶、垂直升級）：只運行一套軟件來服務所有的客戶（同樣只有一套代碼，但因爲要處理多用戶情況、系統設計和開發要求比Level 1高），要增加系統性能只能升級單節點的資源(cpu, memory…）；
4. Level 3: (Scalable, Configurable, Multi tenant) 或（Multi-Tenant, Build-Out/多租戶、水平擴展）：仍然是用一套軟件服務、但通過負載均衡的方式引入多個節點；
5. （原文中沒有、可能是後來人加的）Level 4 （Utopia/烏托邦）：以負載均衡等方式管理服務端多版本軟件的多個實例，對外仍是統一的interface；
上圖4裏的每個實例（instance）有可能是一個monolithic software搞定了所有的功能服務（一個war包寫完所有後臺項目……），但更可能的情況是每個instance都是包含着多個子模塊的複雜系統。既然（不管是業務上還是代碼上）已經拆分成模塊，就會很自然的想到：不必認死理的按 1個instance：1套應用服務{子服務1，子服務2，...} 這樣的方式進行組織發佈。如果這些 {子服務1，子服務2，…} 可以從大項目裏解耦出來、作爲一個發揮特定功能的小instance單獨運行，即對圖4的實例集羣不是單純地從負載均衡的角度進行整體軟件系統的複製（如果不是複製而是從用戶角度進行ad hoc地修改又會回到圖1）、而是從服務的角度（SOA）進行系統分解（break down）：
- 性能瓶頸的服務可以分配到更多的資源/節點；
- 一個模塊的運行出錯也不會把整套應用實例拖掛；
- 一條子服務可以有多個實例維持功能；
- 如果免不了特殊服務、也可以封裝成另外的模塊、而非散佈到每個發佈實例；
細化到一定程度就引出了微服務的概念。
參考AWS re:Invent 2016: From Monolithic to Microservices: Evolving Architecture Patterns in the Cloud (ARC305)，下面圖裏連接着broswer的LoadBalancer就應該對應上圖4裏的Tenant Load Balancer：
和PFC304 Effective IPC in the Cloud: The Pros and Cons of Micro Services Architectures
以及James Lewis&Martin Fowler: Microservices
回到開頭的問題，總結2點：
1. 開頭提到的方案就是Level 1的情況，雖然理想中只要一份代碼、但實際很容易倒退回Level 0、Multi-Instance的情況（總有奇葩的客戶需求）；然後即便是Level 1、在web app裏不區分用戶省下的氣力也要在項目發佈和數據庫管理等別的地方還回來…
2. 架構設計和docker其實沒什麼直接關係…提到docker只是當時正在看。但一個容器一個網站的想法、應該是“tomcat裏丟war包”的思維定勢吧。