我嘗試開發微服務應用程式。在查看微服務的大部分文章時，每個微服務都有兩層（前端和存盤庫層）。通常如果開發單體應用程式 API 層結構，如
Rest API Controller(Like API Frontend) <-> Business Logic <-> Repository Layer(Data Access Layer)
當談到微服務時，每個微服務都有兩層
Rest API Controller(Like API Frontend) <-> Repository Layer(Data Access Layer)
做簡單的 CRUD 應用程式很好。假設來復雜的業務邏輯應用。我應該在哪里實作復雜的業務邏輯？
uj5u.com熱心網友回復：
微服務與每個應用程式有多少層無關，或者實際上與它們的實作方式無關。它們更多地是關于清晰、
微服務應用程式不共享資料庫，而是通過 HTTP 相互通信以進行同步，或者通過某種事件技術（Kafka、訊息佇列等）進行異步通信。
這些應用程式中的每一個都可能以復雜的方式實作或具有復雜的要求，但這并不是使它們成為微服務的原因。
因此，對于您的問題-您的實施在這里不那么重要。如果這是您喜歡的模式，您仍然可以擁有服務/存盤庫，或者 CQRS 模式也可以很好地作業，這與邊界、通信和狀態管理的核心原則無關緊要。
注意：因此，微服務會帶來開銷。你需要遵守 API 和訊息的合同，你需要確保你不會重新發明輪子，團隊需要有效地相互協作。它們在更大的規模上運行良好，并且肯定會推廣一種部署模型，該模型允許您使用盡可能多的計算，但有時它們會由于依賴管理而減慢您的速度。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/508242.html
標籤：休息 asp.net 核心 asp.net-web-api 微服务
上一篇：干凈的架構-擴展的地方