知識星球
作者 | 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中國 榮譽推出
