容器化，微服務，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和容錯的設計