微服務和容器：需要去防範的 5 個「坑」

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

（讓我們等一下，等人們笑聲過去）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者：Kevin Casey 譯者：qhwdw 校對：wxy

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

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive