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

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

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

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

對于想要使用微服務(wù)的公司來說，需要了解微服務(wù)稅的概念：

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

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

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

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

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

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

看起來好像沒什么技術(shù)含量，但是為什么現(xiàn)在市面上的框架都是災(zāi)難一樣的使用體驗(yàn)?zāi)兀磕呐履切┐蠊鹃_源的框架，里面一樣充斥的垃圾代碼和 bug？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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