https://virgool.io/feed/@mahnooshshokri fa 2026-06-16 16:31:23 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@mahnooshshokri https://virgool.io/@mahnooshshokri/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%DA%86%D8%A7%D9%84%D8%B4-%D9%87%D8%A7-%D9%81%D9%86%D8%A7%D9%88%D8%B1%DB%8C-%D9%87%D8%A7-%D9%88-%DA%A9%D8%B3%D8%A8-%D9%88%DA%A9%D8%A7%D8%B1%D9%87%D8%A7-ry9lgti96iip مرضیه برخی، مهنوش شکریمیکروسرویس‌ها سبکی از معماری است که روی تقسیم سیستم به سرویس‌های کوچکی که برای انجام یک عملکرد تجاری منسجم ساخته شده اند، تاکید دارد. این معماری تکاملی از سبک معماری سنتی سرویس‌گرا می‌باشد.از مزایای معماری میکروسرویس می‌توان به افزایش چابکی، بهره‌وری، انعطاف‌پذیری، مقیاس‌پذیری، قابلیت اطمینان، قابلیت نگهداری، جداسازی دغدغه‌ها و سهولت استقرار اشاره کرد.شرکت‌های مشاوره نرم‌افزار و طراح محصول بر این باورند که معماری میکروسرویس به تیم‌ها و سازمان‌های نرم‌افزاری این امکان را می‌دهد که بهره‌وری بالاتری داشته باشند و محصولات موفق‌تری بسازند. هم‌چنین میکروسرویس‌ها معماری مناسبی برای سیستم‌های ابری هستند‌. شرکت‌هایی مانند Netflix، Amazon و SoundCloud از معماری میکروسرویس در فضای ابری استفاده می‌کنند.در این سبک معماری با چالش‌هایی مانند یافتن سرویس‌ها از طریق شبکه، مدیریت امنیت، بهینه‌سازی ارتباطات، اشتراک‌گذاری داده‌ها و کارایی روبرو هستیم.در این پست به بررسی معماری میکروسرویس‌ها و روند پیشرفت آن، فناوری‌های مرتبط با میکروسرویس‌ها و ابزارهای ارائه شده برای آن‌ها، چالش‌های موجود در میکروسرویس‌ها و ضدالگوهای شناخته شده در این معماری می‌پردازیم. هم‌چنین در ادامه معماری سه شرکت Netflix، Amazon و SoundCloud را به عنوان نمونه‌های کسب‌وکارهای موفقی که از معماری میکروسرویس‌ها استفاده می‌کنند مورد بررسی قرار می‌دهیم.میکروسرویس‌ها و معماری سرویس‌گرامیکروسرویس‌ها، با توجه به سرویس‌های مستقل با مرزهای مشخص، مشابه معماری قدیمی‌تر سرویس‌گرا (SOA) می‌باشند. در واقع می‌توان ادعا کرد که معماری میکروسرویس نوع خاصی از معماری سرویس‌گراست.با مقایسه میکروسرویس‌ها و معماری سرویس‌گرا میتوانیم تفاوت‌های زیر را برای آن‌ها برشمریم:معماری سرویس‌گرا به محصولاتی مانند گذرگاه سرویس سازمانی (ESB) یا سایر میان‌افزارهای سنگین وابسته است، در مقابل میکروسرویس‌ها به تکنولوژی های سبک وابسته است.معماری سرویس‌گرا اغلب با وب‌سرویس‌ها، پروتکل‌ها، ابزار و فرمت‌هایی مانند SOAP، WSDLو استانداردهای WS* مرتبط است، اما میکروسرویس‌ها معمولا به REST، HTTP، یا سایر فرمت‌های سبک برای توسعه وب، وابسته است.معماری سرویس‌گرا غالبا به عنوان یک راه‌حل یکپارچه‌سازی در نظر گرفته می‌شود، در حالی که میکروسرویس‌ها معمولا برای ساخت اپلیکیشن‌های جدا به کار گرفته می‌شود.خصوصیات میکروسرویس‌هابعضی از خصوصیات مشترکی که انتظار می‌رود در سیستم‌هایی که با معماری میکروسرویس‌ها توسعه داده شده اند وجود داشته باشد به شرح زیر است:وجود سرویس‌ها به عنوان مولفه پیرامون کارکردهای کسب‌وکار: مؤلفه‌ها (componentها) در یک سیستم نرم‌افزاری، واحدهایی هستند که می‌توانند بدون این که در کار سایر بخش‌های سیستم ایرادی وارد شود، به طور مستقل اجرا، جایگزین و بروزرسانی شوند. شکستن سیستم به میکروسرویس‌ها باید بر مبنای کارکردهای کسب‌وکار (و نه از نظر فنی) باشد. هر تیمی که مسئولیت میکروسرویسی را بر عهده گرفته است، باید شامل متخصصانی از تمامی حوزه‎‌های فنی باشد تا بتوانند به طور مستقل آن میکروسرویس را توسعه داده و نگهداری کنند.تمرکز بر محصول، نه پروژه: در میکروسرویس‌ها تمرکز بر این است که بتوان در بازه‌های زمانی‌ کوتاه‌تری، محصولی قابل ارائه را عرضه کرد و پس از عرضه نیز باید با کاربر در تعامل بود تا در صورت نیاز، نیازمندی‌ها بهبود پیدا کند و یا مشکلات حل شود. واضح است که در سیستم monolith به دلیل یکپارچگی و وابستگی اجزای مختلف سیستم با هم، امکان تغییر، بهبود و یا رفع bug به آسانی وجود ندارد.طراحی هوشمندانه endpointها: همان‌طور که در معماری سرویس‌گرا امکان ارتباط و فرستادن پیام بین سرویس‌ها، به واسطه یک گذرگاه سازمانی مثل ESB مطرح است، در معماری میکروسرویس از گذرگاه‌های سبک‌وزنی مثل message brokerها برای انتقال پیام به صورت غیرهمزمان استفاده می‌شود که به عنوان واسطی بین مبدا و مقصد برای دریافت و انتقال پیام‌ها عمل می‌کند. معمولا هر endpoint در اجزای معماری میکروسرویس با پروتکل‌های REST به نقطه مقابل خود متصل می‌شود. موردی که مطرح است این است که برخلاف معماری سرویس‌گرا که در آن پروتکل‌های ارتباطی می‌توانستند از هر نوعی باشند، در معماری میکروسرویس این استاندارد پذیرفته شده است که پروتکل‌ها، غالبا REST باشند، پس Broker که یک endpoint در این سیستم است، به سنگینی ESB نیست که بخواهد عمل تبدیل انواع قالب‌های پیام را به یکدیگر انجام دهد؛ بلکه صرفا به عنوان یک صف پیام عمل می‌کند.مدیریت غیرمتمرکز : از آن‌جایی که در میکروسرویس‌ها اصل بر این است که می‌توان بنابر نیاز از هر زبان برنامه‌سازی استفاده کرد و هر میکروسرویس واحد مستقلی است، دیگر الزامی برای مدیریت متمرکز مؤلفه‌ها وجود ندارد و صرفا باید ارتباطات بین آن‌ها مدیریت شود. اما این خودمختاری در توسعه‌ی میکروسرویس‌ها به این معنا نیست که همیشه بدون هیچ دورنمایی، می‌توان تکنولوژی‌ها را انتخاب کرد؛ بلکه این انتخاب باید بر مبنای معیارهایی چون دانش فنی اعضای تیم، قابلیت نگهداری سیستم و ملاحظاتی از این دست باشد.مدیریت داده غیرمتمرکز: یکی از راه‌حل‌های جداسازی مدیریت داده‌ها در مؤلفه‌های مختلف سیستم، طراحی دامنه محور (DDD) است. در این روش طراحی، یک دامنه بزرگ به تعدادی زیردامنه محدود شکسته می‌شود و ارتباط بین هر یک از آن‌ها با نگاشت انجام می‌شود. در میکروسرویس ترجیح بر این است که هر سرویس که بخشی از نیاز کسب‌وکار را مرتفع می‌کند، دیتابیس مختص خود را داشته باشد و یا حتی اگر از دیتابیس‌های مشترکی استفاده می‌شود، از instanceهای متفاوتی برای اتصال به آن استفاده کند. به این روش polyglot persistence هم گفته می‌شود.خودکارسازی زیرساخت: پیشرفت بستر Cloud و روی کارآمدن AWS باعث شده است که پیچیدگی‌های ساخت، استقرار و عملیاتی کردن میکروسرویس‌ها کاهش یابد. اغلب محصولات یا سیستم‌هایی که با معماری میکروسرویس توسعه داده شده‌اند، اصل CI/CD را رعایت می‌کنند و زمینه اجرای این اصل، خودکارسازی فرآیندهای توسعه، تست و استقرار است.طراحی مکانیزم مدیریت خطا: از آن جایی که در این معماری سرویس‌ها باید با یکدیگر ارتباط برقرار کنند، لازم است مکانیزمی برای تحمل خطا برای هر سرویسی که با سرویس دیگر در ارتباط است وجود داشته باشد. هر درخواستی که از یک سرویس به سرویس دیگری ارسال می‌شود، ممکن است به دلیل در دسترس نبودن یا خرابی سرویس مقصد، بدون پاسخ بماند. پس باید تکلیف این درخواست‌ها مشخص باشد و به اصطاح مانا باشند. این مورد یکی از معایب استفاده از معماری میکروسرویس در برابر معماری monolithic است. چون ممکن است سرویس‌ها در هر لحظه دچار خرابی شوند، بسیار مهم است که خرابی‌ها به سرعت شناسایی شوند و در صورت امکان، سرویس restore شود. پس وجود monitoringهای real‑time در میکروسرویس‌ها از اهمیت بالایی برخوردار است.طراحی تکاملی: فرآیند تبدیل شدن معماری یک سیستم به میکروسرویس‌ها، عموما به صورت تدریجی و در بازه زمانی طولانی انجام می‌شود. یعنی سیستم‌ها در ابتدا monolith بوده‌اند اما در طی فرآیندی با جداسازی مؤلفه‌ها به عنوان سرویس‌های مستقل، به میکروسرویس تبدیل شده‌اند. پس باید سناریو‌هایی برای جداسازی گام به گام کارکردهای سیستم وجود داشته باشد تا هم معماری به سمت میکروسرویس شدن پیش برود، هم سیستمی که در حال حاضر کاربران از آن استفاده می‌کنند، دچار مشکل نشود.سیر تکاملی میکروسرویس‌هامعماری میکروسرویس در چهار نسل پیشرفت کرده است.نسل اولدر نسل اول، هر سرویس توسط تکنولوژی­های سبک‌وزن container مثل LXC بسته‌بندی می‌شود. سپس این containerها مستقر شده و مدیریت آن‌ها در زمان اجرا توسط ابزارهای orchestration مثل mesosانجام می‌شود. هر سرویس باید خودش موقعیت سایر سرویس­ها را با استفاده از پروتکل­های ارتباطی مخصوص به آن، در نظر بگیرد. همچنین هر مکانیزم پاسخگویی به کنترل خرابی یا پایین آمدن سرویس، باید در سورس کد سرویس پیاده‌سازی شده باشد. هر چه تعداد سرویس‌های مورد نیاز یک اپلیکیشن بیشتر شود و نیاز به استقرار مجدد سرویس­ها در محیط‌های عملیاتی مکررا ایجاد شود، مکان‌یابی نمونه­های سرویس‌ها و کشف و ترمیم خطا، به یک مسئله پیچیده تبدیل می‌شود. همچنین اگر یک سرویس جدید با زبان برنامه‌نویسی متفاوتی پیاده سازی شود، استفاده مجدد از کد مدیریت خطا و مکان‌یابی که برای سرویس‌های دیگر نوشته شده است، برای آن امکان‌پذیر نخواهد بود و باید این امکانات به طور مجزا برای سرویس جدید پیاده‌سازی شود.نسل دومبرای حل بعضی از مشکلات قبلی، در نسل دوم، سرویس‌های مستقل مکان‌یابی و کتابخانه‌های ارتباطی برای مدیریت خطاها معرفی شده است. سرویس‌ها از یک سرویس مکان‌یابی مشترک مانند consul برای ثبت اطلاعات دسترسی خود استفاده می‌کنند. سرویس‌های کلاینت، می‌توانند به صورت داینامیک به این اطلاعات دسترسی داشته باشند، بدون این که نیاز باشد به طور صریح به مکان آن سرویس اشاره کنند. تمام نیازهای مرتبط با مدیریت خرابی نیز توسط کتابخانه مستقلی مانند Finagle انجام می­شود. این استراتژی نه تنها پیاده سازی و تست نرم‌افزار را ساده می‌کند، بلکه امکان استفاده مجدد از کدهای پیچیده ارتباطی بین سرویس‌ها را فراهم می‌کند؛ یعنی اگر سرویس جدیدی نیز اضافه شد، برای مکان‌یابی و مدیریت خطا می‌تواند از سرویس‌های آماده استفاده کند. اما به هر حال، این کتابخانه‌ها به مرور پیچیده‌تر می‌شوند، همچنین چون پیاده‌سازی مجدد هر کدام با یک زبان برنامه نویسی جدید کار ساده و بدیهی نیست، توسعه‌دهندگان اغلب ناچار هستند سرویس‌های جدید را با زبانی که قبلا این کتابخانه‌ها توسعه داده شده‌اند، پیاده‌سازی کنند؛ پس دیگر از مزایای میکروسرویس‌ها به طور کامل بهره برده نمی­شود، چرا که یکی از تعاریف اصلی در معماری میکروسرویس، امکان توسعه مستقل هر سرویس است که نباید توسعه‌دهنده را محدود به استفاده از تکنولوژی خاصی بکند.نسل سومدر پاسخ به مشکلات نسل قبلی، در نسل سوم، پروکسی‌ها و ماشین‌های جانبی استاندارد مثلenvoy به عنوان یک واسط transparent برای سرویس‌ها معرفی شدند. این ایده برای بالابردن امکان استفاده مجدد از سرویس‌ها به وجود آمده است. یعنی هر سرویس بدنه مختص به خود را دارد که مربوط به نیازمندی کسب‌وکار آن است، اما برای ارتباط با دیگر میکروسرویس‌ها و همچنین مدیریت خطا که یک بحث مشترک بین تمامی میکروسرویس‌ها است، از طریق پروکسی عمل می‌کند. این پروکسی‌ها می‌توانند رفتار میکروسرویس را مانیتور کرده و اقدام مناسب را انجام دهند. این مورد، دقیقا ایده اصلی پشت تکنولوژی های service mesh مثل linkerd است. امکان مانتیور کردن تمام این پروکسی‌ها نیز به وسیله یک ناحیه کنترل مرکزی وجود دارد و اپراتورها می‌توانند به صورت داینامیک، رفتار چندین ماشین جانبی را، مانیتور و مدیریت کنند. با این روش می‌توان کنترل ریزدانه‌تری روی طیف گسترده‌ای از میکروسرویس‌ها مثل ویژگی های ارتباطی سرویس به سرویس، مکان یابی، لود بار، تحمل خطا، مسیریابی پیام‌ها و امنیت داشت، بدون آن که کسب‌وکار هر میکروسرویس درگیر این موارد باشد.نسل چهارمدر نسل چهارم تکنولوژی‌های serverless مثل Aws lambda معرفی شدند که به این الگو Faas (Function as a service) گفته می‌شود. با این تکنولوژی، میکروسرویس‌ها به مجموعه ای از توابع موقت تبدیل می‌شوند که هر کدام از آن‌ها می‌توانند بنابر نیاز، ایجاد، بروزرسانی، جایگزین و یا حذف شوند و حتی دیگر پیچیدگی‌های بالا آوردن container ها نیز وجود ندارد. در این نسل مکانیزم‌های ارتباطی مانند نسل سوم بوده است، اما زیرساخت سبک‌تر شده است.فناوری‌ها و ابزارهای ارائه شده در زمینه میکروسرویس‌هااپلیکیشن‌های اولیه میکروسرویس‌ها تحت تاثیر نسل جدیدی از ابزارهای توسعه، استقرار، و مدیریت نرم‌افزار قرار گرفتند. با افزایش محبوبیت میکروسرویس‌ها، این ابزارها برای پشتیبانی از پایگاه کاربری گسترده‌تر و متنوع‌تر، به تکامل خود ادامه دادند و این امر منجر به ایجاد فناوری‌های پیشرفته‌تر شد.در ادامه تعدادی از مهم‌ترین فناوری‌ها و ابزارهایی که بر توسعه، استقرار و عملکرد میکروسرویس‌ها تاثیر گذاشته‌اند، بررسی می‌شود. (5 فناوری اول پیش از آن که میکروسرویس‌ها به طور عمومی پذیرفته شوند، وجود داشتند. 5 فناوری بعدی در پاسخ به محبوبیت روزافزون میکروسرویس‌ها پدید آمدند.)‏‏‏‏‏Containerizationبه سرویس‌ها اجازه می‌دهد تا به طور مؤثرتری بسته‌بندی، مستقر و مدیریت شوند.ابزارها: LXC, Docker, rkt‏Service discovery‏به سرویس‌ها اجازه می‌دهد که بدون اشاره صریح به مکان شبکه خود، با یک دیگر ارتباط برقرار کنند.ابزارها: ZooKeeper, Eureka, etcd, Synapse, Consul‏ Monitoringنظارت زمان اجرا و تجزیه و تحلیل رفتار منابع میکروسرویس را در سطوح مختلف جزئیات ممکن می‌سازد.ابزارها: Graphite, InfluxDB, Sensu, cAdvisor, Prometheus‏ Container orchestrationتخصیص container و وظایف مدیریتی را خودکار می‌کند و جزئیات زیرساخت فیزیکی یا مجازی را از دیدگاه توسعه‌دهندگان سرویس پنهان می‌کند.ابزارها: Mesos, Kubernetes, Docker Swarm, Amazon Elastic Container Service, Nomad‏Fault-tolerant communicationبه سرویس‌ها اجازه می‌دهد که با کارایی و اطمینان بیشتری ارتباط برقرار کنند.ابزارها: Finagle, Hystrix, Proxygen, Resilience4j‏Continuous delivery / DevOpsراهکارهای جامع یکپارچه‌سازی را برای خودکارسازی بسیاری از شیوه‌های DevOps، که معمولاً در محیط تولید میکروسرویس در مقیاس وب استفاده می‌شوند، ارائه می‌کند.ابزارها: Ansible, Drone, Spinnaker, Amazon Web Services CodePipeLine, Otter‏Chaos engineeringاجرای قابلیت اطمینان حیاتی در سطح سیستم و تکنیک‌های تست امنیت، مانند تزریق شکست و حمله، را خودکار می‌کند.ابزارها: Chaos Monkey, Simian Army, Pumba, Chaos Toolkit‏Sidecarویژگی‌های مرتبط با ارتباط مانند service discoveryو استفاده از کتابخانه‌های fault tolerant communication و protocol specific، را محصورسازی می‌کند تا آن‌ها را از دید توسعه‌دهندگان سرویس انتزاعی کند.ابزارها: SmartStack, Prana, Envoy‏Server less computingمدل ابری تابع به عنوان سرویس Faas (function as a service)را پیاده‌سازی می‌کند.ابزارها: Amazon Web Services Lambda, Azure Functions, Google Cloud Functions, OpenWhisk, Spring Cloud Function‏Service meshمبتنی بر فناوری‌های sidecar ساخته می‌شود تا یک محیط نظارت و مدیریت ارتباطات سرویس به سرویس (service to service) کاملا یکپارچه را فراهم کند.ابزارها: Linkerd, Istio, Conduitچالش‌های میکروسرویس‌هاباتوجه به محبوبیت روزافزون میکروسرویس‌ها، این احتمال وجود دارد که این معماری در موقعیت‌هایی استفاده شود که هزینه‌ها بسیار بیشتر از مزایا باشد. میکروسرویس‌ها در همه‌ی موارد راه‌حل درستی نیست. موقعیت‌هایی هم وجود دارند که میکروسرویس‌ها برای آن‌ها مناسب است اما تیم‌ها آن‌ را با موفقیت پیاده‌سازی نمی‌کنند.در ادامه برخی از چالش های موجود در میکروسرویس‌ها را بررسی می‌کنیم.ماژولارسازی و ریفکتور کردن سرویس: در هر رویکرد ماژولارسازی، یافتن ماژول‌های مناسب با اندازه مناسب، تخصیص صحیح مسئولیت‌ها و طراحی خوب رابط‌ها، یک چالش است. چنین چیزی به ویژه برای میکروسرویس‌ها و سایر رویکردهایی که در آن‌ها طراحی بد مرزها می‌تواند منجر به افزایش ارتباطات شبکه‌ای شود، صادق است. چنین افزایشی ممکن است منجر به این شود که سیستم، به دلیل عملکرد بد و بی‌ثباتی، برای وظایف مورد نظرش، نامناسب شود. این چالش از دو جنبه قابل بررسی است: 1) ریفکتور کردن سیستم متشکل از میکروسرویس‌ها را می‌توان از طریق ابزار آسان‌تر کرد. اگرچه این امر ممکن است عواقب ناخواسته‌ای در رابطه با وابستگی توسعه یا زیرساخت داشته باشد. 2) حرکت به سمت ارتباطات غیرهمزمان، استفاده فراگیرتر از کتابخانه‌هایی که الگوهای ثبات را پیاده‌سازی می‌کنند، و محیط‍‍‌های اجرایی پیچیده‌تر، می‌تواند به رفع مشکلات ثبات کمک کند.دانه‌بندی سرویس: چالش دیگر، عدم توافق در مورد اندازه مناسب میکروسرویس‌هاست. با این که به نظر می‌رسد که میکروسرویس‌ها با توجه به نامشان باید تا حد امکان کوچک باشند، تیم‌های پروژه این اصل را به روش‌های بسیار متفاوتی تفسیر می‌کنند. بعضی از تیم‌ها دارای میکروسرویس‌هایی با تنها چند یا چند ده خط کد هستند. بعضی دیگر چند هزار خط کد را به همراه چند ده کلاس و موجودیت‌های پایگاه داده، در یک میکروسرویس کپسوله می‌کنند. ارتباط بین این سرویس‌های با اندازه متوسط می‌تواند همزمان یا غیرهمزمان باشد. همه‌ی این رویکرد‌ها قابل قبول هستند. با این حال با توجه به این که همه از نام میکروسرویس‌ها استفاده کرده اند، این امکان وجود دارد که مجموعه‌ای از الگوها ایجاد شود تا در هنگام تقسیم دامنه به میکروسرویس‌ها و تعیین اندازه هر سرویس، به تصمیم‌گیری‌های طراحی کمک کند.ادغام Front-End : رابط کاربری (UI) جزء مهمی در معماری میکروسرویس‌هاست. با این حال، رابط کاربری مرکز توجه بسیاری از طرفداران میکروسرویس، که معمولا معمارانی هستند که با جنبه‌های back end سروکار دارند، نبوده است. این امر می‌تواند منجر به سیستم‌هایی شود که در آن یک front‑tend یکپارچه (monolithic) از تعدادی میکروسرویس back‑end استفاده می‌کند. چنین معماری‌هایی ممکن است گاهی اوقات خوب باشند، اما اغلب مانع اهداف میکروسرویس‌ها می‌شوند، چون همه‌ی جنبه‌های منفی معماری monolithic هنوز وجود دارد. ماژولار کردن front‑end‌ها در انواع مختلف (web، native، hybrid)، به همراه ارتباط آن‌ها به عنوان بخشی از میکروسرویس‌ها یا یک موجودیت همکار، برای کمک به سازمان‌ها برای پیاده‌سازی یک محیط میکروسرویس full stack، به شدت مورد نیاز است.نظارت و مدیریت منابع: با رشد اندازه و پیچیدگی اپلیکیشن‌های میکروسرویس، تعداد و تنوع منابع زیرساختی (مانند ماشین‌های مجازی، containerها، سرویس‌ها، پیام‌ها و log‌ها)، که باید به طور مداوم در زمان اجرا نظارت و مدیریت شوند، نیز افزایش می‌یابد. به علاوه، ممکن است سرویس‌ها در چندین ناحیه و منطقه دسترسی مستقر شوند، چنین چیزی چالش جمع‌آوری اطلاعات درباره وضعیت و رفتار آن‌ها را تشدید می‌کند. در نهایت، با افزایش سطح خودکارسازی که فناوری‌های نظارت فعلی ارائه می‌دهند، ممکن است توسعه‌دهندگان خود را در میان سیلی از رویدادهای نظارتی ببینند و نتوانند تصمیمات مدیریتی به موقع بگیرند. یکی از مسائل مهم در اینجا این است که چگونه آستانه‌های هشدار و فیلترهای مناسبی تعریف شود، تا هر زمان که مشکلی پیش آمد به توسعه دهندگان اطلاع داده شود، بدون این که اطلاعات اضافی یا نامربوط بارگذاری شود. موضوع چالش برانگیزتر این است که چگونه از رویدادها و اقدامات گذشته یاد بگیریم، تا تصمیمات مدیریت منابع را بهتر اطلاع دهیم یا آن‌ها را خودکار کنیم. مانند بسیاری دیگر از سناریوهای کلان داده‌ها (big data)، تئوری کنترل و یادگیری ماشین باید نقش مهمی را در افزایش مقیاس‌پذیری نظارت و مدیریت منابع میکروسرویس‌ها ایفا کنند.خرابی (Failure)، بازیابی (Recovery) و خود ترمیمی (Self-Repair): میکروسرویس‌ها، مانند هر نوع سیستم توزیع شده، معمولا شکننده هستند. ممکن است به دلایل زیادی، مانند مشکلات شبکه، سخت‌افزار، یا اپلیکیشن، غیرقابل دسترس شوند یا به سادگی شکست بخورند. به دلیل وابستگی‌های سرویس‌، هر سرویس می‌تواند به طور موقت از دسترس خارج شود. در هر تنظیم توزیع‌شده‌ای، ارتباطات هر از گاهی با شکست مواجه می‌شود. با توجه به یک سیستم میکروسرویس به عنوان یک کل، خرابی‌های ارتباطی احتمالا اغلب به دلیل تعداد پیام‌های ارسالی بین سرویس‌ها، رخ می‌دهد. توسعه دهندگان باید به منظور به حداقل رساندن تأثیر قطعی‌های جزئی، سرویس‌هایی مقاوم در برابر خطا (fault tolerant) بسازند که بتوانند به خوبی به انواع خرابی‌ها پاسخ دهند. محققان و متخصصان راه‌هایی برای جداسازی خرابی‌ها پیشنهاد کرده‌اند تا در سراسر سیستم توزیع شده منتشر نشوند. با این حال، کار بیشتری برای مدیریت خودکار خرابی و راه‌حل‌های خود ترمیم برای ترمیم سیستم پس از خرابی، مورد نیاز است.ضدالگوها در میکروسرویس‌هادر این پژوهش به منظور شناسایی ضدالگوها در میکروسرویس‌ها مقاله‌ای را مورد بررسی قرار دادیم که در آن با 72 توسعه‌دهنده که تجربه توسعه سیستم‌های مبتنی بر میکروسرویس‌ها را داشتند، مصاحبه شده بود. از نتیجه این مصاحبه، Bad Smellهایی در زمینه میکروسرویس‌ها شناسایی شد. Bad Smellها همان ضدالگو ها هستند. در واقع Bad Smellها یا Bad Architectural Smellها علائمی از طراحی ضعیف هستند که می‌توانند منجر به کاهش قابلیت فهم و نگهداری کد شوند.‏‏Bad Smellهای شناسایی شده در این مقاله به ترتیب اولویت در ادامه آمده است.‏Wrong Cuts: عدم تفکیک میکروسرویس‌ها بر اساس کارکردهای کسب‌وکار و توجه به لایه‌بندی‌های فنی‏Hard-coded endpoints: تعریف ثابت IPو PORT سرویس‌ها در مبدا و مقصد یک ارتباط که باعث می‌شود پویایی سیستم کاهش پیدا کند و امکان جایگزین کردن سرویس‌ها نیز نباشد.‏Cyclic dependency: وجود حلقه زنجیره فراخوانی بین میکروسرویس‌ها می‌تواند باعث انتشار خطا و خرابی در مجموعه سیستم شود.‏Shared persistency: وجود دیتابیس‌های مشترک با جداول و موجودیت‌های مشترک بین میکروسرویس‌ها و امکان دسترسی هم‌زمان به این داده‌ها می‌تواند سازگاری داده‌ها را نقض کند.‏‏API versioning: اگر چندین API ورودی برای یک میکروسرویس وجود داشته باشد و در نام‌گذاری آن‌ها تفاوتی نباشد، می‌تواند در استفاده درست از آن میکروسرویس مشکل ایجاد کند.‏ESB usage: اگر واسط ارتباطی بین میکروسرویس‌ها یک گذرگاه سنگین‌وزن مثل ESBباشد، بار زیادی به مجموعه سیستم تحمیل می‌شود.‏‏‏Not having an API gateway: اگر درگاه ارتباطی بین میکروسرویس‌ها وجود نداشته باشد و هر کدام جداگانه به یکدیگر متصل شوند، شبکه‌ی ارتباطی بین آن‌ها بسیار پیچیده شده و مدیریت خطا سخت می‌شود.‏Inappropriate service intimacy: دسترسی هر میکروسرویس به داده‌های خصوصی میکروسروس دیگر باعث نقض استقلال هر یک می‌شود.‏Shared libraries: وجود کتابخانه‌های مشترک در پیاده‌سازی میکروسرویس‌های متفاوت باعث می‌شود که تغییر در هر یک از آن‌ها روی تعداد زیادی میکروسرویس اثر بگذارد.‏Too many standards: زیاده‌روی در استفاده از تکنولوژی‌ها و زبان‌های برنامه نویسی متفاوت در پیاده‌سازی میکروسرویس‌ها باعث ایجاد پیچیدگی‌های زیاد در سیستم خواهد شد.‏Microservice greedy: عدم تفکیک درست سیستم به میکروسرویس‌ها و زیاده‌روی در استفاده از آن‌ها باعث پیچیدگی خواهد شد؛ برای مثال برای نمایش یک یا دو صفحه استاتیک HTML یک میکروسرویس در نظر گرفته شود که ضرورتی ندارد.معماری Netflixنتفلیکس یکی از اولین شرکت‌هایی بود که معماری میکروسرویس‌ها را پذیرفت و از معماری monolithic به میکروسرویس‌ها در بستر cloud مهاجرت کرد. در حقیقت، این شرکت مفاهیم میکروسرویس‌ها را، ، قبل از این که حتی به طور آکادمیک معرفی شده باشند، اجرا کرد. بر این اساس می‌توانیم نتفلیکس را به عنوان یک راهبر تکنولوژی و پیشگام در زمینه مهاجرت به میکروسرویس‌ها مطرح کنیم. پس از نتفلیکس شرکت‌هایی مانند گوگل، توئیتر، IBMو آمازون به میکروسرویس‌ها مهاجرت کردند.در حدود 20 سال قبل، نتفلیکس مانند کلوپی بود که با دادن حق اشتراک، فیلم‌ها را در قالب DVD عرضه می‌کرد؛ اما در حال حاضر یکی از بزرگ‌ترین سیستم‌های پخش زنده در بستر اینترنت است. همان طور که مشخص است، برای چنین نیازمندی متفاوت و وسیعی که در طول زمان برای این شرکت ایجاد شد، معماری گذشته دیگر پاسخگو نبود و لازم بود تصمیمات متفاوتی در خصوص ساختار معماری آن گرفته شود.مهاجرت نتفلیکس به میکروسرویس‌ها بیش‌تر از دو سال به طول انجامید. چالش‌های زیادی در این بازه رخ داد، از جمله این که نتفلیکس می بایست هم زیرساخت های ابری خود را نگهداری می‌کرد تا از صحت عملکرد آن مطمئن شود، هم ساختار سنتی خود را حفظ می‌کرد، تا کاربران به مشکل نخورند؛ این مسئله هزینه زیادی را به این شرکت وارد کرد. به علاوه انتقال حجم زیادی از داده به سرورهای جدید، مشکلاتی از قبیل لود زیاد بار و کارآیی پایین را در بر داشت.در این پژوهش معماری نتفلیکس را مورد مطالعه قرار دادیم و فتاوری‌ها و ابزارهای به کارگرفته شده در آن را شناسایی کردیم. در ادامه به شرح جزئیات این معماری و فناوری‌ها و ابزارهای‌های آن می‌پردازیم.‏Netflix OSSنتفلیکس بلوک‌های بسیار جالبی را برای مدیریت و پیاده‌سازی میکروسرویس‌ها ساخته و به صورت open‑source ارائه کرده است. سایر شرکت‌ها می‌توانند از این فناوری‌ها و ابزارها برای پیاده‌سازی میکروسرویس‌ها استفاده کنند.‏Netflix OSS (Netflix Open Source Software Center) مجموعه‌ای از فریمورک‌ها و کتابخانه‌هایی است که نتفلیکس برای حل برخی مشکلات سیستم‌های توزیع‌شده (در زمینه مقیاس‌پذیری) نوشته است.الگوهای کشف سرویس (service discovery)، متعادل‌سازی بار (load balancing)، تحمل خطا (fault-tolerance) مفاهیم بسیار مهمی برای سیستم‌های توزیع‌شده مقیاس‌پذیر هستند و نتفلیکس راه‌حل‌های خوبی برای آن‌ها ارائه می‌کند.میکروسرویس‌ها در Netflixهمانطور که پیش‌تر گفتیم، نتفلیکس از سبک معماری میکروسرویس‌ها استفاده می‌کند. در این معماری، سرویس‌ها باید مستقل از یکدیگر باشند، به عنوان مثال، سرویس ذخیره‌سازی ویدیو از سرویسی که وظیفه رمزگذاری ویدیوها را بر عهده دارد جدا می‌شود.نتفلیکس برای افزایش قابلیت اطمینان (reliability) میکروسرویس‌ها:از ابزارهایی مانند Hystrix، Titus و Chaos Monkey استفاده می‌کند.میکروسرویس‌های حیاتی و مهم را جدا می‌کند. (Critical Microservices)سرویس‌ها به صورت stateless طراحی می‌شود.‏Critical Microservicesنتفلیکس تعدادی از سرویس‌ها را به عنوان سرویس‌های حیاتی جدا می‌کند و وابستگی آن‌ها به سایر سرویس‌ها را به حداقل می‌رساند. میکروسرویس‌های حیاتی شامل قابلیت‌های اساسی مانند جستجوی ویدئو، پیمایش فیلم‎‌ها و پخش ویدئو هستند. چنین روشی منجر به دسترسی‌پذیری (availability) بالا می‌شود و در بدترین سناریو حداقل یک کاربر قادر به انجام کارهای اساسی می‌باشد.‏Stateless Servicesطراحی سرویس‌ها به گونه‌ای است که اگر یکی از endpointها دچار خطا شد یا درخواست به موقع سرویس‌دهی نشد، بتوان به سرور دیگری سوئیچ کرد و کار را انجام داد. در واقع به جای تکیه بر یک سرور خاص و حفظ وضعیت (state) در آن سرور، می‌توان درخواست را به سرور (service instance) دیگری هدایت کرد. اگر سروری از کار بیفتد با سرور دیگری جایگزین خواهد شد.مؤلفه‌های اپلیکیشن Netflixنتفلیکس روی دو cloud کار می‌کند: AWS و Netflix Open Connect (Netflix CDN)اپلیکیشن نتفلیکس دارای 3 مؤلفه اصلی است:‏Client: مؤلفه client دستگاه یا رابط کاربری است که از آن برای مرور و پخش ویدئو‌ها استفاده می‌شود، مانند لپتاپ، تلوزیون، تلفن همراه و XBOX.‏‏OC (Open Connect) یا ‏Netflix CDN: ‏CDN (Content Delivery Network) شبکه‌ای از سرورهای توریع شده در مکان‌‌های جغرافیای مختلف است. Open Connect، CDN سفارشی خود نتفلیکس است. همه موارد مربوط به پخش ویدئو در این مؤلفه کنترل می‌شود. در اپلیکیشن نتفلیکس ویدئو از نزدیک ترین سرور (OC)، به جای سرور اصلی، پخش می‌شود و در نتیجه پاسخ‌دهی سریع‌تر است.‏Backend: مؤلفه ‏Backend شامل پایگاه‌داده‌ها، سرورها، monitoring، موتور recommendation، سرویس‌های background و ... می‌باشد. تمامی موارد (به غیر از موارد مربوط به پخش ویدئو) مانند محتوای جدید، پردازش ویدئوها، توزیع ویدئوها روی سرورهای مختلف در نفاط مختلف جهان و مدیریت ترافیک شبکه در این مؤلفه کنترل می‌شود. ‏AWS EC2، AWS S3، Cassandra، Hadoop و Kafkaنمونه‌هایی از سرویس‌های Backend هستند. اکثر فرآیند‌ها و درخواست‌ها مانند login، recomendationها، تاریخچه‌ی کاربران، صورتحساب‌ها، و پشتیبانی مشتری، توسط سرویس‌های وب آمازون (AWS) انجام می‌شود.‏‏Frontend نتفلیکس با استفاده از ReactJS نوشته شده است.پایگاه‌داده‌های Netflixنتفلیکس از دو پایگاه داده مختلف یعنی MySQL و Cassandra استفاده می‌کند.‏EC2 MySQLنتفلیکس داده هایی مانند اطلاعات صورتحساب، اطلاعات کاربر و اطلاعات تراکنش را در MySQL ذخیره می کند (زیرا این داده‌ها به قابلیت‌های ACID نیاز دارند).پایگاه داده MySQL نتفلیکیس روی instance های Amazon EC2 با موتور InnoDB مستقر شده است.‏Apache Cassandra‏Apache Cassandra یک پایگاه داده توزیع شده NoSQL متن‌باز (open-source) است که برای مدیریت حجم زیادی از داده‌ها طراحی شده است.نتفلیکس از Cassandra برای مقیاس پذیری (scalability)، عدم وجود نقاط شکست واحد (single points of failure) و استقرارهای بین منطقه‌ای (cross-regional deployment) استفاده می کند.نتفلیکس انواع داده ها را در نمونه های Cassandra DB خود ذخیره می کند. به عنوان مثال، تاریخچه مشاهده هر کاربر در Cassandra ذخیره می شود. در ابتدا تاریخچه مشاهده در یک سطر (row) ذخیره می‌شد، اما با افزایش کاربران نتفلیکیس، حجم داده‌ها نیز افزایش یافت و منجر به هزینه عملیاتی بیشتر و کارایی کمتر اپلیکیشن شد. از این رو نتفلیکس معماری ذخیره سازی داده را با دو هدف بازطراحی کرد: 1) Storage Footprint کوچک‌تر، 2) ثبات کارایی خواندن/نوشتن با افزایش بازدید به ازای هر کاربر. برای حل این مسئله سطرهای قدیمی فشرده شدند و داده‌ها را به دو نوع تقسیم شدند:تاریخچه مشاهده زنده Live Viewing History (LiveVH): تعداد کمی رکوردهای مشاهده اخیر با به روز رسانی‌های مکرر به صورت غیر فشرده ذخیره می شوند.تاریخچه مشاهده فشرده شده Compressed Viewing History (CompressedVH): تعداد زیادی رکوردهای مشاهده قدیمی با به‌روزرسانی‌های نادر، به منظور کاهش فضای ذخیره سازی، به صورت فشرده ذخیره می شوند. این نوع داده به ازای هر RowKey در یک ستون واحد ذخیره می شود.ابزارهای استفاده شده در معماری Netflixدر این بخش به بررسی تعدادی از ابزارهایی که Netflix در معماری خود استفاده کرده است، می‌پردازیم.‏Elastic Load Balancer (ELB)نتفلیکس از سرویس ELB آمازون برای هدایت ترافیک به سرویس‌ها استفاده می‌کند. در ELB ابتدا بار (load) روی مناطق (zoneها) و سپس بین سرورها (instanceها) موازنه و بالانس می‌شود این سرویس از تکنیک Round Robin Balancing برای تعادل بار استفاده می‌کند. در نهایت ELBدرخواست را به درگاه API می‌فرستد.‏‏ZUULنتفلیکس از ZUUL به عنوان API gatewayاستفاده می‌کند. ZUUL یک gateway service است که dynamic routing، monitoring، انعطاف‌پذیری و امنیت را فراهم می‌کند.در ادامه نحوه عملکرد ZUUL در نتفلیکس را بررسی می‌کنیم.سرور ZUUL به صورت dynamic درخواست‌ها را به اپلیکیشن‌های backend هدایت می‌کند. Netty handlerها در جلو و پشت فیلترها مسئولیت رسیدگی به پروتکل شبکه، وب‌سرور، مدیریت اتصال و proxying را برعهده دارند. وقتی درخواستی به Netty server رسید، Netty server آن درخواست را به inbound filter میفرستد. Inbound filterها قبل از پروکسی درخواست اجرا می شوند و برای احراز هویت، مسیریابی یا تزئین درخواست استفاده می‌شوند. سپس Endpoint filter برای بازگرداندن یک پاسخ استاتیک (static response) یا پروکسی درخواست به سرویس backendاستفاده می‌شود. پس از بازگرداندن پاسخ outbound filterها اجرا می شوند و برای مواردی مانند معیارها یا افزودن/حذف هدرهای سفارشی استفاده می‌شوند.‏Hystrixدر یک سیستم پیچیده توزیع شده، ممکن است یک سرور به پاسخ سرور دیگری متکی باشد. وابستگی‌های بین سرورها می‌تواند منجر به تأخیر شود و اگر یکی از سرورها در نقطه‌ای از کار بیفتد، ممکن است کل سیستم از کار بیفتد. کتابخانه Hystrix با افزودن منطق تحمل تاخیر (latency tolerance) و تحمل خطا (fault tolerance)، تعاملات بین سرویس‌های توزیع شده را کنترل می‌کند. Hystrix این کار را با ایزوله کردن نقاط دسترسی بین سرویس‌ها، سیستم‌های remote و کتابخانه‌های شخص ثالث انجام می‌دهد.مثال: اگر میکروسرویسی که لیست فیلم‌های مناسب را به کاربر ارائه میکند، fail شود، ترافیک به میکروسرویسی که 10 فیلم برتر را برمی‌گرداند تغییر مسیر می‌دهد و در نتیجه خرابی کنترل می‌شود.مزایای Hystrix:جلوگیری از خرابی‌های آبشاری (cascading failure)بازیابی سریع‏Real-time monitoringکش کردن درخواست‌ها به صورت concurrency awareبه این نکته توجه داشته باشید که Netflix Hystrix دیگر در حال توسعه فعال نیست و در حال حاضر در حالت تعمیر و نگهداری است. برخی از پروژه های داخلی در حال حاضر با resilience4j در حال ساخت هستند.‏Titus‏Titus یک پلتفرم مدیریت container است که اجرای container مقیاس پذیر و قابل اعتماد و ادغام cloud-native با Amazon AWS را فراهم می‌کند. Titus توسط نتفلیکس ساخته شده است و برای تقویت استریم، recomendation و سیستم‌های محتوا استفاده می‌شود.‏Titus هزاران نمونه AWS EC2 را مدیریت می‌کند و روزانه صدها هزار container را برای workloadهای دسته‌ای و سرویس راه‌اندازی می‌کند.‏Titus می‌تواند تصاویر بسته‌بندی‌شده (images packaged) را به‌عنوان containerهای Docker اجرا کند و در عین حال امنیت و قابلیت اطمینان (reliability) بیشتری را در مورد اجرای containerفراهم کند.می‌توان Titus را به عنوان نسخه نتفلیکس Kubernetes در نظر گرفت.‏Chaos Monkey‏Chaos Monkey اسکریپتی است که به طور مداوم در تمام محیط‌های Netflix اجرا می‌شود و با خاموش کردن تصادفی نمونه‌های سرور باعث بی‌ نظمی و هرج و مرج (chaos) می‌شود. از این رو، در حین نوشتن کد، توسعه دهندگان نتفلیکس به طور مداوم در محیطی از سرویس‌های غیرقابل اعتماد و قطعی های غیرمنتظره فعالیت می‌کنند. در واقع Chaos Monkey نمونه‌ها را به طور تصادفی متوقف (terminate) می‌کند تا اطمینان حاصل کند که توسعه‌دهندگان، سرویس‌ها را به گونه‌ای پیاده‌سازی می‌کنند که در برابر خرابی‌ها انعطاف پذیر باشد.‏EVCache‏EVCache یک راه حل ذخیره سازی cache توزیع شده مبتنی بر Memcached و Spymemcached است که به خوبی با Netflix OSS و زیرساخت AWS EC2 یکپارچه شده است.در بسیاری از اپلیکیشن‌ها، حجمی از داده‌ها به طور مکرر استفاده می‌شوند. برای پاسخ سریع‌تر، می‌توان این داده‌ها را در حافظه cacheبسیاری از endpointها ذخیره کرد و آن‌ها را به‌جای سرور اصلی از cache دریافت کرد. این کار باعث کاهش بار سرور اصلی می شود، اما مشکل اینجاست که اگر گره دچار خرابی شود، تمام حافظه پنهان از دست می‌رود و کارایی برنامه را تحت تأثیر قرار می‌دهد. برای حل این مشکل نتفلیکس لایه cache سفارشی خود به نام EVCache را ساخته است. EVCache در واقع یک پوشش (wrapper) در اطراف Memcached است.هر cluster دارای تعداد زیادی گره‌ی Memcached است و آن‌ها نیز cache clientهایی دارند. داده‌ها در سراسر cluster در یک منطقه (zone) به اشتراک گذاشته می‌شود و چندین نسخه کپی از cache در گره‌های خرد شده (sharded node) ذخیره می شود. در هر write برای client، تمام گره‌ها در همه cluster‌ها به‌روزرسانی می‌شوند، اما read از حافظه cache، فقط به نزدیک‌ترین cluster و گره‌های آن (نه همه cluster‌ها و گره‌ها) ارسال می‌شود. در صورتی که یک گره در دسترس نباشد، از گره دیگری که در دسترس است می‌خواند.این رویکرد کارایی (performance)، دسترس‌پذیری (availability) و قابلیت اطمینان (reliability) را افزایش می‌دهد. به طور سنتی ذخیره‌سازی cache روی RAM انجام می‌شود، اما ذخیره کردن حجم زیادی از داده‌ها در RAM هزینه زیادی دارد. از این رو نتفلیکس تصمیم گرفت تا برخی از داده های cache را به SSDمنتقل کند.‏Apache Chukwa‏Apache Chukwa یک سیستم جمع‌آوری داده open-source برای نظارت بر سیستم‌های توزیع شده بزرگ است. Apache Chukwa بر روی سیستم فایل توزیع شده Hadoop (HDFS) و چارچوب Map/Reduce ساخته شده است و مقیاس پذیری و استحکام Hadoop را به ارث برده است. Apache Chukwa همچنین دارای مجموعه‌ای منعطف و قدرتمند از ابزارها برای نمایش (displaying)، نظارت (monitoring) و تجزیه‌و‌تحلیل (analyzing) داده‌های جمع‌آوری‌شده است.نتفلیکس تقریبا 500 میلیارد رویداد داده با مصرف 1.3 پتابایت در روز و 8 میلیون رویداد با مصرف 24 گیگابایت در ثانیه در زمان اوج مصرف، پردازش می‌کند. این رویدادها شامل اطلاعاتی مانند لاگ‌های خطا، فعالیت‌های رابط کاربری، رویداد‌های اجرایی، فعالیت‌های مشاهده ویدئو، و رویدادهای اشکال‌زدایی می‌باشد.Apache Chukwa این رویدادها را از بخش‌های مختلف سیستم جمع‌آوری می‌کند و آن‌ها را در فرمت Hadoop file sequence (S3) می نویسد.‏Apache Kafka‏Apache Kafka یک پلتفرم استریم رویداد توزیع‌ شده open-source است که توسط هزاران شرکت برای piplineهای داده با کارایی بالا، تجزیه‌وتحلیل جریان داده‌ها، یکپارچه سازی داده‌ها و اپلیکیشن‌های حیاتی استفاده می‌شود.در نتفلیکس Apache Kafka مسئول انتقال داده‌ها از kafkaجلویی به موارد مختلفی از جمله S3، Elastic Search، و kafka ثانویه است. مسیریابی این پیام‌ها با استفاده از فریمورک Apache Samzaانجام می‌شود.ترافیک ارسالی توسط Chukwa می‌تواند استریم‌های کامل یا فیلتر شده باشد، بنابراین گاهی اوقات ممکن است لازم باشد فیلترهای بیشتری روی استریم‌های Kafka اعمال شود. به همین دلیل router از یک عنوان Kafka به عنوان دیگر Kafka در نظر گرفته می‌شود.‏Apache Samza‏Apache Samza یک فریمورک open-source محاسباتی غیرهمزمان برای پردازش استریم است. به عبارت دیگر Apache Samza یک موتور پردازش داده مقیاس پذیر است که پردازش و آنالیز داده‌ها را به صورت real-time ممکن می‌سازد.‏Apache Samza در ارتباط با Apache Kafka توسعه یافته است.‏Elasticsearch‏Elasticsearch یک موتور جستجو و آنالیز توزیع شده است که بر روی Apache Lucene ساخته شده است. در واقع Elasticsearc یک موتور جستجوی full-text توزیع شده با قابلیت multitenant است.نتفلیکس از Elasticsearch برای مصورسازی داده ها، پشتیبانی مشتری و برای تشخیص خطا در سیستم استفاده می کند. با Elasticsearch به راحتی می توان وضعیت سیستم را monitorو لاگ‌های خطا و خرابی ها را عیب یابی کرد. به عنوان مثال، اگر کاربر قادر به پخش ویدئو نباشد، مسئول خدمات مشتری این مشکل را با استفاده از elastic search حل می کند. تیم پخش ویدئو، کاربر را جستجو می‌کند تا بداند چرا ویدیو در دستگاه کاربر پخش نمی‌شود. آنها از تمام اطلاعات و رویدادهایی که برای آن کاربر خاص اتفاق می‌افتد آگاه می‌شوند و متوجه می‌شوند که چه چیزی باعث خطا در استریم ویدیو شده است. همچنین برای پیگیری استفاده از منابع و شناسایی مشکلات ثبت نام (signup) یا ورود (login) از elastic search استفاده می‌شود.‏Apache Spark‏Apache Spark یک موتور چند زبانه برای اجرای مهندسی داده، علم داده و یادگیری ماشین در ماشین‌ها یا خوشه‌های single‑node است. نتفلیکس از Apache Spark و یادگیری ماشین برای پیشنهاد فیلم (Movie recommendation) استفاده می‌کند.معماری Amazonتا سال 2000، با وجود این‌که معماری آمازون از لایه‌های مختلفی تشکیل شده بود، اما همچنان یک معماری یکپارچه به حساب می‌آمد، چرا که بخش‌های مختلف، وابستگی زیادی به هم داشتند. از آن سال با توجه به پیچیده‌تر شدن کسب‌وکار آمازون و وسعت زیاد سورس کد آن، این شرکت به سمت تغییر معماری به میکروسرویس‌ها حرکت کرد. آمازون جز اولین شرکت‌هایی نبود که قصد مهاجرت از معماری monolithic به میکروسرویس را داشت، اما به دلیل فراهم آوردن ساختارهای Cloud مانند Amazon Web Service می‌توان گفت هموارکننده‌ی راه سایر شرکت‌ها برای انجام این مهاجرت بوده است؛ چرا که سرویس‌هایی را در فضای Cloud ایجاد کرد که پیچیدگی توسعه میکروسرویس‌ها را بسیار کاهش می‌داد. در معماری میکروسرویس وب‌سایت آمازون نیز از سرویس‌هایAWS استفاده شده است.حال که دانستیم از سرویس‌های (AWS) در توسعه معماری میکروسرویس در آمازون استفاده شده است، ابتدا از دیدگاه کسب‌وکار به بررسی میکروسرویس‌های آن می‌پردازیم.میکروسرویس‌های وب‌سایت آمازونوب‌سایت آمازون از سرویس‌هایی مانند Search، Wish List، Order Tracking، Pricing، Logistics، Items، Purchase Orders، Notification، Recommendation، Historical Order، Order Processing، Archival، Warehouse و Inventory Management تشکیل شده است.هر یک از سرویس‌هایی که در بالا گفته شد، یک فعالیت مستقل دارند و ارتباطات آن‌ها با یکدیگر، سیستم اصلی وب‌سایت فروشگاهی آمازون را تشکیل می‌دهد. نکته‌ای که در مورد آمازون، حائز اهمیت است این است که چون آمازون یک فروشگاه اینترنتی است دائما باید با تامین‌کنندگان کالاها در ارتباط باشد و حجم زیادی از داده‌ها از بیرون سیستم وارد آن می‌شوند و پس از انجام پردازش‌هایی، این داده‌ها درون دیتابیس‌های داخلی سیستم ذخیره می‌شوند و در اختیار کاربر قرار می‌گیرد. پس یکی از سناریو‌های اصلی در معماری میکروسرویس آمازون، کنترل جریان داده‌هایی است که می‌تواند از بیرون از سیستم وارد شده و باید پردازش شوند. دو جریان کلی در معماری آمازون وجود دارد: 1) جریان جستجوی محصولات توسط کاربر و 2) جریان خرید کاربر. نقش اصلی در هدایت داده‌ها در این دو جریان بر عهده مولفه Brokerاست که ترتیب انجام عملیات و وابستگی بین میکروسرویس‌ها را تعیین می‌کند. در ادامه مثالی از عملکرد آن آمده است.اطلاعاتی که از سمت تامین‌کنندگان می‌آید، توسط Inbound Serviceها دریافت شده که به آن‌ها سرویس‌های ورودی گفته می‌شود. وظیفه‌ی این سرویس‌ها واکشی داده‌ها از سرویس‌های خارجی و انتقال آن‌ها به مولفه‌های سیستم آمازون است. برای مثال زمانی که تامین‌کننده‌ای محصول جدیدی را به خدماتش اضافه می‌کند و یا با تامین کننده‌ی جدیدی قرارداد بسته می‌شود، این اطلاعات توسط Inbound Serviceها دریافت شده و وارد Brokerمی‌شود. میکروسرویس‌های دیگر در سیستم مثل Item Serviceهمواره از Inbound Service، Listen می‌کند و زمانی که متوجه ورود و یا تغییر آیتمی شد، API های Add یا Updateرا در دیتابیس مخصوص خود، صدا می‌زند تا داده‌هایش بروز باشند. همان‌طور که قبلا نیز اشاره شد، معمولا هر میکروسرویس، دیتابیس مختص خود را دارد. در این مثال نیز سرویس Item از یک دیتابیس NoSQL استفاده می‌کند؛ زیرا قبل از انجام هر پردازشی روی داده‌ها می‌خواهد فقط وضعیت آیتم‌های موجود در سیستم را در لحظه و آپدیت شده داشته باشد؛ حال این اطلاعات می‎تواند از سمت یک تامین‌کننده‌ی کالای دیجیتال آمده باشد یا یک تامین‌کننده‌ی مد و پوشاک.پس از این که ورود این اطلاعات در دیتابیس میکروسرویس Itemثبت شد، پیام به Broker ارسال می‌شود و میکروسرویس Search Consumer با Listen کردن از آن، داده‌ها را دسته‌بندی و فیلتر کرده و در دیتابیس خود که Elastic Search Clusterاست، ذخیره می‌کند. دلیل استفاده از این دیتابیس، کارآیی بالای آن در انجام جستجوهای متنی و Fuzzy Search است. حال که داده‌ها پردازش شده و در یک دیتابیس کارا ذخیره شدند، میکروسرویس Search می‌تواند از این دیتابیس استفاده کند و برای مثال کاربری که در Home Pageآمازون، محصولی را جستجو کند، اطلاعات از این دیتابیس خوانده می‌شود. علاوه بر Inbound Serviceها که می‌توانند اطلاعاتی را به Broker منتقل کنند، مولفه‌ی Apache Spark Clusterنیز گزارش‌هایی از وضعیت جستجو‌ها در سیستم، می‌سازد که می‌تواند این اطلاعات را به عنوان Recommendation در اختیار Brokerقرار دهد و پس از آن در میکروسرویس جستجو از آن استفاده شود.در جریان خرید کاربر، سازگاری داده‌ها بسیار اهمیت دارد، چرا که اگر محصولی، می‌تواند به عنوان خرید قطعی وارد سبد خرید کاربر شود، باید اطلاعات آن با موجودی آن کالا در سیستم همخوانی داشته باشد. پس در میکروسرویس Ordersاز دیتابیس‌های رابطه‌ای مثل My SQLاستفاده می‌شود که بتوان خاصیت‌های ACID را در آن به طور موثری رعایت کرد. اما نکته‌ای که وجود دارد این است که برای وب‌سایت آمازون، با حجم ترافیک بسیار زیادی که دارد، شاید استفاده از دیتابیس‌های رابطه‌ای به یک گلوگاه تبدیل شود و بر روی کارآیی سیستم اثر بگذارد. یک راه حل برای این مسئله این است که سفارشاتی که به وضعیت نهایی خود رسیده‌اند، یعنی تحویل داده شده یا لغو شده‌اند، توسط میکروسرویس دیگری به نام Order Processing، دنبال شده و به دیتابیس‌های NoSQLدیگری وارد شوند. این موضوع باعث می‌شود در مراجعات بعدی کاربر و برای انجام پردازش‌های Recommendation دیگر نیاز به استفاده از دیتابیس‌های رابطه‌ای نباشد و کارآیی سیستم بالا می‌رود.در این سناریو نقش Broker به عنوان واسط در توالی بین میکروسرویس‌ها و نحوه‎ی ذخیره‌سازی داده‌ها بررسی شد.ابزارهای استفاده شده در معماری Amazonوب‌سایت آمازون روی AWS کار می‌کند و بخشی از ابزارهایی که از آن برای پیاده‌سازی میکروسرویس‌ها استفاده می‌شود، به تفکیک فناوری در ادامه آمده است.ابزارهای آمازون در زمینه‌ی Computingهر میکروسرویس روی یک Container به نام Amazon Elastic Container Service(Amazon ECS) یا Elastic Kubernetes Service (EKS) مستقر شده است.سه روش معمول برای پیاده‌سازی میکروسرویس‌ها عبارتند از:استفاده از تابع‌های Serverless با استفاده از AWS lambdaراه‌اندازی docker containerها روی مدل‌های serverless با استفاده از AWS Fargateراه‌اندازی kubernetesهای مدیریت شده در AWS‏ابزارهای آمازون در زمینه‌ی Storageبرای ذخیره‌سازی امن داده‌ها از Amazon simple storage service (S3) و Elastic Cache استفاده می‎‌شود.‏ابزارهای آمازون در زمینه‌ی Networkingبرای مدیریت ارتباطات بین میکروسرویس‌ها از Amazon API Gateway و برای تعیین داینامیک مسیر برای هدایت ترافیک از AWS Elastic Load Balancing و برای orchestration از Amazon ECS Service Discovery و AWS App Mesh استفاده شده است.ابزارهای آمازون در زمینه‌ی Monitoringبرای مانیتورکردن ترافیک در سیستم از AWS CloudTail استفاده می‌شود و برای مانیتورکردن زیرساخت‌ها (دیتابیس‌ها، کانتینرها و غیره) از Amazon CloudWatch استفاده می‌شود.ابزارهای آمازون در زمینه‌ی Messagingبرای انتقال و ایجاد صف‌های پیام از Simple Queue Service (SQS) استفاده شده و برای ارسال نوتیفیکیشن از سرویس Amazon SNS استفاده می‌شود.پایگاه‌داده‌های آمازونبرای استفاده از پایگاه‌داده­‌های رابطه‌ای و غیررابطه‌ای و Cloud native از سرویس‌های زیر استفاده می‌شود:‏Amazon RDS با دیتابیس‌های رابطه‌ای مثل PostgreSQL، MariaDB، MySQL، Oracle و Microsoft SQL Server سازگار است.‏Amazon Neptune graph database، DocumentDB و DynamoDB با دیتابیس‌های غیر‌رابطه‌ای سازگار هستند.‏Amazon Aurora خود یک دیتابیس cloud native است.معماری SoundCloud‏SoundCloud در حدود سال 2012 معماری خود را به میکروسرویس‌ها تغییر داد. وجود مشکلاتی مانند بروز ریسک‌های زیاد در هنگام اعمال تغییرات روی سیستم monolith، زمان‌گیر بودن تغییرات، افزایش حجم داده‌ها و دشوار بودن نگهداری و پشتیبانی از پایگاه داده‌ها، سبب شد تا تیم SoundCloudبه معماری میکروسرویس‌ها مهاجرت کند.در روند تکاملی معماری میکروسرویس‌ها در SoundCloudمی‌توانیم ابتدا الگوی BFF (Backends for Frontends)، سپس الگوی VAS (Value Added Service) و پس از آن رویکرد Domain Gateway را در نظر بگیریم.در ادامه به بررسی لایه‌های سرویس در معماری SoundCloud، رویکردهای BFF، VASو Domain Gateway و مزایا و معایب آن‌ها و تعدادی از ابزارهای استفاده شده در معماری SoundCloud می‌پردازیم.لایه‌های سرویس در معماری SoundCloud‏Edge‏ (لبه): این لایه قابلیت‌های درگاه API را فراهم می‌کند و محل قرار گرفتن BFF‌ها (Backends for Frontends) می‌باشد. BFFها، APIهای اختصاصی هستند که متناسب با نیازهای مشتری خاص طراحی شده اند.‏Value Added‏ (ارزش افزوده): سرویس‌های این لایه، داده‌های سایر سرویس‌ها را می‌گیرند و به روشی آن‌ها را پردازش می‌کنند تا تجربیات غنی برای کاربران بسازند.‏Foundation (بنیاد): سرویس بنیادی، سرویس سطح پایینی است که بلوک‌های سازنده حول یک دامنه را فراهم می‌کند.الگوی Backends for Frontends (BFF) در معماری SoundCloud‏BFFها مسئولیت‌های درگاه API، از جمله احراز هویت، پاکسازی header وکنترل حافظه cache، را انجام می‌دهند. SoundCloud ده‌ها BFF را اجرا می‌کند. ترافیک خارجی وارد شده به مراکز داده SoundCloud، توسط یکی از BFFها پردازش می‌شود. در مجموع BFFها به صدها میلیون درخواست در ساعت رسیدگی می‌کنند.‏BFFها از یک کتابخانه داخلی استفاده می‌کنند که قابلیت های edge و همچنین نقاط توسعه برای رفتار سفارشی را فراهم می‌کند. نسخه‌های جدید کتابخانه به صورت نیمه‌خودکار در عرض چند ساعت در همه BFFها منتشر می‌شود.نمونه‌هایی از BFFها در SoundCloud عبارتند از:‏Mobile API (برنامه‌های Android و iOS)‏Web API (بخش‌های وب و ویجت)‏Public API‏Partner APIمزایای الگوی BFFجداسازی APIها بر اساس نوع client و بهینه‌سازی راحت API متناسب با نوع clientافزایش سطح انعطاف‌پذیری (resilience)سرعت بالای توسعهمعایب الگوی BFFپیچیدگی غیر ضروری و ایجاد کد تکراریوجود منطق کسب‌وکار و مجوزهای متفاوت در هر یک از BFFها و چالش در نگهداری و همگامی کدالگوی سرویس ارزش افزوده (VAS) در معماری SoundCloudالگوی VAS معماری تمیزتر و جداسازی بهتر دغدغه‌‍‌ها را ممکن می‌سازد و یک نقشه راه روشن برای معماری میکروسرویس‌ها فراهم می‌کند.بلوک‌های سازنده‌ی سرویس‌های ارزش افزوده (VAS)‏Domain (دامنه): دغدغه کاربر یا کسب‌وکار، که در طراحی مرزها حول یکپارچه‌سازی سرویس‌ها مورد استفاده قرار می‌گیرد.‏Entity (موجودیت): موجودیت شیئی است که دارای شناسه مستقل و چرخه حیات است.‏Value Objects‏ (اشیاء ارزش): اشیاء ارزش شامل فراداده‌های (metadata) مربوط به یک موجودیت معین هستند. این اشیاء با چرخه حیات موجودیت نیز در ارتباط هستند.‏Aggregate (تجمع): Aggregate مجموعه ای از یک یا چند موجودیت مرتبط است و دارای یک موجودیت ریشه به نام Aggregate Root است. Aggregateها می توانند ارجاعاتی به موجودیت‌های دیگر داشته باشند، و این به سرویس‌های مصرف‌کننده بستگی دارد که سایر سرویس‌ها را برای ترکیب ارجاعات موجودیت فراخوانی کنند.سرویس‌های ارزش افزوده (Value Added Services)سرویس‌های ارزش افزوده، سرویس‌های تجاری هستند که مسئول برگرداندن یک موجودیت (Entity) و اشیاء ارزش (Value Objects) مرتبط با آن (به عبارت دیگر، Aggregate) به فراخوانی کننده (caller) هستند. توجه به این نکته مهم است که VASمسئول ترکیب متادیتا برای هیچ یک از موجودیت‌های مرتبط نیست. VAS امکان جداسازی دغدغه‌ها را به خوبی فراهم می‌کند؛ یک نقطه متمرکز وجود دارد که در آن متادیتا و قوانین مجوز (authorization) یک موجودیت معین تعریف می‌شود. در ادامه سرویس ارزش افزوده (VAS) می‌تواند فراخوانی سرویس‌ها را برای ترکیب و صدور مجوز Aggregateها و سپس برگرداندن به BFF، هماهنگ کند.مثالی از VAS در SoundCloudبه عنوان مثال، آهنگ (track) موجودیتی است که دارای اشیاء ارزشی مانند metadata، transcoding‌ها، و سیاست‌های مجوز (authorization) برای تعیین دسترسی است. track به user مالک نیز مرتبط است، اما از آنجایی که user موجودیت دیگری است، تنها شامل شناسه کاربر (user ID) به عنوان ارجاع می‌باشد. سرویس مصرف‌کننده با داشتن شناسه track، سرویس ارزش افزوده Tracks VAS را فراخوانی می‌کند؛ VAS از قابلیت دسترسی track اطمینان حاصل می‌کند و سپس track aggregate مربوطه را برمی‌گرداند.در الگوی Backends for Frontends درخواست کاربر نهایی برای پخش track، به BFF ارسال می‌شود. تعیین اینکه آیا دسترسی کاربر به این track مجاز است یا خیر، بر عهده BFF خواهد بود. این الگو شامل فراخوانی سرویس‌های بنیادی مختلفی است که به طور جداگانه مسئول بازگرداندن اطلاعات مجوز و متادیتای track هستند.با معرفی VAS تمام منطق تکراری حول فراخوانی‌های سرویس‌های بنیادی در BFF‌ها به سرویس ارزش افزوده Tracks VAS منتقل شد، که علاوه بر کنترل قابلیت دسترسی و مجوزهای track، به ترکیب‌ track aggregate ها برای BFF‌ها نیز رسیدگی می‌کند. در ادامه BFFمسئول نگاشت track aggregate های داخلی به نمایندگی‌های خارجی برای استفاده مشتریان است.مزایای الگوی VASکاهش تکرار کد در BFFهاجمع کردن منطق یکسان BFFها برای هماهنگی فراخوانی سرویس‌های وابسته در یک سرویسریفکتور و بهینه‌سازی سریع‌تر و آسان‌تر به دلیل وجود یک سرویس متمرکزمعایب الگوی VASهزینه‌های نگهداری و زیرساخت با ایجاد VASجدیدافزایش تاخیر شبکه در الگوی VAS نسبت به الگوی BFFرویکرد Domain Gateway در معماری SoundCloudممکن است یک موجودیت (مانند آهنگ - track)، در دامنه‌های مختلف، برای اهداف مختلف و با الگوهای دسترسی و نیازمندی‌های مجوز متفاوتی استفاده شود. به عنوان مثال SoundCloud علاوه بر این که اپلیکیشنی برای فهرست موسیقی‌ها ارائه می‌دهد، ابزاری را برای سازندگان موسیقی فراهم می‌کند تا موسیقی خود را آپلود کنند و به اشتراک بگذارند. سازندگان و گوش‌دهندگان موسیقی، دامنه‌های متفاوتی هستند.یکی از روش‌های ممکن در اینجا این است که همه موارد مربوط به track(در همه دامنه‌های مختلف) - از جمله کوئری‌ها و دستورات مرتبط - در یک VAS واحد پیاده سازی شود. این روش برای مدتی به خوبی کار می‌کند، اما در نهایت خطر افزایش کوپلینگ (coupling) و پیچیدگی و کاهش بهره‌وری وجود دارد.یک رویکرد مقیاس پذیرتر، شناسایی دامنه‌های مختلف کسب‌وکار و ایجاد یک درگاه دامنه (Domain Gateway) برای هر یک از آن‌هاست. در اصل، Domain Gateway اجرای VAS ای است که مربوط به یک دامنه کسب‌وکار خاص است. هر Domain Gateway می‌تواند توسط تیم‌های مختلف نگهداری شود. به علاوه، هر Domain Gateway دید‌(view)های متفاوتی را در مورد یک موجودیت معین نشان می‌دهد. این نما (facade) می‌تواند پایداری (stability) را فراهم کند و به عنوان یک لایه ضد خرابی (anti-corruption) برای هر یک از دامنه‌ها عمل کند.مزایای رویکرد Domain Gatewayنگهداری توسط تیم‌های مختلف و بهبود استقلال تیمافزایش پایداری (stability)افزایش مقیاس‌پذیری (scalability)ابزارهای استفاده شده در معماری SoundCloudدر این بخش به بررسی تعدادی از ابزارهایی که SoundCloud در معماری خود استفاده کرده است، می‌پردازیم.‏Finagle‏‏Finagle یک فریمورک RPC توسعه‌پذیر و مستقل از پروتکل است که توسط Twitter توسعه داده شده است.اکثر میکروسرویس‌های SoundCloud روی Finagleساخته شده اند و به Scala نوشته شده اند.کلاینت‌ها و سرورهای Finagle با استفاده از non blocking I/O روی فریمورک Netty، باعث افزایش مقیاس‌پذیری (scalability) می‌شوند.‏Finagle قابلیت پیکربندی و توسعه بالایی دارد.‏Jvmkit‏‏SoundCloud از یک کتابخانه داخلی به نام jvmkitاستفاده می‌کند که ساخت میکروسرویس‌ها را برای توسعه‌دهندگان آسان می‌سازد. برخی از قابلیت‌های jvmkit عبارتند از:‏Wrapperهایی در اطراف finagle HTTP، memcached وMySQL با پیکربندی پیش‌فرض و ادغام با Prometheusپیاده‌سازی کشف سرویس مبتنی بر DNS (DNS based service discovery)مسیریابی درخواست HTTP روی Finagleپشتیبانی از تجزیهJSON برای موجودیت‌های request / responseپشتیبانی از ثبت log بر اساس استانداردها‏Kubernetes‏SoundCloud در سال 2016، پلتفرم استقرار بومی خود، Bazooka، را با Kubernetes جایگزین کرد. Kubernetes استقرار، مقیاس‌بندی و مدیریت containerها را خودکار می‌کند.‏Zipkinبا توجه به این که SoundCloud روی صدها میکروسرویس ساخته شده است، با چالش‌های زیادی روبرو است؛ یکی از این چالش‌ها، دیباگ کردن مشکلات سرویس‌های درگیر در تکمیل یک درخواست واحد است. به همین علت SoundCloud از ابزار ZipKin استفاده می‌کند.‏ZipKinیک ابزار ردیابی توزیع شده (distributed tracing) است و توسط Twitter پدید آمده است.علاوه بر ابزارهایی که در بالا بررسی شد، از ابزارهای زیر نیز در معماری SoundCloud استفاده شده است:‏Prometheus‏Memcached‏Docker‏Apache Kafka‏Apache Crunch‏Apache Spark‏Cascading‏Scaldingدسته‌بندی فناوری‌ها و ابزارها بر اساس ویژگی های کیفیپس از مطالعه معماری شرکت‌ها و شناخت ابزارها و فناوری‌ها، آن‌ها را از جنبه ویژگی‌های فنی مورد بررسی قرار دادیم. جدول زیر دسته‌بندی فناوری‌ها و ابزارهای استفاده شده در Netflix، Amazon و SoundCloud را بر اساس ویژگی‌های کیفی نمایش می‌دهد.جمع‌بندیدر این پژوهش، ابتدا با مفهوم میکروسرویس‌ها آشنا شدیم و تفاوت‌های این سبک معماری را با سبک معماری سرویس‌گرا دیدیم. پس از آن ویژگی‌های مشترک بین میکروسرویس‌ها، سیر تکاملی آن‎ها و ابزارها و فناوری‌های موجود برای پیاده‌سازی میکروسرویس‌ها را با جزئیات بررسی کردیم. همچنین با مطالعه مقالات، برخی از چالش‌های عملی در مسیر استفاده از میکروسرویس‌ها و ضدالگو‌هایی که می‌توانند باعث ایجاد یک ساختار معماری ضعیف شوند را مرور کردیم. در ادامه معماری سه شرکت مطرح ، که از میکروسرویس‌ها استفاده می‌کنند، به نام‌های Netflix ، Amazon و SoundCloud را بررسی کرده، دلایل مهاجرت هر یک از آن‌ها به میکروسرویس‌ها، ساختار معماری و ابزارهای مورد استفاده برای توسعه‌ آن‌ها را شرح دادیم. در پایان نیز از جنبه‌ی ویژگی‌های کیفی در معماری، به این شرکت‌ها پرداختیم و فناوری‌ها و ابزارهای مورد استفاده هر شرکت، برای تامین ویژگی‌های کیفی مورد نیازش را بررسی کردیم.مراجع:Alshuqayran, Nuha, Nour Ali, and Roger Evans. "A systematic mapping study in microservice architecture." In 2016 IEEE 9th International Conference on Service-Oriented Computing and Applications (SOCA), pp. 44-51. IEEE, 2016.Jamshidi, Pooyan, Claus Pahl, Nabor C. Mendonça, James Lewis, and Stefan Tilkov. "Microservices: The journey so far and challenges ahead." IEEE Software 35, no. 3 (2018): 24-35.Taibi, Davide, and Valentina Lenarduzzi. "On the definition of microservice bad smells." IEEE software 35, no. 3 (2018): 56-62.https://martinfowler.com/articles/microservices.htmlhttps://netflixtechblog.com/https://netflix.github.io/https://www.geeksforgeeks.org/system-design-netflix-a-complete-architecture/https://medium.com/@narengowda/netflix-system-design-dbec30fede8dhttps://dev.to/gbengelebs/netflix-system-design-backend-architecture-10i3https://thenewstack.io/led-amazon-microservices-architecture/https://www.codekarle.com/system-design/Amazon-system-design.htmlhttps://relevant.software/blog/microservices-on-aws/https://blog.thundra.io/microservices-on-aws-an-in-depth-lookhttps://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/simple-microservices-architecture-on-aws.htmlhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.htmlhttps://blog.dreamfactory.com/microservices-examples/https://developers.soundcloud.com/blog/category/microserviceshttps://developers.soundcloud.com/blog/service-architecture-1https://developers.soundcloud.com/blog/service-architecture-2https://developers.soundcloud.com/blog/service-architecture-3https://developers.soundcloud.com/blog/synchronous-communication-for-microservices-current-status-and-learningshttps://developers.soundcloud.com/blog/inside-a-soundcloud-microservice«این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» مهنوش شکری مهنوش شکری Sat, 12 Feb 2022 20:52:53 +0330 https://virgool.io/@mahnooshshokri/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-single-sign-on-sso-hw6wf7sdjjkz ‏‏Single Sign On (SSO) یک روش احراز هویت است که به کاربران این امکان را می‌دهد که تنها با استفاده از یک مجموعه‌ی اعتبار (credential) ، به طور امن، به چندین اپلیکیشن و سرویس دسترسی داشته باشند. شما با هر یک از سرویس‌های Slack،Asana ،Google Workspace، و یا Zoom سر و کار داشته باشید، SSO یک ویجت pop-up یا یک صفحه login ،با تنها یک رمز عبور، به شما نشان می‌دهد که دسترسی به همه‌ی این اپلیکیشن‌های ادغام شده را برای شما ممکن می‌سازد. در واقع با استفاده از SSO به جای چندین رمز عبور تنها به یک رمز عبور نیاز خواهید داشت. Single Sign On به دوران به خاطر سپردن و وارد کردن چندین رمز عبور پایان می‌دهد و ناامیدی ناشی از reset کردن پسوردهای فراموش شده را از بین می‌برد. همچنین کاربران می‌توانند به تعداد زیادی اپلیکیشن و پلتفرم دسترسی داشته باشند بدون این که لازم باشد هر بار log in کنند.‏SSO چگونه کار می‌کند؟‏در روش SSO ویژگی‌های هویت (identity) در بین سیستم‌های قابل اعتماد اما مستقل به اشتراک گذاشته می‌شود. هنگامی که یک کاربر توسط یک سیستم مورد اعتماد قرار می گیرد، به طور خودکار به سایر سیستم‌هایی که رابطه قابل اعتماد با آن برقرار کرده اند دسترسی پیدا می کند. چنین چیزی اساس روش SSO می‌باشد که از طریق پروتکل هایی مانند OpenID Connect و SAML 2.0 اجرا می‌شود. هنگامی که کاربر از طریق لاگینSSO به یک سرویس وارد می شود، یک توکن احراز هویت ایجاد و در مرورگر کاربر یا در سرورهای SSO ذخیره می شود. هر برنامه یا وب‌سایتی که کاربر متعاقباً به آن دسترسی پیدا ‌کند، با سرویس SSO بررسی خواهد شد، سپس سرویس SSO توکن کاربر را برای تأیید هویت او ارسال می‌کند و به او دسترسی می‌دهد.‏SSO در مقابل FIMگرچه SSO و FIM اغلب با هم استفاده می شوند، اما مترادف نیستند. Single Sign On (SSO) دسترسی به برنامه ها و منابع را در یک دامنه واحد امکان پذیر می کند اما مدیریت هویت متحد FIM (Federated Identity Management) ورود یکباره به برنامه های کاربردی را در چندین دامنه یا سازمان ممکن می‌سازد.پروتکل‌ها و استانداردهای SSO‏Security Access Markup Language (SAML)‏SAML یک استاندارد open-source است که متن را به زبان ماشین رمزگذاری می کند و امکان تبادل اطلاعات شناسایی (identification) را فراهم می‌کند. SAML به یکی از استانداردهای اصلی برای SSO تبدیل شده است و به ارائه‌دهندگان اپلیکیشن کمک می‌کند تا از مناسب بودن درخواست های احراز هویت مطمئن شوند. SAML 2.0 به طور خاص برای استفاده در اپلیکیشن‌های وب بهینه‌سازی شده است و امکان انتقال اطلاعات از طریق یک مرورگر وب را فراهم می کند.‏‏Open Authorization (OAuth)‏‏ OAuth یک پروتکل مجوز (authorization) استاندارد باز (open-standard) است که اطلاعات شناسایی (identification) را بین اپلیکیشن‌ها منتقل می کند و آن را به کد ماشین رمزگذاری می‌کند. این پروتکل به کاربران این امکان را می‌دهد که اجازه دسترسی یک اپلیکیشن به داده‌هایشان را، بدون آن که مجبور باشند که هویت خود را به صورت دستی تایید کنند، به اپلیکیشن دیگر نیز بدهند، چنین قابلیتی به خصوص برای برنامه‌های بومی (native apps) مفید است.‏OpenID Connect (OIDC)‏ پروتکل OpenID Connect یک پروتکل هویت ساده و استاندارد باز (open-standard) است که با استفاده از پروتکل OAuth 2.0 ساخته شده است. این یروتکل اپلیکیشن‌های client را قادر می‌سازد تا به احراز هویتی که توسط OpenID Connect Provider (OP) برای تأیید هویت کاربر انجام می‌شود، تکیه کنند. پروتکل OICD اجازه می دهد تا یک login session در چندین برنامه استفاده شود. به عنوان مثال، به کاربر این امکان را می‌دهد که به جای وارد کردن اطلاعات کاربری، با استفاده از حساب کاربری فیس‌بوک یا گوگل خود به یک سرویس وارد شود.‏Kerberos‏ Kerberosپروتکلی است که احراز هویت دوجانبه را امکان پذیر می‌کند. با استفاده از این پروتکل هم کاربر و هم سرور هویت دیگری را در اتصالات شبکه ناامن تأیید می کنند. پروتکل Kerberos از یک سرویس اعطای بلیط (ticket-granting service) استفاده می کند که برای احراز هویت کاربران و اپلیکیشن‌ها توکن‌هایی را صادر می کند.ابزارهای SSO‏AWS SSO‏AWS Single Sign-On یک سرویس SSO ابری است که مدیریت مرکزی دسترسی به چندین حساب و اپلیکیشن AWS را آسان می‌کند. این سرویس به کاربران امکان این را می‌دهد که با گواهی‌های مشارکتی (corporate credentials) خود به پرتال کاربری وارد شوند و از یک جا به همه‌ی حساب‌ها و اپلیکیشن‌هایشان دسترسی داشته باشند.‏OneLogin‏‏OnLogin یکی از ارائه دهندگان open-sourceاحراز هویت SSO است که اغلب برای دسترسی به اپلیکیشن‌های ابری (cloud‑based) استفاده می‌شود. این ارائه دهنده دسترسی امن و با یک کلیک (one-click) را ممکن می‌سازد و منجر به کاهش هزینه می‌شود. OneLoginمدیریت هویت را برای کارمندان، مشتری‌ها، و شرکا، از طریق انواع دستگاه‌ها، به همه‌ی اپلیکیشن‌های داخلی و ابری سازمانی، ساده می‌سازد. OneLoginهم برای شرکت‌های بزرگ و هم شرکت‌های کوچک مناسب است.‏Keeper SSO‏Keeper SSO مدیریت رمز عبور را با ویژگی‌های SSOترکیب می‌کند. میلیون‌‌ها نفر و هزاران کسب و کار به پلتفرم مدیریت و امنیت رمز عبور Keeper وابسته هستند. Keeper رهبری جهانی برای ایمن‌ سازی رمز عبور، اسناد و دارایی‌های دیجیتال حساس است. با استفاده از Keeper می‌توان به طور خودکار پسوردهای قوی تولید کرد، از فایل‌های حساس در یک صندوق دیجیتالی رمزگذاری شده محافظت کرد، رکوردها را به طور ایمن با تیم‌ها به اشتراک گذاشت و با SSO، LDAP و 2FAادغام شد.‏Okta Identity Cloud‏Okta با به کارگیری قدرت ابر، به افراد اجازه می‌دهد که در هر زمانی و در هر دستگاهی به اپلیکیشن‌ها دسترسی پیدا کنند و همچنان سیاست‌های امنیتی را اعمال می‌کند. از آنجایی که Oktaروی یک پلتفرم یکپارچه اجرا می‌شود، سازمان‌ها می‌توانند این سرویس را به سرعت، در مقیاس بزرگ، و هزینه کم پیاده سازی کنند.‏ Microsoft Azure Active Directoryسرویس هویت سازمانی Azure Active Directory (Azure AD)، احراز هویت Single sign‑on و احراز هویت multi‑factor را، به منظور کمک به حفاظت کاربران در برابر 99.9 درصد حملات سایبری، ارائه می‌دهد.‏JumpCloud، Idaptive، LastPass SSO، و Ping Identity نیز نمونه‌های دیگری از ابزارهای ارائه دهنده‌ی SSO می‌باشند.شرکت‌های ایرانی فعال در زمینه SSOشرکت هویتا (فناوران هویت الکترونیکی امن)، شرکت متن‌باز سامان (مرکز توسعه‌ی نرم‌افزارهای باز سامان) و شرکت پارسو (سامانه احراز هویت متمرکز پارسو) از جمله شرکت‌های ایرانی هستند که در زمینه احراز هویت Single Sign On فعالیت می‌کنند.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع:https://www.pingidentity.com/en/company/blog/posts/2021/sso-vs-federated-identity-management.htmlhttps://www.okta.com/blog/2021/02/single-sign-on-sso/https://www.g2.com/products/microsoft-azure-active-directory/reviewshttps://www.getkisi.com/blog/best-single-sign-on-sso-providershttps://www.comparitech.com/net-admin/best-sso-tools/ مهنوش شکری مهنوش شکری Fri, 24 Dec 2021 21:53:19 +0330 https://virgool.io/@mahnooshshokri/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-message-queue-%D9%88-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%A2%D9%86-ctkag1o8nfel صف‌های پیام (Message Queue) یکی از اجزای حیاتی در هر معماری نرم‌افزار است که کمک می‌کند مؤلفه‌های مختلف به صورت غیر همزمان با یک دیگر صحبت کنند. در این پست در مورد این که صف پیام چیست و چگونه می‌توان از آن استفاده کرد بحث می‌کنیم و تعدادی از ابزارهای پیاده‌سازی صف پیام از جمله RabbitMQ، Appache Kafka و AWS SQS را بررسی می‌کنیم.صف پیام (Message Queue) چیست؟صف‌بندی پیام به برنامه‌ها این امکان را می‌دهد که بتوانند با ارسال پیام‌هایی به یک دیگر از طریق یک صف، به صورت غیرهمزمان ارتباط برقرار کنند. یک صف پیام (message queue) حافظه موقتی بین فرستنده و گیرنده فراهم می‌کند تا فرستنده بتواند در زمانی که برنامه مقصد مشغول است یا متصل نیست، بدون وقفه به کار خود ادامه دهد.صفصف، لیستی از آیتم‌های داده، دستورات یا وظایفی است که به ترتیبی خاص و معمولا به ترتیب درج ذخیره می‌شوند. صف را می‌توان خطی از اشیائی تعریف کرد که به ترتیب شروع از ابتدای خط در انتظار رسیدگی هستند.پیامپیام، داده‌ای است که بین برنامه‌ی فرستنده و گیرنده منتقل می‌شود. در زمینه صف پیام، پیام می‌تواند چیزی باشد که به سیستمی می‌گوید که پردازش وظیفه‌ای را شروع کند، هم‌چنین می‌تواند شامل اطلاعاتی درباره وظیفه تمام شده یا پیامی ساده از یک وظیفه تکمیل شده باشد.صف پیامصف پیام، صفی از پیام‌هایی است که بین برنامه‌ها فرستاده شده است. این صف شامل ترتیبی از اشیاء کاری است که در انتظار پردازش هستند.صف پیام نوعی ارتباط سرویس به سرویس ناهمزمان است. پیام‌ها تا زمانی که پردازش یا حذف شوند در یک صف ذخیره می‌شوند.از صف پیام در معماری‌های میکروسرویس و server-less به منظور جداسازی مؤلفه‌های مختلف استفاده می‌شود. صف پیام با عبور پیام بین مؤلفه‌های مختلف به آن‌ها کمک می‌کند تا به طور غیرهمزمان با یکدیگر ارتباط برقرار کنند.صف پیام یک پروتکل ارتباطی غیرهمزمان را فراهم می‌کند که در آن سیستمی که پیامی را در صف پیام قرار می‌دهد نیازی به پاسخ فوری برای ادامه پردازش ندارد.معماری صف پیامدر معماری صف پیام یک برنامه client به نام تولید‌کننده و برنامه دیگری به نام مصرف‌کننده‌ وجود دارد.تولیدکننده (producer): تولید کننده پیام‌ها را ایجاد کرده و آن‌ها را روی صف‌های پیام قرار می‌دهد.مصرف کننده (consumer) یا کارگر (worker): مصرف‌کننده به صف متصل می‌شود، پیام‌هایی که باید پردازش شوند را دریافت می‌کند، آن پیام‌ها را میخواند و اقداماتی انجام می‌دهد.پیام‌هایی که در صف قرار می‌گیرند تا زمانی که مصرف‌کننده آن‌ها را پردازش کند در حافظه سیستم ذخیره می‌شوند. نیازی نیست که تولیدکننده و مصرف‌کننده پیام به صورت همزمان با صف پیام تعامل کنند.چندین تولیدکننده و مصرف‌کننده می‌توانند از صف استفاده کنند، اما هر پیام تنها توسط یک مصرف کننده پردازش می‌شود. اگر لازم باشد که یک پیام توسط بیش از یک مصرف‌کننده پردازش شود، می‌توان صف‌های پیام را با پیام رسانی Pub/Sub در الگوی طراحی Fan-out ترکیب کرد.معماری صف پیامیک مثال از سناریوی استفاده از صف پیامفرض کنید یک وب سرویس یا API دارید که هر ثانیه تعداد زیادی درخواست دریافت می‌کند و هر درخواست باید توسط فرآیندی زمان بر پردازش شود. لازم است وب سرویس شما دسترس‌پذیری بالایی داشته باشد و برای دریافت درخواست‌های جدید آمادگی داشته باشد، در نتیجه نباید توسط پردازش درخواست‌های دریافت شده‌ی قبلی قفل شود. در این حالت می‌توانید بین وب سرویس و سرویس پردازش یک صف قرار دهید. پیام‌های موجود در صف به ترتیب دریافت و مدیریت می‌شوند. دو فرآیند از یک دیگر جدا می‌شوند و نیازی به انتظاری برای دیگری نیست. اگر تعداد زیادی درخواست در مدت زمان کوتاهی داشته باشید، سیستم پردازش قادر است در هر صورت همه‌ی آن‌ها را پردازش کند.نقش صف پیام در معماری میکروسرویسدر معماری میکروسرویس عملکردهای مختلف در سرویس‌های متفاوت تقسیم می‌شوند. این سرویس‌ها به یک دیگر می‌پیوندند تا یک برنامه نرم‌افزاری کامل را تشکیل دهند. در معماری میکروسرویس معمولا وابستگی‌های متقابل وجود دارد، به این صورت که هیچ سرویسی نمی‌تواند بدون کمک گرفتن از سایر سرویس‌ها عملکردهای خود را انجام دهد. در اینجا وجود مکانیزمی ضروری است تا به سرویس‌ها اجازه دهد که بدون مسدود شدن توسط پاسخ‌ها با یک دیگر در تماس باشند. صف‌بندی پیام‌ها این هدف را برآورده می‌سازد. با به کارگیری صف پیام، سرویس‌ها می‌توانند به صورت غیر همزمان پیام‌ها را به یک صف هدایت کنند و از تحویل آن‌ها به مقصد درست اطمینان حاصل کنند.کارگزار پیام (Message broker)برای پیاده‌سازی صف پیام، به یک کارگزار پیام (message broker) نیاز است. کارگزار پیام را می‌توان به عنوان یک پستچی در نظر گرفت که پیام‌ها را از فرستنده می‌گیرد و به مقصد درست تحویل میدهد. RabbitMQ یکی از کاربردی ترین message brokerهاست. Apache Kafka و AWS SQS نیز از سرویس‌های محبوب صف پیام هستند.ابزار های Message Queue‏RabbitMQنرم‌افزار RabbitMQ یک کارگزار پیام open-source ، رایگان و قابل توسعه است. RabbitMQ پروتکل صف پیام پیشرفته AMQP (Advanced Message Queuing Protocol) را پیاده سازی می‌کند و از طریق یک معماری plug-in گسترش می‌یابد و از پروتکل‌های دیگری مانند پروتکل پیام‌رسانی متن محور STOMP (Streaming Text Oriented Messaging Protocol) و پروتکل انتقال از راه دور صف پیام MQTT (Message Queuing Telemetry Transport) پشتیبانی می‌کند.سرور RabbitMQ به زبان Erlang نوشته شده است و در فریمورک OTP (Open Telecom Platform) پیاده سازی شده است. تکنولوژی Erlang/OTP برای ساخت سیستم‌های پایدار، قابل اعتماد، مقاوم در برابر خطا و مقیاس پذیر با قابلیت مدیریت تعداد بسیار بالای عملیات‌های همزمان، مناسب است.RabbitMQ Message Broker‏Apache Kafka‏Apache Kafka یک پلتفرم استریم رویداد توزیع شده است که قادر است تریلیون‌ها رویداد را در روز مدیریت کند. Kafka در ابتدا به عنوان یک صف پیام رسانی ایجاد شد و به سرعت از صف پیام رسانی به یک پلتفرم استریم رویداد کامل تبدیل شد.همانطور که اشاره شد Kafka یک پلتفرم استریم رویداد توزیع شده است. برای درک بهتر این تعریف لازم است با مفاهیم استریم (stream) و توزیع شده (distributed) آشنا شویم.استریم چیست؟ به بیان ساده می‌توان گفت استریم‌ها داده‌های بی نهایت هستند، داده‌هایی که هرگز تمام نمی‌شوند، به طور مداوم در حال رسیدن هستند، و باید به صورت real-time پردازش شوند.توزیع شده به چه معناست؟ توزیع شده در اینجا به این معناست که Kafkaدر یک خوشه (cluster) کار می‌کند و هر گره (node) در خوشه Broker نامیده می‌شود. این Broker ها سرورهایی هستند که Apache Kafka را اجرا می‌کنند.بنابراین می‌توان گفت که Kafka مجموعه‌ای از ماشین‌هایی است که با یک دیگر کار می‌کنند تا بتوانند داده‌های بی نهایت را به صورت real‑time پردازش کنند.معماری Apache Kafka‏AWS SQSسرویس‌های وب آمازون (AWS) سرویس صف پیام SQS (Simple Queue Service) را ارائه کرده‌اند.سرویس صف ساده آمازون (SQS) یک سرویس صف پیام کاملا مدیریت شده است که جداسازی و مقیاس‌بندی میکروسرویس‌ها، سیستم‌های توزیع شده و اپلیکیشن‌های server‑less را ممکن می‌سازد. با استفاده از SQS می‌توان پیام‌ها را بین مؤلفه‌های نرم‌افزاری ارسال، ذخیره و دریافت کرد، بدون این که پیام‌ها از دست بروند یا نیاز باشد سایر سرویس‌ها دردسترس باشند.سرویس SQS دو نوع صف پیام را ارائه می‌دهد: Standard queue و FIFO queue.صف استاندارد (Standard queue): صف استاندارد به عنوان نوع صف پیشفرض در نظر گرفته می‌شود.صف‌های استاندارد دارای حداکثر throughput می‌باشند. این نوع از صف‌ها تقریبا از تعداد نامحدودی API call در هر ثانیه، در هر API action (ارسال، دریافت، یا حذف پیام) پشتیبانی می‌کنند.صف‌های استاندارد از تحویل at‑least‑once پشتیبانی می‌کنند. با این حال گاهی اوقات، به دلیل معماری توزیع شده که امکان انتقال نامحدود را فراهم می‌کند، ممکن است بیش از یک نسخه از یک پیام خارج از نظم تحویل داده شود.صف‌های استاندارد مرتب‌سازی best‑effort را فراهم می‌کنند که تضمین می‌کند که پیام‌ها عموما به همان ترتیبی که ارسال می‌شوند تحویل داده می‌شوند.صف FIFO (FIFO queue):صف‌های FIFO (First In First Out) به گونه‌ای طراحی شده‌اند که تضمین کنند که پیام‌ها دقیقا یک بار و به ترتیبی که ارسال می‌شوند، پردازش شوند. صف‌های FIFO در مواقعی که ترتیب عملیات و رویدادها حیاتی باشد یا در جایی که موارد تکراری قابل تحمل نباشد، منجر به بهبود پیام رسانی بین اپلیکیشن‌ها می‌شوند.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع:https://www.cloudamqp.com/blog/what-is-message-queuing.htmlhttps://medium.com/@mosesbasseyekwere/message-queue-what-it-is-how-it-works-and-when-to-use-it-2b7fb5dcef48https://medium.com/must-know-computer-science/system-design-message-queues-245612428a22https://medium.com/swlh/everything-you-need-to-know-about-message-queues-a-complete-guide-dbf190d001d7https://aws.amazon.com/sqs/https://en.wikipedia.org/wiki/RabbitMQhttps://www.erlang-solutions.com/blog/an-introduction-to-rabbitmq-what-is-rabbitmq/https://hub.docker.com/_/rabbitmqhttps://www.confluent.io/what-is-apache-kafka/https://medium.com/swlh/apache-kafka-what-is-and-how-it-works-e176ab31fcd5 مهنوش شکری مهنوش شکری Fri, 24 Dec 2021 19:04:29 +0330 https://virgool.io/@mahnooshshokri/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-enterprise-service-bus-na8bstetw9gq در هر سازمانی انتقال داده بین سیستم‌ها به منظور دستیابی به اهداف تجاری بسیار ضروری و حیاتی است. لازم است همه‌ی سیستم‌های دامنه کسب و کار سازمان به طور کارآمد یکپارچه شوند. این سیستم‌ها باید بتوانند به منظور برآوردن نیازهای کسب و کار، با اشتراک گذاری داده‌ها با یک دیگر همکاری کنند.رویکردهای معماری متفاوتی برای یکپارچه سازی سیستم‌ها و اپلیکیشن‌ها وجود دارد که در گذشت زمان تکامل یافته اند. سازمان‌ها با حرکت از یکپارچه سازی نقطه به نقطه P2P(Point to Point) به سمت مدل Hub & Spoke و سپس معماری ESB، در جهت رویکردهای یکپارچه سازی پیچیده تر پیشرفت کردند.‏گذرگاه سرویس سازمانی (Enterprise Service Bus - ESB) یک معماری نرم‌افزاری است که امکان یکپارچه‌سازی اپلیکیشن‌ها و سرویس‌های سازمانی را فراهم می‌کند. در این پست به بررسی این معماری و ابزارهای آن می‌پردازیم.گذرگاه سرویس سازمانی (ESB) چیست؟گذرگاه سرویس سازمانی (ESB) یک معماری مبتنی بر bus است که امکان یکپارچه سازی چندین سیستم را به شیوه‌ای کارآمد فراهم می‌کند. معماری ESB نسبت به سبک‌های یکپارچه سازی سنتی نقطه به نقطه (P2P) و Hub/Spoke پیچیده تر است.گذرگاه سرویس سازمانی (ESB) به عنوان یک میان‌افزار هوشمند عمل می‌کند تا ارتباط بین سیستم‌ها و اپلیکیشن‌های مختلف را ممکن سازد. عملکرد ESB مشابه یک سیستم حمل و نقل اتوبوس سنتی است که در آن تمامی نواحی مجاور به ایستگاه‌های مرکزی اتوبوس متصل شده‌اند تا مسافران را به مقصدهای متصل شده برساند.تصویر زیر معماری گذرگاه سرویس سازمانی (ESB) را نشان می‌دهد که در آن چندین سیستم و اپلیکیشن از طریق یک پایپ پیام رسانی مرکزی (Bus) یکپارچه شده اند. هر سیستم یکپارچه شده ممکن است در نقش تولیدکننده (producer) یا مصرف‌کننده (consumer) یا هر دو عمل کند.معماری گذرگاه سرویس سازمانی ESBگذرگاه ESB را میتوانیم به عنوان یک الگوی طراحی با هدف انتزاعی سازی ارتباطات بین سیستم‌ها در یک لایه یکپارچه‌سازی نیز تعریف کنیم. این الگو از الگوهای یکپارچه‌سازی سازمانی به منظور انجام اعتبارسنجی، غنی‌سازی، تبدیل، تجمیع و مسیریابی، استفاده می‌کند.برای تجسم بهتر گذرگاه سرویس سازمانی (ESB) می‌توانید آن را به عنوان یک router در نظر بگیرید که بین اپلیکیشن‌های سازمانی ارتباط برقرار می‌کند، یا می‌توانید ESB را به عنوان مجموعه‌ای از سوئیچ‌ها در نظر بگیرید که بر اساس پیاده سازی، سیاست‌های کسب و کار یا محتوای پیام، تصمیم می‌گیرند که پیام را به کجا ارسال کنند.مسئولیت‌های گذرگاه ESBمسیریابی، هماهنگی، تبدیل و ترجمه، میانجی‌گری، غنی‌سازی پیام، انتقال، تبدیل پروتکل و سازگاری غیر عملکردی، بخشی از مسئولیت‌ها و قابلیت‌های گذرگاه سرویس سازمانی (ESB) می‌باشند.مسیریابی (Routing): هنگامی که داده‌ها توسط یک سیستم تولیدکننده (producer) ایجاد و به گذرگاه ESBفرستاده شدند، ESB وظیفه دارد بر اساس معیاری مشخص مسیریابی منطقی را انجام دهد و پیام‌ها را به مصرف‌کنندگان (consumers) مورد نظر هدایت کند.­­هماهنگی (Orchestration): گذرگاه ESB مسئولیت برنامه ریزی و هماهنگی را بر عهده دارد و در آن از چندین سرویس به منظور دستیابی به یک وظیفه تجمیعی یا ترکیبی استفاده می‌کند. به عنوان مثال در محیط بانکی گذرگاه ESBمی‌تواند از سرویس‌های اپلیکیشن‎ها یا ماژول‌های بانکی استفاده کند و یک سرویس ترکیبی بر اساس نیازمندی‌های کسب و کار ارائه دهد.تبدیل و ترجمه (Transformation/Translation): هر سیستم ادغام شده به زبان خودش صحبت می‌کند و فرمت‌های خودش را می‌فهمد که ممکن است لزوما با سیستم ادغام شده دیگر یکسان نباشد. این مسئولیت گذرگاه ESB است که همه‌ی تبدیل‌ها و ترجمه‌های لازم بین فرمت‌ها و مشخصات مختلف داده‌ها را انجام دهد تا تضمین شود که سیستم‌ها می‌توانند به درستی یک دیگر را بفهمند.میانجی‌گری و غنی‌سازی پیام (Mediation/Message Enrichment): گذرگاه سرویس سازمانی نقش میانجی (mediator) را نیز بازی می‌کند که در آن سیاست‌های میانجی‌گری (mediation policies) روی جریان‌های ورودی و خروجی (in/out) اعمال می‌شود و ممکن است پیام‌ها بر اساس نیازهای کسب و کار، پیش از آن که به سیستم‌های مصرف‌کننده تحویل داده شوند، غنی سازی و سفارشی سازی شوند.انتقال و تبدیل پروتکل (Transportation/Protocol Conversion): انتقال پیام بین چندین سیستم‌ یکی از قابلیت‌های اصلی گذرگاه ESBاست و هسته اصلی معماری ESB به شمار می‌رود. به علاوه در هنگام انتقال پیام‌ها میان سیستم‌ها، گذرگاه ESBمسئول تبدیل پروتکل‌ها می‌باشد تا با مکانیزم انتقال بخش‌های ادغام شده مطابقت داشته باشد.سازگاری غیر عملکردی (Non-Functional Consistency): ESBهای مدرن مجهز به ویژگی‌ها و قابلیت‌های اضافی خاصی از جمله ویژگی‌های امنیتی، ماژول‌های نظارت (monitoring) و مدیریت و توانایی ارائه استقرارهای مقاوم در برابر خطا و با دسترس‌پذیری بالا هستند.ابزارهای ESB‏ IBM Integration Busبا استفاده از گذرگاه یکپارچه سازی IBM (IBM Integration Bus) می‌توان اپلیکیشن‌ها را، صرف نظر از فرمت‌های پیام یا پروتکل‌هایی که پشتیبانی می‌کنند، به یک دیگر متصل کرد. در این ارتباط اپلیکیشن‌ها می‌توانند در یک زیر ساخت انعطاف پذیر، پویا و قابل توسعه با یک دیگر تعامل داشته باشند و داده‌ها را مبادله کنند. گذرگاه یکپارچه سازی IBM، پیام‌ها را از یک مکان به مکان دیگر مسیریابی، تبدیل و غنی سازی می‌کند. این محصول از بسیاری از پروتکل‌ها شامل WebSphere® MQ، JMS، HTTP و HTTPS، وب سرویس‌های SOAP و REST، سیستم‌های اطلاعات سازمانی (SAP و Siebel)، و TCP/IP پشتیبانی می‌کند. به علاوه این محصول از رنج وسیعی از فرمت‌های داده شامل فرمت‌های باینری (C و COBOL)، XML، و استانداردهای صنعتی (SWIFT، EDI، و HIPAA) پشتیبانی می‌کند. هم‌چنین شما می‌توانید فرمت‌های داده خودتان را در این محصول تعریف کنید.‏‏ Oracle Service Busگذرگاه سرویس Oracle یک جزء اساسی از مجموعه محصولات معماری سرویس‌گرای Oracle است. گذرگاه سرویس Oracle معماری‌های پیچیده و شکننده را از طریق اتصال، مجازی سازی، و مدیریت تعامل بین سرویس‌ها و اپلیکیشن‌ها شبکه‌های یکپارچه سازی چابک (agile) تبدیل می‌کند. این گذرگاه سرویس یکپارچه‌سازی مبتنی بر استاندارد و کم هزینه را برای محیط‌های حیاتی معماری سزویس گرا (SOA)، که در آن‌ها کارایی، مقیاس پذیری و قابلیت اطمینان از نیازمندی‌های ضروری هستند، ارائه می‌دهد. سرویس‌دهنده‌ی این گذرگاه از پروتکل‌های بسیاری شامل HTTP، SOAP، JMS، JCA و WSIF پشتیبانی می‌کند.‏ Apache ServiceMix‏‏Apache ServiceMix یک گذرگاه سرویس سازمانی (ESB) توزیع شده است که بر اساس مشخصاتJava Business Integration (JBI) JSR 208 ساخته شده است و تحت لیسانس Apache می‌باشد. این گذرگاه open source است. گذرگاه سرویس سازمانی Apache ServiceMix عملکرد معماری سرویس‌گرا (SOA) و ماژولار بودن (modularity) را ترکیب می‌کند. در این گذرگاه از پیام‌ها برای اتصال سرویس‌ها و از رابط‌ها برای تبادل اطلاعات از طریق پروتکل‌های متفاوتی مانند FTP، HTTP، وب سرویس‌ها و ... استفاده می‌شود. ServiceMix به منظور فراهم کردن کنترل از راه دور، خوشه‌بندی و شکست توزیع شده از ActiveMQ استفاده می‌کند. ServiceMix از همه‌ی بخش‌های JBI پشتیبانی می‌کند و شامل بسیاری از مؤلفه‌های JBI ازجمله HTTP، JMX، CFX، BPEL و غیره می‌باشد.‏ WSO2 ESB، Mule ESB، Fuse ESB، و Microsoft Azure Service Bus نیز نمونه‌های دیگری از گذرگاه‌های سرویس سازمانی می‌باشند.شرکت‌های ایرانی فعال در زمینه ESBشرکت داده‌پرداز پویای شریف، شرکت پلکتو، شرکت پارس سیستم، شرکت کاریز سیستم پویا، و شرکت آی‌کن (آینده کاوان کهکشان نرم‌افزار) از جمله شرکت‌های ایرانی هستند که در زمینه گذرگاه سرویس سازمانی فعالیت می‌کنند.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع:https://www.brcline.com/blog/what-is-an-enterprise-service-bushttps://medium.com/@rmzoni/what-is-the-future-of-an-enterprise-service-bus-esb-a4abd6cf0054https://tutorialspedia.com/esb-introduction-an-overview-of-esb-concepts-capabilities-benefits-challenges/https://www.ibm.com/docs/en/integration-bus/10.0?topic=overview-integration-bus-introductionhttps://www.oracle.com/middleware/technologies/service-bus.htmlhttps://servicemix.apache.org/docs/6.x/user/what-is-smx4.html مهنوش شکری مهنوش شکری Fri, 24 Dec 2021 17:59:12 +0330 https://virgool.io/PODIUM/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D8%AF%D8%B1%DA%AF%D8%A7%D9%87-api-%D9%88-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%A2%D9%86-aktfunl0au6b در این پست به بررسی مفهوم مدیریت API و درگاه API می‌پردازیم، چگونگی عملکرد درگاه API را بیان می‌کنیم، و تعدادی از ابزارهای ارائه‌دهنده درگاه API را معرفی می‌کنیم.درگاه API چیست؟درگاه API (API gateway) میان‌افزاری (middleware) است که بین یک نقطه انتهایی API (endpoint) و سرویس‌های backend قرار می‌گیرد و request های client را به سرویس مناسبی از یک برنامه انتقال می‌دهد. همچنین API gateway یک الگوی معماری است که در ابتدا برای پشتیبانی از میکروسرویس‌ها ایجاد شد.تکامل معماری APIپیش از این، اپلیکیشن‌ها عمدتا با استفاده از رویکرد monolithic ساخته می‌شدند، یعنی همه‌ی اجزای نرم‌افزار به هم متصل بودند. از این رو client در زمان درخواست بازیابی داده‌ها، یک API callبرقرار می‌کرد. سپس ابزاری به نام load balancer(که در گذشته یک دستگاه سخت‌افزاری جدا بود) همه‌ی ترافیکی که بین نمونه‌های مختلف یک برنامه را دریافت می‌کرد را هدایت می‌کرد و پاسخ (response) را به client باز می‌گرداند. در این رویکرد بروزرسانی و پیاده‌سازی تکنولوژی‌های جدید سخت بود، به همین دلیل معماری monolithic با یک الگوی معماری جدید به نام میکروسرویس (microservices) جایگزین شد.معماری میکروسرویس سرویس‌های مختلف را در سیستم شما از هم جدا می‌کند و آن‌ها را مستقل می‌سازد. برخلاف رویکرد monolithic، هر میکروسرویس نقطه انتهایی (endpoint) عمومی متفاوتی دارد، از این رو clientدرخواست‌ها (requests) را مستقیما به میکروسرویس خواسته شده ارسال می‌کند. برای اپلیکیشن‌های کوچک تر مسئله‌ای وجود ندارد، اما به محض این که یک سیستم در سطح سازمانی معماری میکروسرویس را اتخاذ کند، مشکلات متعددی به وجود خواهد آمد. در ادامه به بررسی تعدادی از این مشکلات می‌پردازیم.تاخیر (Latency): برای انجام یک عملکرد ساده مانند ورود به اپلیکیشن، client باید چندین تماس (call) با میکروسرویس‌های مختلف برقرار کند. این موضوع باعث افزایش تعداد رفت و برگشت‌ها و درنتیجه زمان انتظار طولانی تر می‌شود.امنیت (security): از آنجایی که هر میکروسرویس از طریق یک نقطه انتهایی عمومی در دسترس است، ریسک حمله بالاتری وجود دارد. در حالت ایده آل هر سرویس باید مجوز () داشته باشد اما پیاده سازی چنین چیزی بسیار هزینه‌بر و زمان‌بر است.اتصال محکم (Tight coupling): در ارتباط مستقیم اپلیکیشن‌های client به شدت به میکروسرویس‌های داخلی متصل می‌شوند و بروزرسانی یا بازنشتگی آن‌ها در آینده، اپلیکیشن‌های client را نیز تحت تاثیر قرار می‌دهد.چنین مسائلی را می‌توان با معرفی یک سطح واسط بین client و API حل کرد، یک درگاه API.درگاه API تعادل بار (load balancing) را انجام می‌دهد، تدابیر امنیتی را فراهم می‌سازد و اتصال سست (loose coupling) را ایجاد می‌کند.تصویر پایین 1) دسترسی به monolith از طریق یک API واحد، 2) دسترسی به میکروسرویس‌ها از طریق APIهای جداگانه، 3) استفاده از یک درگاه API واحد، و 4) دسترسی به گروهی از میکروسرویس‌ها از طریق چندین درگاه API، را نشان می‌دهد.تکامل معماری APIعملکرد های API gateway و مدیریت APIدرگاه API عملکردهای کاملا فنی را انجام می‌دهد. مدیر API اصطلاح مشابهی است که معمولا معنای گسترده تری دارد. در اینجا چگونگی ارتباط بین درگاه API و مدیر API را توضیح می‌دهیم.مدیر API یا پلتفرم مدیریت API نرم‌افزاری متمرکز بر کسب و کار است که برای نگهداری، انتشار و مدیریت APIهای شما در طول چرخه عمرشان ایجاد شده است. چنین پلتفرم‌هایی شامل سه عملکرد اصلی هستند:درگاه API، مسئول استقرار، مسیریابی، امنیت و سایر وظایف فنی است.پورتال توسعه‌دهندگان، جایی که API ها مستند می‌شوند و کاربران به آن‌ها دسترسی دارند.تجزیه و تحلیل API، ماژولی که داده‌ها را از درگاه‌ها جمع‌آوری کرده و روی داشبورد نمایش می‌دهد.مدیرهای API تکامل یافته‌ی درگاه‌های APIهستند، زیرا اقتصاد API در حال رشد بود و کسب و کارها نیاز داشتند API‌هایشان را بازاریابی کنند و آن‌ها را به جریان درآمد دیگری تبدیل کنند. مدیر APIعملکردهایی مانند ایجاد مستندات، جمع‌آوری بازخوردها، و سازمان‌دهی یک کاتالوگ API کاربرپسند (user‑friendly) را برای کسب و کارها ممکن می‌سازد. به علاوه تجزیه و تحلیل داده‌های استفاده شده آن‌ها را به بینشی تبدیل می‌کند که به کسب و کارها کمک می‌کند یاد بگیرند که چگونه APIرا به عنوان یک محصول توسعه دهند.درگاه API در نقش facade و الگوی Backend For Frontend (BFF)الگوی معماری facade یک رابط واحد (single interface) را در مقابل یک سیستم پیچیده پیاده سازی می‌کند. این الگو قابلیت استفاده را بهبود می‌بخشد و اتصال سست (loose coupling) را ممکن می‌سازد. در واقع الگوی facade به شما این امکان را می‌دهد که مؤلفه‌های backend را، بدون آن که روی client اثر بگذارند، نگهداری کنید و تغییر دهید.در عین حال، نقطه ورود واحد می‌تواند به سرعت تبدیل به گلوگاه (bottleneck) شود و نهایتا بار دیگر به شکل رویکرد monolithic درآید. اینجا از الگوی Backend For Frontend (BFF) استفاده می‌شود. در این الگو ممکن است چندین درگاه API به عنوان facade برای گروه‌های مختلف سرویس‌ها عمل کنند. به عبارت دیگر در این الگو اپلیکیشن‌ها می‌توانند بر اساس وظایف تجاری یا برنامه‌های client، چندین درگاه API داشته باشند (مانند درگاه‌های جدا برای وب و برنامه‌های موبایل).الگوی Backend For Frontend برای درگاه APIمسیریابی requestها در درگاه APIبرای درک بهتر مفهوم مسیریابی درخواست‌ها در درگاه API به یک مثال در دنیای واقعی توجه کنید. فرض کنید در یک هتل هستید و از اتاق خود با مسئول پذیرش تماس می‌گیرید و یک سینی صبحانه یا استفاده از سرویس خشک‌شویی را درخواست می‌کنید، پذیرش کسی نیست که سرویس را به شما ارائه دهد، بلکه درخواست شما را به شخص مناسب می‌رساند. این کار هم برای راحتی شما انجام می‌شود و هم برای راحتی کارکنان، شما دیگر در هتل به دنبال آشپزخانه یا اتاق رختشویی نمی‌روید و کارکنان مجبور نیستند علاوه بر شغل اصلی خود با خدمات مشتری سروکار داشته باشند. درگاه API به همین ترتیب کار می‌کند، و این رویکرد پروکسی معکوس (reverse proxy) نامیده می‌شود. برخلاف پروکسی رو به جلو (forward proxy) که منشاء clientرا با بازیابی داده‌ها از شبکه عمومی از طرف آن‌ها پنهان می‌کند، درگاه منشاء server را پنهان می‌کند و داده‌های داخلی را برای مشتری بازیابی می‌کند. درگاه API به عنوان یک نقطه انتهایی واحد (که اپلیکیشن‌های client از آن استفاده می‌کنند) عمل می‌کند و سپس همه‌ی requestها را به سرویس‌های داخلی هدایت می‌کند. در عین حال، درگاه API می‌تواند responseها را از چندین سرویس جمع‌اوری کرده و آن‌ها را به عنوان یک پاسخ بفرستد، درنتیجه تعداد تماس‌ها (call) کاهش می‌یابد.ترجمه پروتکل‌های مختلفاکثر APIهای خارجی responseهایی در قالب پیام‌های REST ارائه می‌دهند، اما سرویس‌های داخلی شما ممکن است وابسته به سایر فرمت‌ها باشند. به عنوان مثال سیستم‌های قدیمی تنها از پروتکل SOAP پشتیبانی می‌کنند، یا شما می‌خواهید از مزایای gPRC بهره‌مند شوید. درگاه API می‌تواند تماس‌های REST را به پروتکل‌های سازگار ترجمه کند.ابزارهای ارائه دهنده‌ی API gateway‏Kong Gatewayابزار Kong انواع عملکردهای مدیریت API و درگاه API را فراهم می‌سازد و دو گزینه برای آن وجود دارد: یک محصول منبع‌باز (open‑source) و یک محصول دارای مجوز (licensed) با چند ویژگی اضافی. از نظر استقرار (deployment) نیز چند منظوره است، که یکی از آن‌ها container های از پیش ساخته شده‌ی Docker می‌باشد. نسخه open‑source در محل (On-premise) اجرا می‌شود اما نسخه‌ی سازمانی از اجرای ابری ترکیبی (hybrid cloud) نیز پشتیبانی می‌کند. Kongبخاطر pluginهای فراوانش، چه رسمی و چه توسعه یافته توسط عموم، معروف شده است، که به شما این امکان را می‌دهد تا در صورت نیاز درگاه API خود را به یک پلتفرم مدیریت API کامل تبدیل کنید. با این حال، Kongبرای مدیریت برنامه‌های قدیمی انتخاب قابل اطمینانی نمی‌باشد، چرا که نمی‌تواند تماس (call) ها را به فرمت‌های SOAP یا XML تبدیل کند. این ابزار برای اپلیکیشن‌های مبتنی بر میکروسرویس مدرن مناسب است.‏AWS API Gatewayاگر در حال ساخت یک معماری server‑less با AWS Lambda هستید، درگاه AWS APIبهترین انتخاب برای شماست. این ابزار cloud‑only است و کاربران AWS می‌توانند تنها با چند کلیک آن را ادغام کنند. سطح رایگان این ابزار با یک میلیون API callبه پایان می‌رسد، بنابراین امتحان کردن آن ضرری ندارد، به خصوص که مجموعه ویژگی‌های آن با نسخه سازمانی Kong قابل مقایسه است.‏Tyk Gatewayدرگاه Tyk، open-source می‌باشد و با وجود ویژگی‌هایی در سطح سازمانی رایگان است. ادغام آسان از سایر ویژگی‌های مثبت این نرم‌افزار است، به این صورت که شما می‌تواند پلاگین‌هایی به زبان Python، JavaScript، Go، و سایر زبان‌ها بنویسید و یا از پلاگین‌های ایجاد شده توسط عموم استفاده کنید. در Tyk هر پروتکلی پذیرفته شده و قابل تبدیل است: REST، SOAP، gPRC، GraphQL، و TCP.‏KrakenD‏‏‏KrakenD یک درگاه API open-source است و برای انواع استقرار: در محل (on‑premises)، ابری (cloud) و ترکیبی (hybrid)، در دسترس است. از ویژگی‌های منحصر به فرد آن روشی اعلانی برای ایجاد نقاط انتهایی است که امکان استفاده از آن را بدون هیچ گونه برنامه نویسی فراهم می‌کند. یک سطح سازمانی با تعدادی ویژگی اضافی مانند تولید مشخصات OpenAPIبرای آن وجود دارد، اما استفاده از ویژگی‌های استاندارد برای همه رایگان و نامحدود است. شما می‌توانید KrakenD را با استفاده از Go و Lua توسعه دهید.‏Gloo Edge ‏‏‏این ابزار مبتنی بر پروکسی Envoy می‌باشد. پروکسی Envoy محبوب ترین پروکسی برای Kubernetes است. ابزار Gloo یک نسخه open‑source و یک نسخه سازمانی دارد. هر دو نسخه از عملکردهای server-less و مسیریابی برای gRPC پشتیبانی می‌کنند.‏Apigee‏‏‏Apigee پلتفرمی برای توسعه و مدیریت API ها می‌باشد. این پلتفرم به زبان جاوا نوشته شده است و open-source نیست. پلتفرم Apigee در ابتدا به عنوان یک برنامه XML/SOA شروع به کار کرد، اما به فضای مدیریت API برگشت. Apigee برای تبدیل برنامه‌های قدیمی monolith به API های قابل استفاده برای اشخاص ثالت طراحی شده است و تمرکز کمتری روی میکروسرویس‌ها و API های داخلی دارد. این پلتفرم در سال 2016 توسط گوگل خریداری شد.شرکت‌های ایرانی فعال در زمینه مدیریت APIشرکت وصلشرکت وصل پلتفرم مدیریت API سورنا را ارائه می‌دهد. اسپارا در زمینه گذرگاه سرویس سازمانی (ESB) ، آریو در زمینه Backend-as-a-Service (BaaS)، و نوین در زمینه پلتفرم تحویل سرویس VAS، از محصولات دیگر این شرکت می‌باشند.شرکت ابر درساشرکت ابردرسا شرکتی فعال در حوزه رایانش ابری است و سرویس API gateway ابری را ارئه می‌دهد.شرکت پلکتوشرکت دانش بنیان پلکتو پلتفرم یکپارچه سازی و مدیریت وب سرویس می‌باشد و خدماتی مانند گذرگاه سرویس سازمانی (ESB) و مدیریت API ارائه می‌دهد.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع:https://www.altexsoft.com/blog/api-gateway/https://www.moesif.com/blog/technical/api-gateways/How-to-Choose-The-Right-API-Gateway-For-Your-Platform-Comparison-Of-Kong-Tyk-Apigee-And-Alternatives/http://vasl.ir/platform/api-management/https://dorsacloud.com/service-post/api-gateway-service/https://platco.ir/services/integration-web-services/api-management/ مهنوش شکری مهنوش شکری Fri, 24 Dec 2021 01:20:08 +0330 https://virgool.io/@mahnooshshokri/%D9%85%D8%AF%D9%84-c4-%D8%B1%D9%88%D8%B4%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-d67jaoql35p2 معماری نرم‌افزار و ارائه روشی برای مستندسازی آن از چالش‌های حوزه نرم‌افزار است. در این پست به بررسی مدل C4 که یکی از روش‌های مستندسازی معماری نرم‌افزار است می‌پردازیم.مدل C4 چیست؟مدل C4 روشی برای مدل‌سازی و مستندسازی معماری نرم‌افزار است که آن را در سطوح مختلف جزئیات توصیف و تعریف میکند. مدل C4 یک روش "abstraction-first" است یعنی در این روش نمودارسازی معماری نرم‌افزار بر اساس انتزاعاتی است که نشان می‌دهد معماران و توسعه‌دهندگان نرم‌افزار چگونه در مورد نرم‌افزار فکر می‌کنند و آن را می‌سازند.در مدل C4 می‌توان نقشه‌ای از کد برنامه را در سطوح مختلف از جزئیات ایجاد کرد. در واقع ایده‌ی این روش این است که بتوان همانند نقشه‌ی گوگل روی آن زوم کرد و به جزئیات بیشتری رسید.با استفاده از مدل C4 تیم‌های توسعه نرم‌افزار می‌توانند به طور کارآمد و مؤثر معماری نرم‌افزار خود را در سطوح مختلف از جزئیات، با گفتن داستان‌هایی متفاوت برای مخاطبان متفاوت، هم در زمان طراحی اولیه و هم در مستندسازی، به اشتراک بگذارند.سطوح مدل C4مدل C4 از چهار سطح context، container، component و code تشکیل شده است. هر کدام از این چهار مورد به سطح متفاوتی از جزئیات می‌پردازند و مخاطبان متفاوتی دارند.سطح 1: System Context diagramنمودار context مشخص می‌کند که سیستم چه کاری انجام می‌دهد، چه کسانی از آن استفاده می‌کنند و با چه سیستم‌های دیگری در تعامل است، به بیان دیگر چگونگی تعامل کاربران با سیستم، و چگونگی تناسب سیستم با سایر سیستم‌ها را نشان می‌دهد. به کمک این نمودار می‌توان محدوده پروژه و آن چه که خارج از این محدوده است را به خوبی نمایش داد.در این نمودار سیستم به شکل یک باکس در مرکز نشان داده می‌شود و کاربران و سایر سیستم‌ها در اطراف این باکس قرار می‌گیرند.این نمودار را می‌توان به افراد غیر فنی نشان داد.سطح 2: Container diagramدر نمودار container هر یک از عناصر بزرگ سیستم مانند اپلیکیشن‌های وب و دسکتاپ، اپ‌های موبایل، APIها، پایگاه داده‌ها و فایل سیستم‌ها، در قالب یک container نمایش داده می‌شوند. در واقع container یک واحد قابل اجرا یا قابل استقرار مجزاست که کدی را اجرا یا داده‌هایی را ذخیره می‌کند.نمودار container فناوری‌های اصلی انتخاب شده و چگونگی ارتباط containerها با یکدیگر را نشان‌می‌دهد.این نمودار هم برای توسعه‌دهندگان نرم‌افزار و هم برای کارمندان پشتیبانی IT مفید است.سطح 3: Component diagramنمودار component، مؤلفه‌های تشکیل‌دهنده‌ی یک container را نشان می‌دهد و مسئولیت‌ها و جزئیات فناوری و پیاده‌سازی هر یک از این مؤلفه‌ها (components) را مشخص میکند.نمودار مؤلفه‌ی مدل C4 در مقایسه با نمودار مؤلفه‌ی UML، قوانین سخت‌گیرانه‌ی کمتری دارد.این نمودار برای معماران و توسعه‌دهندگان نرم‌افزار مفید است.سطح 4: Codeدر این سطح چگونگی پیاده‌سازی کد هر component با استفاده از نمودارهای کلاس UML، نمودارهای موجودیت-رابطه و موارد مشابه نشان داده می‌شود. چنین نمودارهای را معمولا می‌توان از طریق ابزارهایی مانند IDEها به طور خودکار تولید کرد.این سطح از جزئیات اختیاری است و تنها برای componentهای مهم یا پیچیده مناسب است و برای سایر componentها توصیه نمی‌شود.نمودارهای مکملعلاوه بر چهار سطح گفته شده که برای نمایش ساختار ایستا استفاده می‌شوند می‌توان نمودارهای C4 را برای نمایش سایر جنبه‌ها تکمیل کرد.نمودار System Landscape diagram: این نمودار مرزهای سازمانی، کاربران داخلی/خارجی و سیستم‌های داخلی/خارجی را نشان می‌دهد.نمودار Dynamic diagram: این نمودار نشان می‌دهد که چگونه عناصر یک مدل ایستا در زمان اجرا برای پیاده سازی یک user story، use case، ویژگی یا موارد دیگر، با یکدیگر همکاری می‌کنند.نمودار Deployment diagram: این نمودار نشان می‌دهد که چگونه سیستم‌های نرم‌افزاری و containerها در مدل ایستا به زیرساخت نگاشت می‌شوند.نشانه‌گذاری در مدل C4مدل C4 نشانه‌گذاری خاصی را تعیین نمی‌کند و آنچه که در نمودارهای نمونه دیده می‌شود نمادهای ساده ایست که روی تخته‌سفید، کاغذ و هر ابزار ترسیم نموداری به خوبی کار می‌کند.در این مدل پیشنهاد می‌شود که:هر نموداردارای یک عنوان باشد که نوع و محدوده نمودار را توصیف می‌کند.هر عنصرشامل یک نام، نوع عنصر (Person، Software System، Container و Component)، فناوری انتخاب شده(در صورت لزوم) و یک متن توصیفی باشد.هر خط نشان‌دهنده‌ی یک رابطه یک‌طرفه باشد، برچسب‌گذاری شود و برچسب با جهت و هدف رابطه سازگار باشد.همچنین می‌توان برای تکمیل نمودار با هدف افزودن اطلاعات اضافی یا زیباتر کردن آن، از اشکال و رنگ‌های مختلف استفاده کرد. نکته مهم این است هر نمادی که از آن استفاده شده با یک کلید راهنما (key/legend) توصیف شود.ترسیم نمودارهای C4 با Structurizrدر سال 2014، Structurizr توسط Simon Brown، خالق مدل C4، ایجاد شد. Structurizr مجموعه‌ای از ابزارها برای ایجاد نمودارهای معماری نرم‌افزار و مستندسازی براساس مدل C4 است. Structurizr از نمودار‌ها به شکل کد (Java, Clojure, .NET, TypeScript, PHP, Python, Go) یا متن (DSL یا YAML) پشتیبانی میکند و ارائه‌ی نمودارها با ابزارهای متفاوتی (Structurizr cloud service, PlantUML, Mermaid و غیره) را ممکن می‌سازد.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع:https://c4model.com/https://www.infoq.com/articles/C4-architecture-model/https://www.diagrams.net/blog/c4-modellinghttps://www.gliffy.com/blog/c4-modelhttps://www.youtube.com/watch?v=x2-rSnhpw0ghttps://www.youtube.com/watch?v=Ym9nhVZs89o مهنوش شکری مهنوش شکری Sat, 20 Nov 2021 21:02:14 +0330