حاکمیت داده در هر میکروسرویس

یک قانون مهم برای معماری میکروسرویس ها این است که هر میکروسرویس باید داده ها و منطق دامنه خود را داشته باشد. همانطور که یک برنامه کامل دارای منطق و داده های خود است، هر میکروسرویس نیز باید منطق و داده های خود را تحت یک چرخه حیات مستقل، با استقرار مستقل در هر میکروسرویس، داشته باشد.این بدان معنی است که مدل مفهومی دامنه بین زیرسیستم ها یا ریزسرویس ها متفاوت است. برنامه‌های کاربردی سازمانی را در نظر بگیرید، جایی که برنامه‌های مدیریت ارتباط با مشتری (CRM)، زیرسیستم‌های خرید معاملاتی، و زیرسیستم‌های پشتیبانی مشتری هر کدام ویژگی‌ها و داده‌های موجودیت مشتری منحصر به فرد را فراخوانی می‌کنند، و جایی که هر یک از یک زمینه محدود (BC) متفاوتی استفاده می‌کنند.این اصل در طراحی دامنه محور (DDD) مشابه است، که در آن هر زمینه محدود یا زیرسیستم یا سرویس مستقل باید مدل دامنه خود را داشته باشد (داده به علاوه منطق و رفتار). هر زمینه DDD Bounded با یک ریزسرویس تجاری (یک یا چند سرویس) مرتبط است. این نکته در مورد الگوی Bounded Context در بخش بعدی بسط داده می شود.از سوی دیگر، رویکرد سنتی (داده‌های یکپارچه) مورد استفاده در بسیاری از برنامه‌ها، داشتن یک پایگاه داده متمرکز یا فقط چند پایگاه داده است. این اغلب یک پایگاه داده SQL نرمال شده است که برای کل برنامه و همه زیرسیستم های داخلی آن، استفاده می شود.در رویکرد سنتی، یک پایگاه داده واحد وجود دارد که در همه سرویس‌ها به اشتراک گذاشته می‌شود، معمولاً در معماری لایه‌ای. در رویکرد میکروسرویس، هر میکروسرویس مدل/داده خود را دارد. رویکرد پایگاه داده متمرکز در ابتدا ساده‌تر به نظر می‌رسد و به نظر می‌رسد استفاده مجدد از موجودیت‌ها را در زیرسیستم‌های مختلف برای سازگار کردن همه چیز ممکن می‌سازد. اما واقعیت این است که شما در نهایت با جداول بزرگی مواجه می شوید که به بسیاری از زیرسیستم های مختلف خدمت می کنند و شامل ویژگی ها و ستون هایی هستند که در بیشتر موارد مورد نیاز نیستند. این مانند تلاش برای استفاده از نقشه فیزیکی مشابه برای پیاده روی در یک مسیر کوتاه، یک سفر یک روزه با ماشین و یادگیری جغرافیا است.یک برنامه یکپارچه با معمولاً یک پایگاه داده رابطه‌ای دو مزیت مهم دارد: تراکنش‌های ACID و زبان SQL که هر دو در تمام جداول و داده‌های مربوط به برنامه شما کار می‌کنند. این رویکرد راهی برای نوشتن آسان یک پرس و جو فراهم می کند که داده ها را از چندین جدول ترکیب می کند.با این حال، هنگامی که به معماری میکروسرویس می‌روید، دسترسی به داده‌ها بسیار پیچیده‌تر می‌شود. حتی در هنگام استفاده از تراکنش‌های ACID در یک میکروسرویس یا زمینه محدود، مهم است که در نظر داشته باشید که داده‌های متعلق به هر میکروسرویس برای آن میکروسرویس خصوصی است و فقط باید به صورت همزمان از طریق نقاط پایانی API آن (REST، gRPC، SOAP، و غیره) یا به صورت ناهمزمان از طریق پیام رسانی (AMQP یا مشابه).کپسوله کردن داده‌ها تضمین می‌کند که میکروسرویس‌ها به‌طور سست جفت شده‌اند و می‌توانند مستقل از یکدیگر تکامل یابند. اگر چندین سرویس به داده های مشابهی دسترسی داشتند، به روز رسانی طرحواره به به روز رسانی هماهنگ برای همه سرویس ها نیاز دارد. این امر استقلال چرخه حیات میکروسرویس را از بین می برد. اما ساختارهای داده توزیع شده به این معنی است که شما نمی توانید یک تراکنش ACID را در میان ریزسرویس ها انجام دهید. این به نوبه خود به این معنی است که شما باید از یکپارچگی نهایی استفاده کنید زمانی که یک فرآیند کسب و کار چندین میکروسرویس را در بر می گیرد. پیاده سازی این بسیار سخت تر از اتصالات SQL ساده است، زیرا نمی توانید محدودیت های یکپارچگی ایجاد کنید یا از تراکنش های توزیع شده بین پایگاه های داده جداگانه استفاده کنید، همانطور که در ادامه توضیح خواهیم داد. به طور مشابه، بسیاری از ویژگی های دیگر پایگاه داده رابطه ای در چندین میکروسرویس در دسترس نیستند.حتی فراتر از این، میکروسرویس های مختلف اغلب از انواع مختلفی از پایگاه داده استفاده می کنند. برنامه های کاربردی مدرن انواع مختلفی از داده ها را ذخیره و پردازش می کنند و پایگاه داده رابطه ای همیشه بهترین انتخاب نیست. برای برخی موارد استفاده، یک پایگاه داده NoSQL مانند Azure CosmosDB یا MongoDB ممکن است مدل داده راحت تری داشته باشد و عملکرد و مقیاس پذیری بهتری نسبت به پایگاه داده SQL مانند SQL Server یا پایگاه داده Azure SQL ارائه دهد. در موارد دیگر، پایگاه داده رابطه ای هنوز بهترین رویکرد است. بنابراین، برنامه های کاربردی مبتنی بر میکروسرویس ها اغلب از ترکیبی از پایگاه های داده SQL و NoSQL استفاده می کنند که گاهی اوقات به آن رویکرد پایداری چند زبانه می گویند.یک معماری پارتیشن بندی شده و پایدار چند زبانه برای ذخیره سازی داده ها مزایای زیادی دارد. اینها شامل خدمات با اتصال ضعیف و عملکرد بهتر، مقیاس پذیری، هزینه ها و مدیریت پذیری است. با این حال، می‌تواند برخی از چالش‌های مدیریت داده‌های توزیع‌شده را معرفی کند، همانطور که در «شناسایی مرزهای مدل دامنه» بعداً در این فصل توضیح داده شد.رابطه بین میکروسرویس ها و الگوی زمینه محدودمفهوم میکروسرویس از الگوی زمینه محدود (BC) در طراحی دامنه محور (DDD) ناشی می شود. DDD با مدل‌های بزرگ با تقسیم آن‌ها به چندین BC و مشخص کردن مرزهایشان سر و کار دارد. هر BC باید مدل و پایگاه داده خود را داشته باشد. به همین ترتیب، هر میکروسرویس دارای داده های مربوط به خود است. علاوه بر این، هر BC معمولاً زبان همه جا حاضر خود را دارد تا به ارتباط بین توسعه دهندگان نرم افزار و کارشناسان دامنه کمک کند.آن عبارات (عمدتاً موجودیت‌های دامنه) در زبان فراگیر می‌توانند نام‌های متفاوتی در زمینه‌های محدود متفاوت داشته باشند، حتی زمانی که موجودیت‌های دامنه‌های مختلف هویت یکسانی دارند (یعنی شناسه منحصربه‌فردی که برای خواندن موجودیت از ذخیره‌سازی استفاده می‌شود). به عنوان مثال، در یک زمینه Bounded پروفایل کاربر، موجودیت دامنه کاربر ممکن است هویت خود را با موجودیت دامنه خریدار در زمینه Bounded سفارش دهنده به اشتراک بگذارد.بنابراین یک میکروسرویس مانند یک زمینه محدود است، اما همچنین مشخص می کند که یک سرویس توزیع شده است. این به عنوان یک فرآیند جداگانه برای هر زمینه محدود ساخته شده است، و باید از پروتکل های توزیع شده استفاده کند، مانند HTTP/HTTPS، WebSockets، یا AMQP. با این حال، الگوی Bounded Context مشخص نمی کند که آیا Bounded Context یک سرویس توزیع شده است یا اینکه صرفاً یک مرز منطقی (مانند یک زیر سیستم عمومی) در یک برنامه کاربردی یکپارچه است.مهم است که تاکید کنیم که تعریف یک سرویس برای هر زمینه محدود نقطه خوبی برای شروع است. اما لازم نیست طراحی خود را به آن محدود کنید. گاهی اوقات شما باید یک زمینه محدود یا یک میکروسرویس تجاری متشکل از چندین سرویس فیزیکی طراحی کنید. اما در نهایت، هر دو الگو -Bounded Context و microservice- ارتباط نزدیکی با هم دارند.DDD با بدست آوردن مرزهای واقعی در قالب ریزسرویس های توزیع شده از میکروسرویس ها سود می برد. اما ایده هایی مانند به اشتراک گذاری نکردن مدل بین میکروسرویس ها همان چیزی است که شما نیز در یک زمینه محدود می خواهید.