容器化，微服務，DevOps，什么情況下會三位一體？

什么情況下，才應該考慮做一些改變呢？

傳統業務突然被互聯網業務沖擊了，應用老是變，三天兩頭要更新，而且流量增大了，原來支付系統是取錢刷卡的，現在要互聯網支付了，流量擴大了N倍。

沒辦法，一個字：拆

拆開了，每個子模塊獨自變化，少相互影響。

拆開了，原來一個進程扛流量，現在多個進程一起扛。

所以稱為微服務。

微服務場景下，進程多，更新快，于是出現100個進程，每天一個鏡像。

容器樂了，每個容器鏡像小，沒啥問題，虛擬機哭了，因為虛擬機每個鏡像太大了。

所以微服務場景下，可以開始考慮用容器了。

虛擬機怒了，老子不用容器了，微服務拆分之后，用Ansible自動部署是一樣的。

這樣說從技術角度來講沒有任何問題。

然而問題是從組織角度出現的。

一般的公司，開發會比運維多的多，開發寫完代碼就不用管了，環境的部署完全是運維負責，運維為了自動化，寫Ansible腳本來解決問題。

然而這么多進程，又拆又合并的，更新這么快，配置總是變，Ansible腳本也要常改，每天都上線，不得累死運維。

所以這如此大的工作量情況下，運維很容易出錯，哪怕通過自動化腳本。

這個時候，容器就可以作為一個非常好的工具運用起來。

除了容器從技術角度，能夠使得大部分的內部配置可以放在鏡像里面之外，更重要的是從流程角度，將環境配置這件事情，往前推了，推到了開發這里，要求開發完畢之后，就需要考慮環境部署的問題，而不能當甩手掌柜。

這樣做的好處就是，雖然進程多，配置變化多，更新頻繁，但是對于某個模塊的開發團隊來講，這個量是很小的，因為5-10個人專門維護這個模塊的配置和更新，不容易出錯。

如果這些工作量全交給少數的運維團隊，不但信息傳遞會使得環境配置不一致，部署量會大非常多。

容器是一個非常好的工具，就是讓每個開發僅僅多做5%的工作，就能夠節約運維200%的工作，并且不容易出錯。

然而本來原來運維該做的事情開發做了，開發的老大愿意么？開發的老大會投訴運維的老大么？

這就不是技術問題了，其實這就是DevOps，DevOps不是不區分開發和運維，而是公司從組織到流程，能夠打通，看如何合作，邊界如何劃分，對系統的穩定性更有好處。

所以微服務，DevOps，容器是相輔相成，不可分割的。

不是微服務，根本不需要容器，虛擬機就能搞定，不需要DevOps，一年部署一次，開發和運維溝通再慢都能搞定。

所以，容器的本質是基于鏡像的跨環境遷移。

鏡像是容器的根本性發明，是封裝和運行的標準，其他什么namespace，cgroup，早就有了。這是技術方面。

在流程方面，鏡像是DevOps的良好工具。

容器是為了跨環境遷移的，第一種遷移的場景是開發，測試，生產環境之間的遷移。如果不需要遷移，或者遷移不頻繁，虛擬機鏡像也行，但是總是要遷移，帶著幾百G的虛擬機鏡像，太大了。

第二種遷移的場景是跨云遷移，跨公有云，跨Region，跨兩個OpenStack的虛擬機遷移都是非常麻煩，甚至不可能的，因為公有云不提供虛擬機鏡像的下載和上傳功能，而且虛擬機鏡像太大了，一傳傳一天。

所以跨云場景下，混合云場景下，容器也是很好的使用場景。這也同時解決了僅僅私有云資源不足，扛不住流量的問題。

容器的正確使用場景：

根據以上的分析，我們發現容器推薦使用在下面的場景下。

1. 部署無狀態服務，同虛擬機互補使用，實現隔離性

2. 如果要部署有狀態服務，需要對里面的應用十分的了解

3. 作為持續集成的重要工具，可以順利在開發，測試，生產之間遷移

4. 適合部署跨云，跨Region，跨數據中心，混合云場景下的應用部署和彈性伸縮

5. 以容器作為應用的交付物，保持環境一致性，樹立不可變更基礎設施的理念

6. 運行進程基本的任務類型的程序

7. 用于管理變更，變更頻繁的應用使用容器鏡像和版本號，輕量級方便的多

8. 使用容器一定要管理好應用，進行health check和容錯的設計