很多系統(tǒng)遷移到微服務(wù)架構(gòu)之后，并沒(méi)有明顯感覺(jué)到微服務(wù)架構(gòu)帶來(lái)的優(yōu)勢(shì)，反而覺(jué)得帶來(lái)了更高的復(fù)雜度，王啟軍在《持續(xù)演進(jìn)的Cloud Native》書(shū)中總結(jié)了七種微服務(wù)架構(gòu)沒(méi)能發(fā)揮出固有優(yōu)勢(shì)的原因，看看自己“中槍”了沒(méi)!

[[249489]]

1、用傳統(tǒng)方式構(gòu)建微服務(wù)

微服務(wù)架構(gòu)和傳統(tǒng)的架構(gòu)方式思路完全不一樣。例如傳統(tǒng)方式實(shí)現(xiàn)高可用，更相信流程，更相信KPI對(duì)人的影響，因此流程需要讓更多的人去測(cè)試，制定更嚴(yán)格的發(fā)布流程。

而微服務(wù)架構(gòu)強(qiáng)調(diào)的是自動(dòng)化發(fā)布、灰度發(fā)布、Design For Failure、自動(dòng)化測(cè)試、故障隔離、自愈。很多失敗的案例以傳統(tǒng)的方式去構(gòu)建微服務(wù)架構(gòu)，一切都沒(méi)有轉(zhuǎn)變，只是把服務(wù)拆開(kāi)，根本無(wú)法享受微服務(wù)架構(gòu)帶來(lái)的便利，反而因此遇到了更多麻煩。最明顯的是對(duì)開(kāi)發(fā)人員的影響，他們質(zhì)疑微服務(wù)架構(gòu)是否適合自己的業(yè)務(wù)場(chǎng)景，而一個(gè)充滿質(zhì)疑的團(tuán)隊(duì)是不可能具備強(qiáng)大戰(zhàn)斗力的。

2、組織結(jié)構(gòu)不變

如果要充分發(fā)揮微服務(wù)架構(gòu)的優(yōu)勢(shì)，組織結(jié)構(gòu)必須發(fā)生轉(zhuǎn)變，構(gòu)建和微服務(wù)配套的小團(tuán)隊(duì)，并且讓他們擁有絕對(duì)的自主權(quán)。實(shí)際上，相當(dāng)一部分實(shí)施微服務(wù)架構(gòu)的團(tuán)隊(duì)都沒(méi)有做到這一點(diǎn)，因?yàn)榻M織結(jié)構(gòu)總是涉及利益。比較典型的問(wèn)題是，小團(tuán)隊(duì)不需要團(tuán)隊(duì)以外的任何人來(lái)批準(zhǔn)是否上線，架構(gòu)如何演進(jìn)，使用什么數(shù)據(jù)庫(kù)。如果小團(tuán)隊(duì)沒(méi)有權(quán)利，任何變動(dòng)都要等待高層進(jìn)行決策，就會(huì)形成決策瓶頸點(diǎn)，導(dǎo)致效率低下，這違背了微服務(wù)架構(gòu)的初衷，團(tuán)隊(duì)成員也會(huì)因此失去主動(dòng)性。 

3、習(xí)慣于領(lǐng)導(dǎo)安排工作

傳統(tǒng)的研發(fā)模式嚴(yán)重依賴流程，原因是沒(méi)有人愿意承擔(dān)責(zé)任，所有人都把責(zé)任推到流程上。微服務(wù)架構(gòu)和敏捷開(kāi)發(fā)流程是天作之合，傳統(tǒng)研發(fā)模式需要領(lǐng)導(dǎo)批準(zhǔn)，然后由團(tuán)隊(duì)負(fù)責(zé)人直接分解任務(wù)、定工時(shí)、安排任務(wù)負(fù)責(zé)人，而按照敏捷開(kāi)發(fā)流程，開(kāi)發(fā)計(jì)劃應(yīng)該是團(tuán)隊(duì)決定的，任務(wù)自主認(rèn)領(lǐng)。精英化團(tuán)隊(duì)絕不僅僅是團(tuán)隊(duì)人數(shù)更少，人員能力更強(qiáng)這么簡(jiǎn)單，這只是表面上的，更重要的是責(zé)任感和主觀能動(dòng)性以及信任!

某公司CEO 曾經(jīng)說(shuō)過(guò)這樣一件事情，員工把請(qǐng)假流程提給“我”，讓“我”審批，但是“我”根本沒(méi)有審批的必要，因?yàn)槟汶S便說(shuō)一個(gè)理由“我”都不可能拒絕，就算拒絕了，下回會(huì)來(lái)一個(gè)更難以拒絕的理由。后來(lái)公司所有的請(qǐng)假都不需要審批了，只要在群里發(fā)一條消息，讓相關(guān)同事知道就可以了。 

4、糾結(jié)如何拆分服務(wù)

不理解微服務(wù)架構(gòu)的人，通常從字面理解，他們認(rèn)為微服務(wù)架構(gòu)的重中之重就是服務(wù)拆分。

到底拆分多細(xì)?與其浪費(fèi)更多的時(shí)間思考這個(gè)問(wèn)題，不如先拆出幾個(gè)服務(wù)運(yùn)行一下，感受一下。架構(gòu)是一個(gè)持續(xù)的過(guò)程，有時(shí)候很難從技術(shù)角度完全解釋清楚。

另一個(gè)錯(cuò)誤是一次性拆分，不能改變。由于技術(shù)人員對(duì)業(yè)務(wù)領(lǐng)域知識(shí)的理解不斷加深，業(yè)務(wù)邏輯有可能運(yùn)行一段時(shí)間也會(huì)轉(zhuǎn)變，這時(shí)候改變是不可避免的。重新合并、劃分，是一個(gè)正常的演變過(guò)程。架構(gòu)是動(dòng)態(tài)的，不是靜態(tài)的。 

5、以大規(guī)模拆分服務(wù)開(kāi)始

微服務(wù)架構(gòu)需要一個(gè)適應(yīng)過(guò)程，持續(xù)拆分效果更佳。如果從大規(guī)模拆分服務(wù)開(kāi)始，需要具備三個(gè)條件，否則可能會(huì)遇到相當(dāng)多的麻煩。

• 團(tuán)隊(duì)有微服務(wù)架構(gòu)經(jīng)驗(yàn)。
• 已具備微服務(wù)架構(gòu)的先決條件，包括自動(dòng)化的研發(fā)環(huán)境、全面的健康檢查、必要的公共服務(wù)及框架，以及敏捷基礎(chǔ)設(shè)施。
• 業(yè)務(wù)目標(biāo)非常明確，已經(jīng)可以預(yù)期未來(lái)的規(guī)模，業(yè)務(wù)幾乎無(wú)變化。 

6、高估架構(gòu)的移植性

架構(gòu)是一門(mén)藝術(shù)，不是隨隨便便復(fù)制一下就可以的，Google、Amazon、Facebook 的架構(gòu)問(wèn)世已經(jīng)很長(zhǎng)時(shí)間了，研發(fā)人員跳槽這么頻繁，但是沒(méi)有哪個(gè)公司能模仿好。MySQL 開(kāi)源了這么多年，放到不同人的手里，結(jié)果完全不一樣。實(shí)際上實(shí)施微服務(wù)架構(gòu)在一個(gè)業(yè)務(wù)場(chǎng)景中的優(yōu)勢(shì)在另一個(gè)場(chǎng)景中很可能會(huì)變成一種劣勢(shì)。如果你仔細(xì)研究就會(huì)發(fā)現(xiàn)，大多數(shù)公司實(shí)施的微服務(wù)架構(gòu)就跟各個(gè)公司的管理制度一樣各不相同。很多公司為了顯示自己的架構(gòu)有多厲害而實(shí)施微服務(wù)架構(gòu)，最終只會(huì)害了團(tuán)隊(duì)，因?yàn)橹话丫Ψ旁谖⒎?wù)架構(gòu)上，可能就減少了對(duì)業(yè)務(wù)實(shí)現(xiàn)、用戶體驗(yàn)的關(guān)注。 

7、從來(lái)沒(méi)有做過(guò)微服務(wù)架構(gòu)的人領(lǐng)導(dǎo)你完成遷移

如果轉(zhuǎn)型的團(tuán)隊(duì)由沒(méi)有經(jīng)驗(yàn)的人來(lái)領(lǐng)導(dǎo)，那么結(jié)果就是只關(guān)注表面，拆了多少服務(wù)、服務(wù)粒度、服務(wù)注冊(cè)發(fā)現(xiàn)、負(fù)載均衡、調(diào)用鏈分析，而隱藏的各種性能問(wèn)題、擴(kuò)展性問(wèn)題、可用性問(wèn)題都沒(méi)有得到足夠的關(guān)注。如果只是從幾個(gè)服務(wù)拆分開(kāi)始積累經(jīng)驗(yàn)還好，一旦大規(guī)模拆分，就會(huì)讓整個(gè)團(tuán)隊(duì)都質(zhì)疑微服務(wù)架構(gòu)的意義。架構(gòu)是需要實(shí)踐的，不要以為看幾篇文章就得到了架構(gòu)的真諦，細(xì)節(jié)會(huì)“殺死”團(tuán)隊(duì)。 

本文選自《持續(xù)演進(jìn)的Cloud Native：云原生架構(gòu)下微服務(wù)最佳實(shí)踐》，作者王啟軍 ，電子工業(yè)出版社10月出版。

作者從全局視角出發(fā)，全面闡釋Cloud Native 的關(guān)鍵技術(shù)，以及其衍生出來(lái)的工具、團(tuán)隊(duì)文化等核心要素，對(duì)于正在部署微服務(wù)架構(gòu)或開(kāi)展云原生業(yè)務(wù)的企業(yè)和組織而言，終于有了面向落地的務(wù)實(shí)參考和全面指導(dǎo)。