我需要微服務嗎？

Question

我正在學習微服務架構，對我來說應該何時將某個功能包裝到微服務中以及何時最好將其保留在單獨的組件中並將組件安裝在相關的微服務中，這對於我來說還不清楚。

例子：

1. Symfony安全ACL組件（ symfony/security-acl ）。 我可以將其包裝到微服務中，該服務僅在Symfony Security ACL API頂部以REST API的形式添加抽象層。 除此之外，我將需要一個服務代理組件，該組件將安裝在相關的微服務上並提供對ACL微服務的訪問。 重點是什么？ 在需要的地方安裝symfony/security-acl並為其提供單獨的數據庫連接是否更容易？

2. 支付系統。 在這種情況下，很顯然它需要包裝到微服務中。 它包含大量的業務邏輯，它們只是要求分離。

基本上，問題是：

1. 在決定將軟件放在微服務中而不是模塊中時，應該考慮什么標准？

2. 將symfony/security-acl包裝到一個非常瘦的微服務中是一個好主意嗎（使微服務變瘦不是很好）嗎？

Answer 1

根據我的經驗，微服務的非官方，非科學原因：

• 橫向可伸縮性 ：如果您的服務不能平均擴展，則可能需要讓10台服務器使用服務A，而只有1台服務器使用服務B。
• 更快的部署 ：每個服務具有單獨的部署過程，使您可以按需部署較小的部分，而不是僅因微小的更改而部署大的項目。
• 獨立的開發風格和生命周期 ：當項目變大時，您可能希望讓其他人接手。 對於具有比模塊更少依賴性的微服務，這顯然更好地工作。 貢獻者和團隊可以隨心所欲發展自己的需求。 每個團隊可以使用不同的語言，不同的管道，測試工具，編輯器等。唯一的共同點是所得API的格式，協議和約定。
• 更簡單的依賴關系管理 ：升級或更改依賴於其他庫的庫可能會導致復雜化，因為顯然並非所有依賴關系都將同時更新，並且會出現不兼容的情況。
• 更清晰的API ：記錄所有公共類和函數可能是一場噩夢。 另一方面，具有不完整或過時文檔的API是放棄項目的原因。 在這方面，微服務沒有提供任何現成的東西，但是接口被明確定義，通常被定義為URL端點和HTTP方法。 如果您遵循REST范例，這將變得更加容易。

在您的特定情況下，很難說要使用什么，因為您沒有提供足夠的上下文。 一些相關的問題：

• 您正在與團隊一起發展嗎？
• 這是框架的一部分嗎？
• 模塊的依賴性是什么？
• 它在設計時考慮了並行訪問數據庫嗎？