Database per Service در مقابل Shared Database
در الگوی Database per Service هر میکروسرویس دیتابیس اختصاصی خودش را دارد و هیچ سرویس دیگری مستقیماً به آن دسترسی ندارد که استقلال کامل میدهد، در حالی که در Shared Database چند سرویس از یک دیتابیس مشترک استفاده میکنند که سادهتر است اما استقلال و مرزبندی واقعی بین سرویسها را از بین میبرد.
| ویژگی | Database per Service | Shared Database |
|---|---|---|
| استقلال سرویسها | کامل | ضعیف |
| سادگی اولیه پیادهسازی | پیچیدهتر | سادهتر |
| ریسک اثر تغییر اسکیما | محدود به یک سرویس | کل سیستم |
کِی از Database per Service استفاده کنیم؟
همیشه بهعنوان اصل پایه معماری میکروسرویس توصیه میشود؛ هر سرویس باید بتواند مستقل از بقیه توسعه، دیپلوی و مقیاسدهی شود.
کِی از Shared Database استفاده کنیم؟
فقط در مرحله انتقال تدریجی از یک Monolith به میکروسرویس (Strangler Pattern) و بهصورت موقت قابل قبول است.
مثال Database per Service
OrderService -> OrderDb (اختصاصی)
InventoryService -> InventoryDb (اختصاصی)
# ارتباط فقط از طریق API یا Event
مثال Shared Database
OrderService ->InventoryService -> SharedDb (یک دیتابیس)
PaymentService ->/
# تغییر اسکیمای یک سرویس بقیه را میشکند
اشتباه رایج
اشتباه رایج نگهداشتن Shared Database «موقت» برای مدت طولانی بدون برنامه مهاجرت است؛ این کار عملاً همان مشکلات Monolith (تغییر اسکیما همهجا اثر میگذارد) را در ظاهر یک معماری میکروسرویس بازتولید میکند.
جمعبندی
برای معماری میکروسرویس واقعی و مستقل همیشه Database per Service را هدف بگیرید؛ Shared Database فقط بهعنوان یک راهحل موقت و گذرا قابل قبول است.