現(xiàn)在稍微有一點(diǎn)規(guī)模的公司基本都上微服務(wù)了，后端工程師在大小公司打雜的話都會(huì)碰到因?yàn)槭俏⒎?wù)，所以在做開(kāi)發(fā)的時(shí)候：

• 依賴太多，沒(méi)有穩(wěn)定的環(huán)境，服務(wù)跑不起來(lái)
• 服務(wù)要走網(wǎng)絡(luò)，穩(wěn)定性問(wèn)題難以解決
• 上下游要解耦，每次上游做修改下游都會(huì)有故障

各種各樣奇形怪狀的問(wèn)題，每一個(gè)痛點(diǎn)都會(huì)涉及到不少相關(guān)的解決方案，比如環(huán)境問(wèn)題，之前我分享過(guò) https://tilt.dev/；穩(wěn)定性問(wèn)題，我們直接去看 Google 三步曲 https://sre.google/books/；上下游用隊(duì)列解耦之后，上游的不穩(wěn)定業(yè)務(wù)事件導(dǎo)致下游故障，有 data validation 平臺(tái)和 schema registry 來(lái)緩解。

我們這里還只是舉了幾個(gè)簡(jiǎn)單的例子，每一個(gè)問(wèn)題都需要額外的努力來(lái)規(guī)避，對(duì)于那些正在遷移到微服務(wù)的公司來(lái)說(shuō)，這些不過(guò)是一大堆問(wèn)題里的九牛一毛。

對(duì)于想要使用微服務(wù)的公司來(lái)說(shuō)，需要了解微服務(wù)稅的概念：

It is the cost you pay to reap the substantial benefits of distributed application architecture.

K8s，可觀測(cè)性基礎(chǔ)設(shè)施，監(jiān)控和基礎(chǔ)的框架，都是在研發(fā)成本以外，需要額外付出的成本，好在現(xiàn)在有 CNCF，有一些微服務(wù)稅我們不用交了，直接使用現(xiàn)成的基礎(chǔ)設(shè)施即可(盡管這個(gè)所謂的 free lunch，也并沒(méi)有多好吃。

在一大堆問(wèn)題里最重要的還是框架問(wèn)題，對(duì)于 Go 語(yǔ)言的生態(tài)來(lái)說(shuō)，目前依然沒(méi)有最像 java 生態(tài)的 spring cloud 那樣大家都認(rèn)可的解法。

框架在微服務(wù)技術(shù)架構(gòu)中是承上啟下的作用：

需要負(fù)責(zé)對(duì)接公司內(nèi)的基礎(chǔ)設(shè)施，盡量將這些基礎(chǔ)設(shè)施的差異性對(duì)業(yè)務(wù)方屏蔽，業(yè)務(wù)研發(fā)只要寫邏輯就可以了，其它問(wèn)題一律不用關(guān)心。

另一方面，框架本身也應(yīng)該協(xié)助業(yè)務(wù)降低重復(fù)代碼的編寫次數(shù)，比如根據(jù)協(xié)議 IDL 來(lái)生成協(xié)議/控制層代碼，根據(jù)用戶預(yù)定義好的 SQL 生成相關(guān)的訪問(wèn)函數(shù)代碼，都是大家熟知的例子。

看起來(lái)好像沒(méi)什么技術(shù)含量，但是為什么現(xiàn)在市面上的框架都是災(zāi)難一樣的使用體驗(yàn)?zāi)?？哪怕那些大公司開(kāi)源的框架，里面一樣充斥的垃圾代碼和 bug？

這個(gè)問(wèn)題我和同事們認(rèn)真地分析過(guò)，主要有下面一些原因：

• 大公司里的框架研發(fā)，基本都是不寫業(yè)務(wù)的
• 公司內(nèi)的晉升、考核，與框架的用戶體驗(yàn)沒(méi)有直接關(guān)系
• 框架的研發(fā)者有意地隱瞞了那些對(duì)他們不利的信息和數(shù)據(jù)

第一點(diǎn)比較好理解，大多數(shù)寫框架的人可能一行業(yè)務(wù)代碼都沒(méi)寫過(guò)，沒(méi)有動(dòng)過(guò)手，自然很難去體會(huì)到業(yè)務(wù)到底苦在哪，沒(méi)有共情，做出來(lái)的東西也很難對(duì)路。如果連用戶調(diào)研都不愿意做，那結(jié)果就是自 high 了。

第二點(diǎn)，中大型公司的考核體系，對(duì)于框架組很多時(shí)候是考核規(guī)模和性能數(shù)據(jù)指標(biāo)，比如：框架覆蓋度，框架和其它業(yè)界同類方案的優(yōu)勢(shì)，以及看起來(lái)比較先進(jìn)的技術(shù)點(diǎn)(看你怎么吹)，不會(huì)考核框架本身的用戶體驗(yàn)。

你可以關(guān)注一下你們公司里會(huì)不會(huì)針對(duì)公司內(nèi)的框架收集 nps 調(diào)查問(wèn)卷，如果沒(méi)有，那大概率就是不會(huì)考核。之前某個(gè)國(guó)內(nèi)的巨頭公司，因?yàn)榭蚣苎邪l(fā)組的老板級(jí)別很高，大家不敢在內(nèi)網(wǎng)吐槽，還要跑到脈脈去講。

第三點(diǎn)，也是因?yàn)榈诙c(diǎn)衍生出來(lái)的，公司考核的就是這些性能指標(biāo)，如果性能指標(biāo)出問(wèn)題了，對(duì)于框架的研發(fā)人員的績(jī)效和考核來(lái)說(shuō)是非常不利的，所以有些數(shù)據(jù)在內(nèi)部測(cè)完之后不會(huì)放出來(lái)，也就是刻意對(duì)用戶進(jìn)行了隱瞞。這個(gè)其實(shí)也不難理解，比如有些 hack 的性能優(yōu)化，是要結(jié)合業(yè)務(wù)場(chǎng)景嚴(yán)謹(jǐn)?shù)胤治霾拍苤朗欠窈线m的，研發(fā)人員在公司內(nèi)為了不出問(wèn)題，一般也會(huì)這么做，但在對(duì)外宣傳的時(shí)候，他們會(huì)把這些優(yōu)化的限制刻意隱瞞掉，導(dǎo)致公司外部的人被相應(yīng)的宣傳所誤導(dǎo)，后續(xù)走彎路。

所以這也是我建議在使用那些大公司開(kāi)源的技術(shù)方案時(shí)，應(yīng)該自己多做一些性能測(cè)試的原因。

好像扯了一些有的沒(méi)的，我們還是要講一點(diǎn)干貨的。

最近被之前螞蟻的質(zhì)量同事教育，了解了做域內(nèi)自動(dòng)化測(cè)試時(shí)，對(duì)于服務(wù)的外部依賴的 mock 需求：

如上圖，自動(dòng)化測(cè)試腳本對(duì)被測(cè)服務(wù)發(fā)起測(cè)試，希望看被測(cè)服務(wù)是否能夠處理各種外部依賴的正常/異常流程，這時(shí)候希望能夠在不侵入被測(cè)代碼的前提下，能夠改變被測(cè)服務(wù)依賴的外部服務(wù)(即這里的 serv_a，serv_b，serv_c)的返回結(jié)果，在 java 中有 jvm-sandbox 這種能夠比較方便地對(duì)測(cè)試進(jìn)行隔離，并且動(dòng)態(tài)修改 class 實(shí)現(xiàn)的神器，但是在 Go 里，這個(gè)需求不太好實(shí)現(xiàn)。

正好目前公司內(nèi)在大規(guī)模落地 go-zero，所以我們和 go-zero 社區(qū)的同學(xué)合作，想了一些辦法來(lái)解決這個(gè)問(wèn)題，下面是社區(qū)同學(xué)提出的方案：

因?yàn)橄胍诓桓谋粶y(cè)服務(wù)的前提下來(lái)修改外部服務(wù)的行為，這讓我們想到了日常工作中用到的一些代理服務(wù)，所以我們?cè)谥虚g加一個(gè) proxy。

這個(gè) proxy 可以和自動(dòng)化測(cè)試腳本交互，由腳本來(lái)設(shè)定相應(yīng)的服務(wù)、請(qǐng)求和響應(yīng)匹配規(guī)則，可以做到 case by case 的請(qǐng)求響應(yīng)匹配/隔離，也就是可以動(dòng)態(tài)地對(duì) serv_a，serv_b，serv_c 這樣的服務(wù)做 mock。

因?yàn)楣緝?nèi)默認(rèn)使用的是 grpc，目前市面上所有 mock 都需要用戶提供 pb 才能進(jìn)行，并且沒(méi)有辦法動(dòng)態(tài)設(shè)置。而對(duì) grpc 比較熟悉的同學(xué)則知道在 grpcurl 這個(gè)工具中，給我們提供了 describe 功能，我們可以使用 grpc desc 來(lái)查看服務(wù)的定義，當(dāng)然，前提是服務(wù)開(kāi)啟了 reflection。

通過(guò) reflection 能夠拿到服務(wù)定義的話，我們無(wú)需再去要求用戶提供原始的 pb 定義。