[[285134]]

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

1. 映射服務

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

如果你走到了這一步，很可能是因為你需要在服務 A 和服務 B 之間映射 DTO，因為服務 A 和服務 B 需要不同的 DTO，但它們之間又相互依賴。出于對微服務的“熱愛”，你嘗試著解耦這兩個服務，于是你創建了服務 C。服務 C 接收 JSON 數據，并把稍微處理后的數據返回，其他什么事也不做。

現在，你的三個服務都耦合在一起了。DTO 到 DTO 的映射應該發生在進程內部，否則的話，可能會有人創建出新的服務來映射服務 A 和服務 C 之間的 DTO。除非服務 C 不會往實體中添加新數據，否則它的存在就不是必要的。一個服務應該只返回它所擁有的數據。

同樣，你會為了給一組數字排序而專門創建一個服務嗎？

2. 靜態內容的映射服務

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

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

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

3. 將應用程序的配置托管在遠程服務上

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

4. 多個服務共享一個數據庫

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

這樣做有悖微服務架構的原則，因為微服務應該是獨立且自包含的。它們應該擁有自己的數據，并可以完全自由決定該怎么持久化數據。它們存在的目的是為了解耦，為了獲得這種靈活性，需要付出一定的代價，但追求靈活性應該成為你的目標。

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

5. 結論

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