Microservices: یک انقلاب برنامه کاربردی که توسط ابر ارائه می شود

ما در بحبوحه یک انقلاب توسعه اپلیکیشن و مدیریت سیستم IT هستیم که توسط ابر هدایت می شود. زیرساخت‌های سریع، چابک، ارزان و بسیار مقیاس‌پذیر، که به‌طور کامل سلف‌سرویس و با صورت‌حساب پرداختی ارائه می‌شود، کارایی عملیاتی را بهبود می‌بخشد و امکان افزایش زمان به ارزش را در صنایع فراهم می‌کند. ظهور کانتینرها با راه اندازی سریع، بسته بندی برنامه استاندارد و مدل ایزوله، کمک بیشتری به کارایی و چابکی می کند.

با این حال، بسیاری از شرکت‌ها دریافته‌اند که ایجاد برنامه‌های کاربردی خود بسیار در دسترس، مقیاس‌پذیر و چابک همچنان چالش برانگیز است. فشارهای تجاری رقابتی ایجاب می‌کند که برنامه‌ها به طور مداوم تکامل یافته و ویژگی‌ها و عملکردهای جدیدی را اضافه کنند و در عین حال 24x7 در دسترس باشند. به عنوان مثال، دیگر قابل قبول نیست که یک وب سایت بانکی دارای پنجره تعمیر و نگهداری باشد، در حالی که حتی چند سال پیش این امر عادی بود. به طور مشابه، یک سایت تجارت الکترونیکی که حتی برای مدت کوتاهی از کار افتاده باشد، مشتریان را به یکی از رقبای متعددی سوق می دهد که می تواند در آن لحظه به آنها خدمت کند. عدم تحقق این خواسته ها می تواند به معنای تفاوت بین مرتبط ماندن و از دست دادن تجارت باشد.

این واقعیت‌های تجاری، توسعه‌دهندگان را به سمت اتخاذ یک مدل معماری کاربردی به نام «microservices» سوق می‌دهد، اصطلاحی که توسط جیمز لوئیس و مارتین فاولر رایج شده است. در این پست، من در مورد اینکه چگونه و چرا یک معماری میکروسرویس می‌تواند به توسعه برنامه‌ها و وظایف چرخه حیات کمک کند، صحبت می‌کنم و قابلیت‌هایی را که پلتفرم‌ها می‌توانند برای پشتیبانی از این معماری‌ها ارائه دهند، شرح دهم. سپس برخی از پلتفرم‌هایی که معمولاً توسط توسعه‌دهندگان به‌عنوان پایه‌ای برای برنامه‌های مبتنی بر میکروسرویس مورد استفاده قرار می‌گیرند را که Azure از آن‌ها پشتیبانی می‌کند، فهرست می‌کنم، و در نهایت، پلتفرم اپلیکیشن میکروسرویس خود را به نام Service Fabric که پشتیبانی جامعی از مدیریت چرخه حیات میکروسرویس ارائه می‌کند، به اختصار شرح خواهم داد.

 

مدل های کاربردی یکپارچه
برای چندین دهه، هزینه، زمان و پیچیدگی تهیه سخت افزار جدید، چه فیزیکی و چه مجازی، به شدت بر توسعه اپلیکیشن تاثیر گذاشته است. این عوامل زمانی که این برنامه‌ها از نظر ماموریت حیاتی هستند، آشکارتر می‌شوند، زیرا زمان بالا به زیرساخت‌های بسیار در دسترس، از جمله سخت‌افزارهای گران‌قیمت مانند SAN و متعادل‌کننده‌های بار سخت‌افزار نیاز دارد. از آنجایی که زیرساخت فناوری اطلاعات ثابت است، برنامه‌ها به گونه‌ای نوشته شده‌اند که اندازه استاتیک داشته باشند و برای سخت‌افزار خاص طراحی شوند، حتی در صورت مجازی‌سازی. حتی زمانی که برنامه‌ها برای به حداقل رساندن نیازهای کلی سخت‌افزار و ارائه سطحی از چابکی و مقیاس‌بندی مستقل تجزیه می‌شدند، معمولاً به مدل کلاسیک سه لایه، با وب، منطق تجاری و سطوح داده، همانطور که در شکل زیر نشان داده شده است، تبدیل شد. با این حال، هر لایه هنوز یکپارچه خاص خود بود و عملکردهای متنوعی را اجرا می‌کرد که در یک بسته واحد ترکیب شدند که روی سخت‌افزار از پیش مقیاس‌بندی شده برای بارهای اوج استفاده می‌شد. هنگامی که بارگذاری باعث می‌شود یک برنامه از سخت‌افزار خود بیشتر شود، پاسخ معمولاً «مقیاس‌سازی» یا ارتقای سخت‌افزار برنامه برای افزودن ظرفیت بود تا از پیکربندی مجدد مرکز داده و معماری مجدد نرم‌افزار جلوگیری شود.

 

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

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

 

معماری میکروسرویس ها
در حالی که برنامه های کاربردی در مقیاس ساده و محدود وجود دارد که معماری یکپارچه برای آنها هنوز منطقی است، میکروسرویس ها رویکرد متفاوتی برای توسعه و استقرار برنامه هستند، رویکردی که کاملاً برای چابکی، مقیاس و قابلیت اطمینان الزامات بسیاری از برنامه های کاربردی ابر مدرن مناسب است. یک برنامه میکروسرویس به اجزای مستقلی به نام "microservices" تجزیه می شود که برای ارائه عملکرد کلی برنامه به طور هماهنگ کار می کنند. اصطلاح «microservice» بر این واقعیت تأکید دارد که برنامه‌ها باید از سرویس‌هایی تشکیل شده باشند که به اندازه کافی کوچک باشند تا واقعاً نگرانی‌های مستقل را منعکس کنند به طوری که هر میکروسرویس یک عملکرد واحد را پیاده‌سازی کند. علاوه بر این، هر یک دارای قراردادهای کاملاً تعریف شده (قراردادهای API) - معمولاً RESTful - برای سایر ریزسرویس‌ها برای برقراری ارتباط و اشتراک‌گذاری داده‌ها با آن است. میکروسرویس ها همچنین باید بتوانند مستقل از یکدیگر نسخه و به روز رسانی کنند. این کوپلینگ شل چیزی است که از تکامل سریع و قابل اعتماد یک برنامه پشتیبانی می کند. شکل 3 نشان می دهد که چگونه یک برنامه یکپارچه ممکن است به میکروسرویس های مختلف تقسیم شود.

 

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

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

ماهیت مستقل و توزیع‌شده برنامه‌های کاربردی مبتنی بر میکروسرویس، به‌روزرسانی‌های متحرک را نیز امکان‌پذیر می‌کند، که در آن تنها زیر مجموعه‌ای از نمونه‌های یک میکروسرویس در هر زمان معین به‌روزرسانی می‌شوند. اگر مشکلی شناسایی شود، قبل از اینکه همه نمونه‌ها با کد یا پیکربندی معیوب به‌روزرسانی شوند، می‌توان یک به‌روزرسانی باگ را «برگرداند» یا لغو کرد. اگر سیستم به‌روزرسانی خودکار باشد، ادغام با خطوط لوله Continuous Integration (CI) و Continuous Delivery (CD) به توسعه‌دهندگان این امکان را می‌دهد که به طور ایمن و مکرر برنامه را بدون ترس از تأثیر در دسترس بودن، توسعه دهند.

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

 

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

یک پلتفرم برنامه کاربردی میکروسرویس با امکانات کامل، تمام مزایای معماری میکروسرویس‌های قبلاً بیان شده از بازده هزینه، مقیاس‌پذیری و در دسترس بودن 24x7 را ارائه می‌دهد. همچنین اینها را یک قدم جلوتر می برد. همانطور که قبلا ذکر شد، باید ارتقاهای ایمن و قابل اعتماد را با استفاده از یک مدل بهداشتی قابل توسعه و برگشت خودکار طراحی کند. همچنین با ارائه یک سرویس نامگذاری به میکروسرویس ها کمک می کند تا یکدیگر را کشف کنند و سلامت آنها را نظارت و حفظ کنند. به عنوان مثال، هنگام مقیاس بندی یا بهبود، یک پلت فرم میکروسرویس اطلاعات مکان به روز شده را از طریق سرویس نامگذاری به سایر میکروسرویس ها منتقل می کند تا بتوانند به سرعت ارتباط برقرار کنند یا دوباره برقرار کنند.

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

 

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

 

Docker Swarm و Docker Compose
فرمت استاندارد بسته بندی و جداسازی منابع ظروف داکر، آنها را با معماری های میکروسرویس سازگاری طبیعی کرده است. Docker Compose یک مدل برنامه کاربردی تعریف می‌کند که از چندین میکروسرویس بسته‌بندی شده با Docker پشتیبانی می‌کند، و Docker Swarm به عنوان یک مدیر خوشه در مجموعه‌ای از زیرساخت‌ها عمل می‌کند که همان پروتکلی را که یک نصب Docker تک نود انجام می‌دهد، نشان می‌دهد، به طوری که با ابزار گسترده Docker کار می‌کند. زیست بوم. سرویس کانتینر Azure از Docker Swarm و Docker Compose پشتیبانی می کند. 

 

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

 

Mesosphere DCOS، با Apache Mesos و Marathon
مایکروسافت و Mesosphere برای آوردن اجزای منبع باز سیستم عامل مرکز داده Mesosphere (DCOS) از جمله Apache Mesos و Marathon به Azure همکاری کرده‌اند. Mesosphere DCOS که توسط Mesos ارائه می‌شود، یک مدیر خوشه مقیاس‌پذیر است که شامل Mesosphere’s Marathon، یک ابزار ارکستراسیون کانتینر درجه تولید است. به عنوان بخشی از سرویس کانتینر Azure در دسترس است. همچنین یک نسخه سازمانی از Mesosphere موجود است که روی Azure اجرا می شود. Mesosphere DCOS قابلیت‌های پلتفرم میکروسرویس‌ها از جمله کشف سرویس، تعادل بار، بررسی سلامت، محدودیت‌های مکان‌یابی و تجمع معیارها را فراهم می‌کند. در نهایت، Mesosphere یک کتابخانه از خدمات تایید شده را ارائه می‌کند که قابلیت‌های اضافی مانند Kafka، Chronos، Cassandra، Spark و موارد دیگر را ارائه می‌دهد که همگی با یک فرمان قابل نصب هستند.

 

OpenShift
OpenShift توسط Red Hat یک سرویس پلتفرم است که از بسته‌بندی مبتنی بر کانتینر Docker برای استقرار قابلیت‌های هماهنگی کانتینر و مدیریت محاسباتی برای Kubernetes استفاده می‌کند و کاربران را قادر می‌سازد تا JBoss Middleware، چندین زبان برنامه‌نویسی، پایگاه‌های داده و سایر زمان‌های اجرا برنامه را اجرا کنند. OpenShift Enterprise 3 یک تجربه توسعه را ارائه می دهد که به توسعه دهندگان امکان می دهد فرآیند ساخت و استقرار برنامه را در یک زیرساخت برنامه ایمن و درجه سازمانی خودکار کنند. با پشتیبانی اخیر از تصاویر لینوکس Red Hat Enterprise در Azure، OpenShift در Azure پشتیبانی می شود. به زودی به دنبال برخی اسناد در مورد این موضوع باشید.

 

ریخته گری ابر محوری
Pivotal Cloud Foundry معماری‌های میکروسرویس را با ترکیب گردش کار و زمان‌بندی کانتینر از Cloud Foundry با ادغام الگوهای میکروسرویس مانند کشف سرویس، متعادل‌سازی بار سمت مشتری، قطع کننده‌های مدار و ردیابی توزیع شده، با استفاده از Spring Cloud و NetflixOSS، فعال می‌کند. Pivotal Cloud Foundry از عملیات میکروسرویس جاری از طریق قابلیت‌های استقرار و مدیریت خدمات مانند مقیاس خودکار، به‌روزرسانی‌های سبز-آبی، نظارت بر سلامت، معیارهای برنامه، گزارش‌های جریان و غیره پشتیبانی می‌کند.

 

پارچه سرویس
برای حمایت از تکامل داخلی خود از داخل محل به ابر و از یکپارچه به برنامه‌های مبتنی بر میکروسرویس، بیش از ده سال پیش Service Fabric را توسعه دادیم. Service Fabric بسیاری از خدمات ابری ما را در مقیاس فوق‌العاده، از جمله SQL DB، DocDB، Intune، Cortana و Skype for Business، و همچنین بسیاری از خدمات زیرساخت داخلی Azure، تامین می‌کند. ما دقیقاً از همان فناوری استفاده کرده‌ایم و Service Fabric را به‌عنوان یک سرویس در Azure منتشر کرده‌ایم، و SDK مستقل امکان استقرار برنامه‌های Service Fabric را در کلاسترهای داخلی و سایر ابرها فراهم می‌کند. در نسخه عمومی اولیه، Service Fabric روی ویندوز با هر زبان دات نت اجرا می شود و پشتیبانی لینوکس و جاوا در دست توسعه است. Service Fabric دارای پشتیبانی داخلی برای مدیریت چرخه حیات، استقرار ترکیبی، و در دسترس بودن 24x7 با تجربه توسعه یکپارچه با استفاده از Visual Studio است. این پلتفرم مدل‌های بهداشتی توسعه‌پذیری را برای زیرساخت‌ها و ریزسرویس‌ها ارائه می‌کند تا امکان ارتقای خودکار مبتنی بر سلامت و بازگشت خودکار، ساده‌سازی DevOps را فراهم کند. علاوه بر این، Service Fabric از ریزسرویس‌های بدون تابعیت و دولتی با انتخاب رهبری پشتیبانی می‌کند تا از سازگاری داده‌ها و یک چارچوب تکرار دولتی پشتیبانی کند که از تراکنش‌ها برای تضمین داده‌های دولتی پشتیبانی می‌کند.

 

نتیجه

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

 

ملاحظات داده برای میکروسرویس ها

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

یک اصل اساسی میکروسرویس ها این است که هر سرویس داده های خود را مدیریت می کند. دو سرویس نباید یک فروشگاه داده را به اشتراک بگذارند. در عوض، هر سرویس مسئول ذخیره داده های خصوصی خود است که سایر سرویس ها نمی توانند مستقیماً به آن دسترسی داشته باشند.

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

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

 

  توجه داشته باشید

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

 

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

مدل‌سازی سنتی داده‌ها از قانون «یک واقعیت در یک مکان» استفاده می‌کند. هر موجودیت دقیقاً یک بار در طرح ظاهر می شود. سایر نهادها ممکن است ارجاعاتی به آن داشته باشند اما آن را تکراری نکنند. مزیت آشکار رویکرد سنتی این است که به‌روزرسانی‌ها در یک مکان واحد انجام می‌شوند که از مشکلات مربوط به سازگاری داده‌ها جلوگیری می‌کند. در معماری میکروسرویس‌ها، باید در نظر بگیرید که چگونه به‌روزرسانی‌ها در بین سرویس‌ها منتشر می‌شوند، و چگونه می‌توانید یکپارچگی نهایی را زمانی که داده‌ها در مکان‌های مختلف بدون ثبات قوی ظاهر می‌شوند، مدیریت کنید.

 

رویکردهای مدیریت داده ها
هیچ رویکرد واحدی وجود ندارد که در همه موارد صحیح باشد، اما در اینجا چند دستورالعمل کلی برای مدیریت داده ها در معماری میکروسرویس وجود دارد.

در صورت امکان از ثبات نهایی استفاده کنید. مکان‌هایی را در سیستم که نیاز به یکپارچگی قوی یا تراکنش‌های ACID دارید و مکان‌هایی که سازگاری نهایی قابل قبول است را بشناسید.

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

 

• برای تراکنش‌ها، از الگوهایی مانند Scheduler Agent Supervisor و Compensating Transaction استفاده کنید تا داده‌ها را در چندین سرویس ثابت نگه دارید. برای جلوگیری از خرابی نسبی در میان چندین سرویس، ممکن است لازم باشد یک داده اضافی را ذخیره کنید که وضعیت یک واحد کاری را که چندین سرویس را در بر می گیرد، نشان دهد. به عنوان مثال، زمانی که یک تراکنش چند مرحله ای در حال انجام است، یک مورد کاری را در یک صف بادوام نگه دارید.

 

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

 

• در نظر بگیرید که آیا خدمات شما منسجم و با هم مرتبط هستند یا خیر. اگر دو سرویس به طور مداوم در حال تبادل اطلاعات با یکدیگر هستند که منجر به ایجاد APIهای چت می شود، ممکن است لازم باشد مرزهای سرویس خود را با ادغام دو سرویس یا بازسازی عملکرد آنها دوباره ترسیم کنید.

 

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

 

• سرویسی که رویدادها را در اختیار دارد، باید طرحی را منتشر کند که بتوان از آن برای خودکارسازی سریال‌سازی و سریال‌زدایی رویدادها استفاده کرد، تا از اتصال شدید بین ناشران و مشترکان جلوگیری شود. طرح JSON یا چارچوبی مانند Microsoft Bond، Protobuf یا Avro را در نظر بگیرید.

 

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

 

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

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

سرویس‌های پشتیبان مختلف به بخش‌های مختلف اطلاعات در درخواست اهمیت می‌دهند، و همچنین پروفایل‌های خواندن و نوشتن متفاوتی دارند.

 

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

انتظار می رود که کاربران به طور مکرر وضعیت یک تحویل را در حالی که منتظر بسته خود هستند بررسی کنند. بنابراین، سرویس Delivery به یک ذخیره‌سازی داده نیاز دارد که بر توان عملیاتی (خواندن و نوشتن) بیش از ذخیره‌سازی طولانی‌مدت تأکید دارد. همچنین، سرویس Delivery هیچ پرس و جو یا تجزیه و تحلیل پیچیده ای انجام نمی دهد، فقط آخرین وضعیت را برای یک تحویل معین واکشی می کند. تیم خدمات تحویل، Azure Cache را برای Redis به دلیل عملکرد خواندن و نوشتن بالای آن انتخاب کرد. اطلاعات ذخیره شده در Redis نسبتا کوتاه مدت است. پس از تکمیل تحویل، سرویس تاریخچه تحویل، سیستم ثبت است.

 

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

سناریوی اول، جمع آوری داده ها به منظور تجزیه و تحلیل داده ها، به منظور بهینه سازی کسب و کار یا بهبود کیفیت خدمات است. توجه داشته باشید که سرویس تاریخچه تحویل، تجزیه و تحلیل واقعی داده ها را انجام نمی دهد. این فقط مسئول بلع و ذخیره سازی است. برای این سناریو، ذخیره سازی باید برای تجزیه و تحلیل داده ها بر روی مجموعه بزرگی از داده ها، با استفاده از رویکرد طرحواره در خواندن برای گنجاندن انواع منابع داده، بهینه شود. فروشگاه Azure Data Lake برای این سناریو مناسب است. Data Lake Store یک سیستم فایل Apache Hadoop سازگار با سیستم فایل توزیع شده Hadoop (HDFS) است و برای عملکرد برای سناریوهای تجزیه و تحلیل داده تنظیم شده است.

سناریوی دیگر این است که کاربران را قادر می سازد تا تاریخچه یک تحویل را پس از تکمیل تحویل جستجو کنند. Azure Data Lake برای این سناریو بهینه نشده است. برای عملکرد بهینه، مایکروسافت توصیه می‌کند که داده‌های سری زمانی را در Data Lake در پوشه‌هایی که بر اساس تاریخ تقسیم‌بندی شده‌اند، ذخیره کنید. (برای عملکرد به تنظیمات فروشگاه Azure Data Lake مراجعه کنید). با این حال، این ساختار برای جستجوی سوابق فردی توسط ID بهینه نیست. جستجو بر اساس شناسه نیاز به اسکن کل مجموعه دارد، مگر اینکه مهر زمانی را نیز بدانید. بنابراین، سرویس تاریخچه تحویل زیرمجموعه ای از داده های تاریخی را برای جستجوی سریعتر در Azure Cosmos DB ذخیره می کند. لازم نیست رکوردها به طور نامحدود در Azure Cosmos DB باقی بمانند. تحویل های قدیمی تر را می توان بایگانی کرد - مثلاً بعد از یک ماه. این را می توان با اجرای یک فرآیند دسته ای گاه به گاه انجام داد.

 

خدمات پکیج
سرویس Package اطلاعات مربوط به تمام بسته ها را ذخیره می کند. شرایط ذخیره سازی بسته عبارتند از:

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

از آنجایی که داده‌های بسته رابطه‌ای نیستند، یک پایگاه داده سند محور مناسب است و Azure Cosmos DB می‌تواند با استفاده از مجموعه‌های خرد شده به توان عملیاتی بالایی دست یابد. تیمی که روی سرویس Package کار می‌کند با پشته MEAN (MongoDB، Express.js، AngularJS و Node.js) آشنا هستند، بنابراین آنها API MongoDB را برای Azure Cosmos DB انتخاب می‌کنند. این به آن‌ها اجازه می‌دهد از تجربه موجود خود با MongoDB بهره ببرند و در عین حال از مزایای Azure Cosmos DB که یک سرویس مدیریت‌شده Azure است بهره‌مند شوند.

چرا از یک رویکرد میکروسرویس برای ساخت برنامه ها استفاده کنیم؟ قسمت دوم

راهنمای طراحی میکروسرویس در Azure
Service Fabric به عنوان یک پلت فرم میکروسرویس
Azure Service Fabric زمانی پدیدار شد که مایکروسافت از ارائه محصولات جعبه‌دار، که معمولاً یکپارچه بودند، به ارائه خدمات انتقال یافت. تجربه ساخت و راه اندازی سرویس های بزرگ، مانند Azure SQL Database و Azure Cosmos DB، Service Fabric را شکل داد. این پلتفرم با گذشت زمان و با پذیرش سرویس های بیشتری تکامل یافت. Service Fabric نه تنها در Azure بلکه در استقرار سرورهای مستقل ویندوز نیز اجرا می شد.

هدف Service Fabric حل مشکلات سخت ساخت و اجرای یک سرویس و استفاده بهینه از منابع زیرساخت است، بنابراین تیم ها می توانند مشکلات تجاری را با استفاده از رویکرد میکروسرویس حل کنند.

Service Fabric به شما کمک می‌کند تا برنامه‌هایی بسازید که از رویکرد میکروسرویس‌ها استفاده می‌کنند با ارائه:

• پلتفرمی که خدمات سیستمی را برای استقرار، ارتقا، شناسایی و راه اندازی مجدد سرویس های ناموفق، کشف سرویس ها، مسیریابی پیام ها، مدیریت وضعیت و نظارت بر سلامت ارائه می دهد.
• توانایی استقرار برنامه های کاربردی در حال اجرا در کانتینرها یا به عنوان فرآیند. سرویس فابریک یک ارکستراتور کانتینر و فرآیند است.
• API های برنامه نویسی مولد برای کمک به شما در ساخت برنامه های کاربردی به عنوان میکروسرویس: هسته ASP.NET، بازیگران قابل اعتماد، و خدمات قابل اعتماد. برای مثال، می‌توانید اطلاعات مربوط به سلامت و تشخیص را دریافت کنید، یا می‌توانید از دسترسی بالای داخلی بهره ببرید.

 

Service Fabric در مورد نحوه ساخت سرویس خود متعصب است و می توانید از هر فناوری استفاده کنید. اما API های برنامه نویسی داخلی را ارائه می دهد که ساخت میکروسرویس ها را آسان تر می کند.

 

انتقال برنامه های کاربردی موجود به Service Fabric
Service Fabric به شما امکان می دهد کدهای موجود را مجددا استفاده کنید و آن را با میکروسرویس های جدید مدرن کنید. پنج مرحله برای نوسازی اپلیکیشن وجود دارد و می توانید در هر مرحله شروع و متوقف کنید. مراحل عبارتند از:

1. با یک برنامه سنتی یکپارچه شروع کنید.
2. مهاجرت. از کانتینرها یا فایل های اجرایی مهمان برای میزبانی کد موجود در Service Fabric استفاده کنید.
3. مدرن کردن. میکروسرویس های جدید را در کنار کد کانتینری موجود اضافه کنید.
4. نوآوری کنید. برنامه یکپارچه را بر اساس نیاز به میکروسرویس ها تقسیم کنید.
5. تبدیل اپلیکیشن ها به میکروسرویس ها برنامه های کاربردی یکپارچه موجود را تغییر دهید یا برنامه های سبز فیلد جدید بسازید.

 

مهاجرت به میکروسرویس ها

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

بیایید به مثال هایی برای هر یک از این مراحل نگاه کنیم.

 

مهاجرت
به دو دلیل، بسیاری از شرکت‌ها برنامه‌های یکپارچه موجود را به کانتینرها منتقل می‌کنند:

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

 

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

بسیاری از سازمان ها در اینجا متوقف می شوند. آنها در حال حاضر مزایای کانتینرها را دارند و Service Fabric تجربه مدیریت کاملی از جمله استقرار، ارتقاء، نسخه‌سازی، بازگشت به عقب و نظارت بر سلامت را فراهم می‌کند.

 

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

 

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

 

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

 

آیا میکروسرویس ها برای برنامه من مناسب هستند؟

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

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

چرا از یک رویکرد میکروسرویس برای ساخت برنامه ها استفاده کنیم؟ قسمت اول

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

 

در اینجا برخی از نیازهای تجاری در حال تغییر وجود دارد:

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

این نیازهای تجاری بر نحوه ساخت برنامه های کاربردی تأثیر می گذارد.

 

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

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

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

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

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

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

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

استانداردها با مشخص کردن نحوه برقراری ارتباط و تحمل تنها چیزهایی که از یک سرویس به آن نیاز دارید، به جای قراردادهای سفت و سخت، رویکرد میکروسرویس ها را به کار می اندازند. مهم است که این قراردادها را از قبل در طراحی تعریف کنید زیرا سرویس ها مستقل از یکدیگر به روز می شوند. یکی دیگر از توضیحاتی که برای طراحی با رویکرد میکروسرویس ابداع شده است، «معماری سرویس‌گرای ریزدانه (SOA)» است.

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

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

 

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

 

1. یک برنامه یکپارچه شامل قابلیت های دامنه خاص است و معمولاً به لایه های کاربردی مانند وب، تجارت و داده تقسیم می شود.
2. شما یک برنامه یکپارچه را با شبیه سازی آن در چندین سرور / ماشین مجازی / کانتینر مقیاس می دهید.
3. یک برنامه میکروسرویس عملکردها را به سرویس های کوچکتر جداگانه جدا می کند.
4. رویکرد میکروسرویس ها با استقرار هر سرویس به طور مستقل، ایجاد نمونه هایی از این سرویس ها در سرورها / ماشین های مجازی / کانتینرها، کاهش می یابد.

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

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

 

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

• یک سناریوی مشتری یا کسب و کار را محصور کنید. چه مشکلی را حل می کنید؟
• توسط یک تیم مهندسی کوچک توسعه یافته است.
• نوشته شده در هر زبان برنامه نویسی، با استفاده از هر چارچوب.
• شامل کد و حالت اختیاری است که هر دو به طور مستقل نسخه‌بندی، مستقر و مقیاس‌بندی شده‌اند.
• با سایر میکروسرویس ها از طریق رابط ها و پروتکل های کاملاً تعریف شده تعامل داشته باشید.
• نام‌های منحصربه‌فردی (URL) داشته باشید که برای تعیین موقعیت مکانی آنها استفاده می‌شود.
• در صورت وجود شکست ثابت و در دسترس بمانید.

 

• به طور خلاصه:

برنامه های Microservice از سرویس های متمرکز بر مشتری کوچک، مستقل و مقیاس پذیر تشکیل شده اند که از طریق پروتکل های استاندارد با رابط های کاملاً تعریف شده با یکدیگر ارتباط برقرار می کنند.

 

نوشته شده در هر زبان برنامه نویسی، با استفاده از هر چارچوب
به عنوان توسعه دهندگان، ما می خواهیم بسته به مهارت های خود و نیازهای سرویسی که ایجاد می کنیم، در انتخاب زبان یا چارچوب آزاد باشیم. برای برخی از خدمات، ممکن است مزایای عملکرد C++ را بیش از هر چیز دیگری ارزش گذاری کنید. برای دیگران، سهولت توسعه مدیریت شده که از سی شارپ یا جاوا دریافت می کنید ممکن است مهمتر باشد. در برخی موارد، ممکن است لازم باشد از یک کتابخانه شریک خاص، فناوری ذخیره سازی داده یا روشی برای ارائه خدمات به مشتریان استفاده کنید.

پس از انتخاب یک فناوری، باید مدیریت عملیاتی یا چرخه عمر و مقیاس بندی سرویس را در نظر بگیرید.

 

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

بیایید برای لحظه ای به مقایسه خود در مورد رویکردهای یکپارچه و میکروسرویس بازگردیم. این نمودار تفاوت در رویکردهای حالت ذخیره سازی را نشان می دهد:

 

ذخیره سازی حالت برای دو رویکرد

رویکرد یکپارچه، در سمت چپ، دارای یک پایگاه داده واحد و ردیف‌هایی از فناوری‌های خاص است.

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

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

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

میکروسرویس ها نسخه شده اند. این امکان وجود دارد که نسخه های مختلف یک میکروسرویس در کنار هم اجرا شوند. یک نسخه جدیدتر از یک میکروسرویس ممکن است در طول ارتقاء خراب شود و باید به نسخه قبلی بازگردانده شود. نسخه‌سازی برای تست A/B نیز مفید است، جایی که کاربران مختلف نسخه‌های متفاوتی از سرویس را تجربه می‌کنند. به عنوان مثال، ارتقاء یک میکروسرویس برای مجموعه خاصی از مشتریان برای آزمایش عملکرد جدید قبل از عرضه گسترده‌تر، معمول است.

 

با سایر میکروسرویس ها از طریق رابط ها و پروتکل های کاملاً تعریف شده تعامل دارد
در طول 10 سال گذشته، اطلاعات گسترده ای منتشر شده است که الگوهای ارتباطی در معماری های سرویس گرا را توصیف می کند. به طور کلی، ارتباطات سرویس از رویکرد REST با پروتکل های HTTP و TCP و XML یا JSON به عنوان فرمت سریال سازی استفاده می کند. از دیدگاه رابط، این در مورد اتخاذ یک رویکرد طراحی وب است. اما هیچ چیز نباید شما را از استفاده از پروتکل های باینری یا فرمت های داده خود باز دارد. فقط توجه داشته باشید که اگر این پروتکل‌ها و فرمت‌ها به طور آشکار در دسترس نباشند، استفاده از میکروسرویس‌های شما برای مردم سخت‌تر خواهد بود.

 

دارای یک نام منحصر به فرد (URL) است که برای تعیین مکان آن استفاده می شود
میکروسرویس شما باید در هر جایی که اجرا می شود آدرس پذیر باشد. اگر به ماشین‌ها فکر می‌کنید و اینکه کدام یک میکروسرویس خاص را اجرا می‌کند، ممکن است اوضاع به سرعت خراب شود.

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

 

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

برای در دسترس بودن، یک میکروسرویس باید در برابر خرابی مقاوم باشد و بتواند در دستگاه دیگری راه اندازی مجدد شود. علاوه بر این الزامات انعطاف‌پذیری، داده‌ها نباید از بین بروند و داده‌ها باید ثابت بمانند.

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

 

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

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

معرفی
 

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

Fabrikam، Inc به تازگی یک سرویس تحویل هواپیمای بدون سرنشین را راه اندازی کرده است تا تجارت فعلی کشتیرانی خود را تکمیل کند. این شرکت ناوگان هواپیماهای بدون سرنشین را مدیریت و اداره می کند. کسب‌وکارها در این سرویس ثبت‌نام می‌کنند و کاربران می‌توانند از پهپاد درخواست کنند تا کالاها را تحویل بگیرند. هنگامی که یک مشتری یک پیکاپ را برنامه ریزی می کند، یک سیستم پشتیبان یک پهپاد را اختصاص می دهد و کاربر را با زمان تخمینی تحویل مطلع می کند. در حالی که تحویل در حال انجام است، مشتری می‌تواند موقعیت پهپاد را با زمان تخمینی رسیدن (ETA) که به طور مداوم به روز می‌شود، ردیابی کند.

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

 

اهداف یادگیری
 شما:

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

 

پیش نیازها

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

 

معماری های یکپارچه و میکروسرویس

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

 

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

 

نمودار منطقی یک معماری یکپارچه

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

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

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

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

 

معماری میکروسرویس چیست؟
معماری میکروسرویس ها شامل سرویس هایی است که کوچک، مستقل و به صورت آزاد با هم مرتبط هستند. هر سرویس می تواند به طور مستقل مستقر و مقیاس شود.

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

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

از آنجایی که هر سرویس مستقل است، می‌توانند از پشته‌های فناوری، چارچوب‌ها و SDK‌های مختلف استفاده کنند. معمولاً مشاهده می‌شود که سرویس‌ها به تماس‌های REST برای ارتباط سرویس به سرویس با استفاده از APIهای تعریف‌شده به‌جای تماس‌های رویه از راه دور (RPC) یا سایر روش‌های ارتباطی سفارشی متکی هستند.

معماری‌های میکروسرویس به فناوری ناشناس هستند، اما اغلب می‌بینید که کانتینرها یا فناوری‌های بدون سرور برای اجرای آنها استفاده می‌شوند. استقرار مداوم و یکپارچه سازی مداوم (CI/CD) اغلب برای افزایش سرعت و کیفیت فعالیت های توسعه استفاده می شود.

 

مزایای معماری میکروسرویس ها
چرا معماری میکروسرویس را انتخاب می کنید؟ چندین مزیت اصلی برای معماری میکروسرویس وجود دارد:

• چابکی
• کد کوچک، تیم های کوچک
• ترکیبی از فناوری ها
• تاب آوری
• مقیاس پذیری
• جداسازی داده ها

 

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

 

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

اندازه تیم های کوچک نیز چابکی بیشتر را افزایش می دهد. "قانون دو پیتزا" می گوید که یک تیم باید به اندازه ای کوچک باشد که دو پیتزا بتواند تیم را تغذیه کند. بدیهی است که این یک معیار دقیق نیست و به اشتهای تیم بستگی دارد! اما نکته این است که گروه‌های بزرگ بازدهی کمتری دارند زیرا ارتباطات کندتر است، هزینه‌های مدیریتی بالا می‌رود و چابکی کاهش می‌یابد.

 

ترکیبی از فناوری ها
 

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

 

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

 

 

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

 

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

 

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

• پیچیدگی
• توسعه و آزمایش
• عدم حاکمیت
• ازدحام و تأخیر شبکه
• یکپارچگی داده
• مدیریت
• نسخه سازی
• مجموعه مهارت

 

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

 

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

 

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

 

ازدحام و تأخیر شبکه
استفاده از بسیاری از خدمات کوچک و جزئی می تواند منجر به ارتباطات بین سرویسی بیشتر شود. اگر زنجیره وابستگی های سرویس بیش از حد طولانی شود، به عنوان مثال، سرویس A با B تماس می گیرد، که C... را فرا می خواند، تاخیر اضافی این تماس های شبکه می تواند مشکل ساز شود. API های خود را با دقت طراحی کنید. از API های بیش از حد گپ پرهیز کنید، به قالب های سریال سازی فکر کنید و به دنبال مکان هایی برای استفاده از الگوهای ارتباطی ناهمزمان باشید.

 

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

 

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

 

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

 

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

 

چه زمانی باید معماری میکروسرویس را انتخاب کنید؟
بر اساس این اطلاعات پس‌زمینه، معماری میکروسرویس برای چه موقعیت‌هایی مناسب‌تر است؟

• کاربردهای بزرگی که به سرعت آزادسازی بالا نیاز دارند.
• برنامه های پیچیده ای که نیاز به مقیاس پذیری بالایی دارند.
• برنامه هایی با دامنه های غنی یا زیر دامنه های زیاد.
• سازمانی که از تیم های توسعه کوچک تشکیل شده است.

 

از دروازه های API در میکروسرویس ها استفاده کنید

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

 

طراحی API برای میکروسرویس ها

تمایز بین دو نوع API مهم است:

• API های عمومی که برنامه های مشتری با آنها تماس می گیرند.
• APIهای Backend که برای ارتباطات بین سرویسی استفاده می شوند.

 

این دو مورد نیاز تا حدودی متفاوت هستند. یک API عمومی باید با برنامه‌های مشتری، معمولاً برنامه‌های مرورگر یا برنامه‌های تلفن همراه بومی سازگار باشد. بیشتر اوقات، این بدان معناست که API عمومی از REST روی HTTP استفاده می کند. با این حال، برای APIهای Backend، باید عملکرد شبکه را در نظر بگیرید. بسته به جزئیات خدمات شما، ارتباطات بین سرویسی می تواند منجر به ترافیک شبکه زیادی شود. سرویس ها می توانند به سرعت به I/O محدود شوند. به همین دلیل، ملاحظاتی مانند سرعت سریال‌سازی و اندازه بار مهم‌تر می‌شوند. برخی از جایگزین های محبوب برای استفاده از REST از طریق HTTP عبارتند از gRPC، Apache Avro و Apache Thrift. این پروتکل ها از سریال سازی باینری پشتیبانی می کنند و به طور کلی کارآمدتر از HTTP هستند.

 

ملاحظات
در اینجا مواردی وجود دارد که باید هنگام انتخاب نحوه اجرای API به آنها فکر کنید.

REST در مقابل RPC. معاوضه بین استفاده از یک رابط به سبک REST در مقابل یک رابط به سبک RPC را در نظر بگیرید.

• REST منابع را مدل می کند، که می تواند راهی طبیعی برای بیان مدل دامنه شما باشد. این یک رابط یکنواخت بر اساس افعال HTTP تعریف می کند که تکامل پذیری را تشویق می کند. از نظر ناتوانی، عوارض جانبی و کدهای پاسخ معنایی کاملاً تعریف شده دارد. و ارتباطات بدون حالت را اعمال می کند که مقیاس پذیری را بهبود می بخشد.
• RPC بیشتر بر روی عملیات یا دستورات متمرکز است. از آنجایی که رابط‌های RPC شبیه فراخوانی‌های متد محلی هستند، ممکن است شما را به سمت طراحی APIهای بیش از حد چت سوق دهد. با این حال، این بدان معنا نیست که RPC باید چت باشد. این فقط به این معنی است که هنگام طراحی رابط باید مراقب باشید.

 

برای یک رابط RESTful، رایج‌ترین انتخاب REST بر روی HTTP با استفاده از JSON است. برای یک رابط به سبک RPC، چندین فریمورک محبوب از جمله gRPC، Apache Avro و Apache Thrift وجود دارد.

بهره وری. کارایی را از نظر سرعت، حافظه و اندازه محموله در نظر بگیرید. معمولاً یک رابط مبتنی بر gRPC سریعتر از REST از طریق HTTP است.

زبان تعریف رابط (IDL). IDL برای تعریف متدها، پارامترها و مقادیر بازگشتی یک API استفاده می شود. از IDL می توان برای تولید کد مشتری، کد سریال سازی و اسناد API استفاده کرد. IDLها همچنین می توانند توسط ابزارهای تست API مانند Postman مصرف شوند. چارچوب هایی مانند gRPC، Avro و Thrift مشخصات IDL خود را تعریف می کنند. REST روی HTTP فرمت استاندارد IDL ندارد، اما یک انتخاب رایج OpenAPI (سابق Swagger) است. همچنین می‌توانید بدون استفاده از زبان تعریف رسمی یک HTTP REST API ایجاد کنید، اما پس از آن مزایای تولید و آزمایش کد را از دست می‌دهید.

سریال سازی چگونه اشیاء روی سیم سریال می شوند؟ گزینه ها شامل فرمت های مبتنی بر متن (عمدتاً JSON) و فرمت های باینری مانند بافر پروتکل است. فرمت های باینری به طور کلی سریعتر از فرمت های مبتنی بر متن هستند. با این حال، JSON از نظر قابلیت همکاری مزایایی دارد، زیرا اکثر زبان ها و فریم ورک ها از سریال سازی JSON پشتیبانی می کنند. برخی از فرمت های سریال سازی نیاز به یک طرحواره ثابت دارند و برخی نیاز به کامپایل یک فایل تعریف طرحواره دارند. در این صورت، باید این مرحله را در فرآیند ساخت خود بگنجانید.

پشتیبانی از چارچوب و زبان HTTP تقریباً در هر چارچوب و زبانی پشتیبانی می شود. gRPC، Avro، و Thrift همگی دارای کتابخانه هایی برای C++، C#، Java و Python هستند. Thrift و gRPC نیز Go را پشتیبانی می کنند.

سازگاری و قابلیت همکاری. اگر پروتکلی مانند gRPC را انتخاب کنید، ممکن است به یک لایه ترجمه پروتکل بین API عمومی و انتهای پشتی نیاز داشته باشید. یک دروازه می تواند آن عملکرد را انجام دهد. اگر از سرویس مش استفاده می کنید، در نظر بگیرید که کدام پروتکل ها با سرویس مش سازگار هستند. به عنوان مثال، Linkerd از HTTP، Thrift و gRPC پشتیبانی داخلی دارد.

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

با این حال، اگر REST را از HTTP انتخاب کنید، باید در مراحل اولیه توسعه، تست عملکرد و بارگذاری را انجام دهید تا تأیید کنید که آیا به اندازه کافی برای سناریوی شما کارایی دارد یا خیر.

 

طراحی RESTful API
منابع زیادی برای طراحی RESTful API وجود دارد. در اینجا مواردی وجود دارد که ممکن است برای شما مفید باشد:

• طراحی API
• پیاده سازی API
• دستورالعمل های Microsoft REST API

 

در اینجا برخی از ملاحظات خاص وجود دارد که باید در نظر داشته باشید.

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

 

• انواع مختلف کلاینت، مانند برنامه تلفن همراه و مرورگر وب دسکتاپ، ممکن است به اندازه بار یا الگوهای تعامل متفاوتی نیاز داشته باشند. استفاده از الگوی Backends for Frontends را برای ایجاد backendهای جداگانه برای هر کلاینت در نظر بگیرید که یک رابط بهینه را برای آن کلاینت نشان می دهد.

 

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

 

• روش‌های HTTP می‌توانند معنایی ناهمزمان داشته باشند، که در آن روش بلافاصله یک پاسخ را برمی‌گرداند، اما سرویس به صورت ناهمزمان عملیات را انجام می‌دهد. در آن صورت، روش باید کد پاسخ HTTP 202 را برگرداند که نشان می‌دهد درخواست برای پردازش پذیرفته شده است، اما پردازش هنوز تکمیل نشده است. برای اطلاعات بیشتر، الگوی درخواست-پاسخ ناهمزمان را ببینید.

 

نگاشت REST به الگوهای DDD
الگوهایی مانند entity، aggregate و value object طراحی شده اند تا محدودیت های خاصی را بر روی اشیاء در مدل دامنه شما اعمال کنند. در بسیاری از بحث‌های DDD، الگوها با استفاده از مفاهیم زبان شی‌گرا (OO) مانند سازنده‌ها یا دریافت‌کننده‌ها و تنظیم‌کننده‌های ویژگی مدل‌سازی می‌شوند. برای مثال، قرار است اشیاء ارزش تغییرناپذیر باشند. در یک زبان برنامه نویسی OO، می توانید این را با اختصاص مقادیر در سازنده و ایجاد ویژگی ها فقط خواندنی اعمال کنید:

export class Location {
    readonly latitude: number;
    readonly longitude: number;

    constructor(latitude: number, longitude: number) {
        if (latitude < -90 || latitude > 90) {
            throw new RangeError('latitude must be between -90 and 90');
        }
        if (longitude < -180 || longitude > 180) {
            throw new RangeError('longitude must be between -180 and 180');
        }
        this.latitude = latitude;
        this.longitude = longitude;
    }
}

 

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

با این حال، در معماری میکروسرویس‌ها، سرویس‌ها از پایه کد یکسانی استفاده نمی‌کنند و ذخیره‌سازی داده‌ها را به اشتراک نمی‌گذارند. در عوض، آنها از طریق API ها ارتباط برقرار می کنند. موردی را در نظر بگیرید که در آن سرویس Scheduler اطلاعات مربوط به یک پهپاد را از سرویس Drone درخواست می کند. سرویس پهپاد مدل داخلی خود را از پهپاد دارد که از طریق کد بیان می شود. اما برنامه‌ریز آن را نمی‌بیند. درعوض، نمایشی از موجودیت هواپیمای بدون سرنشین - شاید یک شی JSON در یک پاسخ HTTP را به دست می‌آورد.

سرویس Scheduler نمی‌تواند مدل‌های داخلی سرویس پهپاد را تغییر دهد یا در فروشگاه داده سرویس پهپاد بنویسد. این بدان معناست که کدی که سرویس Drone را پیاده‌سازی می‌کند، در مقایسه با کدهای یکپارچه سنتی، سطح در معرض کمتری دارد. اگر سرویس Drone یک کلاس Location تعریف کند، دامنه آن کلاس محدود است - هیچ سرویس دیگری مستقیماً کلاس را مصرف نمی کند.

به این دلایل، این راهنما روی شیوه‌های کدنویسی تمرکز چندانی ندارد زیرا به الگوهای تاکتیکی DDD مربوط می‌شود. اما به نظر می رسد که می توانید بسیاری از الگوهای DDD را از طریق API های REST نیز مدل سازی کنید.

 

مثلا:

• مصالح به طور طبیعی به منابع موجود در REST نگاشت می شوند. برای مثال، مجموعه Delivery به عنوان یک منبع توسط Delivery API در معرض دید قرار می گیرد.
• سنگدانه ها مرزهای سازگاری هستند. عملیات روی سنگدانه ها هرگز نباید یک کل را در حالت ناسازگار بگذارد. بنابراین، باید از ایجاد APIهایی که به مشتری اجازه می دهد تا وضعیت داخلی یک مجموعه را دستکاری کند، خودداری کنید. درعوض، از APIهای درشت دانه حمایت کنید که انبوه ها را به عنوان منابع در معرض دید قرار می دهند.
• موجودیت ها هویت منحصر به فردی دارند. در REST، منابع دارای شناسه های منحصر به فرد در قالب URL هستند. URL های منبعی را ایجاد کنید که با هویت دامنه یک نهاد مطابقت دارد. نگاشت از URL به هویت دامنه ممکن است برای مشتری مبهم باشد.
• با پیمایش از موجودیت ریشه می توان به موجودیت های فرزند یک مجموعه دسترسی پیدا کرد. اگر از اصول HATEOAS پیروی می کنید، می توان به نهادهای فرزند از طریق پیوندهای موجود در نمایندگی نهاد والد دسترسی پیدا کرد.
• از آنجا که اشیاء ارزش تغییرناپذیر هستند، به روز رسانی ها با جایگزینی کل شی مقدار انجام می شود. در REST، به روز رسانی ها را از طریق درخواست های PUT یا PATCH پیاده سازی کنید.
• یک مخزن به مشتریان این امکان را می دهد که اشیاء را در یک مجموعه پرس و جو کنند، اضافه یا حذف کنند و جزئیات ذخیره داده های زیرین را انتزاع کنند. در REST، یک مجموعه می تواند یک منبع مجزا باشد، با روش هایی برای جستجوی مجموعه یا افزودن موجودیت های جدید به مجموعه.

 

هنگامی که API های خود را طراحی می کنید، به این فکر کنید که چگونه مدل دامنه را بیان می کنند، نه فقط داده های داخل مدل، بلکه به عملیات تجاری و محدودیت های روی داده ها.

 

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

 

هر زمان که ممکن است، تغییرات API را با گذشته سازگار کنید. به عنوان مثال، از حذف یک فیلد از یک مدل خودداری کنید، زیرا این کار می تواند مشتریانی را که انتظار دارند فیلد در آنجا باشد، از بین ببرد. افزودن یک فیلد سازگاری را از بین نمی برد، زیرا مشتریان باید در پاسخ هر فیلدی را که متوجه نمی شوند نادیده بگیرند. با این حال، سرویس باید مواردی را رسیدگی کند که یک مشتری قدیمی فیلد جدید را در یک درخواست حذف کند.

 

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

 

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

 

هنگامی که اجرای یک سرویس تغییر می کند، برچسب گذاری تغییر با یک نسخه مفید است. این نسخه اطلاعات مهمی را هنگام عیب یابی خطاها ارائه می دهد. این می تواند برای تجزیه و تحلیل علت ریشه ای بسیار مفید باشد که دقیقا بداند کدام نسخه از سرویس فراخوانی شده است. استفاده از نسخه‌سازی معنایی را برای نسخه‌های خدماتی در نظر بگیرید. نسخه‌سازی معنایی از قالب MAJOR.MINOR.PATCH استفاده می‌کند. با این حال، مشتریان فقط باید یک API را بر اساس شماره نسخه اصلی یا احتمالاً نسخه جزئی در صورتی که تغییرات قابل توجه (اما غیرقابل شکست) بین نسخه های جزئی وجود دارد، انتخاب کنند. 

 

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

مشخصات HTTP بیان می‌کند که روش‌های GET، PUT و DELETE باید فاقد قدرت باشند. روش‌های POST تضمینی برای بی‌توان بودن ندارند. اگر یک روش POST منبع جدیدی ایجاد کند، به طور کلی هیچ تضمینی وجود ندارد که این عملیات بی‌توان است. مشخصات idempotent را اینگونه تعریف می کند:

یک روش درخواست در صورتی که تأثیر مورد نظر بر روی سرور چندین درخواست یکسان با آن متد، با تأثیر یک درخواست منفرد یکسان باشد، «غیر توانمند» در نظر گرفته می‌شود. (RFC 7231)

 

درک تفاوت بین معنایی PUT و POST هنگام ایجاد یک موجودیت جدید بسیار مهم است. در هر دو مورد، مشتری نمایندگی یک موجودیت را در بدن درخواست ارسال می کند. اما معنای URI متفاوت است.

• برای یک روش POST، URI یک منبع اصلی موجودیت جدید، مانند یک مجموعه را نشان می دهد. به عنوان مثال، برای ایجاد یک تحویل جدید، URI ممکن است /api/deliveries باشد. سرور موجودیت را ایجاد می کند و یک URI جدید مانند /api/deliveries/39660 به آن اختصاص می دهد. این URI در هدر Location پاسخ برگردانده می شود. هر بار که مشتری درخواستی را ارسال می کند، سرور یک موجودیت جدید با یک URI جدید ایجاد می کند.

 

• برای یک روش PUT، URI موجودیت را شناسایی می کند. اگر قبلاً موجودی با آن URI وجود داشته باشد، سرور موجودیت موجود را با نسخه موجود در درخواست جایگزین می‌کند. اگر هیچ موجودیتی با آن URI وجود نداشته باشد، سرور یکی را ایجاد می کند. به عنوان مثال، فرض کنید مشتری یک درخواست PUT به api/deliveries/39660 ارسال می کند. با فرض عدم تحویل با آن URI، سرور یک URI جدید ایجاد می کند. حال اگر مشتری دوباره همان درخواست را ارسال کند، سرور جایگزین موجودیت موجود می شود.

در اینجا اجرای سرویس تحویل از روش PUT است.

 

[HttpPut("{id}")]
[ProducesResponseType(typeof(Delivery), 201)]
[ProducesResponseType(typeof(void), 204)]
public async Task<IActionResult> Put([FromBody]Delivery delivery, string id)
{
    logger.LogInformation("In Put action with delivery {Id}: {@DeliveryInfo}", id, delivery.ToLogInfo());
    try
    {
        var internalDelivery = delivery.ToInternal();

        // Create the new delivery entity.
        await deliveryRepository.CreateAsync(internalDelivery);

        // Create a delivery status event.
        var deliveryStatusEvent = new DeliveryStatusEvent { DeliveryId = delivery.Id, Stage = DeliveryEventType.Created };
        await deliveryStatusEventRepository.AddAsync(deliveryStatusEvent);

        // Return HTTP 201 (Created)
        return CreatedAtRoute("GetDelivery", new { id= delivery.Id }, delivery);
    }
    catch (DuplicateResourceException)
    {
        // This method is mainly used to create deliveries. If the delivery already exists then update it.
        logger.LogInformation("Updating resource with delivery id: {DeliveryId}", id);

        var internalDelivery = delivery.ToInternal();
        await deliveryRepository.UpdateAsync(id, internalDelivery);

        // Return HTTP 204 (No Content)
        return NoContent();
    }
}

 

انتظار می‌رود که اکثر درخواست‌ها یک موجودیت جدید ایجاد کنند، بنابراین روش به‌طور خوش‌بینانه CreateAsync را روی شی مخزن فراخوانی می‌کند و سپس با به‌روزرسانی منبع، هرگونه استثنای منابع تکراری را مدیریت می‌کند.

میکروسرویس ها چیست؟

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

 

میکروسرویس ها مثالی از اصل باز/بسته را اعمال می کنند:

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

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

• آن‌ها می‌توانند با اطمینان از خراب نشدن مشکلات موجود در یک سرویس یا روی دیگر بخش‌های یک برنامه، نقاط ضعف (SPOF) را حذف کنند.
• میکروسرویس‌های مجزا را می‌توان به‌طور مستقل مقیاس‌بندی کرد تا در دسترس بودن و ظرفیت اضافی را فراهم کند.
• تیم‌های DevOps می‌توانند با افزودن میکروسرویس‌های جدید بدون تأثیر غیرضروری بر سایر بخش‌های برنامه، عملکرد را گسترش دهند.

 

استفاده از میکروسرویس ها می تواند سرعت تیم را افزایش دهد. روش‌های DevOps، مانند Continuous Integration و Continuous Delivery، برای پیشبرد استقرار microservice استفاده می‌شوند. میکروسرویس ها به خوبی معماری های کاربردی مبتنی بر ابر را تکمیل می کنند و به تیم های توسعه نرم افزار اجازه می دهند از سناریوهایی مانند برنامه نویسی رویداد محور و مقیاس خودکار استفاده کنند. اجزای میکروسرویس API ها (رابط برنامه نویسی کاربردی) را معمولاً روی پروتکل های REST برای برقراری ارتباط با سرویس های دیگر در معرض دید قرار می دهند.

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

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

همانطور که از نام آن پیداست، معماری میکروسرویس رویکردی برای ساختن یک برنامه کاربردی سرور به عنوان مجموعه ای از خدمات کوچک است. این بدان معناست که یک معماری میکروسرویس عمدتاً به سمت عقب است، اگرچه این رویکرد برای قسمت جلویی نیز استفاده می شود. هر سرویس در فرآیند خود اجرا می شود و با استفاده از پروتکل هایی مانند HTTP/HTTPS، WebSockets یا AMQP با سایر فرآیندها ارتباط برقرار می کند. هر میکروسرویس یک دامنه سرتاسر یا یک قابلیت تجاری خاص را در یک مرز زمینه خاص پیاده‌سازی می‌کند، و هر یک باید به طور مستقل توسعه یافته و به طور مستقل قابل استقرار باشد. در نهایت، هر میکروسرویس باید دارای مدل داده دامنه مرتبط و منطق دامنه خود (حاکمیت و مدیریت داده غیرمتمرکز) باشد و می تواند بر اساس فناوری های مختلف ذخیره سازی داده ها (SQL، NoSQL) و زبان های برنامه نویسی مختلف باشد.

 

اندازه میکروسرویس باید چقدر باشد؟

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

 

چرا معماری میکروسرویس؟

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

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

 

استقرار یکپارچه در مقابل رویکرد میکروسرویس

در رویکرد سنتی یکپارچه، برنامه با شبیه سازی کل برنامه در چندین سرور/VM مقیاس می شود. در رویکرد میکروسرویس ها، عملکرد در سرویس های کوچکتر تفکیک می شود، بنابراین هر سرویس می تواند به طور مستقل مقیاس شود. رویکرد میکروسرویس تغییرات چابک و تکرار سریع هر میکروسرویس را امکان پذیر می‌کند، زیرا می‌توانید مناطق خاص و کوچکی از برنامه‌های پیچیده، بزرگ و مقیاس‌پذیر را تغییر دهید.

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

 

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

• نظارت و بررسی های بهداشتی خدمات و زیرساخت ها.
• زیرساخت مقیاس پذیر برای خدمات (یعنی ابر و ارکستراتورها).
• طراحی و پیاده سازی امنیت در سطوح مختلف: احراز هویت، مجوز، مدیریت اسرار، ارتباطات امن و غیره.
• تحویل سریع برنامه، معمولاً با تیم های مختلف که بر روی میکروسرویس های مختلف تمرکز می کنند.