歡迎光臨
每天分享高質量文章

微服務和容器:需要去防範的 5 個“坑” | Linux 中國

因為微服務和容器是 天生的“一對”,所以一起來使用它們,似乎也就不會有什麼問題。當我們將這對“天作之合”投入到生產系統後,你就會發現,隨著你的 IT 基礎的提升,等待你的將是大幅上升的成本。是不是這樣的?
— Kevin Casey


本文導航
編譯自 | https://enterprisersproject.com/article/2017/9/using-microservices-containers-wisely-5-pitfalls-avoid 
 作者 | Kevin Casey
 譯者 | qhwdw

微服務與容器天生匹配,但是你需要避開一些常見的陷阱。

因為微服務和容器是 天生的“一對”[1],所以一起來使用它們,似乎也就不會有什麼問題。當我們將這對“天作之合”投入到生產系統後,你就會發現,隨著你的 IT 基礎的提升,等待你的將是大幅上升的成本。是不是這樣的?

(讓我們等一下,等人們笑聲過去)

是的,很遺憾,這並不是你所希望的結果。雖然這兩種技術的組合是非常強大的,但是,如果沒有很好的規劃和適配,它們並不能發揮出強大的性能來。在前面的文章中,我們整理瞭如果你想 使用它們你應該掌握的知識[2]。但是,那些都是組織在容器中使用微服務時所遇到的常見問題。

事先瞭解這些可能出現的問題,能夠幫你避免這些問題,為你的成功奠定更堅實的基礎。

微服務和容器技術的出現是基於組織的需要、知識、資源等等更多的現實的要求。Mac Browning 說,“他們最常犯的一個 [錯誤] 是試圖一次就想‘搞定’一切”,他是 DigitalOcean[3] 的工程部經理。“而真正需要面對的問題是,你的公司應該採用什麼樣的容器和微服務。”

[ 努力向你的老闆和同事去解釋什麼是微服務?閱讀我們的入門讀本如何簡單明瞭地解釋微服務[4]。]

Browning 和其他的 IT 專業人員分享了他們遇到的,在組織中使用容器化微服務時的五個陷阱,特別是在他們的生產系統生命周期的早期時候。在你的組織中需要去部署微服務和容器時,瞭解這些知識,將有助於你去評估微服務和容器化的部署策略。

1、 在部署微服務和容器化上,試圖同時從零開始

如果你剛開始從完全的單例應用開始改變,或者如果你的組織在微服務和容器化上還沒有足夠的知識儲備,那麼,請記住:微服務和容器化並不是拴在一起、不可分別部署的。這就意味著,你可以發揮你公司內部專家的技術特長,先從部署其中的一個開始。Sungard Availability Services]5[5] 的資深 CTO 架構師 Kevin McGrath 建議,通過首先使用容器化來為你的團隊建立知識和技能儲備,通過對現有應用或者新應用進行容器化部署,接著再將它們遷移到微服務架構,這樣才能最終感受到它們的優勢所在。

McGrath 說,“微服務要想運行的很好,需要公司經過多年的反覆迭代,這樣才能實現快速部署和遷移”,“如果組織不能實現快速遷移,那麼支持微服務將很困難。實現快速遷移,容器化可以幫助你,這樣就不用擔心業務整體停機”。

2、 從一個面向客戶的或者關鍵的業務應用開始

對組織來說,一個相關陷阱恰恰就是從容器、微服務、或者兩者同時起步:在嘗試征服一片叢林中的雄獅之前,你應該先去征服處於食物鏈底端的一些小動物,以取得一些實踐經驗。

在你的學習過程中可以預期會有一些錯誤出現 —— 你是希望這些錯誤發生在面向客戶的關鍵業務應用上,還是,僅對 IT 或者其他內部團隊可見的低風險應用上?

DigitalOcean 的 Browning 說,“如果整個生態系統都是新的,為了獲取一些微服務和容器方面的操作經驗,那麼,將它們先應用到影響面較低的區域,比如像你的持續集成系統或者內部工具,可能是一個低風險的做法。”你獲得這方面的經驗以後,當然會將這些技術應用到為客戶提供服務的生產系統上。而現實情況是,不論你準備的如何周全,都不可避免會遇到問題,因此,需要提前為可能出現的問題制定應對之策。

3、 在沒有合適的團隊之前引入了太多的複雜性

由於微服務架構的彈性,它可能會產生複雜的管理需求。

作為 Red Hat[6] 技術的狂熱擁護者,Gordon Haff[7] 最近寫道,“一個符合 OCI 標準的容器運行時本身管理單個容器是很擅長的,但是,當你開始使用多個容器和容器化應用時,並將它們分解為成百上千個節點後,管理和編配它們將變得極為複雜。最終,你將需要回過頭來將容器分組來提供服務 —— 比如,跨容器的網絡、安全、測控”。

Haff 提示說,“幸運的是,由於容器是可移植的,並且,與之相關的管理棧也是可移植的”。“這時出現的編配技術,比如像 Kubernetes[8] ,使得這種 IT 需求變得簡單化了”(更多內容請查閱 Haff 的文章:容器化為編寫應用帶來的 5 個優勢[1])。

另外,你需要合適的團隊去做這些事情。如果你已經有 DevOps shop[9],那麼,你可能比較適合做這種轉換。因為,從一開始你已經聚集了相關技能的人才。

Mike Kavis 說,“隨著時間的推移,部署了越來越多的服務,管理起來會變得很不方便”,他是 Cloud Technology Partners[10] 的副總裁兼首席雲架構設計師。他說,“在 DevOps 的關鍵過程中,確保各個領域的專家 —— 開發、測試、安全、運營等等 —— 全部都參與進來,並且在基於容器的微服務中,在構建、部署、運行、安全方面實現協作。”

4、 忽視重要的需求:自動化

除了具有一個合適的團隊之外,那些在基於容器化的微服務部署比較成功的組織都傾向於以“實現盡可能多的自動化”來解決固有的複雜性。

Carlos Sanchez 說,“實現分佈式架構並不容易,一些常見的挑戰,像資料持久性、日誌、排錯等等,在微服務架構中都會變得很複雜”,他是 CloudBees[11] 的資深軟體工程師。根據定義,Sanchez 提到的分佈式架構,隨著業務的增長,將變成一個巨大無比的繁重的運營任務。“服務和組件的增殖,將使得運營自動化變成一項非常強烈的需求”。Sanchez 警告說。“手動管理將限制服務的規模”。

5、 隨著時間的推移,微服務變得越來越臃腫

在一個容器中運行一個服務或者軟體組件並不神奇。但是,這樣做並不能證明你就一定在使用微服務。Manual Nedbal, ShieldX Networks[12] 的 CTO,他警告說,IT 專業人員要確保,隨著時間的推移,微服務仍然是微服務。

Nedbal 說,“隨著時間的推移,一些軟體組件積累了大量的代碼和特性,將它們放在一個容器中將會產生並不需要的微服務,也不會帶來相同的優勢”,也就是說,“隨著組件的變大,工程師需要找到合適的時機將它們再次分解”。


via: https://enterprisersproject.com/article/2017/9/using-microservices-containers-wisely-5-pitfalls-avoid

作者:Kevin Casey[14] 譯者:qhwdw 校對:wxy

本文由 LCTT 原創編譯,Linux中國 榮譽推出

LCTT 譯者

qhwdw ? ? ? ?
共計翻譯:50 篇
貢獻時間:81 天


推薦文章

< 左右滑動查看相關文章 >

點擊圖片、輸入文章 ID 或識別二維碼直達

赞(0)

分享創造快樂