微服務化的不一樣階段kuberneter的不一樣玩法

做爲容器集羣管理技術競爭的大贏家，Kubernetes已經和微服務緊密聯繫，採用Kubernetes的企業每每都開始了微服務架構的探索。然而不一樣企業不一樣階段的微服務實踐面臨的問題千差萬別，註定要在技術路線上產生分叉。如何選擇適合本身的技術，是每個踐行微服務的團隊面臨的第一個問題。網易雲是Kubernetes的第一批重度用戶，在不一樣業務場景下解決了不少挑戰，在本文中，網易雲首席解決方案架構師劉超梳理了基於Kubernetes構建微服務體系的進階之路。

微服務化的必要性

一個產品的發展，一般可分爲冷啓動階段、高速增加階段和成熟階段。產品冷啓動階段，需求是以最簡單的架構驗證業務。以網易考拉海購（如下簡稱「考拉」）爲例，最初的架構設計目標就是快速啓動，驗證產品方向，該架構包括在線、緩存、線下和管理服務四個方面，即通常電商平臺加上跨境電商必備的進銷存系統，採用了Oracle數據庫、OpenStack管理的虛擬機（VM），並無諸如高併發之類的考慮。

產品高速增加階段，業務規模逐漸擴大，產品複雜度也隨着增長，企業須要解決快速迭代、高可靠和高可用等問題，一個天然的選擇是服務化的拆分，把一個單體架構拆分紅一些較小的模塊，並遵循康威定律，用5-9個小團隊來適應架構的變化。仍以考拉爲例，考拉在高速增加階段也慢慢演化出各類新的模塊，好比單獨的支付模塊、貨倉模塊、第三方商家模塊、推送模塊等，並基於Dubbo框架打造服務發現功能來支持各模塊之間的相互調用。

服務化主要解決了變動的問題。在整個架構演進的過程當中，各個模塊都面臨爆炸性的增加，好比海淘、自營、第三方商家的供應鏈，Web、APP、H5的呈現，限時購、秒殺、預售的活動頁，以及倉庫與物流系統、支付系統的對接等，緊耦合則牽一髮而動全身，工程臃腫，影響迭代速度，分別獨立上線更有利於適應業務發展的需求。考拉在高速增加階段首先按照主頁、活動頁、優惠券、支付等維度縱向拆分，以後又不斷演進成爲100多個相互關聯的模塊，變動頻率由天天2次增加到天天1000屢次，產品質量提高52%。

容器化的優點與挑戰

拆分紅大量小模塊以後，虛擬機與服務化架構的配合就出現了不少新的挑戰，因而有了容器化的需求。

劉超解釋說，拆分以前首先要解決「合」的問題，即須要保證功能仍是原來的功能，代碼質量仍是原來的代碼質量，不會引入新的bug。他認爲，微服務化須要從一