基本架構
一般服務通常都是
1 db + 多 web app + load balance
通常稍微有一點經驗的 devops 都可以用 aws 組起來維護，非常適用新創公司。
大規模架構
然而當業務開始驅動技術時，例如業務量增長，流量逐漸變大時。
db 通常會先做垂直拓展（規格開大），但水平拓展就比較不容易
水平拓展通常會是遇到「巨量資料」時採取的手段，以一般新創的業務量來說基本上短期都不需要擔心。
這部分要先研究遇到的業務量是屬於「大量讀取」還是「大量寫入」
如果是大量讀取，透過一般關聯型資料庫做垂直拓展，配合緩存應該就可以有不錯的發揮。
如果是大量寫入，就會比較適合水平拓展，不過水平拓展後通常會增加開發複雜度
何謂大量？
可以參考大眾點評系統的設計，資料量可是到了 200 G 呢 XD
K8S 無狀態
在 K8S 裡面的容器都應該是無狀態的，無狀態意味著就算某一個服務掛掉，重新啟動或在建一個容器都能夠正常上線運作
但 DB 狀態都是持久化，基本上這是對 k8s 無狀態體系架構提出的挑戰，無論是複製或是擴展都要維護當前的 Data 和 Transactions，這裡會需要較高的學習成本。
所以如果 db 包在 docker, 要怎麼做 migration ? 要怎麼調整效能？ 會是比較麻煩的問題
總結
看過 facebook backend 版上面的討論總結結果
- 建議 db 只有 2-3 台都不需要 docker 化，只會搞死自己而已
- 整個服務的架構 docker 沒有超過 10 個也不需要做到 k8s