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

創(chuàng)新互聯(lián)建站專注于南關網(wǎng)站建設服務及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供南關營銷型網(wǎng)站建設，南關網(wǎng)站制作、南關網(wǎng)頁設計、南關網(wǎng)站官網(wǎng)定制、小程序制作服務，打造南關網(wǎng)絡公司原創(chuàng)品牌,更為您提供南關網(wǎng)站排名全網(wǎng)營銷落地服務。

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

 

傳統(tǒng)業(yè)務突然被互聯(lián)網(wǎng)業(yè)務沖擊了，應用老是變，三天兩頭要更新，而且流量增大了，原來支付系統(tǒng)是取錢刷卡的，現(xiàn)在要互聯(lián)網(wǎng)支付了，流量擴大了N倍。

 

沒辦法，一個字：拆

 

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

拆開了，原來一個進程扛流量，現(xiàn)在多個進程一起扛。

 

所以稱為微服務。

 

 

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

 

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

 

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

 

 

 

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

 

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

 

然而問題是從組織角度出現(xiàn)的。

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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

 

所以，容器的本質是基于鏡像的跨環(huán)境遷移。

 

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

 

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

 

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

 

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

 

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

 

容器的正確使用場景：

 

根據(jù)以上的分析，我們發(fā)現(xiàn)容器推薦使用在下面的場景下。

 

1. 部署無狀態(tài)服務，同虛擬機互補使用，實現(xiàn)隔離性

 

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

 

3. 作為持續(xù)集成的重要工具，可以順利在開發(fā)，測試，生產(chǎn)之間遷移

 

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

 

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

 

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

 

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

 

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

網(wǎng)頁名稱：容器化，微服務，DevOps，什么情況下會三位一體？
分享URL：http://bm7419.com/article6/goehig.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、網(wǎng)站策劃、定制開發(fā)、移動網(wǎng)站建設、網(wǎng)站收錄、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)