SAGA microservice architecture مدیریت تراکنش ها

مقدمه

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

لیست مطالب ارائه شده در این مقاله:

• تعریف مسئله
• Distributed transaction
• Two phase commit
• Saga
• compensating transactions
• Coordinating sagas
• Choreography
• Orchestration-based sagas

باید در نظر داشت هر معماری و یا هر الگوی مزایا و معایب خود را دارد بنابراین هر مسئله ای را نمی توان تنها با یک روش  حل کرد البته که هر چقدر که شناخت ما از مسئله کاملتر و دقیق تر باشد به راه حل دقیق تر می رسیم.

 با سپاس  

علی لطفی

تعریف مسئله

فرض می کنیم شما دارای یک سایت رزرو رستوران هستید که یک سیستم یکپارچه (monolith) “ثبت سفارش” دارد و این سیستم سفارش کاربر، تعداد میزهای خالی برای رزرو، امکان ثبت غذا، بررسی اطلاعات کارت کاربر، کم کردن از حساب کاربرو غیره  را انجام می دهد و همه این فرآینده در یک Transaction  اتفاق می افتاد که یا Commit می شود و یا اگر خطای رخ داد  عملیات Rollback  می گردد. روش های مختلفی برای عملیات transaction در زبان های مختلف وجود دارد در اینجا نمونه ای از باز کردن Transaction  در زبان جاوا و Spring Framework آورده شده است

Transaction :

این annotation وظیفه باز کردن و مدیریت یک transaction  در جاوا را دارد

.

ویژگی های یک Transaction

هر transaction باید دارای  4 ویژگی باشد :

تجزیه ناپذیری یا atomic

هرTransaction   شامل یکسری دستورات است.atomic  بودن تضمین می کند که همه این دستورات مانند یک واحد دیده شود که یا همه با هم اجرا می شوند و یا  هیچکدام اجرا نمی شوند و database بدون هیچگونه تغییر باقی می ماند و اینگونه نیست که برخی از تغییرات اعمال شوند حتی در زمانی که پایگاه داده به طور ناگهانی خاموش شود(با رفتن برق) یا به هر دلیل دیگری از دسترس خارج شوند.

هم‌خوانی (سازگاری) یا  consistency

هر Transaction که پایان می پذیرد باید database را از یک وضعیت معتبر به وضعیت  معتبر دیگری منتقل کند. بدین معنی  که هر داده ای که در database ثبت  می شود و یا تغییری در داده ها رخ دهد باید  از قوانین تعریف شده تبعبت  کنند که شامل constraints, cascades, triggers می باشد یعنی نمی توانیم سطری را حذف کنید که با یک جدول دیگر رابطه دارد و یا داده ای ثبت کنیم که نوع داده آن همخوانی ندارد و… بنابراین همیشه با این قوانین وضعیت درست می باشد.

محدود کردن یا  isolation

 Transactionها معمولا همزمان روی داده ها اجرا می شوند و با محدود کردن  تضمین می شود که transaction  ها به نوبت اجرا شوند البته این موضوع به تنظیمات  سطح محدود کردن شما هم بستگی دارد. بنابراین هر Transaction  همانند Transaction های مستقل انجام می شوند  و سلامت داده ها تحت تاثیر قرار نمی گیرند.

پایایی یا  durability 

براساس این خاصیت transaction ها  که به مرحله انجام (Commit) برسند اثرشان ماندنی است و هرگز به طور تصادفی از بین نمی‌رود هر اتفاقی هم که رخ  دهد بعد ازعملیات  commit یک transaction  از بین نمی رود..

بررسی مدیریت transaction  در محیط های توزیعه شده

دریک  سیستم یکپارچه به دلیل این که هر transaction  دارای ویژگی acid می باشد  نگرانی در مورد سلامت داده ندارید اجازه دهید میکروسرویس ها این  را بررسی کنیم، مجموعه سرویس های متفاوت که هر کدام Database مربوط به خود را دارا است و حتی ممکن است که از تکنولوژی های متفاوتی سود ببرند و بخشی از سرویس ها از دیتابیس های رابطه ای استفاده کنند و بخشی دیگر از دیتابیس های غیر رابطه ای  استفاده نمایند. در مثال ما فرض کنید ثبت سفارش در یک میکرو سرویس ,بخش بررسی اطلاعات  کارت مشتری در یک میکروسرویس بخش ticket  برای صادر کردن بلیط در بخش دیگری است، اگر  هر میکرو سرویس  database مربوط به خود را داشته باشد دیگر نمی توانیم عملیات را با یک transaction مدیریت کرد چون هر میکرو سرویس transaction مربوط به خود را دارد و باید راه حلی را پیدا کنیم که امکان مدیریت کردن transaction ها در تمام میکرو سرویس ها بصورت یک transaction واحد  وجود داشته باشد .

commit دو مرحله ای

همانطور که مشاهده می کنید با انتخاب این معماری وارد چالش مدیریت transaction ها می شوید که در سطح این معماری م باید خاصیت  Acid بودن را داشته باشند بدین معنی که یا روی تمامی database می شود  و یا روی  هیچکدام اجرا نمی شوند، در واقع باید  consistency داده ها رعایت شده باشد و بحث isolation و در نهایت durability رعایت شده باشد بنابراین برای مقابله با این چالش با از روش های مدیریت distributed transaction استفاده کرد  یکی از این روش ها Two phase commit می باشد که  به توضیح آن می پردازیم.

همانطور که از نام این روش  برمی آید commit کردن transaction در دو فاز انجام می شود. در این روش بخشی به نام coordinate مسئول مدیریت transaction ها خواهد بود در واقع شبیه به یک مرکز کنترل که بر مبنایی وضعیت  سرورها و پاسخ های که آنها به این مرکز کنترل می فرستد  تصمیمات لازم را اتخاذ کرده  دستورات لازم را به آنها خواهد داد. بنابراین مدیریت transaction  ها بر عهده این بخش که سرورها کی transaction های خود را commit و یا rollback کنند بر عهده این مرکز فرماندهی خواهد بود و این کار در دو فاز انجام می شود.

فاز آماده سازی

در فاز اول مرکز کنترل پیامی به سرورها می دهد که گوییم آماده انجام هستند و در این صورت داد ه ها در log هر سرور ذخیره می شود  و همچنین اگر نیاز به lock کردن داده ای نیز باشد در این فاز انجام می شود اگر موفق به انجام این کار شدند یک پاسخ مثبت به مرکز کنترل می دهند و منتظر دستور نهایی کردن commit خواهند بود در صورتی که به هر دلیلی به مشکل برخورد کردند نیز پیامی به  مرکز کنترل بر مبنایی  که در فاز آماده سازی  دچار خطا شدند ارسال می کنند  در صورتی که هر یک از سرورها نتوانستند عملیات اولیه را انجام دهند مرکز کنترل به تمام سرور پیام abort و یا rollback را صادر می کند  و همه چیز پایان خواهد یافت و در صورتی که همه موفق به انجام عملیات شدند وارد فاز دو و دستورات بعدی خواهیم شد..

فاز Commit

در فاز 2 به مرحله پایانی کار می رسیم در این فاز اگر همه  سرورها در مرحله قبل موفق بودند مرکز کنترل فرمانی که  اینکه همه سرورها commit کنند ارسال می شود و تمام سرورها اقدام به commit کردن کار می کنند در صورتی که به هر دلیل یکی سرورها موفق به commit کردن نشوند و دچار خطای بشنوند پیامی به مرکز کنترل بر مبنایی Fail  شدن خواهند داد در این صورت مرکز کنترل به تمامی سرور ها پیام rollback را صادر خواهد نمود و بدین صورت همه سرور ها اقدام به undo  کردن transaction خواهند نمود و در صورتی که موفق به کامیت کردن شدن پیامی بر مبنای موفقیت به مرکزفرماندهی  خواهند فرستاد در صورتی که مرکز کنترل موفق به دریافت همه پیام های موفق بشود کار تمام می شود در صورتی که به هر دلیلی پیامی دریافت نکنیم اقدام به ارسال پیام به rollback کردن به سرورها خواهیم فرستاد.

در شکل زیر می توان پیام های که بین مرکز کنترل(Coordinator )  و سرورهای شرکت کننده در این فرآیند را ببینید.

معایب این روش

فرستادن پیام های زیاد

          همانطور که مشاهده می کیند برای انجام این این پردازش باید پیام های زیادی ارسال شود پس اگر n سرور داشته باشیم مجبور به اراسال n به توان 3 پیام هستیم بنابراین پیام های زیادی ارسال می شود و پردازش ها کند می شوند.

Point of frailer(نقطه خرابی)

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

Latency(تاخیر)

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

Database support

همه دیتابیس ها 2PC را پشتیبانی نخواهند کرد بنابراین اگر شما از تکنولوژی استفاده می کنید که دارای این قابلیت نیست دچار مشکل خواهید شد.

Saga

در روش قبل تلاش میکردم  که همه سرورها با هم دریک فرآیند واحد عملیات commit  را انجام دهند و تلاش برآن بود که به نظر ما دارای یک transaction واحد با خاصیت  ACID   در یک فضایی توزیع شده باشیم  اما این روش دارای معایب  و صد البته مزایای خود میباشد مثلا در محیطی که consistency  اهمیت دارد قطعا یکی از روش های مناسب برای  consistency  بودن داده ها است. 

در این روش هر میکرو سرویس  مستقل از دیگر میکرو سرویس ها اقدام به commit  کردن بر روی دیتابیس خود می نمایید بنابراین بر خلاف روش قبل که commit کردن ما وابسته به دیگر سیستم ها بود در این روش کاملا بصورت مستقل بر روی دیتابیس خود commit  می کنیم و یک event ارسال می کنیم به میکرو سرویس بعدی که در این فرآیند شرکت دارد مثلا ما یک order ثبت می کنیم با وضعیت pending  ثبت کرده و سرویس بررسی اطلاعات کارت در میکرو سرویس کارت را صدا کرده و اگر به خطا نخوردیم در پاسخی که دریافت می کنیم وضعیت order ثبت شده را به APPROVE   تغییر می دهد و اگر به خطا خوردیم تبدیل به وضعیت را به  REJECT تبدیل می نماییم.

بیاید با یک مثال مطالب را ادامه  دهیم.

1. Order Service ابتدا یک درخواست با وضعیت APPROVAL_PENDING ثبت خواهیم کرد.
2. Consumer Service این سرویس بررسی می کند آیا کاربر امکان ثبت درخواست دارد.
3. Kitchen Service درخواست مشتری را بررسی نموده و یک ticket باوضعیت CREATE_PENDING ثبت خواهد نمود.
4. Accounting Service کارت مشتری را بررسی نموده که معتبر است یا خیر.
5. Kitchen Service وضعیت ticket را به APPROVE_TICKET تغییر وضعیت می دهد.
6. Order Service تعییر وضعیت درخواست بصورت APPROVE.

همانطور که مشاهده خواهید نمود ارتباط کاملا بصورت async   می باشد بنابراین هر سرویس پس از انجام local transaction  خود یک  event را publish  خواهد کرد  به میکرو سرویس بعدی و اینکه در این روش  به دلیل استفاده از massage broker ها  تمام میکرو سرویس ها بصورت loose coupling هستند هر سرویس به طور کامل از سرویس بعدی خود کاملا بدون اطلاع می باشد چون یک event را publish می کند و هیچ  اطلاعی از اینکه چه میکروسرویسی این event را استفاده خواهد کرد نخواهد داشت  به این دلیل کاملا نسبت به یکدیگر بی اطلاع خواهند بود .اگر سرویس بعدی در دسترس نباشد به دلیل ذخیره شدن در buffer مربوط به message broker هر زمان که آن سرویس در دسترس قرار  بگیرد امکان ادامه فرآیند امکان پذیر خواهد بود.

compensating transactions

در saga هر میکروسرویسی در هر  مرحله  بر روی local db  خود commit خواهدکرد بر خلاف روش معمول که transaction را rollback  می کردیم در saga باید کدهای  نوشته شود که تاثیرات  این commit شدن را در صورت لازم undo نمایید  در این روش همانطور که مشاهده می کنید نیازمند به کدهای بیشتری می باشیم به این کدهای که عملیات undo  را انجام می دهد compensating transactions  گفته می شود. اجازه دهید به توضیح مثال قبل بپردازم که اگر در تایید کارت کاربر به هر دلیلی به خطای رخ دهد  باید order و ticket مربوط به مشتری reject شود بیاید با یک مثال مشاهده نمایید تا کاملا متوجه شوید با همان مثال ثبت order

1. order service یک در خواست با وضعیت APPROVAL_PENDING ثبت می کنیم.
2. Customer service در این مرحله بررسی می کنیم که مشتری امکان رزرو جا را دارد.
3. Kitchen Service بررسی می کند جزییات را و یک ticket با وضعیت CREATE_PENDING ثبت می کند.
4. Accounting Service بررسی می کند اطلاعات مشتری را و در این مرحله به خطا میخوریم.
5. Kitchen Service تغییر وضعیت Ticket به CREATE_REJECTED.
6. Order Service تغییر وضعیت Order به REJECTED.

سرویس های که TicketوOrder را به وضعیت REJECTED تبدیل می کنند به دلیل اینکه سرویس Accounting service  خطا خورده است باید وضعیت ها را به REJECT تبدیل کنیم به این کدهای که برای تغییر وضعیت می نویسم را compensating transactions می گویند.

در جدول زیر نیز میتوانید تاثیرات این مراحل را مشاهد نمایید.

Coordinating sagas

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

• choreography.
• Orchestrator

هر دو روش را بصورت کامل همراه با یک مثال برسی خواهیم نمود ابتدا با choreography به حل مسله خواهیم پرداخت.

Choreography

در این روش بر خلاف  2fc که یک مرکز فرماندهی وظیفه مدیریت transaction ها را بر عهده داشت در این روش به جای اینکه مرکز فرماندهی تصمیم بگیرد و مشخص کند چه باید کرد هر میکرو سرویس شرکت کننده  خود به تنهایی تصمیم می گیرد که بر مبنایی وضعیت موجود خود که آیا موفق به commit و یا دچار مشکل شد چه  event را publish کند   ویا در صورت subscribe  شدن چه عملیاتی را بروی دادهای خود انجام دهد  یعنی منطق به جای آنکه در یکجا متمرکز شده باشد و این وظیفه بین تمام میکرو سرویس ها  پخش شده است دیگر بصورت متمرکز و یک جای مشخص نخواهد بود.

اجازه دهید با مثال قبل این فرآیند را توضیح دهیم تا بصورت کامل و مشخص قابل درک شود.

1. Order service یک  order با وضعیت APPROVAL_PENDING ایجاد کرده و رویداد Order Created را publishes می کنیم.

2. Consumer Service در این مرحله رویداد Consumer service را  استفاده می کند و  بررسی خواهد نمود که آیا مشتری امکان ثبت درخواست را دارد یا خیر در صورت عدم وجود مشکل یک رویداد publishes می کند یک رویداد با نام Consumer Verified.

3. Kitchen Service رویداد Order Create را بررسی می کند و یک Ticket با وضعیت CREATE_PENDING در localDB خود ایجاد می کند و سپس رویداد Ticket Created را Publish می نمایید.

4. Accounting Service این سرویس رویداد Order Create را استفاده کرده و یک Credit_CardAuthorization ایجاد با وضعیت Pending ایحاد می نمایید.

5. Accounting Service رویدادهای Ticket Create و Consumer Verified را دریافت و اطلاعات کارت مشتری را بررسی و در صورت عدم مشکل از حساب مشتری مبلغ را برداشته کرده و وضعیت Credit_CardAuthorization را به CreditCard_Authorized تعییر میدهد و رویداد CreditCardAuthorized را publish میکند.

6. Kitchen Service: این سرویس CreditCardAuthorized را استفاده کرد و وضعیت Ticketرا به AWAITING_ACCEPTANCE تغییر می دهد.

7. Order Service رویداد CreditCardAuthorized را استفاده کرده و وضعیت Order را به APPROVED,  تغییر وضعیت داده و رویداد Order Approved را publish می کند.

همانطور که مشاهده می کنید در این سناریو  همه آنجه که روال طبیعی است اتفاق می افتد اما همیشه اینطور نخواهد بود و گاهی ممکن است به خطا بر خورد کنیم که در ادامه به بررسی این حالت خواهیم پرداخت و.در این حالت برخی سرویس ها باید compensating transactions  برای undo  کردن تغییرات خود داشته باشند با شکل شروع کرده و به توضیح هر مرحله خواهیم پرداخت.

1. Order Service یک Order با وضعیت the APPROVAL_PENDING ایجاد می نمایید و رویداد Order Created را publish می کند.

2. Consumer Service رویداد Order Created استفاده می کند و بررسی می کنه که آیا این کاربر امکان ایجاد Order را دارد و یا خیر فرض کنیم دارد ما رویداد consumerVerfied را publish می کنیم.

3. Kitchen Service رویداد Order Create را استفاده می نمایید Order مربوط به کاربر را بررسی می کند و در صورت معتبر بودن یک Ticket با وضعیت CREATE_PENDING ایچاد می نمایید و رویداد Ticked Create را publish می کند.

4. Account Service رویداد Order Created استفاده می کند و CreditCardAuthorization در وضعیت Pending ایجاد می نمایید.

5. Account Service رویدادهای Ticket Created و consumerVerfied استفاده می کند و وضعیت کارت کاربر را بررسی می کند و به خطا می خوریم در این صورت یک رویداد با عنوان Credit Card Authorization Failed را Publish مینمایید.

6. Kitchen Service استفاده می کند از وضعیت Credit Card Authorization Failed و وضعیت Ticket را به Reject تغییر وضعیت می دهد.

7. Order Service استفاده می کند از وضعیت Credit Card Authorization Failed و وضعیت Order را به Reject تغییر وضعیت می دهد.

نکات مورد توجه در این روش

• مطمئن شویم که هر میکروسرویس شرکت کننده در این فرآیند حتما دادهای خود را در database ویرایش نمایید و وضعیت خود را تعییر دهد و نکته ای بعدی مطمئن شویم که حتما یک event را publish  کند. مثلا  در saga مربوط به ایجاد سفارش ، سرویس آشپزخانه رویداد Consumer Verified event  را دریافت کرده و یک  Ticket ایجاد می کند و یک رویداد Ticket Created را منتشر می کند.ضروری است که به روز رسانی پایگاه داده و انتشار رویداد به صورت اتمی اتفاق بیفتد.

• نکته ای بعدی باید مطمئن شویم که هر میکروسرویس شرکت کننده در saga رویدادی را که دریافت می کند و باید بتواند به دادهای خود در دیتابیس مپ کند. به عنوان مثال ، هنگامی که Account Service رویداد  CreditCardAuthorized  را publish   کرده و از سوی دیگر Order Service  باید بتواند order مورد نظر را پیدا کرده و وضعیت  آن را به  APPROVED تبدیل نمایید.

مزایا و معایب این روش

مزایا:

• سادگی : در این روش بر عکس روش دیگر ساده است هر زمانی که  تغییری business  مانند ایجاد ،حذف و ویرایش و غیره  رخ دارد کافی است که یک event را publish کنید.
• عدم وابستگی:در این روش چون بر مبنایی message broker پیش رفتیم تمام میکروسرویس ها کاملا از یکدیگر بی اطلاع می باشد .

معایب این روش شامل:

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

• به وجود آمدن حلقه:ممکن است اگر دقت نکنیم ممکن است که حلقه به وجود بیاریم که هیچگاه پایین نپذیرد.سرویس ها تا بی نهایت در یک حلقه گیر کنند.

Orchestration-based sagas

در این روش برخلاف روش قبلی یک مرکز فرماندهی (orchestration)  وظیفه مدیریت فرآیند saga بر مبنایی پیام های که بصورت async به این مرکز می رسد را بر عهده دارد و بر مبنایی آن تصمیم می گیرد که microservice  شرکت کننده در saga چه عملیاتی را انجام دهد. در  این  روش هر شرکت کننده پس از انجام کار خود یک پیام به مرکز فرماندهی صادر می کند و منتظر پیام بعدی خواهد شد و در این مرکز فرماندهی تصمیم خواهد گرفت که در گام بعدی چه میکروسرویسی شرکت کننده در این فرآیند چه عملیات را باید انجام دهد. بیاید با یک مثال مسئله را جلو ببریم.

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

در این روش order service با ایجاد یک order با وضعیتتPENDING و همچنین ایجاد  رویداد  Create Order Saga فرآیند  را بصورت زیر آغاز می کند.

1. مرکز فرماندهی با ارسال فرمان Verify Consumer به Consumer Service برای بررسی درخواست مشتری.
2. Consumer Service به مرکز فرماندهی پاسخ می دهد که همه چیز مرتب است امکان ادامه فرآینده وجود دارد.
3. مرکز فرماندهی به با ارسال فرمان a Create Ticket به سرویس Kitchen Service  دستور ایجاد یک Ticket را می دهد.
4. Kitchen Service فرمان را اجرا کرده و یک Ticket ایجاد کرده و یک پیام به مرکز فرماندهی بر مبنایی اینکه موفق به ساخت شده را ارسال می کند.
5. مرکز فرماندهی یک فرمان به  Accounting Service بر مبنای  Authorize Card به این سرویس اررسال کرده و منتظر پاسخ می ماند.
6. در ادامه Accounting Service با پیام اینکه همه چیز درست است ب مرکز فرماندهی پیام مید هد.
7. مرکز فرماندهی به ارسال فرمان Approve Ticket به سرذویس Kitchen Service. دستور تغییر وضعیت TICKET را به APROVE میدهد.
8. مرکز فرماندهی با ارسال یک پیام به سرویس Order Service به منظور تغییر وضعیت Order را می دهد با فرمان  Approve Order.

مسائلی که ممکن است در آن به خطا برخورد کنیم

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

1. مرکز فرماندهی فرمان با ثبت Order در وضعیت Pending کار را آغاز میکند .سپس فرمان Verifying Consumer به the Consumer Service ارسال می کند و منتظر پاسخ که آیا کاربر امکان ثبت Order دارد یا خیر بررسی شود.
2. فرمان Creating Ticket به Ticket service ارسال کرده و منتظر پاسخ بر مبنایی ثبت Ticket می ماند.
3. فرمان Authorizing Card  را ارسال می کند مرکز فرماندهی و خطا خواهیم خورد بنابراین با دریافت پیام خطا فرمان  لازم  را برای تغییر وضعیت Order و Ticket را به REJECT صادر خواهد نمود و به وضعیت  Order را نیز به  REJECT  تغییر میدهیم.

همانطور که مشاهده می نمایید در دیاگرام بالا ما با یک State Machin روبرو هستم با هر Transaction  در یک وضعیت جدید قرار خواهیم گرفت که در هر وضعیت با Transaction  جدید به یک وضعیت جدید قرار خواهیم گرفت که یا در نهایت Reject خواهیم شد و یا Approve.

مزایا و معایب این روش

مزایا

• عدم به وجود آمدن چرخه

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

• Less coupling

دیگر نیازی نیست که سرویس یک رویدا را publish کند و این مرکز کنترل خواهد که تصمیم خواهد گرفت چه زمان و برای چه سرویس های فرمان را ارسال کند بنابراین وابستگی کمی به وجود آمده است.

• سادگی درک و توسعه

همانطور که در بالا توضیح داده شده با توجه به state Machin بودن و متمرکز بودن منطق درک و خطا یابی و توسعه ساده تری نسبت به روش قبل خواهد داشت.

و مشکلی که دارد این است که ممکن در افراطی قرار بگیرد که تمام بیزنس ها در این بخش متمرکز کنیم و سرویس ها بدون بیزنس و خالی باشند بنابراین بسیار با اهمیت است که دقت کنیم افراط زیادی به خرج ندهیم  به اندازه.

ایان دوستان خوبم امیدوارم لذت برده باشین و خوشحالم میشم که در این مورد با هم دانشمون رو به اشتراک بگذارید

https://Github.com/LotfiAli

LotfiAliDev@gmail.com

منبع :

https://en.wikipedia.org/wiki/ACID https://docs.microsoft.com/