این پست براساس کتابی به اسم microservices-vs-service-oriented-architecture نوشته شده است.
یادگیری تفاوت های اصلی بین این دو معماری، می تواند منجر به انتخاب درست با توجه به شرایط خاص پروژه شما شود.
دنیای معماری های مبتنی بر سرویس
هر دو معماری microservice و soa مبتنی بر سرویس هستند. به این معنی که این الگوهای معماری تاکید زیادی روی سرویس به عنوان جزء اصلی معماری برای پیاده سازی کارهای تجاری و غیرتجاری دارند. اگرچه microservice و soa تفاوت های زیادی باهم دارند اما ویژگی های مشترک بسیاری هم دارند.
یک چیز مشترکی که معماری های مبتنی بر سرویس دارند، معماری توزیع شده اونهاست. به این معنی که سرویس ها می توانند از طریق rest ، soap ، AMQP,JMS,MSMQ,RMI با هم ارتباط برقرار کنند.
معماری های توزیع شده مزایای قابل توجهی نسبت به معماری های یکپارچه ( monolithic) و مبتنی بر
لایه ها دارند، از جمله مقیاس پذیری بهتر، جداسازی بهتر و کنترل بهتر روی توسعه ، تست و استقرار.
اجزا در یک معماری توزیع شده تمایل بیشتری به خودمختاری دارند که کنترل بهتر روی تغییرات و نگهداری ساده تر را فراهم میکند و این به نوبه خود منجر به برنامه های قوی تر و واکنش پذیر می شود.
معماری توزیع شده کمک میکنه به وابستگی کمتر و modular بودن برنامه.
در زمینه معماری های مبتنی بر سرویس modularity روشی است برای encapsulating بخشهایی از برنامه که منجر به داشتن یک سرویس خود مختار می شود که می توانند با کمترین وابستگی یا بدون وابستگی به سایر اجزا یا سرویس های داخل برنامه به صورت جداگانه ، توسعه ، تست و استقرار شود.
معماری های ماژولار همچنین از مفهوم بازنویسی برای نگهداری حمایت میکند و اجازه میدهد بازنویسی ( refactoring) یا جایگزینی در قسمت های کوچکتر و در طول زمان رشد پروژه باشد (بر خلاف بازنویسی و جایگزینی یک اپلیکیشن با روش BIG-BANG)
در مورد مزایای معماری توزیع شده اعتراضی نیست اما برای پیاده سازی آن یک سری هزینه و چالش پیچیده وجود دارد. انتخاب پروتکل مناسب برای ارتباط سرویس ها ، حفظ و نگهداری قرارداد سرویس ها ، تامین امنیت ارتباط سرویس ها ، مدیریت تراکنش های توزیع شده و نحوه برخورد با سرویس غیرپاسخگو و غیرقابل دسترس، تنها بخشی از مسائل پیچیده ای هستند که در هنگام پیاده سازی معماری مبتنی بر سرویس با ان روبرو می شویم.
در ادامه هر کدام از این چالش ها را شرح می دهیم.
قراردادهای سرویس (service contracts)
قرارداد سرویس یک توافق بین سرویس و سرویس مشتری (client) است که تعیین میکند فرمت ورودی و خروجی دیتا به چه صورت باشد. (json, xml, java object,....)
ایجاد و نگهداری این قرارداد یک کار دشوار است که نباید به آسانی پذیرفته و یا به صورت یک کاری که بعداً در موردش فکر میکنیم تلقی شود. به همین ترتیب این موضوع، مستلزم توجه ویژه ای در زمینه معماری مبتنی بر سرویس است.
در معماری مبتنی بر سرویس شما می توانید از دو نوع مدل قرارداد سرویس استفاده کنید: قراردادهای مبتنی بر سرویس (خدمات دهنده) و قراردادهای مبتنی بر مشتری (مصرف کننده یا سرویس مشتری یا کلاینت).
تفاوت واقعی بین این مدل قراردادها، درجه همکاری است.
در قرارداد مبتنی بر سرویس (خدمات دهنده) ، سرویس تنها مالک قرارداد و به طور کلی آزاد است هر تغییری را در قرارداد بدون نیاز به فهمیدن نظر مصرف کننده (سرویس مشتری یا کلاینت) ایجاد کند. این مدل، مصرف کنندگان را مجبور میکند تغییرات جدید قرارداد را اعمال کنند. چه یک مصرف کننده به آن قابلیت نیاز داشته باشد و یا نداشته باشد.
از سوی دیگر، قراردادهای مبتنی بر مصرف، مبتنی بر ارتباط نزدیک بین سرویس و مصرف کنندگان خدمات است. با استفاده از این مدل همکاری قوی بین صاحب سرویس و مصرف کنندگان سرویس وجود دارد به طوری که نیازهای مصرف کنندگان سرویس با توجه به قراردادهایی که به آنها متصل می شوند، مورد توجه قرار می گیرند. این مدل به طور کلی نیاز به این دارد که سرویس بداند چه کسانی مصرف کننده اون هستند و هر کدام از این مصرف کننده ها چگونه از سرویس استفاده می کنند. مشتریان سرویس آزاد هستند که پیشنهادات تغییرات در قرارداد خدماتی را ارائه دهند، که سرویس دهنده می توانند بسته به اینکه چه تاثیری روی بقیه مصرف کنندگان می گذارد، پیشنهاد را پذیرفته یا رد کنند. در یک سناریوی کامل، مصرف کننده سرویس، تست های خود را به صاحب سرویس ارائه می دهند تا در صورتی که یک مصرف کننده تغییری را پیشنهاد کند، تست ها می توانند انجام شوند تا ببینند آیا این تغییر مصرف کننده خدمات دیگری را مختل می کند. ابزارهای متن باز مانند pact و pacto می توانند به حفظ و تست قراردادهای مبتنی بر مصرف کمک کنند.
ادامه دارد...
