[[285134]]

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

1. 映射服務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 結(jié)論

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