經過一晚我猜可能已經有人想到昨天提的架構中，解決了哪些問題又有哪些問題沒有被解決，但是還是要長話一下，說說昨天架構的問題點在哪裡。

• 已解決：

  • 升版容易，環境單純：
    將服務容器化後，我們不必在擔心服務是要跑在 Window、Linux(Ubuntu)、Linux(RedHat)...等不同作業系統，因為 Docker 服務就是提倡在任何環境快速佈署，讓開發人員不必在擔心作業系統、Kernel、環境等問題。版本升級方面也很容易，只需要更該「映像檔(image)」版本，即可完成版本升級。

  • 服務佈署超快速：
    假設有新進同事剛到公司報到，只需要將撰寫好的docker-compose.yml檔案提供給新同事，加上幾行指令，即可將開發中的專案跑起來，還不用擔心有任何環境問題。

  • 管理方便：
    因為每個環境的 image 跟 docker-compose.yml 佈署方式都相同(可能只會差異在環境變數)，不再出現「虛擬機」安裝過程中因不同人員建制造成的差異問題，服務也已經透過虛擬機分隔開，所以在管理上更加單純簡易。

• 尚未解決：

  • 浪費機器資源：
    因服務主要還是透過「虛擬機」進行劃分，所以還是必須要有多台「虛擬機」，因此就算在「虛擬機」上執行 container 服務，也只是縮短佈署服務的時間而已，並未真的解決資器資源問題，而解決這問題的方式，在下面的文章中，會在透過 K8S 架構的介紹，解決該問題。

  • 高成本：
    與上述相同的問題，服務主要還是透過「虛擬機」進行劃分，相對的還是得購買足夠的「實體機」數量，避免「虛擬機」數量過多，互搶「實體機」資源。

隨著 container 數量越來越多，漸漸會會感覺到難以控管，就像大量的「虛擬機」問題一樣，此刻你可能會開始尋找工具管理龐大數量的 container。(ex: docker swarm、K8S、K3S...)

可能會開始考慮使用雲端Server，例如: Google 推出的 GCP 或者 Amazon 的 AWS 雲端服務，因為這些雲端機器都已經有提供內建的 K8S 環境，讓用戶不用在為了架設 K8S 環境煩惱。

萬一團隊最後的決策是不希望將服務放置雲端機房，那有可能就衍生以下架構圖：

• 明天會在說明該架構內容，讀者可以在思考一下還有哪些更好的架構，歡迎提出來分享。
• 另外明天也會說明為什麼機器不再是「虛擬機」，而是直接使用「實體機」代替。