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. 結論

 

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