https://virgool.io/feed/@sajadko ?‍?دانشجوی علوم کامپیوتر ? علاقه مند به نرم افزار و یادگیری ماشین و یادگیری عمیق fa 2026-06-24 19:48:00 https://files.virgool.io/upload/users/1555224/avatar/fqFJnZ.jpeg?height=120&width=120 https://virgool.io/@sajadko https://virgool.io/@sajadko/message-brokers-jutifatpaztq منبع تصویر : unsplash.comکارگزار ها یا واسط های پیام ( Message Brokers ) یک تکنولوژی و فناوری ارتباطی میان اپلیکیشن ها هستند که به ایجاد مکانیزم ادغام سازی و یکپارچه سازی مشترک برای پشتیبانی از معماری های که ابری ( cloud native )، بر اساس میکروسرویس ها ، بدون سرور ( Serverless ) و هیبرید هستند کمک میکنند . کارگزار ها یا واسط های پیام چه هستند ؟ یک واسط یا کارگزار پیام ( Message Broker ) ، نرم افزاری است که اپلیکیشن ها ، سیستم ها و سرویس ها را قادر می سازد تا با یک دیگر در ارتباط باشند و اطلاعات مبادله کنند . کارگزار پیام ، این کار را از طریق ترجمه کردن message ها بین پروتکل های رسمی پیام انجام می دهد . این کار به سرویس های مستقل اجازه می دهد تا به صورت مستقیم بایکدیگر " گفتگو" کنند . حتی اگر به زبان های مختلف نوشته شده باشند یا اینکه در پلتفرم های متفاوتی پیاده سازی شده باشند . واسط های پیام ( Message Brokers ) ، ماژول های نرم افزاری هستند که از جمله راه حل های میان افزار پیامرسانی ( messaging middleware ) یا میان افزار پیام گرا ( message-oriented middleware - MOM ) هستند . این نوع میان افزار ( middleware) ابزار های استانداردی را برای مدیریت جریان داده ها ( Data Flow ) میان قسمت های یک اپلیکیشن فراهم میکند و در اختیار توسعه دهندگان قرار میدهد تا آن ها بتوانند بر روی منطق اصلی و Core Logic اپلیکیشن تمرکز داشته باشند . این واسط ها ، می توانند به عنوان یک لایه ارتباطی توزیع شده عمل کنند که اجازه میدهد اپلیکیشن های موجود در چندین پلتفرم ، به صورت داخلی بایکدیگر ارتباط برقرار کنند . واسط ها یا کارگزار های پیام ( Message Brokers ) می توانند پیام ها را اعتبارسنجی ( validate ) ، ذخیره ، مسیر یابی کنند و به مقصد مناسب و مورد نظر ارسال کنند . همچنین به عنوان واسط میان اپلیکیشن های دیگر عمل می کنند و به فرستنده ها این امکان را می دهند که بدون اینکه بدانند گیرنده ها در کجا هستند ، آیا فعال هستند یا نه ، یا تعداد آن ها چقدر است ، پیام هایشان را ارسال کنند . این کار واسط ها یا کارگزار های پیام ، امر جداسازی فرایند ها و سرویس ها در سیستم ها را تسهیل و آسان می کند .واسط ها یا کارگزار های پیام ( Message Brokers ) ، برای ذخیره مطمئن پیام ها و تضمین تحویل پیام ها ، معمولا به زیرساختی به نام صف پیام یا Message Queue متکی هستند که پیام ها را تا زمانی که اپلیکیشن مصرف کننده بتواند آن ها را پردازش کند ، ذخیره و مرتب سازی سازی می کند . در یک صف پیام ، پیام ها دقیقا به همان ترتیبی که ارسال شده اند ، ذخیره می شوند و تا زمانی که دریافت پیام تایید شود ، در صف باقی خواهند ماند .معماری RabbitMQ که یکی از Message Broker های محبوب استپیام رسانی ناهمزمان ( Asynchronous Messaging ) ، یکی از انواع ارتباط میان اپلیکیشن ها است که واسط های پیام ( Message Brokers ) آن را ممکن می سازند . پیام رسانی ناهمزمان ، جلوی از دست دادن داده های ارزشمند را می گیرد و این امکان را فراهم می سازد که حتی در مواردی که مشکلات اتصال و تاخیر که در شبکه های عمومی رایج است ، رخ دهد ، سیستم ها به عملکرد خود ادامه دهند . پیام رسانی ناهمزمان تضمین می کند که پیام ها فقط و فقط یک بار با ترتیبی صحیح نسبت به پیام های دیگر ، تحویل داده می شوند.واسط ها یا کارگزار های پیام ممکن است در بردارنده مدیران صف ( Queue Managers ) باشند تا تعاملات و ارتباط بین صف های پیام متعدد ، همچنین سرویس هایی که مسیریابی داده ها ، ترجمه پیام ها ، پایداری و عملکرد های مدیریت وضعیت کلاینت ها را فراهم میکنند ، را انجام دهند .مدل های کارگزار یا واسط پیام ( Message Broker Models )واسط ها یا کارگزار های پیام ( Message Brokers ) ، دو الگوی اصلی توزیع پیام یا استایل پیام دادن را ارائه میدهند :پیام رسانی نقطه به نقطه ( Point-to-Point Messaging ) : این الگوی توزیع پیام در صف های پیام با یک رابطه یک به یک میان فرستنده و گیرنده پیام ، مورد استفاده قرار می گیرد . هر پیام موجود در صف فقط برای یک گیرنده ارسال می شود و فقط یک بار مورد مصرف واقع می شود . پیام رسانی نقطه به نقطه زمانی مورد استفاده قرار میگیرد که یک پیام فقط باید یک بار عمل کند . نمونه هایی از استفاده از این مدل ، میتوان پرداخت حقوق و پردازش تراکنش های مالی را مثال زد . در این سیستم ها هم فرستنده و هم گیرنده نیاز به این ضمانت دارند که هر پرداختی فقط و فقط یک بار ارسال شود .پیام رسانی انتشار / اشتراک ( Publish / Subscribe Messaging ) : در این الگوی توزیع پیام ، که معمولا تحت عنوان "pub/sub" مطرح می شود ، تولید کننده هر پیام ، آن پیام را در یک topic منتشر و publish می کند و چندین مصرف کننده پیام به موضوعاتی که میخواهند پیام های آن ها را دریافت کنند subscribe می کنند و درواقع مشترک آن topic می شوند . همه پیام های منتشر شده در یک topic یا موضوع ، به همه اپلیکیشن هایی که مشترک و subscribed آن موضوع یا topic هستند ، توزیع می شود . این روش توزیع به سبک Broadcast یا پخش می باشد که در آن یک رابطه یک به چند ( One to Many ) بین تولید کننده پیام و مصرف کنندگان آن پیام وجود دارد .برای مثال یک شرکت هواپیمایی قرار است که بروزرسانی هایی را در مورد زمان فرود یا وضعیت تاخیر پرواز های خود منتشر کند ، چندین طرف میتوانند از این اطلاعات استفاده کنند : خدمه روی زمین که نگهداری و سوخت گیری هواپیما را بر عهده دارند - حمل کننده های چمدان ها - مهماندار ها و خلبانان سفر بعدی هواپیما - اپراتور های نمایشگر های موجود در فرودگاه که مردم را مطلع می کنند. استایل پیام رسانی pub/sub برای چنین سناریو و شرایطی می تواند مناسب باشد . کارگزار های پیام در معماری های ابری ( Cloud Architectures )اپلیکیشن های native ابری ، برای استفاده از مزایای رایانش ابری ، از جمله انعطاف پذیری و مقیاس پذیری ( Scalability ) و گسترش سریع ، ساخته شده اند . این اپلیکیشن ها از قسمت های کوچک ، گسسته و با قابلیت استفاده مجدد ساخته شده اند که میکروسرویس ها نامیده می شوند . هر میکروسرویس میتواند مستقل از سایر میکروسرویس ها ، گسترش یابد و اجرا شود . این به این معنی است که هر کدام از این میکروسرویس ها میتوانند بدون تاثیر بر سرویس های دیگر موجود در سیستم ، بروزرسانی و توسعه و راه اندازی مجدد شود . میکروسرویس ها که به طور معمول در کانتینر ها ( Containers ) بسته بندی می شوند ، باهم کار می کنند تا یک اپلیکیشن کامل را تشکیل دهند . ولی هر کدام از این میکروسرویس ها دارای Stack و فناوری خاص خود هستند ، که شامل پایگاه داده و مدل داده که ممکن است متفاوت از بقیه میکروسرویس ها باشد .میکروسرویس ها باید ابزاری برای برقراری ارتباط با یکدگیر را در اختیار داشته باشند تا بتوانند به صورت هماهنگ با یکدیگر عمل کنند . واسط ها یا کارگزار های پیام ( Message Brokers ) ، یکی از مکانیسم هایی هستند که میکروسرویس ها استفاده میکنند تا پایه و اساس و ستون های این ارتباط مشترک را ایجاد کنند . کارگزار های پیام ، معمولا برای مدیریت ارتباط بین سیستم های داخلی ( on-premises ) و قسمت ها و کامپوننت های ابری در محیط های هیبرید ابری مورد استفاده قرار می گیرند . استفاده از کارگزار پیام یا همان Message Broker ، کنترل بیشتری بر ارتباط میان سرویسی ایجاد میکند و تضمین میکند که داده ها به طور امن و قابل اعتماد و درست و کارآمد بیت قسمت های یک اپلیکیشن ارسال می شوند. کارگزار های پیام ، میتوانند نقش مشابهی را در یکپارچه سازی محیط های چندابری ( MultiCloud ) ایفا کنند و ارتباط بین Workload ها و زمان های اجرا ( Runtimes ) را در پلتفرم های مختلف امکان پذیر کنند . کارگزار های پیام همچنین برای استفاده در پردازش های Serverless یا همان Serverless Computing مناسب هستند که در آن ، سرویس های میزبانی ابری مفرد و جداگانه ، بر اساس تقاضا ( on-demand ) و بر اساس درخواست ( per-request ) اجرا می شوند . کارگزار های پیام در مقایسه با API ها ( Message Brokers vs APIs )از REST API ها معمولا برای ارتباط بین میکروسرویس ها مورد استفاده قرار می گیرند . عبارت زیر Representational State Transferیا به اختصار REST یکسری مفاهیم و اصول را بیان و تعریف میکند که توسعه دهندگان می توانند به هنگام ساخت وب سرویس های خود از آن ها پیروی کنند . هر سرویسی که به این مفاهیم و اصول پایبند باشد ، می تواند به کمک یکسری از اپراتور ها و درخواست های مشترک Stateless ، با یکدگیر ارتباط برقرار کند . عبارتApplication Programming Interfaceیا به اختصار API ، نشان دهنده کد پایه ای است که اگر با قوانین REST مطابقت داشته باشد ، به سرویس ها این اجازه را می دهد که با یکدیگر صحبت کنند . REST API ها از Hypertext Transfer Protocol یا HTTP استفاده می کنند . چون HTTP پروتکل استاندارد انتقال اینترنت عمومی است ، REST API ها به طور گسترده شناخته شده هستند و زیاد مورد استفاده قرار می گیرند و به طور گسترده ای قابل تعامل هستند . پروتکل HTTP یک پروتکل request/response می باشد . با این حال ، بهترین شرایطی که برای استفاده از این پروتکل وجود دارد شرایطی است که یک request/reply همزمان ( Synchronous ) را نیاز دارد . این به این معنا است که سرویس هایی که Request هایی را از طریق REST APIs ایجاد می کنند ، باید به گونه ای طراحی شوند که انتظار یک پاسخ سریع و فوری را داشته باشند . اگر کلاینت دریافت کننده پاسخ ، قطع ( down ) باشد ، سرویس ارسال تا زمانی که در انتظار پاسخ است مسدود می شود . مدیریت خطا ( Error Handling ) باید در هر دو سرویس نوشته و تعبیه شود . کارگزار های پیام ( Message Brokers ) ارتباط ناهمزمان یا asynchronous را بین سرویس ها فراهم می کنند تا سرویس ارسال کننده ، منتظر پاسخ سرویس گیرنده نباشد . این کار باعث بهبود تلرانس ( تحمل ) خطا و انعطاف پذیری سیستم ها می شود . همچنین استفاده از کارگزار های پیام ، گسترش سیستم ها را آسان تر می کند ، زیرا یک الگوی پیام رسانی pub/sub ، به راحتی از تغییر تعداد سرویس ها پشتیبانی می کند . کارگزار های پیام همچنین وضعیت مصرف کنندگان را نیز پیگیری میکنند . کارگزار های پیام در مقایسه با پلتفرم های Event Streamingکارگزار های پیام ( Message Brokers ) می توانند از دو یا تعداد بیشتری الگوی پیام رسانی از جمله صف های پیام ( Message Queues ) و pub/sub پشتیبانی کنند ، در حالی که پلتفرم های Event Streaming یا پلتفرم های جریان رویداد فقط از استایل توزیع پیام pub/sub پشتیبانی می کنند . این پلتفرم ها که برای استفاده با حجم بالایی از پیام ها طراحی شده اند ، به آسانی قابل گسترش هستند . آن ها می توانند استریم های ریکورد ها را در دسته هایی به نام topic مرتب کنند و آن ها را برای مدت زمانی که از پیش تعیین شده ، ذخیره کنند . بر خلاف کارگزار های پیام ، این پلتفرم ها نمیتوانند تحویل پیام را تضمین کنند یا ردیابی کنند که مشتری های کدام پیام ها را دریافت کرده اند .پلتفرم های Event Streaming ، گسترش و Scalability بیشتری را نسبت به کارگزار های پیام ارائه می دهند . اما ویژگی های کمتری ارائه میدهند که تلرانس خطا ( مانند ارسال مجدد پیام ) و قابلیت های مسیریابی و روتینگ و صف بندی پیام ها با محدودیت بیشتر را تضمین می کنند .موارد استفاده از کارگزار های پیام ( Message Brokers )پیاده سازی Message Broker ها می تواند طیف عظیمی از نیاز های بیزینسی را در صنایع و محیط های سازمانی گوناگون برطرف کند . Message Broker ها در هر زمانی و مکانی که به ارتباط قابل اعتماد و تحویل با اطمینان پیام بین اپلیکیشن ها نیاز باشد ، مفید هستند . معمولا به روش های زیر ، Message Broker ها به کار گرفته می شوند :تراکنش های مالی و پردازش پرداخت ها : بسیار مهم و حیاتی است که مطمئن باشیم پرداخت ها فقط و فقط یک بار ارسال می شوند . استفاده از Message Broker ها برای رسیدگی به داده های این تراکنش ها تضمین می کند که اطلاعات پرداخت ، نه از بین می رود و نه به طور تصادفی تکرار می شود ، تایید دریافت را فراهم می کند و به سیستم ها اجازه می دهد به طور قابل اعتمادی حتی زمانی که شبکه های واسطه از کار افتاده باشند ، ارتباط برقرار کنند .پردازش و انجام سفارشات E-Commerce : اگر بیزینس آنلاین انجام می دهید ، قدرت و شهرت برند شما به میزان قابلیت اطمینان به سایت و پلتفرم شما بستگی دارد . قابلیت های کارگزار های پیام برای افزایش تلرانس و تحمل خطا و تضمین اینکه پیام ها یکبار و فقط یکبار مصرف می شوند ، آن ها را به انتخابی طبیعی برای استفاده در هنگام پردازش سفارش های آنلاین تبدیل می کند .حفاظت از داده های بسیار مهم و حساس در حالت استراحت و جابجایی : اگر صنعت شما به شدت تحت نظارت است یا کسب و کار شما با خطرات امنیتی قابل توجهی مواجه است ، می توانید از یک راه حل پیامرسانی و messaging با قابلیت رمزگذاری سرتاسر ( end-to-end ) استفاده کنید . نمونه های Message Brokers : محبوب ترین کارگزار ها یا واسط های پیام عبارتند از :RabbitMQ , Apache Kafka , Redis , Amazon SQS , Amazon SNSهمه مواردی که ذکر شد جزو ابزار های خیلی عالی و برتر در این زمینه هستند و در مواقعی که لود کار پایین است تفاوتی را بین آن ها از نظر پرفرومنس احساس نمی کنید . ولی زمانی که در مقیاس های عملیاتی گسترده و پیشرفته کار کنیم ، هر کدام از این ها ، به طور متفاوتی کار میکنند .نتیجه گیریاپلیکیشن های مدرن ، روز به روز پیچیده تر می شوند . عملیات های مصرف کننده زمانی و منابعی ، ارتباط بین چندین سرویس ، پردازش داده های زیاد و … فقط تعدادی از مشکلاتی هستند که توسعه دهنده ها با آن ها دست و پنجه نرم می کنند . برای رفع این مشکلات میتوانیم از Message Broker ها استفاده کنیم که بسیاری از مشکلات مطرح شده را تا حد زیادی رفع می کنند و در صرفه جویی منابع و زمان کمک بسیاری به ما میکنند . منبع :ibm.com/cloud سجاد کلاه چی سجاد کلاه چی Wed, 30 Mar 2022 20:15:12 +0430 https://virgool.io/@sajadko/microservices-fo9giios0q7i منبع تصویر : unsplash.comمعماری میکروسرویس ها ( Microservices Architecture ) ، رویکرد و روشی است که در آن یک اپلیکیشن واحد ، از تعداد زیادی سرویس های کوچک تر که خود آزاد و مستقل هستند تشکیل می شود .میکروسرویس ها چه هستند ؟میکروسرویس ها ( معماری میکروسرویس ها ) یک رویکرد معماری native ابری می باشد که یک اپلیکیشن واحد از تعداد زیادی سرویس های کوچک تر که خود مستقل و آزاد هستند تشکیل شده است که این سرویس ها معمولا دارای ویژگی های زیر می باشند :تکنولوژی های مخصوص خود را دارند که شامل پایگاه داده ها و مدل مدیریت داده می شود این سرویس ها با ترکیبی از REST API ها و Message Broker ها و Event Streaming ها باهم ارتباط برقرار می کنند ( که هر کدام از این موارد جزئیات بسیار فراوانی را شامل می شود )با اینکه بیشتر بحث مربوط به میکروسرویس ها ، حول محور تعاریف و ویژگی های مروبط به این معماری نرم افزاری می چرخد ، می توان ارزش میکروسرویس ها را از طریق مزایای تجاری و سازمانی به خوبی متوجه شد:کد های مربوط به نرم افزار بسیار ساده تر و راحت تر می توانند بروزرسانی و Update شوند و همچنین قابلیت ها و functionality های جدید را می توان بدون اینکه کل اپلیکیشن مورد دستکاری قرار بگیرد ، اضافه شوند.تیم ها میتوانند از زبان های برنامه نویسی و تکنولوژی های متفاوتی برای هر قسمت استفاده کنند . هر جزء و قسمت را می توان جدا و بدون وابستگی به اجزای دیگر ، گسترش داد که این خود باعث می شود تا هزینه ها و ضایعات مربوط به گسترش کل اپلیکیشن به صورت یک واحد ، کاهش یابد.همچنین از طریق مقایسه معماری میکروسرویس ها با معماری های دیگر میتوان به درک بهتری از این معماری نرم افزاری رسید . برای مثال می توان دو معماری میکروسرویس ها و معماری یکپارچه را مورد مقایسه قرار داد . تفاوت میان معماری میکروسرویس ها و معماری یکپارچه این است که در میکروسرویس ها ، یک اپلیکیشن به تعداد زیادی سرویس کوچک تر که خود مستقل هستند تقسیم می شود ولی در معماری یکپارچه این گونه نیست و اپلیکیشن یک واحد بزرگ است و به نحوی که در میکروسرویس ها داریم ، قابل تقسیم نیست . مزایای میکروسرویس ها برای سازمان ها میکروسرویس ها همانقدر که در بین توسعه دهندگان نرم افزار محبوبیت دارند ، در میان مدیران اجرایی و مدیران پروژه ها نیز محبوب هستند . این خود یکی از ویژگی های خاص میکروسرویس ها می باشد زیرا معمولا دغدغه و بحث های مربوط به معماری مورد استفاده برای نرم افزار ، در تیم های توسعه نرم افزار قرار دارد . زیرا میکرو سرویس ها ، روش و رویکردی را که خیلی از مدیران بیزینس ها در نظر دارند تا تیم ها و پروسه توسعه خود را بر اساس آن پیاده سازی کنند ، را بهتر منعکس می کنند .به عبارت دیگر ، میکروسرویس ها یک معماری هستند که یک مدل عملیاتی مورد نظر را بهتر تسهیل و آسان میکنند . در نظرسنجی که اخیرا در سال 2021 شرکت IBM ( که یکی از شرکت های عظیم تکنولوژی می باشد ) درباره میکروسرویس ها از حدود 1200 توسعه دهنده و مدیر فناوری اطلاعات انجام داده است ، حدود 87 درصد از کاربرانی که از میکروسرویس ها استفاده می کنند ، تایید کرده اند و موافق هستند که رفتن به سمت معماری میکروسرویس ها و پذیرش این معماری ، ارزش هزینه و تلاش مورد نیازش را دارد .گسترش مستقلانهاحتمالا مهمترین ویژگی معماری میکروسرویس ها این باشد که چون سرویس ها کوچک تر هستند ، برای تغییر یک خط کد یا اضافه کردن امکانات جدید ، نیازی به تصمیم گیری های عظیم وجود ندارد و تغییرات ساده تر و سریع تر می توانند انجام پذیرند .میکروسرویس ها در سازمان ها این قابلیت را ایجاد میکنند که بسیاری از مشکلاتی و دغدغه های مربوط به اینکه یک تغییر کوچک ، هزینه زمانی بسیاری را در پی خواهد داشت ، را کاهش دهند و این موضوع که رویکردی که سرعت و چابک بودن ( Agile ) را تسهیل کند ، بسیار ارزشمند است ، کاملا واضح می باشد . ولی سرعت ، تنها مزیت طراحی سرویس ها از طریق این معماری نیست . یکی از مدل های سازمانی در حال رایج و ترند شدن این است که تیم های مختلف ، حول یک مشکل بیزینسی یا سرویس یا محصول گرد هم جمع شوند. مدل میکروسرویس ها به خوبی با این مدل و روند مطابقت می کند. چون سازمان ها را قادر می سازد تا تیم های کوچک و متقابلی را حول یک سرویس یا مجموعه ای از سرویس ها جمع کند و آن ها را با شیوه ای چابک و Agile ، به کار گیرد . اینکه این در میکروسرویس ها ، سرویس ها به هم وابسته نیستند ، باعث می شود که ایزوله سازی خطا و انعطاف پذیری بهتری در اپلیکیشن ایجاد شود . کوچک بودن سرویس ها به همراه مشخص بودن حدود و مرز های آن ها و همچنین واضح بودن نحوه ارتباط آن ها با هم ، باعث می شود که اعضای جدید که وارد تیم می شوند ، کد ها را بتوانند بهتر درک کنند و سریع تر بتوانند در پروژه مشارکت داشته باشند . ( نمونه ای واضح از مزایای میکروسرویس ها در زمینه سرعت و روحیه اعضای تیم )ابزار مناسب برای کار در معماری های سنتی ، معمولا یک اپلیکیشن ، یک سری تکنولوژی یا درواقع stack مشترک را به همراه یک پایگاه داده رابطه ای بزرگ که از کل اپلیکیشن پشتیبانی می کند را شامل می شود . این رویکرد چندین مشکل دارد . مشخص ترین مشکل این رویکرد آن است که تمام قسمت های اپلیکیشن باید از همان تکنولوژی مشترک و مدل داده و پایگاه داده استفاده کنند حتی با اینکه ابزار های مناسب تری برای کار برخی از قسمت ها وجود داشته باشد . این باعث ایجاد یک معماری بد می شود و همچنین برای توسعه دهنده هایی که آگاه به این موضوع هستند که ابراز ها و راه ها و رویکرد های بهتر و بهینه تری برای ساخت قسمت هایی از اپلیکیشن وجود دارد ، آزار دهنده می باشد .در مقابل ، در یک مدل میکروسرویس ها ، قسمت ها مختلف اپلیکیشن به صورت مستقل گسترش داده می شوند و از طریق ترکیبی از REST API ها و Message Broker ها و Event Streaming ها ارتباط بر قرار میکنند . بنابراین امکان این وجود دارد که برای هر بخش و قسمت ، تکنولوژی و Stack و رویکرد مناسب و بهینه برای آن قسمت را در گسترش آن به کار ببریم . تکنولوژی هرلحظه و هر زمان در حال تغییر می باشد و قطعا اپلیکیشنی که از قسمت ها و سرویس های کوچک و مستقل تشکیل شده باشد ، توسعه آن با تکنولوژی های جدید و مورد نظر ، آسان تر و کم هزینه تر خواهد بود .چالش های موجودمیکروسرویس ها با اینکه مزایای زیادی دارند ولی این مزایا چالش هایی را به همراه خود دارد . انتقال از معماری یکپارچه به معماری میکروسرویس ها به معنای پیچیدگی بیشتر در مدیریت ، سرویس های بیشتر که توسط تیم های بیشتری در مکان های بیشتری ساخته شده اند می باشد . مشکل در یکی از سرویس ها می تواند در سرویس های دیگر مشکل ایجاد کند یا اینکه خود نتیجه مشکل در یک سرویس دیگر بوده باشد . لاگ کردن داده ها ( که برای مانیتورینگ و بررسی مشکلات استفاده می شود ) ارزش بیشتری پیدا می کند . نسخه های جدید می توانند مشکل سازگاری با نسخه های قبلی را ایجاد کند . اپلیکیشین ها شامل اتصالات شبکه بیشتری خواهند بود که به این معنی است فرصت بیشتری برای مشکلات مربوط به تاخیر و اتصالات ایجاد خواهد شد. استفاده از راهکار DevOps می تواند بسیاری از این مشکلات را تحت پوشش قرار دهد ولی خود این راه کار ، چالش های مربوط به خود را دارد !با این حال ، این چالش ها باعث نمی شود که حرکت به سمت این معماری با توجه به مزایای زیادی که دارد ، متوقف شود و افرادی را که هنوز از این معماری استفاده نکرده اند را از حرکت به سمت آن باز نمی دارد . همچنین افرادی را که از این معماری استفاده میکنند را از ادامه استفاده و عمیق تر شدن باز نمی دارد . در نظرسنجی اخیر شرکت IBM ، داده ها نشان می دهد که 56 درصد کابرانی که از میکروسرویس ها استفاده نمی کنند ، شاید یا به احتمال زیاد در طی دو سال آینده از معماری میکروسرویس ها استفاده خواهند کرد و 78 درصد از کاربران فعلی که در حال استفاده از این معماری هستند ، احتمالا زمان و منابع مالی و تلاش بیشتری را در این زمینه سرمایه گذاری خواهند کرد . میکروسرویس ها هم استفاده از DevOps را فعال تر می کنند و هم به آن نیاز دارند !معماری میکروسرویس ها به طور معمول ، تحت عنوان بهینه سازی شده برای DevOps و CI/CD مطرح می شوند که در چون سرویس های کوچک می توانند به طور مکرر مورد گسترش و توسعه قرار گیرند ، درک این عنوان واضح است . (منظور از CI/CD عبارت Continuous integration / Continuous Delivery می باشد )اما اگر بخواهیم از زاویه دیگری به رابطه بین میکروسرویس ها و DevOps نگاه کنیم ، درواقع می توان گفت که معماری میکروسرویس ها برای موفق بودن ، به DevOps نیاز دارد . با اینکه اپلیکیشن هایی با معماری یکپارچه مشکلاتی را دارند که قبلا در همین مقاله به آن اشاره شد ، یکی از مزیت های آن ها این است که این اپلیکیشن ها ، سیستم های توزیع شده با قسمت های مختلف که هر کدام تکنولوژی و stack خاص و مستقل خود را دارند، نیستند . در مقابل ، با توجه به افزایش در پیچیدگی ، قسمت های مستقل و وابستگی های مربوط به میکروسرویس ها ، استفاده کردن از این معماری و نزدیک شدن به آن بدون توجه و سرمایه گذاری قابل قیاس در توسعه و استقرار و نظارت و مانیتورینگ و اتوماسیون چرخه حیات ( Lifecycle ) کار غیر عقلانی و به دور از اندیشه می باشد . ابزار ها و فناوری های کلیدی در میکروسرویس ها با اینکه تقریبا هر زبان و ابزار مدرنی را میتوان در این معماری مورد استفاده قرار داد ، ولی یکسری از ابزار های مهم و کاربردی وجود دارند که برای استفاده از این معماری ، نقش پایه و اساسی دارند :استفاده از Container ها ، Docker و Kubernetesیکی از ویژگی های کلیدی یک میکروسرویس این است که به طور کلی ، بسیار کوچک است . ( البته هیچ مقدار دلخواهی از کد یا تعداد خطوط کد وجود ندارد که تعیین کند که مثلا یک سرویس ، میکروسرویس به حساب می آید یا نه ، ولی همانطور که در طول این مقاله مشاهده کردید ، عبارت "میکرو" در نام این معماری وجود دارد )هنگامی که داکر در سال 2013 ، عصر کانتینر های مدرن را اغاز کرد ، همچنین یک مدل محاسباتی را معرفی کرد که ارتباط زیادی با میکروسرویس ها داشت . چون کانتینر های مفرد و مجزا ، سربار سیستم عامل خود را ندارند ، نسبت به VM ها یا همان ماشین های مجازی ( Virtual Machines ) سنتی ، سبک تر و کم حجم تر هستند و عملکرد سریع تری خواهند داشت . این منجر به این است که با سرویس های کوچک تر و سبک تر موجود در معاری میکروسرویس ها ارتباط و مطابقت کاملی داشته باشند . با افزایش سرویس ها و کانتینر ها ، مدیریت گروه های عظیم کانتینر ها ، سریعا تبدیل یه یکی از چالش های مهم و حیاتی شد . Kubernetes که یک پلتفرم متن باز مدیریت کانتینر ها می باشد ، به عنوان یکی از محبوب ترین راه حل های مدیریت کانتینر ها مورد استفاده قرار میگیرد و این کار را به خوبی انجام می دهد . استفاده از API هامیکروسرویس ها معمولا برای ارتباط با یک دیگر از API ها استفاده می کنند. درحالی که این درست است که کلاینت ها و سرویس ها میتوانند با یکدگیر مستقیما ارتباط برقرار کنند ، استفاده از API ها معمولا یک لایه واسطه ای مفید می باشد ، به خصوص زمانی که تعداد سرویس های موجود در یکی اپلیکیشن در طول زمان افزایش و رشد پیدا می کند . استفاده از API ، برای کلاینت ها نقش یک پراکسی معکوس را از طریق مسیردهی ریکوئست ها ، ارسال ریکوئست ها به چندین سرویس و همچنین ایجاد امنیت و احراز هویت بیشتر ، ایفا می کند.تکنولوژی ها و فناوری های متعددی برای پیاده سازی API ها وجود دارد ، شامل پلتفرم های مدیریت API . ولی اگر معماری میکروسرویس ها توسط کانتینر ها و Kubernetes پیاده سازی شده باشد ، دروازه یا Gateway مربوط به API از طریق Ingress یا Istio پیاده سازی خواهد شد . پیام رسانی و استریم رویداد ها ( Messaging and Event Streaming )میکروسرویس های بدون حالت یا Stateless ، هیچ حالتی را در سرویس ها به هنگام فراخوانی ، حفظ نمی کنند . آن ها درخواست را دریافت می کنند ، سپس پردازش میکنند و سپس یک پاسخ را بر می گردانند بدون اینکه هیچ اطلاعاتی را ذخیره کنند . ولی میکروسرویس حالت دار یا Stateful ، وقتی مثلا یک ریکوئست را دریافت میکنند ، اطلاعات مربوط به آن ریکوئست را در حافظه خود ذخیره میکنند که این ممکن است محدودیت ها و مشکلاتی را ایجاد کند . مثلا فرض کنید که 3 میکروسرویس Stateful داریم و یک درخواست به این سرویس ها ارسال می شود و میکروسرویس شماره 1 درخواست را پردازش میکند و ادامه می دهد . حال اطلاعات مربوط به آن در خواست در میکروسرویس شماره 1 ذخیره شده است و اگر درخواست بعدی مرتبط با درخواست قبلی بوده باشد ( مثلا بخش هایی از یک تراکنش بوده باشند ) این درخواست جدید فقط می تواند توسط میکروسرویس شماره 1 مورد پردازش قرار گیرد زیرا اطلاعات مربوط به درخواست اول ، در این میکروسرویس وجود دارد . این با استفاده از میکروسرویس های Stateful است . ولی اگر از میکروسرویس های Stateless استفاده کنیم ، اطلاعات مربوط به مثلا ریکوئست ها میتواند در یک پایگاه داده مرکزی به منظور ذخیره سازی این اطلاعات ذخیره شود و در نتیجه میکروسرویس ها به این داده ها دسترسی دارند و محدودیتی که با Stateful ها داشتیم ، از بین می رود . در حالی که ممکن است بهترین راهکار ، طراحی سرویس های Stateless باشد ، ولی سرویس های Stateful هم وجود دارند . و همچنین در حالی که استفاده از API ها معمولا یک روش موثر در ایجاد و مدیریت حالت اولیه یک سرویس است ، یک راه کار موثر برای بروز و up to date بودن نیست . لازم است که فراخوانی های API را با سیستم های Messaging و Event Steaming همراه کنیم تا سرویس ها بتوانند این تغییرات را به گونه ای ذخیره کنند که سایر سرویس ها بتوانند به این تغییرات گوش داده و در صورت نیاز تغییرات لازم را ایجاد کنند . برای این کار از Message Broker ها مانند RabbitMQ استفاده می کنیم . البته مواردی هم وجود دارد که سیستم های Event Streaming مانند Apache Kafka شاید گزینه مناسب تری باشند. با ترکیب میکروسرویس ها با معماری Event Driven یا مبتنی بر رویداد ، توسعه دهنده ها می توانند سیستم های توزیع شده ، قابل گسترش ، مقاوم نسبت به خطا و توسعه پذیر ایجاد کنند که می تواند مقادیر بسیار زیادی از رویداد ها یا اطلاعات را به صورت Real Time مورد مصرف و پردازش قرار دهد . معماری Serverlessمعماری Serverless بعضی از پترن ها و الگو های اصلی و مرکزی میکروسرویس ها و Cloud را به نتایج منطقی خود نزدیک میکند. در این معماری ، واحد اجرایی فقط یک سرویس کوچک نیست ، بلکه یک تابع است که معمولا می تواند از چند خط کد تشکیل شده باشد . مرز و خط جدا کننده توابع Serverless و میکروسرویس ، زیاد واضح نیست ولی به طور معمول ، مفهوم توابع این است که از میکروسرویس ها کوچک تر باشند .جایی که معماری Serverless و پتلفرم های " توابع به عنوان سرویس " یا (FaaS) ها با میکروسرویس ها شباهت دارند آن جا است که هر دو آن ها در تلاش برای ساخت واحد های کوچک تر شامل توسعه و Deploy هستندمیکروسرویس ها و سرویس های ابریمیکروسرویس ها لزوما مربوط به رایانش ابری نمی شوند ، ولی چندین دلیل مهم وجود دارد که بیان می کند چرا اغلب ، این دو باهم ترکیب می شوند . دلایلی که فراتر از این هستند که میکروسرویس ها یک استایل معماری جدید و محبوب برای اپلیکیشن ها است و همچنین فضای ابری یک میزبان محبوب و جدید برای اپلیکیشن های جدید است .از جمله مزایای معماری میکروسرویس ها ، استفاده و هزینه های مربوط به توسعه و deploy کردن قسمت های مجزا و مفرد در این معماری می باشد . با اینکه این مزایا با استفاده از فضاها و زیر ساخت های غیر ابری موجود در محل ( غیر ابری ) وجود دارند ولی ترکیب بخش های کوچک ، مستقل و قابل گسترش ، با زیر ساخت های ابری که دارای ویژگی های پرداخت به ازای استفاده ( pay-per-use ) و پرداخت به میزان تقاضا ( on-demand ) جایی است که دقیقا بهینه سازی واقعی و اصلی در هزینه ها ایجاد می شود .همچنین شاید نکته مهم تر این باشد که یکی دیگر از مزایای میکروسرویس ها این است که هر بخش مستقل ( هر Component ) می تواند از فناوری و تکنولوژی و Stack ای که کار آن بخش را به بهترین نحو انجام می دهد بهره بگیرد و استفاده کند . افزایش تنوع فناوری های مورد استفاده وقتی که خودمان آن ها را کنترل کنیم می تواند پیچیدگی های جدی و اساسی ایجاد کند . ولی استفاده از فناوری های مختلف به کمک سرویس های ابری می تواند به طور قابل ملاحظه ای این چالش های مدیریتی را کاهش دهد . یه عبارت دیگر با این که غیر ممکن نیست که زیر ساخت میکروسرویس های خود را ، خودتان مدیریت و پیاده سازی کنید ، ولی با توجه به وجود فضاهای ابری ، این روشی نیست که قابل توصیه کردن باشد به خصوص زمانی که ابتدای کار هستید و شروع به کار می کنید . الگو ها و Best Practice ها در میکروسرویس هادر معماری میکروسرویس ها ، تعداد زیادی الگو های طراحی ، ارتباط و ادغام کردن وجود دارد که مفید و کاربردی هستند و چالش هایی را که معمولا در این معماری با آن ها روبرو می شویم را پوشش می دهند . بک-اند برای فرانت-اند ( BFF یا Backend-for-frontend ) : این الگو یک لایه میان UX و منابع مورد استفاده ، قرار می دهد . برای مثال ، اپلیکیشنی که روی Desktop استفاده می شود ، اندازه صفحه نمایش و محدودیت های پرفرمونس متفاوتی نسبت به یک موبایل دارد . الگوی BFF به توسعه دهنده ها این امکان را می دهد که با استفاده از بهترین آپشن ها برای آن interface و رابط ، یک Backend به ازای هر نوع رابط کاربری ایجاد کنند . نه اینکه سعی کنند از یک Backend عمومی که برای همه رابط های کاربری کار میکند ولی در پرفرومنس Frontend تاثیر منفی دارد استفاده کنند .موجودیت و الگو های مجموع ( Entity and Aggregate Patterns ) : یک موجودیت ، یک شی است که با هویتش منحصر به فرد می شود . برای مثال در یک سایت فروشگاهی ، یک "محصول" ممکن است توسط نام و نوع و قیمتش متمایز شده باشد . یک aggregate یا تجمع ، مجموعه ای از موجودیت های مرتبط به هم است که به عنوان یک واحد باید با آن رفتار شود . مثلا در همین سایت فروشگاهی ، یک "سفارش" مجموعه ای ( تجمع - aggregate ) از محصولات ( موجودیت های محصول ) است که توسط یک کلاینت سفارش داده شده است . این الگو برای دسته بندی داده ها در راه های قابل فهم استفاده می شود . الگو های کشف سرویس ( Service Discovery Patterns ) : این الگو ها به اپلیکیشن ها و سرویس ها کمک میکنند که یک دیگر را پیدا کنند . در معماری میکروسرویس ها ، نمونه های سرویس ها به دلایلی مثل توسعه و ارتقاء ، خرابی سرویس و حتی از بین رفتن سرویس به صورت دینامیک و پویا ، تغییر می کنند . این الگو ها ، مکانسیم های کشف و پیدا کردن را برای مقابله با این ناپایداری ها فراهم می کنند . بالانس کردن Load و بار ممکن است از طریق مثلا بررسی های سلامتی و خرابی سرویس ها به عنوان محرک هایی برای تعادل مجدد ترافیک ، از این الگو ها استفاده استفاده کند . الگو های میکروسرویس های وفق دهنده - آداپتور ( Adapter Microservices Patterns ) : به این الگو های آداپتور همانگونه که به آداپتور های برق که در هنگام مسافرت به کشوری دیگر با خود میبرید ، فکر کنید. هدف و مقصود الگو های آداپتور و وفق دهنده ، کمک به ترجمه روابط میان اشیاء و کلاس هایی است که در غیر این صورت باهم ناسازگار هستند . مثلا اپلیکیشنی که متکی بر API های شخص ثالث ( یا همون third-party ) است ممکن است به این الگو های وفق دهنده ( آداپتور ) نیاز داشته باشد تا اپلیکیشن بتواند با آن API مورد نظر ، ارتباط داشته باشد . الگوی Strangler Application : این الگو ها به مدیریت refactor کردن و تبدیل کردن یک اپلیکیشن با ساختار و معماری یکپارچه به اپلیکیشنی با معماری میکروسرویس ها کمک میکنند . نام این الگو برمیگردد به اینکه چطور یک گیاه انگور ( میکروسرویس ) ، به آرامی و در طول زمان یک درخت ( اپلیکیشن با معماری یکپارچه ) را در بر می گیرد . نباید ها در میکروسرویس ها در حالی که الگو های بسیاری وجود دارد که انجام آن ها در معماری میکروسرویس ها ، باعث می شود از بسیاری از مشکلات معمول جلو گیری شود ، ولی نباید هایی هم وجود دارد که از انجام آن ها باید پرهیز کرد که این موارد می توانند هر تیم توسعه ای را سریعا وارد مشکل کنند :قانون اول میکروسرویس ها این است که ، با میکروسرویس شروع نکنید ! : معماری میکروسرویس ها یکی از راه های مدیریت اپلیکیشن به هنگامی است که که اپلیکیشن بسیار بزرگ می شود و عملا به سادگی نمی توان آن را نگه داری کرد و توسعه داد . فقط زمانی که شما می توانید حس کنید که این مشکل وجود دارد و یکپارچه بودن موجب درد و مشکل است ، استفاده از میکروسرویس ها ارزش پیدا می کند و شما باید در نظر بگیرید که آن زمان چطور این اپلیکیشن یکپارچه را به سرویس ها کوچک تر تبدیل کنید و به سمت معماری میکروسرویس ها حرکت کنید .معماری میکروسرویس ها را بدون DevOps و سرویس های ابری انجام ندهید : ساخت با استفاده از معماری میکروسرویس ها یعنی ساخت سیستم های توزیع شده ، و سیستم های توزیع شده مدیریت سختی دارند . استفاده از معماری میکروسرویس ها بدون استفاده از اتوماسیون های توسعه و مانیتورینگ و همچنین بدون استفاده از سرویس های ابری مدیریت شده که زیر ساخت های بزرگ و ناهمگن شما را پشتیبانی کنند ، باعث به وجود آمدن مشکلات زیادی است . تعداد زیادی میکروسرویس با کوچک کردن اندازه آن ها ایجاد نکنید : اگر در عبارت "میکرو" در میکروسرویس ها زیاده روی کنید ، دچار پیچیدگی و سربار های زیادی می شود که بسیاری از مزایای میکروسرویس ها را از بین خواهد برد . بهتر است از سرویس های بزرگ استفاده کنید و فقط زمانی آن ها را به بخش های کوچک تر تبدیل کنید که استفاده از میکروسرویس ها واقعا مفید و مزایای آن ها برای استفاده مشخص باشد . مثلا اگر انجام تغییرات سخت و کند شود ، یا یک مدل داده رایج بیش از حد پیچیده شود ، یا قسمت های مختلف سرویس نیاز های متفاوتی از نظر بار و مقیاس دارند . سعی نکنید مانند شرکت Netflix عمل کنید ! : شرکت Netflix یکی از شرکت های پیشرو در زمینه معماری میکروسرویس ها به هنگام ساخت و مدیریت اپلیکیشنی که تقریبا یک سوم ترافیک کل اینترنت را تشکیل می داد . نمونه کاملی از یک طوفان کامل که آن ها را مجبور به ساخت تعداد زیادی کد های Custom و سرویس های غیر ضروری برای یک برنامه متوسط کرد . توصیه می شود و بهتر است که با سرعت و گامی شروع کنید که قابل به هندل کردن و مدیریت آن باشید و از پیچیدگی های غیر ضروری اجتناب کنید و تا جای ممکن از ابزار های آماده استفاده کنید تا کار را راحت تر انجام دهید . نتیجه گیریمعماری میکروسرویس ها ( Microservices Architecture ) معماری است که نسبت به معماری های سنتی و یکپارچه ، زمانی که پیچیدگی های اپلیکیشن های یکپارچه و سنتی زیاد می شود و عملا نگهداری و توسعه اپلیکیشن با مشکل مواجه می شود ، می تواند مزایای بسیار زیادی هم از نظر فنی و هم از نظر سازمانی و بیزینسی داشته باشد و هزینه های مربوط به بخش های مالی و زمانی و نیروی توسعه ( توسعه دهنده ها ) را کاهش دهد و باعث شود تا بهینگی افزایش یابد و تمرکز بر روی موارد اصلی افزایش یابد . پ . ن : بعضی مفاهیم موجود در این مقاله ، خود نیاز به یک مقاله جداگانه و مطالعه دقیق دارند و توضیح آن ها در این مقاله نمی گنجد . مثلا برای Docker و Kubernetes ، سیستم های Message Broker ، معماری هایی مانند Serverless و همچنین چالش های مربوط به DevOps ، نیاز به مطالعه دقیق و جداگانه هست و این مفاهیم به یکدیگر وابسته هستند .منابع پیشنهادی برای مطالعه بیشتر در زمینه معماری میکروسرویس ها : کتاب Building Microservices ، نویسنده Sam Newman - ویرایش دوم - انتشارات O'Reilly کتاب Monolith to Microservices ، نویسنده Sam Newman - ویرایش اول - انتشارات O'Reillyمنبع :ibm.com/cloud سجاد کلاه چی سجاد کلاه چی Wed, 30 Mar 2022 13:37:33 +0430