24-08-2020, 09:05 PM
(آخرین ویرایش: 24-08-2020, 09:10 PM، توسط علي پروازي لطفي.)
پردیس فناوری کیش _طرح مشاوره متخصصین صنعت ومدیریت _دپارتمان فناوری اطلاعات وارتباطات
میکروسرویس، واژه‌ای که این روزها شاید در اکثر شرکت‌های تکلونوژی دنیا اسمش شنیده می‌شود.
در این نوشته به تعریف این معماری از منظر خودم و مزایا و معایب آن می‌پردازم و در نوشته‌های بعدی جزئیاتی را هم در این باره منتشر میکنم.
من به موجودیتی سرویس می‌گویم که به تنهایی قابل توسعه، دیپلوی، تست و scale باشد.
برخلاف اسمش که میکرو در آن وجود دارد، هیچ‌وقت این تصور را نداشته باشید که یک سرویس هر چه قدر کوچک‌تر باشد بهتر است.
خب حالا سوالات اساسی:
[list]
[*]چرا میکروسرویس؟
[*]فرق معماری میکروسرویس‌ها با معماری مونولوتیک چیست؟
[/list]خب بدیهی‌ترین فرق این است که در معماری مونولوتیک، یک سیستم از یک سرویس تشکیل شده است ولی در معماری میکروسرویس‌ها از چند سرویس.
حالا برخی مزایای مهم معماری میکروسرویس‌ها را بیان میکنم:
ابتدا از تعریفی که ارائه دادم شروع میکنم و کمی توضیحش میدهم:
[list]
[*]هر سرویس به تنهایی قابل توسعه دادن است!
[/list]شاید بگویید مگر در بقیه حالت‌ها قابل توسعه نیست؟ در جواب باید بگویم که بله در برخی حالت‌ها اگر در زمان مناسبش اقدام درستی انجام نشود سرویس توانایی توسعه‌اش را از دست می‌دهد. حالا چگونه؟
فرض کنید که سیستم خیلی بزرگ دارید و چند تیم روی آن کار می‌کنند. حالا زیاد هم نگوییم مثلا سه تیم پنج نفره. هر چقدر هم کد یک پروژه تمیز باشد و وابستگی در آن کم باشد، یک برنامه‌نویس چون یک آدم است، می‌تواند اشتباه کند و اگر جایی اشتباه کند همین اشتباه او باعث کرش در سیستم شده و کل مجموعه را از کار می‌اندازد. و از جنبه دیگر، وقتی با یک سرویس سر و کار دارید و یک برنامه‌نویسی باشید که تازه به آن مجموعه اضافه شده‌اید شاید سال‌ها طول بکشد که از همه جای آن سر در بیاورید و عملا نمی‌توانید توسعه خاصی روی آن انجام دهید. ولی اگر این سیستم به چند سرویس شکسته شده باشد شما در یک تیم مجزا به توسعه سرویس خودتان می‌پردازید. و با بقیه کاری ندارید.
[list]
[*]هر سرویس به تنهایی قابل دیپلوی کردن است.
[/list]همین سرویس بزرگ قبلی را تصور کنید، شما یک کامیت روی برنچ مستر انجام می‌دهید. در بهترین حالت احتمالا دو روز طول بکشد که کدی که شما زده‌اید بر روی نسخه پروداکشن اجرا شود. به نظرتان زمان خوبی است؟ اگر کدی که شما زده‌اید فقط یک خط باشد چه؟ واقعا فاجعه است! اما در میکروسرویس فاصله مرج تا دیپلوی می‌تواند حتی کمتر از یک دقیقه باشد. این یعنی چابکی به معنای واقعی کلمه.
[list]
[*]هر سرویس یه تنهایی قابل تست کردن است.
[/list]شما یک کدی میزنید و انتظار دارید کارایی که می‌خواهید را داشته باشد و حتی برایش تست هم نوشته‌اید. اما از کجا می‌دانید که کد شما قسمت‌های مختلفی که سایر تیم‌ها روی آن‌ها کار می‌کنند تاثیر نمی‌گذارد آن‌ها را خراب نمی‌کند و برعکس. اما در میکروسرویس شما توسعه را در سرویسی که برای خودتان است پیش می‌برید و تست‌های خودتان که پاس شد روی نسخه عملیاتی اجرایش میکنید. و حتی اگر خراب هم شود فقط روی این سرویس تاثیر می‌گذارد و کل سیستم مختل نمی‌شود.
[list]
[*]هر سرویس به تنهایی scale کردن است.
[/list]در حالت مونولوتیک اگر بار روی سرویس‌تان زیاد شود و بخواهید آن را حالا با هر روشی scale کنید، مجبور هستید برای همه سیستم این کار را انجام دهید. و این در حالی است که احتمال زیاد همه قسمت‌های آن مثلا همه apiها، بار زیادی ندارند و فی‌الواقع نیازی نیست که scale شوند.
ولی در معماری میکروسرویس‌ها شما می‌توانید هر سرویس را به طور جداگانه و در حد نیازش scale کرده و خروجی خوبی را به کاربران خود بدهید.
![[تصویر: ppoidsthb6xf.png]](https://files.virgool.io/upload/users/54035/posts/tobr25bsyblg/ppoidsthb6xf.png)
اما در میان مزایا، این معماری مانند هر چیز دیگری معایبی را دارد. که به نظر من مهم‌ترین آن‌ها پیچیدگی است که به مجموعه اضافه می‌کند. از این جهت که اگر یک کسب و کار نوپا در همان اول کار دنبال میکروسرویس بودن باشد احتمال زیاد هم وقت زیادی صرف می‌کند و هم خطاها و شکست‌هایی در پی خواهد داشت. مهم‌ترین نکته در بین مرز معماری میکروسریس‌ها و مونولوتیک، شناختن و درک عمیق زمان درست مهاجرت از مونولوتیک به میکروسرویس‌ها است که اگر این زمان درست انتخاب شود، اتفاقات خوبی را برای یک کسب و کار نوپا از نظر فنی رقم می‌زند.
میکروسرویس، واژه‌ای که این روزها شاید در اکثر شرکت‌های تکلونوژی دنیا اسمش شنیده می‌شود.
در این نوشته به تعریف این معماری از منظر خودم و مزایا و معایب آن می‌پردازم و در نوشته‌های بعدی جزئیاتی را هم در این باره منتشر میکنم.
من به موجودیتی سرویس می‌گویم که به تنهایی قابل توسعه، دیپلوی، تست و scale باشد.
برخلاف اسمش که میکرو در آن وجود دارد، هیچ‌وقت این تصور را نداشته باشید که یک سرویس هر چه قدر کوچک‌تر باشد بهتر است.
خب حالا سوالات اساسی:
[list]
[*]چرا میکروسرویس؟
[*]فرق معماری میکروسرویس‌ها با معماری مونولوتیک چیست؟
[/list]خب بدیهی‌ترین فرق این است که در معماری مونولوتیک، یک سیستم از یک سرویس تشکیل شده است ولی در معماری میکروسرویس‌ها از چند سرویس.
حالا برخی مزایای مهم معماری میکروسرویس‌ها را بیان میکنم:
ابتدا از تعریفی که ارائه دادم شروع میکنم و کمی توضیحش میدهم:
[list]
[*]هر سرویس به تنهایی قابل توسعه دادن است!
[/list]شاید بگویید مگر در بقیه حالت‌ها قابل توسعه نیست؟ در جواب باید بگویم که بله در برخی حالت‌ها اگر در زمان مناسبش اقدام درستی انجام نشود سرویس توانایی توسعه‌اش را از دست می‌دهد. حالا چگونه؟
فرض کنید که سیستم خیلی بزرگ دارید و چند تیم روی آن کار می‌کنند. حالا زیاد هم نگوییم مثلا سه تیم پنج نفره. هر چقدر هم کد یک پروژه تمیز باشد و وابستگی در آن کم باشد، یک برنامه‌نویس چون یک آدم است، می‌تواند اشتباه کند و اگر جایی اشتباه کند همین اشتباه او باعث کرش در سیستم شده و کل مجموعه را از کار می‌اندازد. و از جنبه دیگر، وقتی با یک سرویس سر و کار دارید و یک برنامه‌نویسی باشید که تازه به آن مجموعه اضافه شده‌اید شاید سال‌ها طول بکشد که از همه جای آن سر در بیاورید و عملا نمی‌توانید توسعه خاصی روی آن انجام دهید. ولی اگر این سیستم به چند سرویس شکسته شده باشد شما در یک تیم مجزا به توسعه سرویس خودتان می‌پردازید. و با بقیه کاری ندارید.
[list]
[*]هر سرویس به تنهایی قابل دیپلوی کردن است.
[/list]همین سرویس بزرگ قبلی را تصور کنید، شما یک کامیت روی برنچ مستر انجام می‌دهید. در بهترین حالت احتمالا دو روز طول بکشد که کدی که شما زده‌اید بر روی نسخه پروداکشن اجرا شود. به نظرتان زمان خوبی است؟ اگر کدی که شما زده‌اید فقط یک خط باشد چه؟ واقعا فاجعه است! اما در میکروسرویس فاصله مرج تا دیپلوی می‌تواند حتی کمتر از یک دقیقه باشد. این یعنی چابکی به معنای واقعی کلمه.
[list]
[*]هر سرویس یه تنهایی قابل تست کردن است.
[/list]شما یک کدی میزنید و انتظار دارید کارایی که می‌خواهید را داشته باشد و حتی برایش تست هم نوشته‌اید. اما از کجا می‌دانید که کد شما قسمت‌های مختلفی که سایر تیم‌ها روی آن‌ها کار می‌کنند تاثیر نمی‌گذارد آن‌ها را خراب نمی‌کند و برعکس. اما در میکروسرویس شما توسعه را در سرویسی که برای خودتان است پیش می‌برید و تست‌های خودتان که پاس شد روی نسخه عملیاتی اجرایش میکنید. و حتی اگر خراب هم شود فقط روی این سرویس تاثیر می‌گذارد و کل سیستم مختل نمی‌شود.
[list]
[*]هر سرویس به تنهایی scale کردن است.
[/list]در حالت مونولوتیک اگر بار روی سرویس‌تان زیاد شود و بخواهید آن را حالا با هر روشی scale کنید، مجبور هستید برای همه سیستم این کار را انجام دهید. و این در حالی است که احتمال زیاد همه قسمت‌های آن مثلا همه apiها، بار زیادی ندارند و فی‌الواقع نیازی نیست که scale شوند.
ولی در معماری میکروسرویس‌ها شما می‌توانید هر سرویس را به طور جداگانه و در حد نیازش scale کرده و خروجی خوبی را به کاربران خود بدهید.
کلا معماری میکروسرویس‌ها نکته‌های خوب زیاد دارد که در این حجم از کلام نمی‌گنجد و همین کتابی که اول نوشته معرفی کردم یکی از منابع خوب برای شناختن هر چه بهتر آن است.
اما در میان مزایا، این معماری مانند هر چیز دیگری معایبی را دارد. که به نظر من مهم‌ترین آن‌ها پیچیدگی است که به مجموعه اضافه می‌کند. از این جهت که اگر یک کسب و کار نوپا در همان اول کار دنبال میکروسرویس بودن باشد احتمال زیاد هم وقت زیادی صرف می‌کند و هم خطاها و شکست‌هایی در پی خواهد داشت. مهم‌ترین نکته در بین مرز معماری میکروسریس‌ها و مونولوتیک، شناختن و درک عمیق زمان درست مهاجرت از مونولوتیک به میکروسرویس‌ها است که اگر این زمان درست انتخاب شود، اتفاقات خوبی را برای یک کسب و کار نوپا از نظر فنی رقم می‌زند.
source:https://vrgl.ir/QlkEl