فصل 8. خدمات ضد پاتر

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

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

8. 1ضد گره

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

با این وجود ، یک روش بهتر برای حل مشکل ادغام سرویس به سرویس استفاده از موتور ارکستراسیون خارجی است. ایده استفاده از الگوی ارکستراسیون ، فعال کردن مدیریت فرآیند تجارت است - راهی برای تحلیلگران تجارت و IT برای کنترل و تأیید اینکه فرآیندها به صورت پیش بینی شده انجام می شوند (لازم نیست برای آن از موتور ارکستراسیون استفاده کنید ، اما این کمک می کند). در زمینه حل یا اجتناب از آنتی پاتر گره ، الگوی ارکستراسیون بهتر از الگوی FloveFlodize است زیرا تمام تعامل بین خدمات را متمرکز و خارج می کند ، و به طور موثری تمام کد مشکل ساز را از خود خدمات خارج می کند.

8. 2antipatte nanoservice

به دست آوردن دانه بندی مناسب خدمات یکی از سخت ترین کارها در طراحی خدمات است. تعادل زیادی وجود دارد: ارتباطات سربار ، انعطاف پذیری سیستم ، پتانسیل استفاده مجدد و غیره. من نمی توانم یک دستور العمل دقیق به شما ارائه دهم تا به درستی از خدمات استفاده کنید ، زیرا آنچه "درست" است به زمینه ، محیط و سایر تصمیماتی که طراحان خدمات می گیرند بستگی دارد. تعریف آنچه نباید یک سرویس باشد از آنچه باید باشد آسان تر است. به عنوان مثال ، شما قطعاً نباید تمام سیستم ERP موجود خود را یک سرویس واحد بنامید. Antipatte Nanoservice در مورد Extreme دیگر - خدمات کوچکتر صحبت می کند.

متأسفانه همیشه یافتن خدمات مناسب دیگر (نانو یا اندازه مناسب) که می تواند عملکرد یک سرویس نانو را جذب کند ، همیشه امکان پذیر نیست. در این موارد ، خلاص شدن از شر یک نانو سرویس بیشتر از یک تمرینی است که از آن استفاده مجدد است. من روی پروژه ای کار کردم که دارای یک سرویس تخصیص خدمات (SAS) بود. نقش SAS این بود که در مورد مکان های سایر خدمات ، وضعیت های بهداشتی و استفاده از آن آگاهی داشته باشد و در صورت درخواست تصمیم گیری برای استفاده از نمونه های خدماتی (مانند ابتدای حماسه - فصل 5 را برای بحث در مورد الگوی حماسه ببینید)واداین سرویس همچنین قابلیت های گزارشگری را برای ساگاس های فعال ، استفاده از خدمات و غیره ارائه می دهد. این ممکن است مانند یک نانو سرویس به نظر نرسد ، و در ابتدا فکر می کردیم که اینگونه نیست ، اما با پیشرفت این پروژه ، ما دریافتیم که چون SAS یک قطب مرکزی است ، همانطور که در شکل 8. 6 نشان داده شده است ، SAS به یک تنگنا عملکرد تبدیل شد. این هزینه های اضافی (در زمان تاخیر) را در بسیاری از تماس ها و تعامل های انجام شده توسط سایر خدمات متحمل شده است. ابزار SAS با هزینه کاهش می یابد. این یک نانو سرویس بود.

8. 3. یکپارچه سازی معاملات ضد

اوضاع در راه حل SOA بسیار بدتر است زیرا هر سرویس می تواند و به طور مستقل از نظر استقرار و عملکرد به طور مستقل تکامل یابد. چه اتفاقی می افتد که سرویس موجودی به مرکز داده دیگری منتقل شود (به عنوان مثال ، وقتی به ابر منتقل می شود)؟چه می شود اگر طراحان سرویس موجودی تصمیم بگیرند که وقتی سطح موجودی به یک آستانه برخورد می کند ، این سرویس به طور خودکار منابع جدید را در یک معامله سفارش می دهد؟اکنون تا زمانی که منابع جدید سفارش داده نشود ، نمی توانید یک مورد را در موجودی تأمین کنید. به طور ناگهانی ، معامله شما گسترش یافته است و اکنون شامل سرویس سفارش ، سرویس موجودی و سرویس تأمین کننده است. همانطور که مشاهده می کنید ، یکی از ریسک های ادغام معامله ای این است که طراحان خدمات شرکت کننده در معامله شما معامله را برای رسیدگی به قوانین تجاری مورد نیاز برای رعایت آنها گسترش می دهند.

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

8. 4همان راه قدیمی ضد پاتر

مالیات SOA به این واقعیت اشاره دارد که شما باید در زمان طراحی و زمان اجرا بیشتر سرمایه گذاری کنید. به عنوان مثال SOA شامل افزایش تأخیر است ، زیرا لایه های دیگری مانند سریال سازی و دفع کردن ، ارتباطات و غیره وجود دارد. اگر به جای دو سرویس بتوانید با استفاده از اشیاء که در همان فضای حافظه با یکدیگر صحبت می کنند ، مدیریت کنید ، هیچ یک از این سربارها را ندارید. مالیات SOA همچنین می تواند به افزایش پیچیدگی محلی هر مؤلفه اشاره کند. اجرای سرویس داده همانطور که قبلاً مورد بحث قرار گرفت ، چیزی شبیه به شکل 8. 9 بود. شما یک سرویس میزبان در یک سرور وب دارید که یک API REST REST را ورزش می کند که نمایش داده ها و سایر عملیات CRUD را امکان پذیر می کند ، به جای اینکه فقط لایه دسترسی داده ای را که در غیر این صورت استفاده کرده اید ، انجام دهید. این سرویس همچنین شامل تلاش اضافی در آزمایش ، استقرار و نظارت است.

ترفند اصلی در مورد اصلاح مجدد این ضد پاتر ، در وهله اول متوجه آن می شود و تصدیق می کنید که شما هر کاری را که قبلاً انجام می دادید در لباس SOA انجام می دهید. برای کمک به شناسایی مشکل ، می توانید در مورد اشتباهات محاسبات توزیع شده فکر کنید (به بخش 1. 1. 3 فصل 1 مراجعه کنید). اگر فهمیدید که آنچه شما "SOA" می نامید ، یک یا چند مورد از آنها را فرض می کند ، این بوی است که ممکن است واقعاً SOA نباشد.

8. 5خلاصه

در این فصل برخی از مشکلات متداول که احتمالاً هنگام حرکت به SOA انجام می دهید ، معرفی کرده است.

من در ابتدای این فصل ذکر کردم که این بخش دوم کتاب به جنبه های مختلف SOA در دنیای واقعی نگاهی می اندازد. اکنون که ما به دنبال آنتی پاتر به پایان رسیدیم ، بعد به جنبه دیگری از SOA در دنیای واقعی نگاه خواهیم کرد ، این بدان معناست که مشکلات واقعی آنقدر بزرگ و پیچیده هستند که یک الگوی واحد نمی تواند آنها را حل کند. ما به یک مطالعه موردی از یک راه حل پایان به پایان می پردازیم که چندین الگوی را در کل بیشتر ادغام می کند.< SPAN> ترفند اصلی با استفاده از این ضد پاتر ، در وهله اول متوجه آن می شود و تصدیق می کنید که شما هر کاری را که قبلاً انجام می دادید در لباس SOA انجام می دهید. برای کمک به شناسایی مشکل ، می توانید در مورد اشتباهات محاسبات توزیع شده فکر کنید (به بخش 1. 1. 3 فصل 1 مراجعه کنید). اگر فهمیدید که آنچه شما "SOA" می نامید ، یک یا چند مورد از آنها را فرض می کند ، این بوی است که ممکن است واقعاً SOA نباشد.