آموزش هوش تجاری از ۰ تا ۱۰۰

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

• لایه نمایشی
• لایه کسب و کار
• لایه پایگاه داده

هر یک از این بخش‌های وابسته به یک بسته نرم‌افزاری واحد تعلق دارند، به این معنی که آن‌ها به طور محکم جفت شده‌اند. این معماری دارای چندین مزایا و معایب است که در زیر نشان داده شده است:
 
مزایا

• پیاده سازی ساده در فناوری واحد

همه به یک زبان صحبت می کنند و از این رو آسان تر است. تعامل و هماهنگی تیم آسان است. مخزن واحد همچنین در جایی که تیم با شاخه‌بندی و برچسب‌گذاری آسان فعال است، کاملاً کار می‌کند.

• راه اندازی و راه اندازی اولیه بسیار آسان است

راه اندازی پروژه با بلوک های ساختمانی اساسی آسان است و تنها یک بار مورد نیاز است. ویژگی های افزودنی بیشتر در بالای آن پیاده سازی شده است.

• ارتباط مستقیم

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

• اشکال زدایی و تست آسان

اشکال زدایی ساده و آسان است زیرا همه مؤلفه ها در یک بسته در دسترس هستند و به هم مرتبط می شوند.

• استقرار آسان

حتی ما به چندین نمونه از یک برنامه نیاز داریم، به راحتی می توان کل راه حل را در چندین سرور در پشت یک متعادل کننده بار مستقر کرد. تمرین و مراحل استقرار کاملاً مستقیم است.

معایب

• توسعه آهسته زمانی که بزرگ و پیچیده است

هنگامی که ویژگی ها همچنان در حال افزایش هستند و تیم در حال افزودن/تغییر کد است، بارها و بارها، پیچیدگی افزایش می یابد و در نهایت سرعت توسعه کاهش می یابد.

• مقیاس بندی توسط اجزا یا ماژول های جداگانه امکان پذیر نیست

به دلیل یک بسته نرم افزاری در طبیعت، مقیاس بندی توسط جزء یا ماژول امکان پذیر نیست. اگر نیاز به افزایش مقیاس دارید، کل برنامه باید بزرگ شود، حتی زمانی که فقط یک یا چند مؤلفه باید بزرگ شوند.

• هنگامی که یک اشکال وجود دارد، ممکن است کل برنامه از کار بیفتد

احتمال زیادی وجود دارد که کل برنامه در صورت بروز یک باگ از کار بیفتد. به عنوان مثال. اگر باگ منجر به از بین بردن دامنه برنامه شما شود، مطمئناً کل برنامه از بین خواهد رفت.

• تغییرات کوچک می تواند منجر به کل آزمایش شود

در حین ایجاد هرگونه تغییر در برنامه Monolithic، ماژول های دیگر احتمالاً تحت تأثیر قرار می گیرند و از این رو نیاز دارند که کل برنامه با چرخه های آزمایش کامل انجام شود. این می تواند زمان زیادی را صرف کند.

• استقرار مداوم سخت است

تا زمانی که کل ساخت آماده نشود، استقرار مکرر و مداوم امکان پذیر نیست. این شامل یک چرخه آزمایش کامل است که اطمینان حاصل می کند که همه چیز به خوبی کار می کند.

• کل برنامه در هنگام تغییر کوچک مستقر می شود

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

• پذیرش فناوری جدید یک کابوس است

معماری یکپارچه موظف است در یک پشته فناوری توسعه یابد که در واقع به یک تیم نسبتاً بزرگ در آن پشته فناوری نیاز دارد. همچنین هنگام مهاجرت از یک فناوری به فناوری دیگر، بسیار دشوار و زمان بر است.

معماری میکروسرویس
 
همانطور که از نام آن پیداست، این معماری مبتنی بر خدمات است. این معماری بیشتر از معماری SOA است. خدمات معمولاً با قابلیت های تجاری یا زیر دامنه از هم جدا می شوند. هنگامی که ماژول ها / مؤلفه ها تعریف می شوند، می توان آنها را از طریق مجموعه ای متفاوت از تیم ها پیاده سازی کرد. این تیم ها تیم های پشته فناوری یکسان یا متفاوت خواهند بود. به این ترتیب، اجزای جداگانه را می‌توان در صورت نیاز بزرگ‌تر کرد و پس از پایان نیاز، به سرعت آن‌ها را کوچک کرد. 

مزایای معماری میکروسرویس

• یک تیم کوچک می تواند درگیر شود و مالک شود

برخلاف رویکرد یکپارچه، معماری Microservices به مجموعه بزرگی از تیم‌ها در یک پشته فناوری نیاز ندارد، اما می‌توان تیم کوچکی از پشته‌های فناوری مختلف را نیز درگیر کرد. بنابراین از نظر هزینه سازمانی منجر به صرفه جویی می شود.

• کد و منطق قابل درک آسان

از آنجایی که میکروسرویس ها نسبت به Monolithic کوچک هستند و کد کمتری دارند، درک کد و منطق نوشته شده توسط یکی به دیگری آسان است.

• چابکی آسان است

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

• معرفی تاب آوری

از آنجایی که برنامه بر اساس دامنه (یا قابلیت تجاری) تجزیه می شود، نگهداری آن به صورت جداگانه آسان است. این همچنین باعث کاهش زمان خرابی و افزایش مقیاس پذیری می شود.

• تسریع زمان ورود به بازار

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

• تحویل مستمر امکان پذیر است

برای دریافت همه نوع تغییرات و ویژگی‌های جدید، همه به یک شکل ممکن است. کسب و کار شما را به روز و مشتری را خوشحال می کند.

• توسعه پذیری ساده است

هر زمان که یک ویژگی جدید مورد نیاز است، به سادگی سرویس جدید را به معماری برنامه موجود اضافه کنید. بدون نیاز به بازگشت به کد موجود، ساخت ویژگی های جدید، و سپس یک ویژگی جدید می تواند نسبتاً سریعتر اضافه شود، زیرا این امر مستلزم معرفی سرویس جدید است و بر پایه کد موجود تأثیری نخواهد گذاشت.

• قابلیت تعویض در هر زمان

در صورت نیاز، خدمات موجود را می توان به جای نگهداری طولانی مدت، با هم جایگزین کرد. این همچنین ما را مجبور می‌کند تا کیفیت کد را حفظ کنیم، نه اینکه کد موجود را بارها و بارها با تعداد زیادی وصله تغییر دهیم.

آیا واقعاً به میکروسرویس نیاز دارید؟
 
اکنون در مورد مزایای Microservices صحبت کردیم، اما این بدان معنا نیست که معماری تک برنامه ها باید در Microservices ترسیم شود. قبل از استفاده از معماری Microservice از خود بپرسید "آیا واقعاً به یک برنامه کاربردی مبتنی بر Microservice نیاز دارید؟" قبل از اینکه Microservices را ادامه دهید، تصمیم خود را با پرسیدن یک مجموعه ساده از سوالات قضاوت کنید.

• آیا نیاز فعلی برنامه شما به اندازه کافی بزرگ است که به چندین دامنه تقسیم شود؟ (یعنی میکروسرویس ها؟) اگر نه، احتمالاً به این رویکرد نیاز ندارید.
• آیا برنامه شما واقعاً نیاز به مقیاس بندی ماژول ها یا مؤلفه ها به صورت جداگانه دارد؟ اگر نه، شما خوب هستید که با Monolithic بروید. به عنوان مثال. یک برنامه تجارت الکترونیک باید ماژول سفارش خود را در طول دوره فروش مقیاس بندی کند و ماژول های دیگر مانند کاربر، محصول و غیره در حین بزرگ شدن مورد نیاز نیستند.
• هزینه/مدت پروژه کمتر است؟ خدمات میکرو به دلیل پیاده سازی، امنیت، نظارت، زیرساخت و غیره مطمئناً برای برنامه های کوچک پرهزینه خواهد بود. همه اینها باید به همه ذینفعان اطلاع داده شود، سپس تصمیمات مشترک اتخاذ می شود.
• آیا برای تست ادغام پیچیده آماده هستید؟ توسعه برنامه های پیچیده می تواند در دراز مدت با استفاده از Microservices آسان باشد، اما تست یکپارچه سازی همه سرویس ها مطمئناً انجام نخواهد شد. اطمینان حاصل کنید که ابزار، تکنیک ها و اعضای کافی برای مدیریت وضعیت دارید.
• آیا توسعه دهندگان Full-stack دارید؟ آنها نیاز اساسی هستند. اگر اعضای آماده ای در یک تیم ندارید، قبل از ورود به معماری Microservice باید آنها را داشته باشید.
• آیا Dev-Ops آماده هستید؟ بدون خط لوله یکپارچه سازی مداوم/تحویل مستمر/ استقرار مداوم (CI/CD/CD)، فرهنگ Dev-Ops نمی تواند راه اندازی شود که به تولید سریعتر نیاز دارد. اگر این فرهنگ را نداشته باشید، تمام هدف شکست خواهد خورد.
• آیا سیستم نظارت قوی دارید؟ معماری میکروسرویس شبکه ای از خدمات است و اگر هر یک از آنها از بین برود، باید به زودی بازیابی یا تکرار شوند. بدون یک سیستم نظارت قوی و فرآیند تحمل خطا خوب، این امکان پذیر نخواهد بود و شما تجارت را از دست خواهید داد.

عوامل بیشتری وجود دارد که ابتدا باید بررسی شوند، اما نکات ذکر شده در بالا برای رفع تردید شما در مورد انتخاب معماری Microservice یا خیر خوب است.
 
ملاحظات کلیدی در اجرای میکروسرویس ها
 
اکنون دید کلی خوبی از معماری Microservice دارید، اما با گفتن این موضوع، اجرای عملی هنوز در مقایسه با Monolithic تفاوت های زیادی دارد. آنها واقعاً مشابه معماری سنتی یکپارچه نیستند. ما باید اطمینان حاصل کنیم که همه چیز بدون هیچ زحمتی آماده است. در زیر نکات کلیدی که در این معماری باید رعایت شود آورده شده است:

• ذخیره سازی داده ها

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

• ارتباطات خدماتی

ارتباط با سرویس ها را می توان با استفاده از API Gateway انجام داد. API Gateway دروازه مرکزی است که از آنجا می توان تمام درخواست ها را ترجمه کرد و خدمات مناسب را فراخوانی کرد. ارتباط بین سرویس ها را می توان با استفاده از درخواست/پاسخ همزمان و ناهمزمان با استفاده از صف های پیام رسانی به دست آورد.

• امنیت

برخلاف سیستم یکپارچه، فرآیند مجوز و احراز هویت در معماری Microservices متفاوت است. برنامه Monolithic به راحتی از session استفاده می کند در حالی که Microservices از احراز هویت مبتنی بر توکن استفاده می کند.

• آزمایش کردن

از آنجایی که میکروسرویس ها به طور کامل در طبیعت توزیع شده اند، آزمایش یکپارچه سازی با یک برنامه کاربردی Monolithic متفاوت است. تست ارتباط بین فرآیندی می تواند برای یک تازه کار چالشی باشد.

• گسترش

هر میکروسرویس باید به گونه ای مستقر شود که دیگر منابع سرویس را مسدود نکند و به همین دلیل است که استقرار مستقل توصیه می شود. برای ایجاد یک استقرار کارآمدتر، باید کانتینرسازی دنبال شود. Independent Deploy, Update, Replace, Scale (DURS) زیبایی میکروسرویس است و باید مورد استفاده قرار گیرد.

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