業務應用系統為什麼要導入新架構微服務與Container？這些技術具備怎樣特性去解決以往哪些較難克服的情境問題？而當我們在設計一個Container時又有什麼原則我們該考慮才能真的解決上述的情境問題呢？我們可以先把一個Container想像成機械公敵裡面的單一機器人來理解：
啟動簡單迅速、消耗品、Scalable
- 需要時可以立即啟動
- 消耗品，壞掉了也無所謂，丟掉再啟動一個新的就是了
- 一個不夠就派兩個，可以依此類推透過無限增加數量來完成任務
而微服務架構Container設計原則的另一端就可以想像成是環太平洋裡面的巨型機器人：
- 啟動的前置時間很長，作業繁複危險，需要有專門的維運團隊負責
- 每個機器人都是傾全國力量打造，數量稀少，壞掉一個就有大麻煩了
- 一個不夠後面也沒有幾個能支援了，一但遇到之前沒遇過的新強度容易全軍覆沒，打掉重練
IT容易因應業務的快速變化與多樣需求
以上幾點，最重要的就在於沒遇過的挑戰。現在的業務應用發展非常迅速，變化的幅度也相當大，面臨的挑戰多樣化，有的可能是流量上的挑戰，有的是服務介面或流程上的多樣性調整或其他各式各樣不同應用情境下面臨的新挑戰。
而微服務架構下的Container最大優點即是容易因應變化。引用反脆弱這本書的想法來解釋，未來的變化越來越不可預測，而因為事前的預測不可行，所以避免被未知變化打敗的策略不是變得更堅強(ex:造巨型機器人)，而是變得可以因應變化(ex:透過各種容易打造，靈活改變與量產的微型機器人)
以Netflix全球線上影音播放龍頭來說，它們每日面臨的流量變化是無法預估的，服務遍及全球，所以哪個地方的網路突然不穩定也是不可預測的，但只要透過微服務架構，流量一大即可透過立即增加微服務數量來彈性因應，服務預期外下線只要讓其他服務Fail-over接手即可。
引用到金融業，為來可能與APP業者合作推出行銷方案，因活動所帶來流量的不確定性與方案的多樣性就很適合用微服務架構來因應。
所以今天不管海底冒出什麼變種怪物，都可以透過靈活快速改變迭代微型機器人的功能與增加數量來對付。
技術實作要與微服務基礎架構配合
在談實作之前要先釐清，Contaienr本身不能夠決定自己容不容易快速啟動、是否具備消耗品特性、與scalable，要具備以上能力不僅Container設計時要考慮，更重要的前期階段整個微服務基礎設施架構設計上就要考慮進去。也就是說如果沒有一個良好在背後運籌帷幄自動調配的為微服務基礎設施架構，Container是沒有辦法發揮1+1>=2的效果。
打個簡單比方，前方戰線吃緊但後方的大本營卻狀況外，遲遲不開啟新機器人出去應戰那也是沒有用的。
Container生命週期
典型的Container設計對外是透過RestAPI來提供服務，所以內部是一個Web Service，其中包含了必要的業務邏輯，啟動後會有systemd自動把服務帶起並運作，啟動後Container加入Service Discovery就可以開始處理業務請求了。
整個啟動時間以Tomcat應用來說是可以在1秒內啟動完成。而一但這個Container不再需要即可透過微服務基礎設施進行刪除來結束生命週期。
檢康檢查機制
每個Container都要盡可能避免自己出現Fatal Error，也就是會出現導致服務中斷不回應的例外錯誤。systemd在這裡可以發揮適當的進程守護機制，如監控Tomcat健康狀態如發現進程掛掉自動重啟等。
而微服務基礎設施也有責任透過協調好的Health Check API或Ping去發現回應不如預期的Container，並作出適當回應機制如Fail-Over。畢竟不能夠相信有 100%1不會掛掉的Container存在。
錯誤復原與Root Cause分析
一但發生錯誤，第一時間的錯誤復原很簡單可讓基礎設施透過Docker特性，重啟整個Container來達到恢復狀態。但這個事件必須要被Log給記錄下來。包含呼叫的Container與Image版本、呼叫的AP、時間、帶入的參數等等。在事後才能透過以上資訊來找出Root Cause並升級Container Image來防止再次發生。
Image版本控管
Contaienr通常是會不斷迭代的
- 基礎設施升級並提供新功能，Container配合升級以提供新功能
- Container bug fix 或 feature add
因為不同類型的Container常會以功能劃分並模組化管理，而隨著不斷迭代，基礎設施與Image版本也幾乎必定會有向下相容的議題產生，特定版本的基礎設施要搭配特定幾版以上的Image。所以長期來看版本控制就特別重要。所以導入Git與做好文件是系統能不能長期穩定提供服務與發展的重要關鍵。
而如果基礎設施版本與Image版本之間有Dependence的關係一定要特別註明。
資料保存
Container能夠快速重起的特性帶來一個重要議題：重啟後Container內的資料是會不見的。所以如果Container內的資料是很重要的，如資料庫檔案等請參考Docker Volume把重要的資料掛載一個鏡像在Host。這樣一但程式有問題，重啟後資料還在，才可以繼續維持服務。
這部分典型應用如把MySQL做成Container，這時候MySQL版本進行升級只要替換Image版本，就可以在資料保存不丟失的狀態下升級MySQL。
結論
一開始從談論導入微服務架構與Container對業務的好處是什麼開始，因為IT能夠長期有效並從容迅速的去解決未來可能面臨的各種業務需求問題，才能最大化IT價值。接著從此架構的特性來談為甚麼能解決上述問題，最後再跑過一次整個細部技術實作上會遇到的議題。
實務上除了微服務基礎設施一定要自己全部掌握與了解，其實就Container單一服務只要考慮好：
- 把API接口input/output定義
- performance與壓力測試要求
- 啟動時間
- scale的方式是否能跟微服務設施搭配
- 錯誤處理機制
- 文件撰寫規範
- 版本控制
上述幾點考慮好其實就單個特定需求的Container服務來說是可以透過外包的方式來實作也沒有問題的。
可以發現的是Container設計起來相對於微服務基礎設施簡單，需要考慮的議題除了版本控管與Scale之外都偏向於單點技術的實作。而這也是符合避免打造一台巨型機器人的原則。
附錄
附錄裡介紹Netflix在全球有上萬Container去服務數百萬觀眾，而這只需要10多個維運工程師，令人印象深刻。