容器雲平臺微服務架構設計的誤區

如何使用微服務架構來實現容器雲平臺的設計?在設計實現容器雲平臺支援微服務應用的時候，往往沒有考慮到容器雲平臺自身的微服務元件劃分。如果自己不真正用容器雲平臺支撐自己的業務，可能就無法真正理解容器雲平臺微服務架構的設計需求，也就很難理解客戶的關心和真實需要。

微服務的設計和拆分一直是個難點。筆者也多次跟包括容器雲平臺廠商在內的很多人討論過，如何使用微服務架構來實現容器雲平臺的設計。有句話叫 “燈下黑” ，在設計實現容器雲平臺支援微服務應用的時候，往往沒有考慮到容器雲平臺自身的微服務元件劃分。就像很多做DevOps諮詢和DevOps平臺的公司自己還沒有實現DevOps，所以並不真的能體會到DevOps的精髓。不是說指鹿為馬、稱之為 “微服務” ，它就真的是 “微服務” 了。如果自己不真正用容器雲平臺支撐自己的業務，可能就無法真正理解容器雲平臺微服務架構的設計需求，也就很難理解客戶的關心和真實需要。

一、 從使用者體驗說起

引入微服務很重要的一點是為了松耦合單體系統架構，減少依賴，實現敏捷更新，降低變更所帶來的影響，同時便於快速擴充套件，使終端使用者無感，給使用者帶來好的體驗。當前我們過分強調微服務的優勢而有意無意忽略了微服務所帶來的麻煩，這導致使用者體驗就很不好。任何一個事物都有兩面性，需要辯證的去看待它。如果為了微服務而微服務，就會使簡單的問題複雜化。以前筆者也提到過，有容器雲平臺 Portal 劃分了 20 多個微服務，但這些微服務並沒有分散式部署的需求，也沒有擴充套件的需求，彼此之間還緊耦合，部署之後有 20 多個容器，最重要的是，還做不到一個元件一個元件獨立升級，每次都要等幾個月升級整個版本。說到底這還是單體豎井系統思維，使運維和管理複雜化。這樣的微服務設計純粹是不懂微服務，純粹是為了微服務而微服務，把簡單問題複雜化。

二、 容器雲平臺架構設計及微服務化

容器雲平臺作為企業的一個基礎設施平臺，核心能力是支撐業務應用的部署執行，需要考慮頻繁的迭代升級需求。單體豎井系統之所以發展為微服務架構，就在於為了減小變更所帶來的影響和提升迭代的效率。容器雲平臺採用微服務架構並不是因為微服務架構比較流行，而是微服務架構可以解決容器雲平臺自身的松耦合、敏捷變更、分散式部署等需求。

在最初容器雲平臺架構設計時我們提出的 “ 三視角四層次一閉環 ”架構設計，用微服務架構的設計思路比較好的解決了平臺各元件的松耦合問題。“三個視角”是從管理的角度來設計的，“管理員視角”側重平臺的管理、元件的對接和基礎設施資源的維護，其目的是為了租戶使用者便利地使用平臺來管理和運維業務應用。“租戶視角”是“以應用管理為核心”實現微服務業務應用的部署、配置、執行、監控、彈性擴縮容、負載分發、安全管控等管理和治理能力。“標準化交付視角”以映象倉庫為媒介分離研發和運維之間的耦合關係，以映象為標準化交付物，封裝服務執行環境和執行配置細節，實現環境一致性，減少因環境變化帶來的異常和故障，保障生產環境的穩定性，從而提升運維的可靠性。“四層次”的“業務應用層”關注業務的管理和治理等運維體驗，由平臺層賦能，提供相應的管理治理能力。“平臺層”是在 Kubernetes 之上對業務應用管理和治理能力的封裝，同時對映 kubernetes 的管理、治理和排程能力，特別需要考慮認證許可權准入的訪問控制能力對映。“ 資源排程層 ” 則基於 “ 基礎設施資源層 ” 所能提供的資源服務能力實現資源排程，比如虛擬化、物理伺服器、行業雲、公有云的資源排程，這基於基礎設施資源層的封裝能力。這也是我們一直強呼叫雲管平臺來統一管理基礎設施資源的原因。“ 一閉環 ” 則側重研發、運維的 DevOps 閉環過程自動化、自服務能力實現。

在這個架構設計中，平臺層的很多元件比如認證、許可權、配置、映象倉庫、日誌、監控、告警等都是獨立的元件，以插拔的方式和容器雲平臺無縫融合在一起。這些元件都可以獨立成為企業內的一個平臺，其能力用微服務架構用於構建可複用的技術中臺服務。

作為終端使用者，關注容器雲平臺的核心資產是業務應用。業務應用層，也就是 Portal 是管理租戶和租戶業務應用的入口和工具。容器雲平臺不能用開發人員的思維來設計，需要從終端使用者視角來設計，給使用者好的使用操作體驗。另外 portal 的元件服務劃分就需要基於實際的情況來定義。需要認識到的是，微服務的劃分和具體的部署方式是兩個層面。單個微服務可以打包部署，多個微服務也可以一起打包部署。這要基於是否有分散式部署的需求。如果 Portal 的元件都部署在一臺機器上，沒有必要分幾十個服務獨立部署，特別打包成幾十個映象。不說元件之間的互動額外帶來效能損失，也導致節點上資源的很大浪費，而且帶來很多資源分配和調配及維護工作量。如果資源分配不合理，就可能導致一些元件服務異常，或不斷重啟。微服務不是小服務，微服務的範圍劃分需要基於實際的元件服務關係和部署需求來確定。

平臺元件對系統資源的需求往往會隨著節點的增加和 pod 的增加而增長。比如說監控元件和日誌元件，最具有代表性。這些元件如果使用容器部署，需要配置縱向彈性伸縮。理論上，平臺自身的元件數量不應該太多，佔用的資源也不能太多，這要求廠商對平臺元件去做最佳化，而不是隨隨便便就扔給客戶。節點上不能因為系統容器而導致節點資源消耗過大，不能讓業務容器沒有資源可用。

Kubernetes 本身就是元件化、外掛化服務架構，因此基於 kubernetes 的容器雲平臺的微服務設計重點在於 Portal 和平臺層元件封裝以及節點的元件上。

三、 平臺元件容器數量及資源佔用問題

由於梳理容器雲安全問題，發現在數千個容器中也只有四分之一的容器是業務容器，另外的近四分之三竟然都是容器雲平臺自身帶來的容器。這為容器雲平臺的運維管理帶來很大的工作量，也充分說明了容器雲平臺元件設計的不合理性。每個容器節點理論上不應該有那麼多平臺的容器。筆者也理解每個節點都需要實現眾多的功能，比如日誌採集、監控、容器網路元件、儲存外掛、安全管控元件等等，但是這些元件如果不進行整合和重新設計，就會喧賓奪主，佔用很多節點的資源，導致整個容器節點部署不了幾個業務容器，會造成極大的浪費，也帶來額外的運維工作量。容器有輕量的特點。但再輕量也架不住數量眾多。因此在進行微服務設計的時候，需要從整體上來考慮微服務元件的定義，每個節點上的平臺容器佔用節點的資源不應該超過 10% ，數量也儘可能少，服務元件儘可能整合最佳化。

容器雲平臺其實並不像很多廠商所宣稱的那樣節省資源。某些情況下還會更浪費資源。容器資源的使用取決於容器中執行的應用及應用架構、應用執行編排、資源限制等。想要節省資源，就需要做好微服務的設計，以及容器雲平臺自身的微服務設計，同時還要規劃好業務應用的資源使用時段，實現不同型別應用的分時段資源佔用，這樣才能充分的利用資源。但就容器雲平臺本身的架構設計來說，需要充分考慮業務資產管理和資源使用的問題。

總的來說，容器雲平臺微服務架構設計是平臺彈性、可擴充套件性的要求，是容器化PaaS平臺建設和容器化雲作業系統建設的要求。不過微服務拆分的能力直接關係著整個平臺的可維護性和穩定性，以及客戶的體驗和運維成本。如果要做好容器雲平臺產品，採用微服務架構實現彈性和可擴充套件性，就必須在微服務元件設計方面以使用者思維，深入實踐和思考，真正解決客戶關注的問題。

【作者】汪照輝，中國銀河證券架構師，專注於容器雲、微服務、DevOps、資料治理、數字化轉型等領域，對相關技術有獨特的理解和見解。擅長於軟體規劃和設計，提出的“平臺融合”的觀點越來越得到認同和事實證明。發表了眾多技術文章探討容器平臺建設、微服務技術、DevOps、數字化轉型、資料治理、中臺建設等內容，受到了廣泛關注和肯定。個人公眾號：技術思維創新