انتشار مقاله مهاجرت به معماری میکروسرویس ها

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

صفحه مقاله در Researchgate

لایه های معماری سازمانی سرویس گرا : سرویس های فرآیندی، ترکیبی و اتمیک

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

  • لایه کسب و کار
  • لایه سرویس
  • لایه نرم افزار و سیستم های اطلاعاتی

در این میان خود لایه سرویس به سه دسته مجزی تقسیم می شود :

  • سرویس های فرآیندی (هم نواساز)
  • سرویس های ترکیبی
  • سرویس های اتمیک (منحصر بفرد)

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

  • نقدی
  • واریز به کارت اعتباری
  • در یک چک

پس اینترفیس های متنوع و گوناگون برای دریافت سرویس ها توسط دینفعان فراهم شده است. در واقع اساتید دانشگاه حکم سرویس گیرندگان را دارند، ATM یا چک پول حکم اینترفیس را ایفا می کنند و ارائه حقوق نقش سرویس را دارد.

اما مزیت این سرویس های هم نواسازی در چیست ؟

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

 

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

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

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

برای استخراج منطق این لایه دو راه داریم :

  • مدل فرآیندی سازمان
  • مصاحبه با متبحران سازمانی
  • مستندات قابل قبول و ۱۰۰ درصد تایید شده

نکته دیگر اینکه سرویس های ترکیبی به دو دسته وظیفه محور و موجودیت محور تقسیم می شوند.

وظیفه محور ها : منطق و اصول کسب و کار را ارائه می کنند.

موجودیت محورها : اطلاعات، مشخصات و عملیات مربوط به یک Entity در سازمان را ارائه می کنند.

لایه سرویس های اتمیک (یکتا) : به طور مفید و مختصر یک کار یا یک سرویس مشخص در این سطح ارایه می شود.(بصورت مکانیزه).این لایه پایین ترین لایه معماری سرویس گرا محسوب می شود که در سطح فناوری یا فیزیکال حضور دارد. این سرویس ها به دو صورت طراحی و پیاده سازی می شوند :

  • مجزا
  • بر بستر نرم افزاهای موروثی یا Legacy Softwares

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

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

موارد ارتباط سرویس های اتمیک با Legacy Software ها از این قبیل است :

  • ERP
  • پایگاه های دادده
  • برنامه های پکیج شده
  • و …

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

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

در هم نواسازی ما دو تا عنصر اصلی داریم :

  • رهبر ارکستر
  • نوازندگان ابزارها (شما فرض کن سنتور که من عاشقشم)

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

اما تو رقصندگی ما چی داریم ؟

  • یه رقصنده داریم
  •  یه گروه از رقّاصان صحنه

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

هم نواساز سرویس (Service Orchestration) یک فرآیند کسب و کار قابل اجرای متمرکز منفرد (به مانند رهبر ارکستر) را ارئه می کند که نقش هماهنگی تعاملات فی ما بین سرویس های مختلف را بر عهده دارد.

در واقع Orchestrator یا هم نواساز دو تا وظیفه داره :

  • فراخوانی سرویس ها Service Invoke
  • ترکیب سرویس ها Service Combine

در واقع در Service Orchestration سرویس های چندگانه رو توسط یک Fixed Logic کنار هم قرار میدیم. این  Fixed Logic تو یه جای منفرد تشریح میشه. مثالش هم BPEL process هست. BPEL process شامل یه Logic هستش که می تونه چندین سرویس رو فراخونی کنه و Response هاشون رو یه عنوان یه Single Response Service ارائه کنه.

Orchestration زمانی مفید مواقع میشه که روی تمامی Actor های فرآیندمون کنترل داشته باشیم زمانی که همه اون Actor ها داخل یه Domain Control حاضر باشن و ما بتونیم جریان جریان کار رو دیکته کنیم. (dictate the flow of activities).

مساله دیگه اینکه هم نواسازی نسبت به رقصندگی دو تا مزیت داره :

  • قابلیت اطمینان Reliability
  • قابلیت تغییر Modifiability : ساخت و تغییر  process workflows و ترکیب سرویس های پیچیده (complex service compositions) در visual BPM tools که داخل پلت فرم های هم نواسازی هست آسون تره.

از سوی دیگه دیگه اینکه هم رقصندگی نسبت به هم نواسازی دو تا مزیت داره :

  • عملکرد Performance : هم نواساز هنگام تفسیر اسکریپت های جریان کار دچار یه سربار عملکرد (performance overhead) میشه
  • هزینه Cost : رقصندگی بر خلاف هم نواساز نیاز به زبان میانی یا زبان خاصی نداره

 

DevOps and Microservices

بررسی DevOps و Microservices

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

یه فعالیت دیگه که به نوعی DevOps محسوب میشه هم “تحویل مداوم” هست. همین تحویل مداوم از بخش های متصل و جدایی ناپذیر میکروسرویس ها هستش . از دیگر فعالیت های ضروری DevOps هم “مانیتورینگ مداوم” هست که باعث میشه یه سری بازخوردهای مرتبط با عملکرد سیستم رو به توسعه دهندگان برسونه ؛ علاوه بر این تشخیص آنومالی های عملیاتی رو تسریع می بخشه.

در واقع DevOps با بهره گیری از فاکتور سرعت باعث میشه که بهتر بتونه به مشتری هاش سرویس بده و اونا رو حفظ کنه. وقتی ما تحت مدل DevOps هستیم دیگه تیم توسعه و تیم عملیاتی به صورتی سیلویی (Siloed)  نیستتند. گاهی اوقات دو تا  تیم توسعه و تیم عملیاتی در قالب یک تیم ظاهر میشن و مهندس ها در سراسر چرخه خیات برنامه کار میکنن ؛ از توسعه و آزمایش برنامه گرفته تا استقرار و بحث عملیاتی.

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

افزایش استفاده از DevOps و Microservices بر مبنای Google

شکل بالا هم افزایش استفاده از DevOps و Microservices بر مبنای موتور جست و جوی گوگل رو نشون میده که از سال ۲۰۰۹ شروع به رشد داشته و در سال ۲۰۱۶ به اوج رشد خودشون رسیدن . رنگ آبی مربوط به DevOps هست و رنگ قرمز مربوط به Ms

اما DevOps چه مزایای داره ؟

سرعت

تحویل سریع و مداوم

قابلیت اطمینان

مقیاس پذیری

بهبود همکاری و ارتباطات تیمی

تامین امنیت

اینجا رو هم ببینید که محشره.

WSO2 چیست ؟

WSO2  یک  فناوری متن باز برای کسب و کارهای دیجیتال است که راه حل های مبتنی بر معماری سرویس گرا – Service-Oriented Architecture را برای توسعه دهندگان نرم افزار فراهم می آورد و تحت پشتیبانی شرکتی با همین نام WSO2 اداره می شود . WSO2 توسط Dr. Sanjiva Weerawarana  در آگوست ۲۰۰۵ راه اندازی شد و یکی از همکاران کلیدی پروژه عظیم وب سرویس آپاچی که شامل پروژه های Apache Axis2, Apache Rampart, Apache Synapse, Apache Axiom می شود می باشد . این فناوری تحت مجوز Apache License Version 2 بصورت رایگان منتشر می شود. این شرکت کنفرانسی را هم تحت عنوان WSO2Con در Colombo برگزار می کند که در رابطه با  SOA, Cloud Computing, IT strategies بحث می کنند.

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

  • مسیر یابی پیام – Message routing
  • Message transformation
  • سوییچ بین پروتکل ها – Protocol switching
  • نگاشت داده – Data mapping.
  • تحلیل و ردیابی پیام ها – Message tracing and analytics.
  • امکان یکپارچه شدن با رابط های کاربردی نرم افزاری فضای ابری (سرویس ایمیل گوگل ، توییتر و …)  – Integration with cloud APIs (e.g. Salesforce, Gmail, and Twitter) using 160+ cloud connectors.
  • امکان یکپارچه شدن با پایگاه های داده و سرویس های ارایه دهنده داده – Integration with databases and offer data services.
  • Integration with proprietary systems (e.g. SAP, FIX, and HL7)

WSO 2 Identity Server  ؟

یک سرویس مدیریت متن باز اعتبارسنجی است که از استانداردهای زیر تبعیت می کند :

  • OpenID
  • OAuth 1.0a/2.0
  • XACML 2.0/3.0
  • SAML2
  • WS-Trust/STS
  • SCIM
  • XKMS
  • User Management
  • Connectors to AD/LDAP

WSO 2 Identity Server به منظور رفع اشکالات اعتبارسنجی ایجاد شده است و به مدیریت اعتبارسنجی نرم افزارهای تحت وب و API’s می پردازد.


پروتکل های سرویس گرایی – SOAP

SOAP که سر واژه کلمات Simple Object Access Protocol هست ، فرمت تبادل پیام در قالب XML می باشد که در تعاملات وب سرویس ها استفاده می شود. غالب پیام های SOAP بر بستر HTTP یا JMS انتقال می یابند با این وجود دیگر پروتکل های انتقال هم می توانند استفاده شوند. استفاده از SOAP خاصه در وب سرویس ها توسط WSDL – (Web Service Definition Language) تعریف می شود.

SOAP
SOAP

SOAP در مستندات زیر توسط کنسرسیوم وب جهانی W3C به خوبی تشریح شده است :

برای کسب اطلاعات بیشتر اینجا را ببینید.

پیام های SOAP همچون نامه های پستی در قالب یک Envelope (پاکت) در بستر اینترنت ارسال می شوند. همانطور که بالاتر هم اشاره شد SOAP یک استاندارد از سوی W3C می باشد. در واقع SOAP به عنوان جایگزینی برای REST , JSON می باشد. (پیش تر در مقاله معماری وب گرا در رابطه با تفاوت های SOAP , REST توضیحاتی نوشتم که می توانید در اینجا آنها را بخوانید)

ساختار SOAP بدین شکل هست :

ساختار پیام SOAP
ساختار پیام SOAP

پاکت نامه SOAP حاوی دو بخش است :

  • سرآیند اختیاری (Optional Header) که اطلاعاتی رو به منظور احراز هویت ، کدینگ داده ها ، یا چگونگی پردازش این پیام توسط گیرنده اشاره دارد.
  • بدنه محتوی که حاوی پیام هست. این پیام توسط WSDL تعریف می شود.

تو شکل بالا هم که کشیدم اشاره کردم که SOAP غالبا از HTTP بهره می بره ولی می تونه از پروتکل های دیگه مثل SMTP (Simple Mail Transfer Protoco)l هم استفاده کنه.

نکته : زمانی که SOAP شروع به کار کرد حروفش مخفف Simple Object Access Protocol بودند ولی از زمانی که ورژن ۱٫۰۲ استارت خورد این حروف دیگر معنای خاصی را القاء نمی کنند.

پس SOAP شامل سه بخش است :

  • Envelope
    • Packet Local Name
    • zero or more Quality Attribute
    • Body (Not Optional)1
  • Header
    • استایل رمزنگاری
    • نقش (Role)
  • Body
    • A Local name
    • A Namespace name
    • zero or more Attribute
    • zero or more Elements

توجه شود که Envelope اجباری است بر خلاف سرآیند که اختیاری است ،

ارتباط پروتکل SOAP و وب سرویس ها هم اینطوره :

پروتکل SOAP و وب سرویس ها
پروتکل SOAP و وب سرویس ها

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

تفاوت های معماری سرویس گرا با میکروسرویس ها

در رابطه با معماری سرویس گرا و میکروسرویس ها باید گفت هر دو زیر مجموعه از تفکر سرویس گرایی هستند و نقطه مشترکی که دارند بحث Distribution (توزیع پذیری) هست. در معماری سرویس گرایی بخش هایی از نرم افزار تو شِمای سرویس encapsulate (کپسوله) میشوند. حالا این کپسوله سازی رو همونطور که قبلا هم حتما شنیدید به این مساله اشاره داره که سرویس ها بصورت مجزی از هم طراحی می شوند.

سرویس ها هم در معماری به دو صورت طبقه بندی میشن :

  • Service Type (سطح الگوی معماری)
  • Business Type (سطح پیاده سازی)

تو میکروسرویس ها هم Service Type به دو صورت هست :

  • Functional
  • Infrastructure

به این صورت که کلاینت میاد یه درخواستی رو به سمت لایه API ارسال میکنه ، لایه API هم میاد منتقلش میکنه به سطح عملیات سرویس و اینجا هم تقاضای سرویس به سطح زیربنایی سرویس فرستاد میشه ، حالا شکلش رو میکشم بهتر متوجه بشیم :

 

تو SOA هم سرویس ها دو دسته هستند :

  • Business Service مثل XML , WSDL , BPEL ( سطح تجرید اینجا بالا هست)
  • Enterprise Service که مثلا تحت چارچوب دات نت با زبان سی شارپ پیاده سازی صورت بگیره یا …
  • Application Service
  • Infrastructure Service

اما  چطوره ؟

مدل مالکیت میکروسرویس هم بدین شکله :

مدل مالکیت میکروسرویس
مدل مالکیت میکروسرویس

تو SOA هر سرویسی صاحب خودشو داره ولی تو میکروسرویس این یه تیم هستش که درگیر میشه بر خلاف SOA که چند تا تیم میان درگیر چند تا سرویس میشن و این یه نقطه منفی واسه SOA محسوب میشه و همین ویژگی منفی باعث شده میکروسرویس ها بالاتر از SOA باشن. از منظر Granularity (دانه بندی) هم سرویس ها هستش که چون اندازه کوچکتری دارن :

  • سریع تر تولید میشن
  • سریع تر تو پروژه استقرار پیدا میکنن
  • سریع تر هم تست میشن

پس در این صورت میشه مزایای میکروسرویس ها رو اینا بر شمرد :

  • هزینه میاد پایین
  • زمان کمتری واسه توسعه نیاز هست
  • مشتری های رضایت بیشتری دارن
  • Stakeholder ها هم راضی ترن

الآن چلش اصلی SOA همین بحث  Granularity (دانه بندی) هستش که متاسفانه برخی معماران درک درستی ازش ندارن ؛ بعضی سرویس ها خیلی ریز طراحی میشن ، بعضی سرویس ها هم خیلی درشت . اگه یادتون باشه تو پایگاه داده یه قانون داشتیم به نام ACID که طبق اون اگه دانه بندی خیلی ریز باشه ما نمی تونیم سرویس ها رو با هم Synchronize کنیم.

دانه بندی هم رو دو تا فاکتور تاثیر میذاره :

  • Functionality
  • Transaction Management

میکرو سرویس ها :

  • Small Size
  • Small Structure

بحث دیگه ای هم که مطرح هست موضوع Component Share هست که SOA و Micro services با هم تفاوت دارند که سرویس گرایی بیشترین اشتراک رو داره بر خلاف میکروسرویس ها که کمترین اشتراک رو داره و همین شده واسش مزیت ! اما چرا ؟

  • چون که Modules Dependency پایین هستش پس نگهداری آسون تره چون که تکامل سرویس ها مستقل از سرویس های دیگه ست.
  • دوم اینکه فاز استقرار راحت تره ممکن هست ، چون که حجم کدهایی که تغییر میکنه زیاد نیست
  • سوم اینکه ریسک تاثیر تغییر یه سرویس به باقی سرویس ها میادش پایین

 

وب سرویس ها در معماری سرویس گرا

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

نقش وب سرویس ها در معماری سرویس گرا
نقش وب سرویس ها در معماری سرویس گرا

نسخه انگلیسی تصویر در اینجا قابل مشاهده است.