الگوهای معامله توزیع شده برای میکروسرویس ها مقایسه شده است

من به عنوان یک معمار مشاوره در Red Hat ، این افتخار را داشتم که روی لژیونهای پروژه های مشتری کار کنم. هر مشتری چالش های خاص خود را به وجود می آورد اما من برخی از مشترکات را پیدا کردم. یک مورد که بیشتر مشتریان می خواهند بدانند نحوه هماهنگی نوشتن با بیش از یک سیستم ضبط است. پاسخ دادن به این سؤال به طور معمول شامل توضیحات طولانی در مورد نوشتن های دوگانه ، معاملات توزیع شده ، گزینه های مدرن و سناریوهای شکست احتمالی و اشکالاتی از هر رویکرد است. به طور معمول ، این لحظه ای است که مشتری متوجه می شود که تقسیم یک برنامه یکپارچه به میکروسرویس یک سفر طولانی و پیچیده است و معمولاً به تجارت نیاز دارد.

این مقاله به جای پایین آمدن از خرگوش در مورد بحث در مورد معاملات به طور عمیق ، خلاصه رویکردها و الگوهای اصلی برای هماهنگی نوشتن به منابع متعدد است. من می دانم که شما ممکن است تجربه های گذشته خوب یا بد را با یک یا چند مورد از این رویکردها داشته باشید. اما در عمل ، در متن مناسب و با محدودیت های مناسب ، همه این روش ها خوب کار می کنند. منجر به انتخاب بهترین رویکرد برای زمینه خود می شود.

توجه: اگر به نوشتن دوگانه علاقه دارید ، جلسه Red Hat Summit 2021 را تماشا کنید ، جایی که من به طور عمیق چالش های نوشتن دوگانه را پوشش دادم. همچنین می توانید از طریق اسلایدها از ارائه من استفاده کنید. در حال حاضر ، من با Red Hat OpenShift Streams برای Apache Kafka ، یک سرویس کاملاً مدیریت شده Apache Kafka درگیر هستم. کمتر از یک دقیقه شروع می شود و در طول دوره آزمایشی کاملاً رایگان است. آن را امتحان کنید و به ما کمک کنید تا با بازخورد اولیه خود آن را شکل دهیم. اگر در مورد این مقاله سؤال یا نظری دارید ، در توییتر Bibryam به من ضربه بزنید و اجازه دهید شروع کنیم.

مشکل نوشتن دوگانه

نشانگر واحد که ممکن است مشکل نوشتن دوگانه داشته باشید ، نیاز به نوشتن بیش از یک سیستم ضبط به طور قابل پیش بینی است. این نیاز ممکن است آشکار نباشد و می تواند خود را به روش های مختلفی در فرآیند طراحی سیستم های توزیع شده بیان کند. مثلا:

• شما بهترین ابزارها را برای هر کار انتخاب کرده اید و اکنون باید یک پایگاه داده NOSQL ، یک فهرست جستجو و حافظه پنهان را به عنوان بخشی از یک معامله تجاری واحد به روز کنید.
• خدمتی که شما طراحی کرده اید باید پایگاه داده خود را به روز کند و همچنین یک اعلان را به سرویس دیگری در مورد تغییر ارسال کند.
• شما معاملات تجاری دارید که چندین مرز خدمات را شامل می شود.
• ممکن است شما مجبور شوید عملیات خدماتی را به عنوان idempotent پیاده سازی کنید زیرا مصرف کنندگان مجبورند دوباره دعوت های ناموفق را دوباره امتحان کنند.

برای این مقاله ، ما از یک سناریوی نمونه واحد برای ارزیابی رویکردهای مختلف برای رسیدگی به نویسندگان دوگانه در معاملات توزیع شده استفاده خواهیم کرد. سناریوی ما یک برنامه مشتری است که در یک عملیات جهش دهنده از یک میکروسرویس استفاده می کند. سرویس A باید پایگاه داده خود را به روز کند ، اما همچنین باید سرویس B را در یک عملیات نوشتن فراخوانی کند ، همانطور که در شکل 1 نشان داده شده است. نوع واقعی بانک اطلاعاتی ، پروتکل تعامل خدمات به سرویس ، برای بحث ما بی ربط استاز آنجا که مشکل یکسان است.

شکل 1: مشکل نوشتن دوگانه در میکروسرویس.

یک توضیح کوچک اما مهم توضیح می دهد که چرا هیچ راه حل ساده ای برای این مشکل وجود ندارد. اگر سرویس A به پایگاه داده خود می نویسد و سپس یک اعلان را به صف سرویس B ارسال می کند (بگذارید آن را یک رویکرد محلی-پس از آن منتشر کنیم)) ، هنوز هم فرصتی وجود دارد که برنامه به طور قابل اعتماد کار نخواهد کرد. در حالی که سرویس A به پایگاه داده خود می نویسد و سپس پیام را به یک صف ارسال می کند ، احتمال کمی از برنامه در حال خراب شدن پس از تعهد به پایگاه داده و قبل از عملیات دوم وجود دارد که این سیستم را در حالت متناقض قرار می دهد. اگر پیام قبل از نوشتن به پایگاه داده ارسال شود (بیایید این رویکرد را منتشر کنیم-به عنوان-کابین-تعهد) ، امکان نوشتن بانک اطلاعاتی وجود دارد که در آن موارد عدم موفقیت یا زمان بندی وجود دارد که در آن سرویس B قبل از سرویس A دریافت کرده است قبل از سرویس A ، تغییر در تغییر خود را انجام داده است. بانک اطلاعاتیدر هر صورت ، این سناریو شامل نوشتن دوگانه به یک پایگاه داده و یک صف است که این مشکل اصلی است که ما می خواهیم آن را کشف کنیم. در بخش های بعدی ، من در مورد رویکردهای مختلف اجرای امروز برای این چالش همیشه ارائه می دهم.

یکپارچه مدولار

توسعه برنامه شما به عنوان یک یکپارچه مدولار ممکن است به نظر برسد هک یا به عقب در تکامل معماری ، اما من دیده ام که در عمل خوب کار می کند. این یک الگوی میکروسرویس نیست بلکه یک استثناء در قانون میکروسرویس است که می تواند با احتیاط با میکروسرویس ها ترکیب شود. هنگامی که قوام نوشتن قوی نیاز به رانندگی است ، حتی از توانایی استقرار و مقیاس میکروسرویس به طور مستقل ، مهمتر است ، می توانید با معماری یکپارچه مدولار بروید.

داشتن یک معماری یکپارچه به معنای این نیست که سیستم ضعیف یا بد طراحی شده است. در مورد کیفیت چیزی نمی گوید. همانطور که از نام آن پیداست ، این سیستمی است که به روشی مدولار با دقیقاً یک واحد استقرار طراحی شده است. توجه داشته باشید که این یک مونولیت مدولار هدفمند و پیاده سازی شده است ، که با یک یکپارچه به طور تصادفی ایجاد شده است که با گذشت زمان رشد می کند. در یک معماری یکپارچه ماژولار هدفمند ، هر ماژول از اصول میکروسرویس پیروی می کند. هر ماژول تمام دسترسی به داده های خود را محاصره می کند ، اما این عملیات به عنوان تماس با روش حافظه در معرض و مصرف قرار می گیرد.

معماری یک یکپارچه مدولار

با این رویکرد ، شما باید هر دو میکروسرویس (سرویس A و سرویس B) را به ماژول های کتابخانه ای تبدیل کنید که می توانند در یک زمان مشترک مشترک مستقر شوند. سپس می توانید هر دو میکروسرویس را به عنوان نمونه پایگاه داده به اشتراک بگذارید. از آنجا که این سرویس ها به عنوان کتابخانه در یک زمان اجرا مشترک نوشته و مستقر شده اند ، می توانند در همان معاملات شرکت کنند. از آنجا که ماژول ها یک نمونه بانک اطلاعاتی را به اشتراک می گذارند ، می توانید از یک معامله محلی برای ارتکاب یا بازپرداخت همه تغییرات به طور همزمان استفاده کنید. همچنین در مورد روش استقرار تفاوت هایی وجود دارد زیرا ما می خواهیم ماژول ها به عنوان کتابخانه در یک استقرار بزرگتر مستقر شوند و در معاملات موجود شرکت کنند.

حتی در یک معماری یکپارچه ، روش هایی برای جداسازی کد و داده ها وجود دارد. به عنوان مثال ، می توانید ماژول ها را در بسته های جداگانه ، ساخت ماژول ها و مخازن کد منبع ، که می تواند متعلق به تیم های مختلف باشد ، جدا کنید. شما می توانید با گروه بندی جداول با نامگذاری کنوانسیون ، طرح ها ، نمونه های پایگاه داده یا حتی توسط سرورهای پایگاه داده ، جداسازی داده های جزئی انجام دهید. نمودار در شکل 2 ، با الهام از گفتگوی Axel Fontaine در مورد یکپارچه های ماژولار با شکوه ، سطح مختلف کد و داده های مختلف را در برنامه ها نشان می دهد.

شکل 2: سطح کد و جداسازی داده ها برای برنامه ها.

آخرین قطعه از معما استفاده از زمان اجرا و یک سرویس بسته بندی است که قادر به مصرف ماژول های دیگر و از جمله آنها در زمینه معامله موجود است. همه این محدودیت ها ماژول ها را محکم تر از میکروسروس های معمولی می سازند ، اما فایده این است که سرویس بسته بندی می تواند یک معامله را شروع کند ، از ماژول های کتابخانه برای به روزرسانی پایگاه داده های خود استفاده کند ، و بدون نگرانی در مورد یک عملیات ، به عنوان یک عملیات متعهد یا عقب نشینی کند. شکست جزئی یا قوام نهایی.

در مثال ما ، که در شکل 3 نشان داده شده است ، ما خدمات A و سرویس B را به کتابخانه ها تبدیل کرده ایم و آنها را به یک زمان مشترک اعزام کرده ایم ، یا یکی از خدمات می تواند به عنوان زمان مشترک عمل کند. جداول پایگاه داده ها همچنین یک نمونه بانک اطلاعاتی واحد را به اشتراک می گذارند ، اما به عنوان گروهی از جداول که توسط خدمات کتابخانه مربوطه اداره می شوند ، از هم جدا می شوند.

شکل 3: یکپارچه مدولار با یک پایگاه داده مشترک.

مزایا و اشکال یکپارچه مدولار

در برخی از صنایع ، معلوم می شود که مزایای این معماری بسیار مهمتر از تحویل سریعتر و سرعت تغییر است که در جاهای دیگر بسیار ارزشمند است. جدول 1 مزایا و اشکال معماری یکپارچه مدولار را خلاصه می کند.

• یک زمان اجرا مشترک مانع از استقرار و مقیاس گذاری ماژول های مستقل ما می شود و از انزوا عدم موفقیت جلوگیری می کند.
• جداسازی منطقی جداول در یک پایگاه داده واحد قوی نیست. با گذشت زمان ، می تواند به یک لایه ادغام مشترک تبدیل شود.
• زمینه اتصال و اشتراک ماژول نیاز به هماهنگی در مرحله توسعه دارد و اتصال بین خدمات را افزایش می دهد.

• زمان هایی مانند Apache Karaf و Wildfly که امکان استقرار ماژولار و پویا خدمات را فراهم می کند.
• مؤلفه های مستقیم و مستقیم VM آپاچی شتر اجازه می دهد تا عملیات را برای دعوت های داخل حافظه در معرض دید قرار داده و زمینه های معامله را در یک فرآیند JVM حفظ کنند.
• Apache Isis یکی از بهترین نمونه های معماری یکپارچه مدولار است. این امکان را برای توسعه برنامه های دامنه محور با تولید خودکار API UI و REST برای برنامه های بوت بهار شما فراهم می کند.
• Apache of Biz نمونه دیگری از یک یکپارچه ماژولار و معماری خدمات گرا (SOA) است. این یک سیستم جامع برنامه ریزی منابع سازمانی با صدها جدول و خدمات است که می تواند فرآیندهای تجاری شرکت را خودکار کند. با وجود اندازه آن ، معماری مدولار آن به توسعه دهندگان اجازه می دهد تا آن را به سرعت درک و سفارشی کنند.

معاملات توزیع شده به طور معمول آخرین راه حل است که در موارد مختلف مورد استفاده قرار می گیرد:

• هنگامی که می نویسد برای منابع متفاوت نمی تواند در نهایت سازگار باشد.
• هنگامی که ما باید برای منابع داده ناهمگن بنویسیم.
• در صورت نیاز به پردازش پیام دقیقاً یکپارچه و ما نمی توانیم یک سیستم را مجدداً مورد استفاده قرار دهیم و عملیات آن را غیرممکن کنیم.
• هنگام ادغام با سیستم های شخص ثالث جعبه سیاه یا سیستم های میراث که مشخصات متعهد دو فاز را اجرا می کنند.

در تمام این شرایط ، هنگامی که مقیاس پذیری نگران کننده نیست ، ممکن است معاملات توزیع شده را گزینه ای در نظر بگیریم.

اجرای معماری متعهد دو فاز

الزامات فنی برای تعهد دو فاز این است که شما به یک مدیر معامله توزیع شده مانند Narayana و یک لایه ذخیره سازی قابل اعتماد برای سیاهههای مربوط به معاملات نیاز دارید. شما همچنین به منابع داده سازگار با DTP XA با درایورهای XA همراه نیاز دارید که قادر به شرکت در معاملات توزیع شده مانند RDBMS ، کارگزاران پیام و انبارها هستند. اگر خوش شانس هستید که از منابع داده مناسب برخوردار هستید اما در یک محیط پویا مانند Kubeetes اجرا می شوید ، برای اطمینان از وجود تنها یک نمونه واحد از مدیر معامله توزیع شده ، به یک مکانیسم شبیه به اپراتور نیز نیاز دارید. مدیر معامله باید بسیار در دسترس باشد و همیشه باید به گزارش معامله دسترسی داشته باشد.

برای اجرای ، می توانید یک کنترلر بازیابی Snowdrop را که از الگوی kubeetes stayfulset برای اهداف تک و حجم مداوم برای ذخیره سیاهههای معامله استفاده می کند ، کشف کنید. در این گروه ، من همچنین مشخصاتی از قبیل خدمات وب معامله اتمی (WS-AtomicTransaction) را برای خدمات وب SOAP درج می کنم. آنچه همه این فناوری ها با هم مشترک هستند این است که آنها مشخصات XA را پیاده سازی می کنند و یک هماهنگ کننده معاملات مرکزی دارند.

در مثال ما ، در شکل 4 نشان داده شده است ، سرویس A از معاملات توزیع شده برای انجام همه تغییرات در پایگاه داده خود و پیام به صف استفاده می کند بدون اینکه فرصتی برای نسخه های تکراری یا پیام های گمشده باقی بماند. به همین ترتیب ، سرویس B می تواند از معاملات توزیع شده برای مصرف پیام ها و تعهد به پایگاه داده B در یک معامله واحد و بدون هیچ نسخه ای استفاده کند. یا ، سرویس B می تواند از معاملات توزیع شده استفاده نکند ، بلکه از معاملات محلی استفاده کرده و الگوی مصرف کننده Idempotent را پیاده سازی کرده است. برای ضبط ، یک مثال مناسب تر برای این بخش استفاده از WS-atomictransaction برای هماهنگی نوشتن به پایگاه داده A و پایگاه داده A در یک معامله واحد و جلوگیری از سازگاری نهایی است. اما این رویکرد این روزها حتی کمتر از آنچه توضیح دادم متداول است.

شکل 4: متعهد دو فاز بین یک پایگاه داده و یک کارگزار پیام.

مزایا و اشکال معماری دو فاز

پروتکل تعهد دو فاز ضمانت های مشابهی را برای معاملات محلی در رویکرد یکپارچه مدولار ارائه می دهد ، اما با چند استثنا. از آنجا که دو یا چند منبع داده جداگانه در یک به روزرسانی اتمی وجود دارد ، ممکن است به روشی متفاوت شکست بخورد و معامله را مسدود کند. اما به لطف هماهنگ کننده اصلی آن ، کشف وضعیت سیستم توزیع شده در مقایسه با سایر رویکردهایی که در مورد آنها بحث خواهم کرد ، آسان است.

جدول 2 مزایا و اشکالات این رویکرد را خلاصه می کند.

• رویکرد مبتنی بر استاندارد با مدیران معامله خارج از جعبه و پشتیبانی از منابع داده.
• قوام داده های قوی برای سناریوهای شاد.

• محدودیت های مقیاس پذیری.
• هنگام عدم موفقیت مدیر معامله ، شکست های احتمالی بهبود می یابد.
• پشتیبانی منبع داده محدود.
• نیازهای ذخیره سازی و مجرد در محیط های پویا.

• API معاملات جاکارتا (قبلاً API معامله جاوا)
• WS-atomicTranscame
• JTS/IIOP
• Ebay's Grit
• تتومیکوس
• نارایانا
• کارگزاران پیام مانند Apache ActiveMQ
• منابع داده رابطه ای که مشخصات XA را اجرا می کنند ، فروشگاه های داده های حافظه مانند Infinispan

تنظیم و ارکستراسیون

با یک یکپارچه ماژولار ، ما از معاملات محلی استفاده می کنیم و همیشه وضعیت سیستم را می شناسیم. با معاملات توزیع شده بر اساس پروتکل تعهد دو فاز ، ما همچنین یک حالت ثابت را تضمین می کنیم. تنها استثناء یک شکست غیرقابل برگشت است که شامل هماهنگ کننده معامله است. اما اگر بخواهیم الزامات سازگاری را در حالی که هنوز وضعیت سیستم توزیع شده کلی و هماهنگی از یک مکان واحد را می دانیم ، کاهش دهیم؟در این حالت ، ما ممکن است یک رویکرد ارکستراسیون را در نظر بگیریم ، جایی که یکی از خدمات به عنوان هماهنگ کننده و ارکستر تغییر کلی دولت توزیع شده عمل می کند. سرویس ارکستراتور وظیفه دارد تا زمان رسیدن به وضعیت مورد نظر ، با سایر خدمات تماس بگیرد یا در صورت عدم موفقیت اقدامات اصلاحی انجام دهد. ارکستر از پایگاه داده محلی خود برای پیگیری تغییرات حالت استفاده می کند و این مسئولیت بازیابی هرگونه خرابی مربوط به تغییرات حالت را بر عهده دارد.

اجرای معماری ارکستراسیون

محبوب ترین پیاده سازی تکنیک ارکستراسیون ، پیاده سازی مشخصات BPMN مانند پروژه های JBPM و Camunda است. نیاز به چنین سیستمهایی با معماری های بیش از حد توزیع شده مانند میکروسرویس یا بدون سرور ناپدید نمی شود. در مقابل ، افزایش می یابد. برای اثبات ، ما می توانیم به موتورهای ارکستراسیون حالت جدیدتر که از مشخصات خود پیروی نمی کنند ، نگاه کنیم اما رفتارهای مشابهی را ارائه می دهیم ، مانند هادی Netflix ، Cadence Uber و جریان هوا Apache. توابع بدون سرور مانند عملکردهای آمازون ، عملکردهای با دوام لاجورد و برنامه های Azure Logic نیز در این گروه قرار دارند. همچنین کتابخانه های منبع باز وجود دارد که به شما امکان می دهد هماهنگی های حالت و رفتارهای برگشت پذیر مانند اجرای الگوی حماسه Apache Camel و قابلیت حماسه NServiceBus را اجرا کنید. بسیاری از سیستم های خانگی که الگوی حماسه را اجرا می کنند نیز در این گروه قرار دارند.

شکل 5: معاملات توزیع شده ارکستر بین دو سرویس.

در نمودار مثال ما ، که در شکل 5 نشان داده شده است ، ما به عنوان ارکستر مطبوع که وظیفه دارد با سرویس B تماس بگیرد و از طریق خرابی از طریق یک عمل جبران کننده در صورت لزوم ، از خدمات استفاده کنیم ، خدمت می کنیم. ویژگی مهم این رویکرد این است که سرویس A و سرویس B دارای مرزهای معامله محلی هستند ، اما خدمات A دانش و مسئولیت ارکستر جریان تعامل کلی را دارد. به همین دلیل مرز معامله آن نقاط پایانی سرویس B را لمس می کند. از نظر اجرای ، ما می توانیم این کار را با فعل و انفعالات همزمان ، همانطور که در نمودار نشان داده شده است ، یا با استفاده از صف پیام در بین خدمات تنظیم کنیم (در این صورت می توانید از یک تعهد دو فاز نیز استفاده کنید).

مزایا و اشکال ارکستراسیون

ارکستراسیون یک رویکرد در نهایت سازگار است که ممکن است شامل احیای مجدد و بازپرداخت برای توزیع به یک حالت ثابت باشد. در حالی که از نیاز به معاملات توزیع شده جلوگیری می کند ، ارکستراسیون به خدمات شرکت کننده نیاز دارد تا در صورتی که هماهنگ کننده مجبور به آزمایش مجدد عملیات باشد ، عملیات IDEMPotent را ارائه دهد. خدمات شرکت کننده همچنین باید در صورتی که هماهنگ کننده تصمیم به عقب نشینی و رفع وضعیت جهانی بگیرد ، نقاط پایانی بازیابی را ارائه دهد. مزیت بزرگ این رویکرد توانایی هدایت خدمات ناهمگن است که ممکن است با استفاده از تنها معاملات محلی ، معاملات توزیع شده را به حالت سازگار پشتیبانی نکنند. هماهنگ کننده و خدمات شرکت کننده فقط به معاملات محلی نیاز دارند و همیشه می توان با درخواست هماهنگ کننده وضعیت سیستم را کشف کرد ، حتی اگر در یک وضعیت جزئی سازگار باشد. انجام این کار با رویکردهای دیگر که من توصیف خواهم کرد امکان پذیر نیست.

• مختصات در بین مؤلفه های توزیع شده ناهمگن.
• نیازی به معاملات XA نیست.
• وضعیت توزیع شده شناخته شده در سطح هماهنگ کننده.

• مدل برنامه نویسی توزیع شده پیچیده.
• ممکن است نیاز به idempotency و جبران عملیات از خدمات شرکت کننده داشته باشد.
• قوام نهایی
• احتمالاً شکست های غیرقابل برگشت در هنگام جبران خسارت.

• jbpm
• کاموندا
• اقدامات طولانی مدت در حال اجرا
• رهبر ارکستر
• آهنگ و ریتم
• توابع پله
• توابع بادوام
• اجرای الگوی حماسه Apache Camel
• اجرای الگوی حماسه nservicebus
• مشخصات گردش کار بدون سرور CNCF
• پیاده سازی های خانگی

رقص رقص

همانطور که تاکنون در بحث مشاهده کرده اید ، یک عملیات تجاری واحد می تواند منجر به تماس های متعدد در بین خدمات شود و می تواند قبل از پردازش یک معامله تجاری ، مدت زمان مشخصی را انجام دهد. برای مدیریت این کار ، الگوی ارکستراسیون از یک سرویس کنترل کننده متمرکز استفاده می کند که به شرکت کنندگان می گوید چه کاری انجام دهند.

یک جایگزین برای ارکستراسیون، رقص است، که سبکی از هماهنگی خدمات است که در آن شرکت کنندگان رویدادها را بدون یک نقطه کنترل متمرکز مبادله می کنند. با این الگو، هر سرویس یک تراکنش محلی را انجام می دهد و رویدادهایی را منتشر می کند که تراکنش های محلی را در سرویس های دیگر راه اندازی می کنند. هر یک از اجزای سیستم به جای تکیه بر یک نقطه کنترل مرکزی، در تصمیم گیری در مورد گردش کار یک معامله تجاری شرکت می کند. از لحاظ تاریخی، رایج ترین پیاده سازی برای رویکرد رقص استفاده از یک لایه پیام رسانی ناهمزمان برای تعاملات سرویس بود. شکل 6 معماری اصلی الگوی رقص را نشان می دهد.

شکل 6: طراحی رقص سرویس از طریق یک لایه پیام.

رقص با نوشتن دوگانه

برای اینکه طراحی رقص مبتنی بر پیام کار کند، ما به هر سرویس مشارکت کننده نیاز داریم تا یک تراکنش محلی را اجرا کند و با انتشار یک فرمان یا رویداد در زیرساخت پیام، سرویس بعدی را راه اندازی کند. به طور مشابه، سایر خدمات شرکت کننده باید یک پیام را مصرف کرده و یک تراکنش محلی را انجام دهند. این به خودی خود یک مشکل نوشتن دوگانه در یک مشکل نوشتن دوگانه سطح بالاتر است. هنگامی که یک لایه پیام با نوشتن دوگانه برای پیاده سازی رویکرد رقص ایجاد می کنیم، می توانیم آن را به عنوان یک تعهد دو مرحله ای طراحی کنیم که یک پایگاه داده محلی و یک کارگزار پیام را در بر می گیرد. من قبلاً به آن رویکرد پرداختم. از طرف دیگر، ممکن است از الگوی انتشار-سپس-لوکال-متعهد یا تعهد-سپس-انتشار محلی استفاده کنیم:

• Publish- then-local-commit : می توانیم سعی کنیم ابتدا یک پیام منتشر کنیم و سپس یک تراکنش محلی را انجام دهیم. اگرچه این گزینه ممکن است خوب به نظر برسد، اما چالش های عملی دارد. به عنوان مثال، اغلب شما نیاز به انتشار یک شناسه دارید که از تعهد تراکنش محلی ایجاد شده است، که برای انتشار در دسترس نخواهد بود. همچنین، تراکنش محلی ممکن است با شکست مواجه شود، اما ما نمی توانیم پیام منتشر شده را برگردانیم. این رویکرد فاقد معناشناسی خواندنی-نوشتن است و راه حلی غیرعملی برای اکثر موارد استفاده است.
• محلی-کمپارچه-بعد منتشر شده: یک رویکرد کمی بهتر این است که ابتدا مرتکب معامله محلی شوید و سپس پیام را منتشر کنید. این احتمال کمی از عدم موفقیت پس از انجام معامله محلی و قبل از انتشار پیام دارد. اما حتی در این حالت ، شما می توانید خدمات خود را طراحی کنید تا idempotent باشید و عملیات را دوباره امتحان کنید. این به معنای ارتکاب دوباره معامله محلی و سپس انتشار پیام است. اگر شما مصرف کنندگان پایین دست را کنترل کنید ، این روش می تواند کار کند و می تواند آنها را نیز IDEMPOTION کند. همچنین به طور کلی گزینه اجرای بسیار خوبی است.

رقص رقص بدون نوشتن دوگانه

روشهای مختلف اجرای معماری رقص ، هر سرویس را محدود می کند تا فقط با یک منبع داده واحد با یک معامله محلی و در هیچ جای دیگر بنویسد. بیایید ببینیم که چگونه می تواند بدون نوشتن دوگانه کار کند.

بیایید بگوییم سرویس A درخواست دریافت می کند و آن را به پایگاه داده A و در هیچ جای دیگر می نویسد. سرویس B به طور دوره ای خدمات A را رأی می دهد و تغییرات جدید را تشخیص می دهد. هنگامی که این تغییر را می خواند ، سرویس B پایگاه داده خود را با تغییر و همچنین شاخص یا زمان بندی که در آن تغییرات را انتخاب کرده است ، به روز می کند. بخش مهم در اینجا این واقعیت است که هر دو سرویس فقط به پایگاه داده خود می نویسند و با یک معامله محلی متعهد می شوند. این رویکرد ، که در شکل 7 نشان داده شده است ، می تواند به عنوان رقص خدمات توصیف شود ، یا می توانیم آن را با استفاده از اصطلاحات خوب خط لوله داده قدیمی توصیف کنیم. گزینه های اجرای احتمالی جالب تر است.

شکل 7: رقص خدمات از طریق نظرسنجی.

ساده ترین سناریو این است که سرویس B بتواند به یک پایگاه داده به سرویس متصل شود و جداول متعلق به سرویس A. را بخوانید. صنعت سعی می کند از این سطح از اتصال با جداول مشترک جلوگیری کند ، با این حال و به یک دلیل خوب: هرگونه تغییر در اجرای سرویس Aو مدل داده می تواند سرویس B. را بشکند. ما می توانیم چند پیشرفت تدریجی در این سناریو ایجاد کنیم ، به عنوان مثال با استفاده از الگوی Outbox و ارائه یک سرویس A به A که به عنوان یک رابط عمومی عمل می کند. این جدول فقط می تواند حاوی داده های داده B باشد ، و می تواند به گونه ای طراحی شود که پرس و جو و پیگیری برای تغییرات آسان باشد. اگر این به اندازه کافی خوب نباشد ، پیشرفت بیشتر برای سرویس B خواهد بود که از خدمات A برای هرگونه تغییر از طریق یک لایه مدیریت API درخواست کند نه اتصال مستقیم به پایگاه داده A.

اساساً، همه این تغییرات از یک اشکال رنج می برند: سرویس B باید سرویس A را به طور مداوم نظرسنجی کند. انجام این کار می تواند منجر به بار مداوم غیرضروری بر روی سیستم یا تاخیر غیرضروری در برداشتن تغییرات شود. نظرسنجی از یک میکروسرویس برای تغییرات کار سختی است، بنابراین بیایید ببینیم برای بهبود بیشتر این معماری چه کاری می توانیم انجام دهیم.

رقص با Debezium

یکی از راه های بهبود معماری رقص و جذاب تر کردن آن، معرفی ابزاری مانند Debezium است که می توانیم از آن برای انجام تغییر ضبط داده (CDC) با استفاده از گزارش تراکنش های پایگاه A استفاده کنیم. شکل 8 این رویکرد را نشان می دهد.

شکل 8: طراحی رقص سرویس با ضبط داده های تغییر.

Debezium می تواند گزارش تراکنش های پایگاه داده را نظارت کند، هرگونه فیلتر و تبدیل لازم را انجام دهد و تغییرات مربوطه را در موضوع آپاچی کافکا ارائه دهد. به این ترتیب، سرویس B می تواند به رویدادهای عمومی در یک موضوع به جای نظرسنجی از پایگاه داده یا API های سرویس A گوش دهد. تعویض نظرسنجی پایگاه داده برای تغییرات جریان و معرفی یک صف بین سرویس ها، سیستم توزیع شده را قابل اعتمادتر، مقیاس پذیرتر می کند و امکان معرفی سایر مصرف کنندگان را برای موارد استفاده جدید باز می کند. استفاده از Debezium روشی زیبا برای پیاده سازی الگوی صندوق خروجی برای پیاده سازی الگوی Saga مبتنی بر ارکستراسیون یا رقص ارائه می دهد.

یکی از عوارض جانبی این رویکرد این است که امکان دریافت پیام های تکراری سرویس B را معرفی می کند. این را می توان با اجرای سرویس به عنوان بی توان، یا در سطح منطق کسب وکار یا با یک حذف کننده فنی (با چیزی مانند تشخیص پیام تکراری Apache ActiveMQ Artemis یا الگوی مصرف کننده بی توان Apache Camel) برطرف کرد.

رقص با منبع رویداد

منبع یابی رویداد یکی دیگر از اجرای رویکرد طراحی رقص خدمات است. با این الگو، وضعیت یک موجودیت به عنوان دنباله ای از رویدادهای تغییر دهنده وضعیت ذخیره می شود. هنگامی که یک به روز رسانی جدید وجود دارد، به جای به روز رسانی وضعیت موجودیت، یک رویداد جدید به لیست رویدادها اضافه می شود. افزودن رویدادهای جدید به فروشگاه رویداد یک عملیات اتمی است که در یک تراکنش محلی انجام می شود. زیبایی این رویکرد، که در شکل 9 نشان داده شده است، این است که فروشگاه رویداد نیز مانند یک صف پیام برای سرویس های دیگر برای مصرف به روزرسانی ها رفتار می کند.

شکل 9: طراحی رقص خدمات از طریق منبع یابی رویداد.

مثال ما ، هنگامی که به استفاده از منابع رویداد تبدیل می شود ، درخواست های مشتری را در یک فروشگاه رویداد فقط ضمیمه ذخیره می کند. سرویس A می تواند با پخش مجدد رویدادها ، وضعیت فعلی خود را بازسازی کند. فروشگاه رویداد همچنین باید به سرویس B اجازه دهد تا در همان رویدادهای بروزرسانی مشترک شوند. با استفاده از این مکانیسم ، سرویس A از لایه ذخیره سازی خود نیز به عنوان لایه ارتباطی با سایر خدمات استفاده می کند. در حالی که این مکانیسم بسیار مرتب است و هر زمان که تغییر دولت رخ دهد ، مشکل انتشار قابل اعتماد را حل می کند ، یک سبک برنامه نویسی جدید را برای بسیاری از توسعه دهندگان ناآشنا می کند و پیچیدگی های اضافی در مورد بازسازی دولت و تراکم پیام ، که به فروشگاه های داده تخصصی نیاز دارد.

مزایا و اشکال رقص رقص

صرف نظر از مکانیسم مورد استفاده برای بازیابی تغییرات داده ، رویکرد رقص دکوراسیون می نویسد ، امکان مقیاس پذیری خدمات مستقل را فراهم می کند و باعث افزایش مقاومت کلی سیستم می شود. نکته منفی این رویکرد این است که جریان تصمیم گیری غیر متمرکز است و کشف وضعیت توزیع شده در سطح جهان دشوار است. کشف وضعیت درخواست نیاز به پرس و جو از منابع داده های مختلف دارد که با تعداد زیادی از خدمات می تواند چالش برانگیز باشد. جدول 4 مزایا و اشکالات این رویکرد را خلاصه می کند.

• اجرای و تعامل را از بین می برد.
• هیچ هماهنگ کننده معاملات مرکزی.
• ویژگی های مقیاس پذیری و تاب آوری بهبود یافته.
• تعامل نزدیک در زمان واقعی.
• کمتر از سیستم با Debezium و ابزارهای مشابه.

• حالت جهانی سیستم و منطق هماهنگی در همه شرکت کنندگان پراکنده است.
• قوام نهایی

• پایگاه داده خانگی یا اجرای نظرسنجی API.
• الگوی صندوق عقب
• رقص بر اساس الگوی حماسه
• منابع
• اتفاق افتاده
• دبیزیم
• ماکسول Zendesk
• کانال علی بابا
• بروکلین Linkedin
• چارچوب آکسون
• EventStoredb

خط لوله موازی

با استفاده از الگوی رقص ، هیچ مکان اصلی برای پرس و جو از وضعیت سیستم وجود ندارد ، اما دنباله ای از خدمات وجود دارد که دولت را از طریق سیستم توزیع شده تبلیغ می کند. رقص رقص یک خط لوله متوالی از خدمات پردازش ایجاد می کند ، بنابراین می دانیم که وقتی یک پیام به مرحله خاصی از روند کلی برسد ، تمام مراحل قبلی را پشت سر گذاشته است. چه می شود اگر بتوانیم این محدودیت را شل کنیم و تمام مراحل را به طور مستقل پردازش کنیم؟در این سناریو ، سرویس B می تواند بدون توجه به اینکه سرویس A آن را پردازش کرده است یا خیر ، درخواست را پردازش کند.

با خطوط لوله موازی ، ما یک سرویس روتر اضافه می کنیم که درخواست ها را می پذیرد و آنها را به سرویس A و سرویس B از طریق یک کارگزار پیام در یک معامله محلی واحد منتقل می کند. از این مرحله به بعد ، همانطور که در شکل 10 نشان داده شده است ، هر دو سرویس می توانند درخواست ها را بطور مستقل و به صورت موازی پردازش کنند.

شکل 10: پردازش از طریق خطوط لوله موازی.

در حالی که این الگوی برای اجرای بسیار ساده است ، فقط در موقعیت هایی که هیچ اتصال زمانی بین خدمات وجود ندارد ، کاربرد دارد. به عنوان مثال ، سرویس B باید بدون توجه به اینکه آیا سرویس A همان درخواست را پردازش کرده است ، بتواند درخواست را پردازش کند. همچنین ، این رویکرد برای هدف قرار دادن پیام ها به یک سرویس روتر اضافی یا مشتری نیاز دارد که از خدمات A و B آگاه باشد.

به خود گوش کن

یک جایگزین سبک تر برای این رویکرد وجود دارد ، که به عنوان الگوی Leart to Yourself شناخته می شود ، جایی که یکی از خدمات نیز به عنوان روتر عمل می کند. با این رویکرد جایگزین ، هنگامی که خدمات A درخواست دریافت می کند ، به پایگاه داده خود نمی نویسد بلکه در عوض درخواست را در سیستم پیام رسانی منتشر می کند ، جایی که هدف آن به سرویس B و به خودی خود است. شکل 11 این الگوی را نشان می دهد.

شکل 11: الگوی گوش دادن به خود.

دلیل عدم نوشتن به پایگاه داده ، جلوگیری از نوشتن دوگانه است. هنگامی که یک پیام در سیستم پیام رسانی قرار دارد ، پیام به سرویس B می رود ، و همچنین به خدمات A در یک زمینه معامله کاملاً جداگانه می رود. با استفاده از این پیچ و تاب جریان پردازش ، سرویس A و سرویس B می توانند به طور مستقل درخواست را پردازش کرده و در پایگاه داده های مربوطه خود بنویسند.

مزایا و اشکال خطوط لوله موازی

جدول 5 مزایا و اشکالات استفاده از خطوط لوله موازی را خلاصه می کند.

جدول 5: مزایا و اشکال خطوط لوله موازی.

نحوه انتخاب استراتژی معاملات توزیع شده

همانطور که ممکن است قبلاً از این مقاله حدس زده باشید ، هیچ الگوی درست یا اشتباهی برای انجام معاملات توزیع شده در یک معماری میکروسرویس وجود ندارد. هر الگوی جوانب مثبت و منفی خود را دارد. هر الگوی در حالی که دیگران را به نوبه خود ایجاد می کند ، برخی از مشکلات را حل می کند. نمودار در شکل 12 خلاصه ای از ویژگی های اصلی الگوهای نوشتن دوگانه را که در مورد آنها بحث کردم ارائه می دهد.

شکل 12: ویژگی های الگوهای نوشتن دوگانه.

هر رویکردی که انتخاب می کنید ، باید انگیزه تصمیم و پیامدهای معماری طولانی مدت انتخاب خود را توضیح داده و مستند کنید. شما همچنین باید از تیم هایی که در دراز مدت سیستم را پیاده سازی و حفظ می کنند ، پشتیبانی کنید. من دوست دارم رویکردهای شرح داده شده در این مقاله را بر اساس ویژگی های سازگاری داده و مقیاس پذیری آنها ، همانطور که در شکل 13 نشان داده شده است ، سازماندهی و ارزیابی کنم.

شکل 13: سازگاری داده های نسبی و ویژگی های مقیاس پذیری الگوهای نوشتن دوگانه.

به عنوان یک نقطه شروع خوب ، ما می توانیم رویکردهای مختلف را از مقیاس پذیر و بسیار در دسترس با کمترین مقیاس پذیر و در دسترس ارزیابی کنیم.

بالا: خطوط لوله موازی و رقص رقص

اگر مراحل شما به طور موقت جدا شده است ، می تواند آنها را به روش خط لوله موازی اجرا کند. این احتمال وجود دارد که بتوانید این الگوی را برای قسمت های خاصی از سیستم اعمال کنید ، اما برای همه آنها نیست. در مرحله بعد ، با فرض اینکه یک اتصال زمانی بین مراحل پردازش وجود دارد ، و برخی از عملیات و خدمات باید قبل از دیگران اتفاق بیفتد ، ممکن است رویکرد رقص را در نظر بگیرید. با استفاده از رقص خدمات ، می توان یک معماری مقیاس پذیر و رویداد محور ایجاد کرد که در آن پیام ها از طریق خدمات به سرویس از طریق یک فرآیند ارکستراسیون غیر متمرکز جریان می یابند. در این حالت ، اجرای الگوی Outbox با Debezium و Apache Kafka (مانند Red Hat OpenShift جریان برای Apache Kafka) به ویژه جالب و کشش است.

متوسط: ارکستراسیون و متعهد دو فاز

اگر رقص رقص مناسب نیست و به یک نکته اصلی نیاز دارید که مسئول هماهنگی و تصمیم گیری باشد ، آنگاه ارکستراسیون را در نظر می گیرید. این یک معماری محبوب است و پیاده سازی های منبع باز مبتنی بر استاندارد و سفارشی در دسترس است. در حالی که یک اجرای مبتنی بر استاندارد ممکن است شما را وادار به استفاده از معناشناسی برخی از معاملات کند ، یک اجرای ارکستراسیون سفارشی به شما امکان می دهد تا بین قوام داده های مورد نظر و مقیاس پذیری را معامله کنید.

کم: یکپارچه مدولار

اگر بیشتر در طیف قرار دارید ، به احتمال زیاد نیاز بسیار قوی به قوام داده ها دارید و آماده هستید تا با تجارت قابل توجهی هزینه آن را بپردازید. در این حالت ، معاملات توزیع شده از طریق تعهدات دو فاز با منابع داده خاصی کار می کنند ، اما اجرای قابل اعتماد در محیط های ابری پویا طراحی شده برای مقیاس پذیری و در دسترس بودن بالا دشوار است. در این حالت ، شما می توانید تمام راه را به رویکرد یکپارچه خوب مدولار قدیمی ، همراه با شیوه های آموخته شده از جنبش میکروسرویس بروید. این رویکرد بالاترین قوام داده را اما با قیمت اتصال زمان اجرا و منبع داده تضمین می کند.

نتیجه

در یک سیستم توزیع شده قابل توجهی با ده ها خدمات ، یک رویکرد واحد وجود نخواهد داشت که برای همه کار کند ، اما تعدادی از این ترکیبات و برای زمینه های مختلف کاربردی است. شما ممکن است چند سرویس مستقر در زمان اجرا مشترک برای نیازهای استثنایی پیرامون قوام داده ها داشته باشید. شما ممکن است یک تعهد دو فاز را برای ادغام با یک سیستم میراث که از JTA پشتیبانی می کند ، انتخاب کنید. شما ممکن است یک فرآیند تجاری پیچیده را ارکستر کنید ، و همچنین از رقص و پردازش موازی برای بقیه خدمات استفاده کنید. در پایان ، مهم نیست که شما چه استراتژی را انتخاب می کنید. آنچه مهم است انتخاب یک استراتژی به دلایل مناسب و اجرای آن است.

آخرین به روز شده: 12 سپتامبر 2022