کشف خدمات در سیستم های توزیع شده با استفاده از مثال Consul. الکساندر سیگاچف

پیشنهاد می‌کنم متن گزارش الکساندر سیگاچف را در سیستم‌های توزیع‌شده با استفاده از Consul به عنوان مثال، Service Discovery بخوانید.

Service Discovery ایجاد شد تا با حداقل هزینه بتوانید یک برنامه جدید را به محیط موجود ما متصل کنید. با استفاده از Service Discovery، می‌توانیم یک داکر کانتینر یا یک سرویس مجازی را از محیطی که در آن اجرا می‌شود جدا کنیم.

من به همه خوش آمد می گویم! من الکساندر سیگاچف هستم، در اینونتوس کار می کنم. و امروز شما را با مفهومی به عنوان کشف سرویس آشنا می کنم. بیایید به عنوان مثال به سرویس Discovery با استفاده از Consul نگاه کنیم.

سرویس Discovery چه مشکلاتی را حل می کند؟ Service Discovery ایجاد شد تا با حداقل هزینه بتوانید یک برنامه جدید را به محیط موجود ما متصل کنید. با استفاده از Service Discovery، می‌توانیم یک داکر کانتینر یا یک سرویس مجازی را از محیطی که در آن اجرا می‌شود جدا کنیم.

چه شکلی است؟ در یک مثال کلاسیک در وب، این قسمت جلویی است که درخواست کاربر را می‌پذیرد. سپس آن را به باطن هدایت می کند. در این مثال، این load-balancer دو backend را متعادل می کند.

در اینجا می بینیم که در حال راه اندازی نمونه سوم از برنامه هستیم. بر این اساس، هنگامی که برنامه شروع می شود، با Service Discovery ثبت نام می کند. Service Discovery به بار متعادل کننده اطلاع می دهد. Load-balancer پیکربندی خود را به طور خودکار تغییر می دهد و باطن جدید راه اندازی می شود. به این ترتیب، Backend ها را می توان اضافه کرد، یا برعکس، از کار حذف کرد.

چه کارهای دیگری با سرویس Discovery راحت است؟ Service Discovery می‌تواند پیکربندی‌های nginx، گواهی‌ها و فهرستی از سرورهای باطن فعال را ذخیره کند.

سرویس Discovery همچنین به شما امکان می دهد تا خرابی ها را شناسایی کرده و خرابی ها را شناسایی کنید. طرح های ممکن برای تشخیص خرابی ها چیست؟

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

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

اگر ما برنامه را به ارث برده ایم یا توسط شخص دیگری توسعه داده شده است، گزینه سوم زمانی مناسب است که ما یک handler می نویسیم و همه اینها به طور خودکار وارد کار ما می شود.

این یک نمونه است. Load-balancer به شکل nginx راه اندازی مجدد می شود. این یک ابزار اختیاری است که با کنسول ارائه می شود. این الگوی کنسول است. ما قاعده را شرح می دهیم. ما می گوییم که از یک الگو (موتور قالب گلانگ) استفاده می کنیم. هنگامی که رویدادها رخ می دهند، هنگامی که اعلان هایی مبنی بر اینکه تغییرات رخ داده است، دوباره تولید می شود و دستور "بارگذاری مجدد" به سرویس Discovery ارسال می شود. ساده ترین مثال زمانی است که nginx توسط یک رویداد پیکربندی مجدد و راه اندازی مجدد می شود.

کنسول چیست؟

• اول از همه، این سرویس کشف است.

• دارای مکانیزم بررسی در دسترس بودن - بررسی سلامت.

• فروشگاه KV نیز دارد.

• و بر اساس قابلیت استفاده از Multi Datacenter است.

از همه اینها برای چه می توان استفاده کرد؟ در KV Store می توانیم تنظیمات نمونه را ذخیره کنیم. بررسی سلامت ما می توانیم خدمات محلی را بررسی کنیم و اطلاع دهیم. Multi Datacenter برای ساختن یک نقشه خدمات استفاده می شود. به عنوان مثال، آمازون چندین منطقه و مسیرهای ترافیکی را به بهینه ترین حالت دارد تا درخواست های غیرضروری بین مراکز داده وجود نداشته باشد که جدا از ترافیک محلی شارژ می شوند و بر این اساس تاخیر کمتری دارند.

بیایید کمی با اصطلاحاتی که در Consul استفاده می شود آشنا شویم.

• کنسول سرویسی است که در Go نوشته شده است. یکی از مزایای برنامه Go 1 فایل باینری است که فقط دانلود می کنید. از هر جایی راه اندازی شده است و هیچ وابستگی ندارید.
• سپس با استفاده از کلیدها می توانیم این سرویس را در حالت مشتری یا در حالت سرور راه اندازی کنیم.
• همچنین، ویژگی “datacenter” به شما امکان می دهد پرچمی را تعیین کنید که این سرور به کدام مرکز داده تعلق دارد.
• اجماع - بر اساس پروتکل raft. اگر کسی علاقه مند است، می توانید اطلاعات بیشتری در این مورد در وب سایت کنسول بخوانید. این پروتکلی است که به شما امکان می دهد رهبر را تعیین کنید و تعیین کنید که کدام پول معتبر و قابل دسترسی است.
• Gossip پروتکلی است که تعامل بین گره ها را امکان پذیر می کند. علاوه بر این، این سیستم غیرمتمرکز است. در یک مرکز داده، همه گره ها با همسایگان خود ارتباط برقرار می کنند. و بر این اساس، اطلاعات مربوط به وضعیت فعلی به یکدیگر منتقل می شود. می توان گفت که این شایعات بین همسایگان است.
• LAN Gossip - تبادل محلی داده بین همسایگان در همان مرکز داده.
• WAN Gossip - زمانی استفاده می شود که نیاز به همگام سازی اطلاعات بین دو مرکز داده داریم. اطلاعات بین گره هایی که به عنوان سرور علامت گذاری شده اند جریان می یابد.
• RPC - به شما امکان می دهد درخواست ها را از طریق یک کلاینت روی سرور اجرا کنید.

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

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

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

کنسول چه API ارائه می دهد؟ برای به دست آوردن اطلاعات، کنسول دو نوع API دارد.

این DNS API است. به طور پیش فرض، کنسول روی پورت 8600 اجرا می شود. ما می توانیم پروکسی درخواست را پیکربندی کنیم و دسترسی را از طریق وضوح محلی، از طریق DNS محلی فراهم کنیم. ما می توانیم بر اساس دامنه پرس و جو کنیم و در پاسخ اطلاعات آدرس IP را دریافت کنیم.

HTTP API - یا می توانیم به صورت محلی اطلاعاتی در مورد یک سرویس خاص در پورت 8500 درخواست کنیم و پاسخ JSON دریافت کنیم، سرور چه IP دارد، چه میزبانی دارد، چه پورتی ثبت شده است. و اطلاعات اضافی را می توان از طریق توکن منتقل کرد.

برای اداره کنسول به چه چیزهایی نیاز دارید؟

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

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

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

چک های سلامت چگونه ارائه می شود؟ یک قانون تأیید را به شکل Json در فهرست پیکربندی Consul می نویسیم. اولین گزینه در دسترس بودن دامنه google.com در این مثال است. و می گوییم که این بررسی باید در فواصل 30 ثانیه انجام شود. به این ترتیب بررسی می کنیم که گره ما به شبکه خارجی دسترسی دارد.

گزینه دوم این است که خودتان را بررسی کنید. ما از curl معمولی برای فراخوانی لوکال هاست در پورت مشخص شده در فواصل 10 ثانیه استفاده می کنیم.

این چک ها خلاصه شده و به Service Discovery ارسال می شوند. بر اساس در دسترس بودن، این گره ها یا حذف می شوند یا در لیست ماشین های موجود و به درستی کار می کنند.

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

در این مثال، تب "سرویس" باز است. نشان داده شده است که سه سرویس در حال اجرا است که یکی از آنها کنسول است. تعداد بررسی های انجام شده و سه مرکز داده وجود دارد که ماشین ها در آنها قرار دارند.

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

همچنین می توانید اطلاعاتی در مورد وضعیت دیسک ها و میانگین بارگذاری به کنسول ارسال کنید.

پرسش

سوال: ما یک داکر کانتینر داریم، چگونه با کنسول از آن استفاده کنیم؟

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

سوال: پس خود کنسول کانتینر داکر را راه اندازی می کند؟

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

سوال: معلوم می شود که در داخل کانتینر داکر که می خواهیم به سرویس دیسکاوری متصل کنیم باید نوعی منطق وجود داشته باشد که بتواند داده ها را برای کنسول ارسال کند؟

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

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

پاسخ: در UI داده هایی از پایگاه داده و سرویس Discovery وجود دارد. ما خودمان رمز عبور را در تنظیمات تنظیم می کنیم.

سوال: آیا می توان این را در اینترنت منتشر کرد؟

پاسخ: به طور پیش فرض، کنسول روی لوکال هاست شروع به کار می کند. برای انتشار در اینترنت، باید نوعی پروکسی نصب کنید. ما مسئول قوانین ایمنی خود هستیم.

سوال: آیا داده های تاریخی را خارج از جعبه ارائه می دهد؟ نگاهی به آمار چک های سلامتی جالب است. همچنین اگر سرور اغلب از کار می افتد، می توانید مشکلات را تشخیص دهید.

پاسخ: من مطمئن نیستم که جزئیات چک در آنجا وجود داشته باشد.

سوال: وضعیت فعلی به اندازه پویایی مهم نیست.

پاسخ: برای تحلیل – بله.

سوال: آیا بهتر است از Service Discovery for Consul docker استفاده نشود؟

پاسخ: استفاده از آن را توصیه نمی کنم. هدف از این گزارش معرفی این است که چه مفهومی وجود دارد. از نظر تاریخی، به نظر من به نسخه 1 راه پیدا کرده است. اکنون راه حل های کامل تری وجود دارد، به عنوان مثال، Kubernetes، که همه اینها را زیر کاپوت دارد. به عنوان بخشی از Kubernetes Service Discovery نسبت به Etcd پایین تر است. اما من آنقدر که با کنسول آشنا هستم با آن آشنا نیستم. بنابراین، تصمیم گرفتم با استفاده از Consul به عنوان مثال، سرویس Discovery را ایجاد کنم.

سوال: آیا طرح با سرور رهبر، شروع برنامه را به طور کلی کند نمی کند؟ و اگر این یکی دروغ می گوید کنسول چگونه رهبر جدیدی را تعیین می کند؟

پاسخ: یک پروتکل کامل توضیح داده شده است. اگر علاقه دارید می توانید آن را بخوانید.

سوال: کنسول به عنوان یک سرور تمام عیار برای ما عمل می کند و همه درخواست ها از طریق آن انجام می شود؟

پاسخ: به عنوان یک سرور تمام عیار عمل نمی کند، بلکه یک منطقه خاص را در اختیار می گیرد. معمولا به service.consul ختم می شود. و بعد منطقی پیش می رویم. ما از نام های دامنه در تولید استفاده نمی کنیم، بلکه از زیرساخت داخلی استفاده می کنیم که اگر با استفاده از DNS کار کنیم، معمولاً در پس کش سرور پنهان می شود.

سوال: یعنی اگر بخواهیم به یک پایگاه داده دسترسی داشته باشیم، در هر صورت کنسول را می کشیم تا این پایگاه داده را اول پیدا کند، درست است؟

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

گپ محصول hashicorp — گپ کاربر Hashicorp: Consul، Nomad، Terraform

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

200 OK for healthy
503 Service Unavailable for unhealthy

منابع:
https://www.consul.io/docs/agent/checks.html
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://thoslin.github.io/microservice-health-check-in-kubernetes/

منبع: www.habr.com