運(yùn)維就要無(wú)所不能，無(wú)所不會(huì)

[TOC]

大家好，我是史丹利「stanley」见转，今天來(lái)聊聊微服務(wù)做容器化時(shí)應(yīng)該規(guī)避哪些坑。

在上上篇文章里蒜哀，我們有提到容器化時(shí)成本控制斩箫。

運(yùn)維職業(yè)的第一職業(yè)敏感是成本。這毫無(wú)異議撵儿。

曾經(jīng)有架構(gòu)師推薦老板容器化的一個(gè)理由也是容器化可以大范圍節(jié)約公司資金成本乘客，我也一度很認(rèn)可，但后來(lái)發(fā)現(xiàn)凡事是有前提的淀歇。

微服務(wù)天生適合容器化易核，這也毫無(wú)異議，但也是有前提的浪默，前提就是做了合理的微服務(wù)拆分牡直！

太過粗糙的微服務(wù)拆分，頂多影響開發(fā)工作版本迭代浴鸿，提升版控難度井氢，但過于細(xì)分的微服務(wù)拆分，則會(huì)增大容器化后的成本岳链。

安全起見花竞，Java 進(jìn)程啟動(dòng)時(shí)都分顯示聲明的內(nèi)存分配

-javaagent:/usr/local/skywalking_agent/skywalking-agent.jar -Dskywalking_config=/usr/local/skywalking_agent/config/app.config --eureka.client.serviceUrl.defaultZone=http://eureka.example.com/eureka/ -XX:PermSize=128m -XX:MaxPermSize=128m

k8s 也一樣，官方建議對(duì)所有的pod做限額配置。

        resources:
          requests:
            cpu: 2
            memory: 2048Mi
          limits:
            cpu: 2
            memory: 2Gi

如上的方式為資源硬設(shè)置约急，即固定分配2c2G的資源零远，如果覺得這樣的方式，太浪費(fèi)資源厌蔽，k8s 同樣提供了如下比較人性人的設(shè)置,

limits:
- default:
    cpu: 800m
  defaultRequest:
    cpu: 800m
  max:
    cpu: 800m
  min:
    cpu: 200m
  type: Container

軟資源限制對(duì)資源浪費(fèi)有緩存牵辣，但并不能實(shí)質(zhì)性解決資源浪費(fèi)的情況，因?yàn)闆]人知道什么時(shí)間pod的資源占用會(huì)達(dá)到峰值奴饮，即使知道纬向，這部分資源也需要一直為其預(yù)留，與其這樣戴卜，反倒硬資源限制更安全逾条。

所以，問題就回到了投剥，如何微服務(wù)的切割原則师脂。

一、微服務(wù)常見的坑

單體應(yīng)用運(yùn)行一段時(shí)間后江锨，隨著業(yè)務(wù)的增長(zhǎng)吃警，對(duì)系統(tǒng)性能和并發(fā)性要求越來(lái)越高，這個(gè)時(shí)候就面臨著微服務(wù)重構(gòu)的選擇啄育，但在重構(gòu)前酌心，我們必須反復(fù)權(quán)衡并且做好必要的基礎(chǔ)設(shè)施準(zhǔn)備以應(yīng)對(duì)新架構(gòu)下面臨的新問題，而不是覺得微服務(wù)現(xiàn)在火腦袋一熱就開始著手微服務(wù)重構(gòu)灸撰。

結(jié)合實(shí)際項(xiàng)目回顧下微服務(wù)可能存在的坑谒府，主要包含以下幾點(diǎn)：

• 過分強(qiáng)調(diào)’微‘，致使服務(wù)拆分過細(xì)浮毯，服務(wù)數(shù)量太多，導(dǎo)致服務(wù)間關(guān)系復(fù)雜泰鸡，系統(tǒng)復(fù)雜度上升债蓝，人力和維護(hù)成本變高；
• 原本的單體同進(jìn)程間服務(wù)調(diào)用變成遠(yuǎn)程不同進(jìn)程間服務(wù)調(diào)用盛龄，調(diào)用模式從內(nèi)存調(diào)用變成網(wǎng)絡(luò)調(diào)用饰迹，如果調(diào)用鏈路過長(zhǎng)，反而會(huì)導(dǎo)致性能下降余舶，響應(yīng)時(shí)間變長(zhǎng)啊鸭，同時(shí)問題定位變得愈發(fā)困難；
• 基礎(chǔ)設(shè)施不健全匿值，沒有必要的服務(wù)監(jiān)控和治理赠制，導(dǎo)致服務(wù)管理混亂，原本設(shè)想的輕量級(jí)微服務(wù)變成一堆亂麻挟憔，此外钟些，自動(dòng)化測(cè)試和部署支持也要更上烟号，否則服務(wù)間有依賴的話無(wú)法實(shí)現(xiàn)快速交付。

我們分幾方面介紹：

• 服務(wù)拆分前提
• 服務(wù)拆分時(shí)機(jī)
• 服務(wù)拆分方法
• 服務(wù)拆分規(guī)范

二政恍、服務(wù)拆分前提

• 公司的CICD平臺(tái)較完善

服務(wù)拆分后汪拥，同步帶來(lái)的驗(yàn)證、測(cè)試篙耗、上線等工作量是有增無(wú)減迫筑，微服務(wù)的過程其實(shí)是人力換質(zhì)量的過程 。如果配套工具不成熟宗弯，同步帶來(lái)的復(fù)雜度會(huì)遠(yuǎn)勝便利性铣焊。

• RESTFUL API 接口和前后端分離

[圖片上傳失敗...(image-27f485-1610636671284)]

新一代開發(fā)開發(fā)框架，基本上已經(jīng)有很好的前后端分離罕伯。這樣的好處是曲伊，無(wú)論后端如何變化，對(duì)前端都是透明的追他。而且可以實(shí)現(xiàn)拆分過程中的灰度發(fā)布坟募，路由分發(fā)，流量切分邑狸，從而保證拆分的平滑進(jìn)行

• 數(shù)據(jù)庫(kù)表設(shè)計(jì)

各功能模塊間沒有大量的復(fù)雜聯(lián)合查詢懈糯，優(yōu)秀的庫(kù)表設(shè)計(jì)應(yīng)該能達(dá)到絕大多數(shù)的功能查詢只是 k/v 的O(n) 查詢。否則单雾，微服務(wù)的拆分會(huì)有很大難度赚哗，和代碼重構(gòu)無(wú)異

• 無(wú)狀態(tài)化

[圖片上傳失敗...(image-91cb7a-1610636671284)]

新一代的開發(fā)框架和開源流行工具都在強(qiáng)調(diào)的功能特性，去中心化硅堆，無(wú)狀態(tài)化屿储。無(wú)狀態(tài)化同樣是k8s的核心思想之一。

三渐逃、服務(wù)拆分時(shí)機(jī)

新業(yè)務(wù)通常使用springcloud全家桶够掠，在某些程度或者完全實(shí)現(xiàn)微服務(wù)化。

舊業(yè)務(wù)的微服務(wù)化改造的拆分并非自上而下一步到位的重構(gòu)改造茄菊，通常是由痛點(diǎn)驅(qū)動(dòng)疯潭，是業(yè)務(wù)真正遇到了快速迭代和高并發(fā)的問題，如果不拆分面殖，將對(duì)于業(yè)務(wù)的發(fā)展帶來(lái)影響竖哩，只有這個(gè)時(shí)候，微服務(wù)的拆分是有確定收益的脊僚，增加的運(yùn)維成本才是值得的相叁。

比如如下的情況之一：

• 提交代碼頻繁沖突
• 無(wú)法快速版本迭代，小功能要積累到大版本才能上線，每次上線各種問題钝荡，不蛻三層皮上線不成功
• 業(yè)務(wù)有高并發(fā)需求
• 熔斷全斷if-else

如上情況街立，可考慮服務(wù)拆分

四、服務(wù)拆分方法

[圖片上傳失敗...(image-62efa9-1610636671284)]

[AKF擴(kuò)展立方體](參考《The Art of Scalability》)埠通，是一個(gè)叫AKF的公司的技術(shù)專家抽象總結(jié)的應(yīng)用擴(kuò)展的三個(gè)維度赎离。理論上按照這三個(gè)擴(kuò)展模式，可以將一個(gè)單體系統(tǒng)端辱，進(jìn)行無(wú)限擴(kuò)展梁剔。

• X 軸 ：指的是水平復(fù)制，很好理解舞蔽，就是講單體系統(tǒng)多運(yùn)行幾個(gè)實(shí)例荣病，做個(gè)集群加負(fù)載均衡的模式。

• Z 軸 ：是基于類似的數(shù)據(jù)分區(qū)渗柿，比如一個(gè)互聯(lián)網(wǎng)打車應(yīng)用突然或了个盆，用戶量激增，集群模式撐不住了朵栖，那就按照用戶請(qǐng)求的地區(qū)進(jìn)行數(shù)據(jù)分區(qū)颊亮，北京、上海陨溅、四川等多建幾個(gè)集群终惑。

Y 軸 ：就是我們所說的微服務(wù)的拆分模式，就是基于不同的業(yè)務(wù)拆分门扇。

場(chǎng)景說明：比如京東商城雹有，一個(gè)集群撐不住時(shí)，分了多個(gè)集群臼寄，后來(lái)用戶激增還是不夠用霸奕，經(jīng)過分析發(fā)現(xiàn)是6.18訪問量很大，就將商城頁(yè)面流量大功能再做拆分脯厨，每個(gè)拆分出來(lái)的功能铅祸，獨(dú)立維護(hù)，各自都可以再次按需擴(kuò)展合武。

反面教材：

我們公司的內(nèi)部應(yīng)用系統(tǒng)，使用人數(shù)不超過100人涡扼，但系統(tǒng)卻拆分成30多個(gè)模塊稼跳，造成容器化時(shí)大量資源浪費(fèi)。

五吃沪、服務(wù)拆分規(guī)范

服務(wù)拆分規(guī)范并不是運(yùn)維強(qiáng)項(xiàng)汤善，或者運(yùn)維并沒有太多的機(jī)會(huì)和話語(yǔ)權(quán)參與到開發(fā)的實(shí)際開發(fā)工作中。

在實(shí)際工作中，微服務(wù)對(duì)運(yùn)維工作造成比較大的影響红淡，比如工作量陡增不狮，資源成本消耗更多，但服務(wù)質(zhì)量并沒有實(shí)際提升在旱，那么優(yōu)先考慮

• 運(yùn)維工具是否成熟健全
• CICD流程是否成熟可靠

如果均沒有摇零，再考慮微服務(wù)拆分問題，這里僅做入門桶蝎，建議深入學(xué)習(xí)后再和開發(fā)同學(xué)一起改進(jìn)優(yōu)化驻仅。

• 服務(wù)拆分的規(guī)范一：服務(wù)拆分最多三層，兩次調(diào)用
• 服務(wù)拆分的規(guī)范二：僅僅單向調(diào)用登渣，嚴(yán)禁循環(huán)調(diào)用
• 服務(wù)拆分的規(guī)范三：將串行調(diào)用改為并行調(diào)用噪服，或者異步化
• 服務(wù)拆分的規(guī)范四：接口應(yīng)該實(shí)現(xiàn)冪等
• 服務(wù)拆分的規(guī)范五：接口數(shù)據(jù)定義嚴(yán)禁內(nèi)嵌，透?jìng)?/li>
• 服務(wù)拆分的規(guī)范六：規(guī)范化工程名

微服務(wù)規(guī)范參考: http://dockone.io/article/8241