[[285134]]

在這篇文章里，我將簡(jiǎn)要地介紹在設(shè)計(jì)微服務(wù)架構(gòu)時(shí)需要注意的問題。如果實(shí)施得當(dāng)，就會(huì)獲得自治能力和靈活性，但同時(shí)也會(huì)帶來通信延遲和部署及托管成本。這篇文章并不是一個(gè)高級(jí)指南，我只是希望能夠在你們決定采用微服務(wù)架構(gòu)時(shí)幫你們做出更好的判斷。

1. 映射服務(wù)

在我看來，映射服務(wù)是一種很糟糕的想法。

如果你走到了這一步，很可能是因?yàn)槟阈枰诜?wù) A 和服務(wù) B 之間映射 DTO，因?yàn)榉?wù) A 和服務(wù) B 需要不同的 DTO，但它們之間又相互依賴。出于對(duì)微服務(wù)的“熱愛”，你嘗試著解耦這兩個(gè)服務(wù)，于是你創(chuàng)建了服務(wù) C。服務(wù) C 接收 JSON 數(shù)據(jù)，并把稍微處理后的數(shù)據(jù)返回，其他什么事也不做。

現(xiàn)在，你的三個(gè)服務(wù)都耦合在一起了。DTO 到 DTO 的映射應(yīng)該發(fā)生在進(jìn)程內(nèi)部，否則的話，可能會(huì)有人創(chuàng)建出新的服務(wù)來映射服務(wù) A 和服務(wù) C 之間的 DTO。除非服務(wù) C 不會(huì)往實(shí)體中添加新數(shù)據(jù)，否則它的存在就不是必要的。一個(gè)服務(wù)應(yīng)該只返回它所擁有的數(shù)據(jù)。

同樣，你會(huì)為了給一組數(shù)字排序而專門創(chuàng)建一個(gè)服務(wù)嗎？

2. 靜態(tài)內(nèi)容的映射服務(wù)

并不是所有東西都需要被包裝成微服務(wù)，網(wǎng)站的靜態(tài)資源，比如腳本、樣式表或圖像，要么把它們放在主服務(wù)器上，要么放在 CDN 上。

對(duì)于后端服務(wù)，如果需要在初始化的時(shí)候讀取一些簡(jiǎn)單的字符串，而這些字符串很少發(fā)生變化，可能幾個(gè)月或者幾天才會(huì)修改一次，那么可以考慮使用冷存儲(chǔ)，比如亞馬遜的 S3 或者微軟的 BlogStorage。需要訪問控制？可以考慮基于 IP 或域名的訪問限制。所以，在考慮是否需要?jiǎng)?chuàng)建新的微服務(wù)時(shí)，要十分謹(jǐn)慎，因?yàn)樗赡軙?huì)給你帶來巨大的維護(hù)和托管成本。

另外請(qǐng)注意，持久存儲(chǔ)必須是分布式可伸縮的。出于簡(jiǎn)單起見，數(shù)據(jù)應(yīng)該采用鍵值對(duì)的形式，否則就會(huì)遇到與“多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)”一樣的問題。

3. 將應(yīng)用程序的配置托管在遠(yuǎn)程服務(wù)上

線程池該配置多少個(gè)線程？重試策略該怎么配？本地內(nèi)存緩存的有效時(shí)間設(shè)置多久合適？需要通過一個(gè)遠(yuǎn)程服務(wù)來配置這些東西嗎？在很多情況下，把這些東西放在配置文件或者環(huán)境變量里是完全可以的，所以可以先考慮這種方式。如果不行，可以嘗試一些已有的配置工具，比如 Consul，盡量避免自己開發(fā)浪費(fèi)時(shí)間和精力。

4. 多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)

如果架構(gòu)過于簡(jiǎn)單，很快也會(huì)遇到問題。如果多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)的連接、存儲(chǔ)空間和計(jì)算能力很快就會(huì)不夠用。接下來就會(huì)出現(xiàn)一些不太好的局面——一些服務(wù)使用的表被刪掉了?；蛘?，有兩個(gè)客戶端使用了同一張表，其中一個(gè)客戶單要求對(duì)表結(jié)構(gòu)做出修改，這個(gè)時(shí)候就需要做一些適配才能不影響另一個(gè)客戶端。在我看來，現(xiàn)在的系統(tǒng)變成了一個(gè)分布式單體。

這樣做有悖微服務(wù)架構(gòu)的原則，因?yàn)槲⒎?wù)應(yīng)該是獨(dú)立且自包含的。它們應(yīng)該擁有自己的數(shù)據(jù)，并可以完全自由決定該怎么持久化數(shù)據(jù)。它們存在的目的是為了解耦，為了獲得這種靈活性，需要付出一定的代價(jià)，但追求靈活性應(yīng)該成為你的目標(biāo)。

微服務(wù)之間應(yīng)該通過公開暴露的 API 進(jìn)行交互?；?HTTP 的通信可以選擇 REST、GraphQL、gRPC，或者也可以使用消息隊(duì)列，比如 RabbitMQ、Apache Kafka。

5. 結(jié)論

希望你們大部分人都很清楚上述的這些問題，不過肯定會(huì)有一些人犯下這些錯(cuò)誤，也許看了本文后你能學(xué)到一些。不管怎樣，在微服務(wù)這個(gè)新奇和多變的世界里犯點(diǎn)錯(cuò)誤是在所難免的。