爲何 kubernetes 自然適合微服務

本文由  網易雲 發佈。

 

做者：劉超，網易雲首席解決方案架構師

最近總在思考，爲何在支撐容器平臺和微服務的競爭中，Kubernetes 會取得最終的勝出，事實上從不少角度出發三大容器平臺從功能方面來看，最後簡直是一摸同樣。（可參考《容器平臺選型的十大模式：Docker、DC/OS、K8S 誰與當先？》）

通過一段時間的思索，以及採訪了從早期就開始實踐 Kubernetes 的網易雲架構師們後，我把反思所得總結爲今天的這篇文章。

1、從企業上雲的三大架構看容器平臺的三種視角

如圖所示，企業上雲的三大架構爲 IT 架構、應用架構和數據架構，在不一樣的公司，不一樣的人、不一樣的角色，關注的重點不一樣。

對大部分的企業來說，上雲的訴求是從 IT 部門發起的，發起人每每是運維部門，他們關注計算、網絡、存儲，試圖經過雲計算服務來減輕 CAPEX 和 OPEX。

有的公司有 ToC 的業務，於是累積了大量的用戶數據，公司的運營須要經過這部分數據進行大數據分析和數字化運營，於是在這些企業裏面每每還須要關注數據架構。

從事互聯網應用的企業，每每首先關注的是應用架構，是否可以知足終端客戶的需求，帶給客戶良好的用戶體驗。業務量上每每會有短時間內出現爆炸式增加的現象，於是關注高併發應用架構，並但願這個架構能夠快速迭代，從而搶佔風口。

在容器出現以前，這三種架構每每經過虛擬機雲平臺的方式解決。當容器出現以後，容器的各類良好的特性讓人眼前一亮，它的輕量級、封裝、標準、易遷移、易交付的特性，使得容器技術迅速被普遍使用。

然而一千我的心中有一千個哈姆雷特，因爲原來工做的關係，三類角色分別從自身的角度看到了容器的優點給本身帶來的便捷。

對於原來在機房裏管計算、網絡、存儲的 IT 運維工程師來說，容器更像是一種輕量級的運維模式，在他們看來，容器和虛擬機的最大的區別就是輕量級，啓動速度快，他們每每更願意推出虛擬機模式的容器。

對於數據架構來說，他們天天都在執行各類各樣的數據計算任務，容器相對於原來的 JVM，是一種隔離性較好，資源利用率高的任務執行模式。

從應用架構的角度出發，容器是微服務的交付形式，容器不只僅是作部署的，並且是作交付的，CI/CD 中的 D 的。

因此這三種視角的人，在使用容器和選擇容器平臺時方法會不同。

2、Kubernetes 纔是微服務和 DevOps 的橋樑

Swarm：IT 運維工程師

 

 

從 IT 運維工程師的角度來看：容器主要是輕量級、啓動快，而且自動重啓，自動關聯，彈性伸縮的技術，使得 IT 運維工程師彷佛不用再加班。

Swarm 的設計顯然更加符合傳統 IT 工程師的管理模式。

他們但願可以清晰地看到容器在不一樣機器的分佈和狀態，能夠根據須要很方便地 SSH 到一個容器裏面去查看狀況。

容器最好可以原地重啓，而非隨機調度一個新的容器，這樣原來在容器裏面安裝的一切都是有的。

能夠很方便地將某個運行的容器打一個鏡像，而非從 Dockerfile 開始，這樣之後啓動就能夠複用在這個容器裏面手動作的 100 項工做。

容器平臺的集成性要好，用這個平臺原本是爲了簡化運維的，若是容器平臺自己就很複雜，像 Kubernetes 這種自己就這麼多進程，還須要考慮它的高可用和運維成本，這個不划算，一點都沒有比原來省事，並且成本還提升了。

最好薄薄的一層，像一個雲管理平臺同樣，只不過更加方便作跨雲管理，畢竟容器鏡像很容易跨雲遷移。

Swarm 的使用方式比較讓 IT 工程師有熟悉的味道，其實 OpenStack 所作的事情它都能作，速度還快。

Swarm 的問題

然而容器做爲輕量級虛擬機，暴露出去給客戶使用，不管是外部客戶，仍是公司內的開發，而非 IT 人員本身使用的時候，他們覺得和虛擬機同樣，可是發現了不同的部分，就會有不少的抱怨。

例如自修復功能，重啓以後，原來 SSH 進去手動安裝的軟件不見了，甚至放在硬盤上的文件也不見了，並且應用沒有放在 Entrypoint 裏面自動啓動，自修復以後進程沒有跑起來，還須要手動進去啓動進程，客戶會抱怨你這個自修復功能有啥用？

例若有的用戶會 ps 一下，發現有個進程他不認識，因而直接 kill 掉了，結果是 Entrypoint 的進程，整個容器直接就掛了，客戶抱怨大家的容器太不穩定，總是掛。

容器自動調度的時候，IP 是不保持的，因此每每重啓後原來的 IP 就沒了，不少用戶會提需求，這個能不能保持啊，原來配置文件裏面都配置的這個 IP ，掛了重啓就變了，這個怎麼用啊，還不如用虛擬機，至少沒那麼容易掛。

容器的系統盤，也即操做系統的那個盤每每大小是固定的，雖然前期能夠配置，後期很難改變，並且沒辦法每一個用戶能夠選擇系統盤的大小。有的用戶會抱怨，咱們原來原本就不少東西直接放在系統盤的，這個都不能調整，叫什麼雲計算的彈性啊。

若是給客戶說容器掛載數據盤，容器都啓動起來了，有的客戶想像雲主機同樣，再掛載一個盤，容器比較難作到，也會被客戶罵。

若是容器的使用者不知道他們在用容器，當虛擬機來用，他們會以爲很難用，這個平臺一點都很差。

Swarm 上手雖然相對比較容易，可是當出現問題的時候，做爲運維容器平臺的人，會發現問題比較難解決。

Swarm 內置的功能太多，都耦合在了一塊兒，一旦出現錯誤，不容易 debug。若是當前的功能不能知足需求，很難定製化。不少功能都是耦合在 Manager 裏面的，對 Manager 的操做和重啓影響面太大。

Mesos：數據運維工程師

從大數據平臺運維的角度來說，如何更快地調度大數據處理任務，在有限的時間和空間裏面，更快地跑更多的任務，是一個很是重要的要素。

因此當咱們評估大數據平臺牛不牛的時候，每每以單位時間內跑的任務數目以及可以處理的數據量來衡量。

從數據運維的角度來說，Mesos 是一個很好的調度器。既然可以跑任務，也就可以跑容器，Spark 和 Mesos 自然的集成，有了容器以後，能夠用更加細粒度的任務執行方式。

在沒有細粒度的任務調度以前，任務的執行過程是這樣的。任務的執行須要 Master 的節點來管理整個任務的執行過程，須要 Worker 節點來執行一個個子任務。在整個總任務的一開始，就分配好 Master 和全部的 Work 所佔用的資源，將環境配置好，等在那裏執行子任務，沒有子任務執行的時候，這個環境的資源都是預留在那裏的，顯然不是每一個 Work 老是所有跑滿的，存在不少的資源浪費。

在細粒度的模式下，在整個總任務開始的時候，只會爲 Master 分配好資源，不給 Worker 分配任何的資源，當須要執行一個子任務的時候，Master 才臨時向 Mesos 申請資源，環境沒有準備好怎麼辦？好在有 Docker，啓動一個 Docker，環境就都有了，在裏面跑子任務。在沒有任務的時候，全部節點上的資源都是可被其餘任務使用的，大大提高了資源利用效率。

這就是 Mesos 最大的優點，在 Mesos 的論文中，最重要闡述的就是資源利用率的提高，而 Mesos 的雙層調度算法是核心。

原來大數據運維工程師出身的，會比較容易選擇 Mesos 做爲容器管理平臺。不過原來是跑短任務，加上 marathon 就能跑長任務。可是後來 Spark 將細粒度的模式 deprecated 掉了，由於效率仍是比較差。

Mesos 的問題

調度在大數據領域是核心中的核心，在容器平臺中是重要的，但不是所有。因此容器還須要編排，須要各類外圍組件，讓容器跑起來運行長任務，而且相互訪問。Marathon 只是萬里長征的第一步。

因此早期用 Marathon + Mesos 的廠商，可能是裸用 Marathon 和 Mesos 的，因爲周邊不全，於是要作各類的封裝，各家不一樣。你們有興趣能夠到社區上去看裸用 Marathon 和 Mesos 的廠商，各有各的負載均衡方案，各有各的服務發現方案。

因此後來有了 DCOS，也就是在 Marathon 和 Mesos 以外，加了大量的周邊組件，補充一個容器平臺應有的功能，可是很惋惜，不少廠商都本身定製過了，仍是裸用 Marathon 和 Mesos 的比較多。

並且 Mesos 雖然調度牛，可是隻解決一部分調度，另外一部分靠用戶本身寫 framework 以及裏面的調度，有時候還須要開發 Executor，這個開發起來仍是很複雜的，學習成本也比較高。

雖然說後來的 DCOS 功能也比較全了，可是感受沒有如 Kubernetes 同樣使用統一的語言，而是採起大雜燴的方式。在 DCOS 的整個生態中，Marathon 是 Scala 寫的，Mesos 是 C++ 寫的，Admin Router 是 Nginx+lua，Mesos-DNS 是Go，Marathon-lb 是 Python，Minuteman 是 Erlang，這樣太複雜了吧，林林總總，出現了 Bug 的話，比較難本身修復。

Kubernetes

而 Kubernetes 不一樣，初看 Kubernetes 的人以爲他是個奇葩所在，容器還沒建立出來，概念先來一大堆，文檔先讀一大把，編排文件也複雜，組件也多，讓不少人望而卻步。我就想建立一個容器，怎麼這麼多的前置條件。若是你將 Kubernetes 的概念放在界面上，讓客戶去建立容器，必定會被客戶罵。

在開發人員角度，使用 Kubernetes 絕對不是像使用虛擬機同樣，開發除了寫代碼，作構建，作測試，還須要知道本身的應用是跑在容器上的，而不是當甩手掌櫃。開發人員須要知道，容器是和原來的部署方式不同的存在，你須要區分有狀態和無狀態，容器掛了起來，就會按照鏡像還原了。開發人員須要寫 Dockerfile，須要關心環境的交付，須要瞭解太多原來不瞭解的東西。實話實說，一點都不方便。

在運維人員角度，使用 Kubernetes 也絕對不是像運維虛擬機同樣，我交付出來了環境，應用之間互相怎麼調用，我才無論，我就管網絡通不通。在運維眼中他作了過多不應關心的事情，例如服務的發現，配置中心，熔斷降級，這都應該是代碼層面關心的事情，應該是 SpringCloud 和 Dubbo 關心的事情，爲何要到容器平臺層來關心這個。

Kubernetes + Docker，倒是 Dev 和 Ops 融合的一個橋樑。

Docker 是微服務的交付工具，微服務以後，服務太多了，單靠運維根本管不過來，並且很容易出錯，這就須要研發開始關心環境交付這件事情。例如配置改了什麼，建立了哪些目錄，如何配置權限，只有開發最清楚，這些信息很難經過文檔的方式又及時又準確地同步到運維部門來，就算是同步過來了，運維部門的維護量也很是的大。

因此，有了容器，最大的改變是環境交付的提早，是每一個開發多花 5% 的時間，去換取運維 200% 的勞動，而且提升穩定性。

而另外一方面，原本運維只管交付資源，給你個虛擬機，虛擬機裏面的應用如何相互訪問我無論，大家愛咋地咋地，有了 Kubernetes 之後，運維層要關注服務發現，配置中心，熔斷降級。

二者融合在了一塊兒。在微服務化的研發的角度來說，Kubernetes 雖然複雜，可是設計的都是有道理的，符合微服務的思想。

3、微服務化的十個設計要點

微服務有哪些要點呢？第一張圖是 SpringCloud 的整個生態。

第二張圖是微服務的 12 要素以及在網易雲的實踐。

第三張圖是構建一個高併發的微服務，須要考慮的全部的點。（打個廣告，這是一門課程，即將上線。）

接下來細說微服務的設計要點。

設計要點一：API 網關。

在實施微服務的過程當中，難免要面臨服務的聚合與拆分，當後端服務的拆分相對比較頻繁的時候，做爲手機 App 來說，每每須要一個統一的入口，將不一樣的請求路由到不一樣的服務，不管後面如何拆分與聚合，對於手機端來說都是透明的。

有了 API 網關之後，簡單的數據聚合能夠在網關層完成，這樣就不用在手機 App 端完成，從而手機 App 耗電量較小，用戶體驗較好。

有了統一的 API 網關，還能夠進行統一的認證和鑑權，儘管服務之間的相互調用比較複雜，接口也會比較多，API 網關每每只暴露必須的對外接口，而且對接口進行統一的認證和鑑權，使得內部的服務相互訪問的時候，不用再進行認證和鑑權，效率會比較高。

有了統一的 API 網關，能夠在這一層設定必定的策略，進行 A/B 測試，藍綠髮布，預發環境導流等等。API 網關每每是無狀態的，能夠橫向擴展，從而不會成爲性能瓶頸。

設計要點二：無狀態化，區分有狀態的和無狀態的應用。

影響應用遷移和橫向擴展的重要因素就是應用的狀態，無狀態服務，是要把這個狀態往外移，將 Session 數據，文件數據，結構化數據保存在後端統一的存儲中，從而應用僅僅包含商務邏輯。

狀態是不可避免的，例如 ZooKeeper, DB，Cache 等，把這些全部有狀態的東西收斂在一個很是集中的集羣裏面。

整個業務就分兩部分，一個是無狀態的部分，一個是有狀態的部分。

無狀態的部分能實現兩點，一是跨機房隨意地部署，也即遷移性，一是彈性伸縮，很容易地進行擴容。

有狀態的部分，如 DB，Cache，ZooKeeper 有本身的高可用機制，要利用到他們本身高可用的機制來實現這個狀態的集羣。

雖然說無狀態化，可是當前處理的數據，仍是會在內存裏面的，當前的進程掛掉數據，確定也是有一部分丟失的，爲了實現這一點，服務要有重試的機制，接口要有冪等的機制，經過服務發現機制，從新調用一次後端服務的另外一個實例就能夠了。

設計要點三：數據庫的橫向擴展。

數據庫是保存狀態，是最重要的也是最容易出現瓶頸的。有了分佈式數據庫可使數據庫的性能能夠隨着節點增長線性地增長。

分佈式數據庫最最下面是 RDS，是主備的，經過 MySql 的內核開發能力，咱們可以實現主備切換數據零丟失，因此數據落在這個 RDS 裏面，是很是放心的，哪怕是掛了一個節點，切換完了之後，你的數據也是不會丟的。

再往上就是橫向怎麼承載大的吞吐量的問題，上面有一個負載均衡 NLB，用 LVS，HAProxy, Keepalived，下面接了一層 Query Server。Query Server 是能夠根據監控數據進行橫向擴展的，若是出現了故障，能夠隨時進行替換的修復，對於業務層是沒有任何感知的。

另一個就是雙機房的部署，DDB 開發了一個數據運河 NDC 的組件，可使得不一樣的 DDB 之間在不一樣的機房裏面進行同步，這時候不但在一個數據中內心面是分佈式的，在多個數據中內心面也會有一個相似雙活的一個備份，高可用性有很是好的保證。

設計要點四：緩存

在高併發場景下緩存是很是重要的。要有層次的緩存，使得數據儘可能靠近用戶。數據越靠近用戶能承載的併發量也越大，響應時間越短。

在手機客戶端 App 上就應該有一層緩存，不是全部的數據都每時每刻從後端拿，而是隻拿重要的，關鍵的，時常變化的數據。

尤爲對於靜態數據，能夠過一段時間去取一次，並且也不必到數據中心去取，能夠經過 CDN，將數據緩存在距離客戶端最近的節點上，進行就近下載。

有時候 CDN 裏面沒有，仍是要回到數據中心去下載，稱爲回源，在數據中心的最外層，咱們稱爲接入層，能夠設置一層緩存，將大部分的請求攔截，從而不會對後臺的數據庫形成壓力。

若是是動態數據，仍是須要訪問應用，經過應用中的商務邏輯生成，或者去數據庫讀取，爲了減輕數據庫的壓力，應用可使用本地的緩存，也可使用分佈式緩存，如 Memcached 或者 Redis，使得大部分請求讀取緩存便可，沒必要訪問數據庫。

固然動態數據還能夠作必定的靜態化，也即降級成靜態數據，從而減小後端的壓力。

設計要點五：服務拆分和服務發現

當系統扛不住，應用變化快的時候，每每要考慮將比較大的服務拆分爲一系列小的服務。

這樣第一個好處就是開發比較獨立，當很是多的人在維護同一個代碼倉庫的時候，每每對代碼的修改就會相互影響，經常會出現我沒改什麼測試就不經過了，並且代碼提交的時候，常常會出現衝突，須要進行代碼合併，大大下降了開發的效率。

另外一個好處就是上線獨立，物流模塊對接了一家新的快遞公司，須要連同下單一塊兒上線，這是很是不合理的行爲，我沒改還要我重啓，我沒改還讓我發佈，我沒改還要我開會，都是應該拆分的時機。

另外再就是高併發時段的擴容，每每只有最關鍵的下單和支付流程是核心，只要將關鍵的交易鏈路進行擴容便可，若是這時候附帶不少其餘的服務，擴容便是不經濟的，也是頗有風險的。

再就是容災和降級，在大促的時候，可能須要犧牲一部分的邊角功能，可是若是全部的代碼耦合在一塊兒，很難將邊角的部分功能進行降級。

固然拆分完畢之後，應用之間的關係就更加複雜了，於是須要服務發現的機制，來管理應用相互的關係，實現自動的修復，自動的關聯，自動的負載均衡，自動的容錯切換。

設計要點六：服務編排與彈性伸縮

當服務拆分了，進程就會很是的多，於是須要服務編排來管理服務之間的依賴關係，以及將服務的部署代碼化，也就是咱們常說的基礎設施即代碼。這樣對於服務的發佈，更新，回滾，擴容，縮容，均可以經過修改編排文件來實現，從而增長了可追溯性，易管理性，和自動化的能力。

既然編排文件也能夠用代碼倉庫進行管理，就能夠實現一百個服務中，更新其中五個服務，只要修改編排文件中的五個服務的配置就能夠，當編排文件提交的時候，代碼倉庫自動觸發自動部署升級腳本，從而更新線上的環境，當發現新的環境有問題時，固然但願將這五個服務原子性地回滾，若是沒有編排文件，須要人工記錄此次升級了哪五個服務。有了編排文件，只要在代碼倉庫裏面 revert，就回滾到上一個版本了。全部的操做在代碼倉庫裏都是能夠看到的。

設計要點七：統一配置中心

服務拆分之後，服務的數量很是多，若是全部的配置都以配置文件的方式放在應用本地的話，很是難以管理，能夠想象當有幾百上千個進程中有一個配置出現了問題，是很難將它找出來的，於是須要有統一的配置中心，來管理全部的配置，進行統一的配置下發。

在微服務中，配置每每分爲幾類，一類是幾乎不變的配置，這種配置能夠直接打在容器鏡像裏面，第二類是啓動時就會肯定的配置，這種配置每每經過環境變量，在容器啓動的時候傳進去，第三類就是統一的配置，須要經過配置中心進行下發，例如在大促的狀況下，有些功能須要降級，哪些功能能夠降級，哪些功能不能降級，均可以在配置文件中統一配置。

設計要點八：統一的日誌中心

一樣是進程數目很是多的時候，很難對成千上百個容器，一個一個登陸進去查看日誌，因此須要統一的日誌中心來收集日誌，爲了使收集到的日誌容易分析，對於日誌的規範，須要有必定的要求，當全部的服務都遵照統一的日誌規範的時候，在日誌中心就能夠對一個交易流程進行統一的追溯。例如在最後的日誌搜索引擎中，搜索交易號，就可以看到在哪一個過程出現了錯誤或者異常。

設計要點九：熔斷，限流，降級

服務要有熔斷，限流，降級的能力，當一個服務調用另外一個服務，出現超時的時候，應及時返回，而非阻塞在那個地方，從而影響其餘用戶的交易，能夠返回默認的託底數據。

當一個服務發現被調用的服務，由於過於繁忙，線程池滿，鏈接池滿，或者老是出錯，則應該及時熔斷，防止由於下一個服務的錯誤或繁忙，致使本服務的不正常，從而逐漸往前傳導，致使整個應用的雪崩。

當發現整個系統的確負載太高的時候，能夠選擇降級某些功能或某些調用，保證最重要的交易流程的經過，以及最重要的資源所有用於保證最核心的流程。

還有一種手段就是限流，當既設置了熔斷策略，又設置了降級策略，經過全鏈路的壓力測試，應該可以知道整個系統的支撐能力，於是就須要制定限流策略，保證系統在測試過的支撐能力範圍內進行服務，超出支撐能力範圍的，可拒絕服務。當你下單的時候，系統彈出對話框說 「系統忙，請重試」，並不表明系統掛了，而是說明系統是正常工做的，只不過限流策略起到了做用。

設計要點十：全方位的監控

當系統很是複雜的時候，要有統一的監控，主要有兩個方面，一個是是否健康，一個是性能瓶頸在哪裏。當系統出現異常的時候，監控系統能夠配合告警系統，及時地發現，通知，干預，從而保障系統的順利運行。

當壓力測試的時候，每每會遭遇瓶頸，也須要有全方位的監控來找出瓶頸點，同時可以保留現場，從而能夠追溯和分析，進行全方位的優化。

4、Kubernetes 自己就是微服務架構

基於上面這十個設計要點，咱們再回來看 Kubernetes，會發現越看越順眼。

首先 Kubernetes 自己就是微服務的架構，雖然看起來複雜，可是容易定製化，容易橫向擴展。

如圖黑色的部分是 Kubernetes 原生的部分，而藍色的部分是網易云爲了支撐大規模高併發應用而作的定製化部分。

Kubernetes 的 API Server 更像網關，提供統一的鑑權和訪問接口。

衆所周知，Kubernetes 的租戶管理相對比較弱，尤爲是對於公有云場景，複雜的租戶關係的管理，咱們只要定製化 API Server，對接 Keystone，就能夠管理複雜的租戶關係，而不用管其餘的組件。

在 Kubernetes 中幾乎全部的組件都是無狀態化的，狀態都保存在統一的 etcd 裏面，這使得擴展性很是好，組件之間異步完成本身的任務，將結果放在 etcd 裏面，互相不耦合。

例如圖中 pod 的建立過程，客戶端的建立僅僅是在 etcd 中生成一個記錄，而其餘的組件監聽到這個事件後，也相應異步的作本身的事情，並將處理的結果一樣放在 etcd 中，一樣並非哪個組件遠程調用 kubelet，命令它進行容器的建立，而是發現 etcd 中，pod 被綁定到了本身這裏，方纔拉起。

爲了在公有云中實現租戶的隔離性，咱們的策略是不一樣的租戶，不共享節點，這就須要 Kubernetes 對於 IaaS 層有所感知，於是須要實現本身的 Controller，Kubernetes 的設計使得咱們能夠獨立建立本身的 Controller，而不是直接改代碼。

API-Server 做爲接入層，是有本身的緩存機制的，防止全部的請求壓力直接到後端數據庫上。可是當仍然沒法承載高併發請求時，瓶頸依然在後端的 etcd 存儲上，這和電商應用一摸同樣。固然可以想到的方式也是對 etcd 進行分庫分表，不一樣的租戶保存在不一樣的 etcd 集羣中。

有了 API Server 作 API 網關，後端的服務進行定製化，對於 client 和 kubelet 是透明的。

如圖是定製化的容器建立流程，因爲大促和非大促期間，節點的數目相差比較大，於是不能採用事先所有建立好節點的方式，這樣會形成資源的浪費，於是中間添加了網易雲本身的模塊 Controller 和 IaaS 的管理層，使得當建立容器資源不足的時候，動態調用 IaaS 的接口，動態的建立資源。這一切對於客戶端和 kubelet 無感知。

爲了解決超過 3 萬個節點的規模問題，網易雲鬚要對各個模塊進行優化，因爲每一個子模塊僅僅完成本身的功能，Scheduler 只管調度，Proxy 只管轉發，而非耦合在一塊兒，於是每一個組件均可以進行獨立的優化，這符合微服務中的獨立功能，獨立優化，互不影響。並且 Kubernetes 的全部組件都是 Go 開發的，更加容易一些。因此 Kubernetes 上手慢，可是一旦須要定製化，會發現更加容易。

5、Kubernetes 更加適合微服務和 DevOps 的設計

好了，說了 K8S 自己，接下來講說 K8S 的理念設計，爲何這麼適合微服務。

前面微服務設計的十大模式，其中一個就是區分無狀態和有狀態，在 K8S 中，無狀態對應 deployment，有狀態對應 StatefulSet。

deployment 主要經過副本數，解決橫向擴展的問題。

而 StatefulSet 經過一致的網絡 ID，一致的存儲，順序的升級，擴展，回滾等機制，保證有狀態應用，很好地利用本身的高可用機制。由於大多數集羣的高可用機制，都是能夠容忍一個節點暫時掛掉的，可是不能容忍大多數節點同時掛掉。並且高可用機制雖然能夠保證一個節點掛掉後回來，有必定的修復機制，可是須要知道剛纔掛掉的究竟是哪一個節點，StatefulSet 的機制可讓容器裏面的腳本有足夠的信息，處理這些狀況，實現哪怕是有狀態，也能儘快修復。

在微服務中，比較推薦使用雲平臺的 PaaS，例如數據庫，消息總線，緩存等。可是配置也是很是複雜的，由於不一樣的環境須要鏈接不一樣的 PaaS 服務。

K8S 裏面的 headless service 是能夠很好地解決這個問題的，只要給外部服務建立一個 headless service，指向相應的 PaaS 服務，而且將服務名配置到應用中。因爲生產和測試環境分紅 Namespace，雖然配置了相同的服務名，可是不會錯誤訪問，簡化了配置。

微服務少不了服務發現，除了應用層可使用 SpringCloud 或者 Dubbo 進行服務發現，在容器平臺層固然是用 Service了，能夠實現負載均衡，自修復，自動關聯。

服務編排，原本 K8S 就是編排的標準，能夠將 yml 文件放到代碼倉庫中進行管理，而經過 deployment 的副本數，能夠實現彈性伸縮。

對於配置中心，K8S 提供了 configMap，能夠在容器啓動的時候，將配置注入到環境變量或者 Volume 裏面。可是惟一的缺點是，注入到環境變量中的配置不能動態改變了，好在 Volume 裏面的能夠，只要容器中的進程有 reload 機制，就能夠實現配置的動態下發了。

統一日誌和監控每每須要在 Node 上部署 Agent，來對日誌和指標進行收集，固然每一個 Node 上都有，daemonset 的設計，使得更容易實現。

固然目前最最火的 Service Mesh，能夠實現更加精細化的服務治理，進行熔斷，路由，降級等策略。Service Mesh 的實現每每經過 sidecar 的方式，攔截服務的流量，進行治理。這也得力於  Pod 的理念，一個 Pod 能夠有多個容器，若是當初的設計沒有 Pod，直接啓動的就是容器，會很是的不方便。

因此 K8S 的各類設計，看起來很是冗餘和複雜，入門門檻比較高，可是一旦想實現真正的微服務，K8S 能夠給你各類可能的組合方式。實踐過微服務的人，每每會對這一點深有體會。

6、Kubernetes 常見的使用方式

關於微服務化的不一樣階段，Kubernetes 的使用方式，詳見這篇文章：微服務化的不一樣階段 Kubernetes 的不一樣玩法

 

網易雲輕舟微服務是圍繞應用和微服務打造的一站式 PaaS 平臺，幫助用戶快速實現易接入、易運維的微服務解決方案。

可點擊這裏獲取方案及報價。

 

瞭解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/

免費試用網易雲基礎服務：https://www.163yun.com/product-cloudcompute