K8S怎麼就和微服務成死對頭了？

• 1、互聯網架構的演變過程

  • 1.一、 垂直擴展

  • 1.二、 分拆架構

  • 1.三、 橫向擴展

  • 1.四、 架構優化

  • 1.五、 業務拆分

• 2、K8S要解決的問題

• 3、微服務要解決的問題

• 4、k8s和Spring衝突的功能

K8S怎麼就和微服務成死對頭了？

運維就要無所不知，無所不會

你們好，我是史丹利。今天和你們聊一聊K8S和微服務的生存之戰，或者說將來這片戰場到底會不會有。

我先拋2個問題：

1. liveness檢測誰來作：spring全家桶是微服務的標配。其中 Eureka 監管全部服務的生命週期。用了k8s後，一般會使用svc便可。SVC和 Eureka 誰能笑到最後。
2. 成本管理上漲: 自從微服務火了以後「其實吧，這個概念早就有了，從人類第一個登月工程開始《人月神話》就已經有的，Linux內核的實現思想也是微內核」。全部的高層應用，不說微服務，感受都不是作IT的。那你遇到過一個簡單的服務拆成幾十個微服務的嗎**？容器化後的成本，算誰的？

好了，這麼簡單的問題描述，想必不少朋友壓根沒看懂。

不要緊，文章較長，要有耐心。我一點點把問題抽出來。基礎好的大佬，直接跳到最後便可。

1、互聯網架構的演變過程

互聯網的架構發現一直在演變，一直到今天都未中止。但這不是咱們本次要討論的重點，我儘量簡單的帶過，節省篇幅。

互聯網行業有一個明顯的特性是爆發性成長。在很長一段時間裏，投資人對互聯網行業的印象都是先有流量再談盈利。即便是虧損狀態，只要流量和模式在，也會鉅額投入。像如今你們耳熟能詳的攜程、餓了麼、小黃車、摩拜、小紅書、滴滴、新蛋等等，幾乎全部叫的上名字的公司，都離不開這樣的模式。

這同步帶來一個問題，就是如此巨大的流量+中國爆炸的人工紅利+全球計算機硬件的普及，如何支撐業務正常運營成爲全球互聯網公司的難題。

隨着互聯網技術的不斷成熟，互聯網技術也在不斷迭代成長。咱們姑且認爲互聯網是從1990年進入中國的。到如今也有30年的時間了。互聯網架構大體有以下幾個階段的演變

• 垂直擴展
• 分拆架構
• 橫向擴展
• 業務拆分
• 架構優化

下面咱們來逐一介紹。

1.一、 垂直擴展

業務上線前，公司一般都是老闆和合夥人本身出錢，窮的不行。一切都是成本和速度優先。這個階段有沒有運維都是兩碼事。

一般在初創階段，全部的應用都是 AllInOne，即全部的服務都運行在一臺服務器上。架構也是最簡單，當時最流量最輕量的 LNMP 架構。

Lamp架構

隨後業務逐步有轉機，流量變大。垂直擴展是容易便捷的解決問題方式。從4c8g 提高到  32c64g 能在一段時間內解決問題。

1.二、 分拆架構

但一夫難擋萬人勇，服務器的網絡、性能、存儲、運算能力總歸會見頂。一臺服務器不可能再支撐流量的時候，這時最快捷的辦法就是分拆硬件架構。

把數據庫和存儲分拆出去，再把運算模塊分拆出去，再把流量模塊分拆出去。

初步分拆架構圖

總歸一個字：拆。就對了。

1.三、 橫向擴展

各類拆完，若是仍是抗不住，說明公司規模已經不錯了，離盈利不遠或者已經有盈利了。這時就要考慮一些高可用技術，稍微有點挑戰的技術了。

• LVS的10w併發起步的流量負載均衡,；

• MySQL 的分庫分表, 主從分離，MMM 高併發架構;

• 數據的冷熱分離;

較複雜的架構

這個階段，仍是純技術的升級迭代，對抗這個階段的壓力還可行。但就實際來說，早應該在軟件架構層面作優化了，好比業務功能分拆、優化緩存策略、先後臺分離

1.四、 架構優化

再往下就是架構優化了，這個層面已經不只僅是運維能力能造就的成果。須要引入外部財力、開發架構改造等資源。

• 加緩存

早期爲了省錢CDN沒買的，要搞了。session 不只後臺技術要作緩存，前端也要作。CTO甚至要親自下手狠抓代碼質量，彌補前期追進度丟質量的坑。「咱們就深有體會，並且一抓就抓了3年多，最後仍是走在了放棄的路上，計劃全新重構。。。」

Redis,RabbiqMQ等異步架構，在非及時場景，都儘量合入。

• 分拆模塊

原來隨便調用，隨便穿洞引用的調用關係，要全新梳理，定規範，定製度。收縮入口和出口。

按熱度、流量、功能特性，作模塊拆分。其實，就是打造中臺的過程。只是阿里把這個口號喊的太大，把你們帶偏了。有能力沒能力都想搞箇中臺。。

• 業務分層

原來混在一塊兒的模型作分層，代理層、緩存層、網關層、業務層、數據層、存儲層

1.五、 業務拆分

若是4個打法還不能支持業務，恭喜你騎在了一頭獨角獸身上。公司上市指日可待。

這個階段已經不只僅是技術層面能解決的問題了。很大可能已經進行了部門重組，業務拆分。以電商狗東爲例：

原來PC端和手機端極可能是一個團隊作的，如今拆分紅2個部門。

原來購買、下單、秒殺、搜索、售後可能都是一個團隊作的，如今要拆分紅4個團隊，專門的市場拉新、智能運營、大數據殺熟團隊、智能搜索，下面還要再細化。

而後，把前面的步驟再來一遍就行了。

好了，終於囉嗦完了。但願說的還明白。

總結下來就是一句話：運維要有快速平行擴展業務迅猛擴張的流量壓力的能力。

你們請先記住這句話。

2、K8S要解決的問題

其實，一直在k8s出現以前，上面囉嗦了這麼長的一段內容都是由運維完成。也俗稱運維架構能力。但自從k8s出現以後，運維只要掌握了 k8s ，就掌握了絕大部分的運維架構能力。

說白了，就像 git 的出現同樣，技術世界再次演繹了一次，經過技術手段降維打擊技術門檻的好戲。

• 快速遷移環境的能力

原來僅僅快速遷移環境的能力，就是運維頭大不能自已。測試開發環境不統一，測試環境永遠不夠用，跨平臺部署環境難上加難。

如今只是Dockerfile 和k8s yaml 的編寫能力。指數級降維打壓

• 高可用架構能力

原來，運維須要掌握F5,A10 等高端硬防設備。掌握nginx 7層代理，lvs四層代理， 4種轉發10種算法，面試各類被問原理。看盡面試官的裝完逼回頭給本身同事講，其實剛問的那些問題我也不會。。。。

如今全然不用，由於面試官k8s 本身也是隻知其一;不知其二！吹完 k8s 就能夠回家等通知，拿高薪了。由於k8s 他敢說 yes。

• 分佈式數據存儲能力

原來運維還要懂 ceph， gfs, hdfs, swift, 等一大坨牛逼的分佈式存儲，搞不搞還要被問原理。

「問尼大爺啊，老子就是搞運維的，世界難題就是存儲了，我要懂了早就去拯救世界了。混毛的運維」，不知道有多少朋友有這樣的想法。

如今全然不用，對不起，k8s yml 全然搞定。運維專一業務便可。

• 網關架構分層能力

k8s把全部的出入口收縮到 svc 和 ingress，從技術手段逼迫架構優異。不再用，和開發亂打洞，亂路由對抗了。你們今後就是酒桌上的好朋友，不用再是工做中的死對頭。

• CICD 流程建設能力

k8s生態提供了成熟的CICD的工具。由於使用容器鏡像，因此CICD變的更加容易且規範。運維重心也將從原來的環境構建變爲鏡像傳輸和維護。

• 數據收集監控能力

k8s生態提供的插件，會將全部的原生數據所有收集起來，數據收集再也不是難題。數據彙總和彙報，纔有更大的價值。

• 權限管理能力

k8s收縮了服務器的登陸權限，使用 conf 認證文件，便可在全部網絡互通的服務器上登陸，並管理k8s集羣。生產環境更安全。

最重要的k8s收縮了系統管理的權限，由於全部人不須要再管理系統。只需管理k8s。k8s本身就是系統。

• 資源配額管理能力

資源配額太簡單了。原來須要系統，代碼各類配置。如今只須要修改容器參數。最後體如今修改 yaml 便可

• 流量管控能力

k8s相對雲原生和serverless有一點差距。但徹底不影響普通大多數公司的功能需求。很是便利。

其他的看圖本身體悟。

k8sarch

---

我是可愛的分隔線。扯淡這麼久，爲何感受和題目沒毛線關係。

是的，由於我不鋪掂好k8s的做用， 他和微服務的衝突會很難講清楚。

3、微服務要解決的問題

微服務要解決哪些問題呢？扯開了講，又是一大篇。咱們只能精簡了說。

若是說k8s拯救了運維，那微服務拯救了開發。主要是java開發。相對於python, golang, php 等個性化很強的語言，所謂的模塊化開發，主要靠前期業務模塊分工，每一個人預估模塊的工做量，領取工做項。但最後都得合在一塊兒，作爲總體應用，統一對外提供惟一服務，最多算是半個微服務。

java則比較幸福，業內當前主要流行的是 spring cloud全家桶。從接口規範、服務管理、健康檢測、全連接監控、配置管理。提供了一整套解決方案，真的是爽翻天了。

摘自網圖的spingcloud的架構圖

可是！！！

一整套解決方案

這幾個字是否是有點眼熟。。。

是的。老朋友都知道，咱們前面已經囉嗦的不能再囉嗦了。k8s也提供了一整套完整的解決方案。

這就有點尷尬了，不巧的是，k8s的理念和springcloud的理念並不徹底相同，也不是一家公司的。

咱們就咱們如今遇到的問題爲例，給你們舉例說明。

4、k8s和Spring衝突的功能

這裏不得不畫圖了，你們知道，畫圖特別費時間。。。

svc相對是無狀態的

Eureka註冊的ip地址不能是pod地址，你們知道的。但svc後面能夠跟不少pod,因此註冊到Eureka也是假的。。

因此 ，我說明白了嗎？

這個問題要怎麼解呢？

當下 k8s 也只是和 Eureka 的功能上的重疊，只是思想不一致。在 AllIn 容器化的大前提下， Eureka的方式可能會被廢棄。改用 k8s的全套方案。

其它

• 衝突的功能還有  xxljob。k8s 提供了相似 cronjob 的定時任務功能
• apollo 使用 configmap代替
• 甚至於連 zuul 網關也能夠去掉。主要看頂層的設計和深刻度了。

好了，今天聊到這裏。無論你懂了沒有，史丹利已經累趴~  ^ ^