تفاوت Consul, ZooKeeper, Eureka

با انتشار نسخه Ilford می توانید برای ایجاد ServiceDiscovery در Spring Cloud از هر یک از مجموعه های فوق استفاده نمایید. هرچند به تازگی در توضیحات آخرین انتشار آمده است که مجموعه Netflix حذف شده اما هنوز این مورد در مستندات فنی بجا مانده.

در این پست تصمیم گرفتم تفاوت هر سه را بیان کنم تا بتوان انتخاب درستی داشت.

ابزار Eureka

ابزار Eureka معماری کلاینت / سرور است و دارای مجموعه ای از سرورهای Eureka در هر مرکز داده (Zone)‌ است. معمولاً مشتریان Eureka از SDK تعبیه شده برای Register و ServiceDiscovery استفاده می کنند. برای دیگر Client ها، از یک ماشین جانبی مانند Ribbon برای ServiceDiscovery از طریق Eureka استفاده می شود.

ابزار Eureka در مشاهده تداوم سرویس کمی ضعیف عمل کرده. وقتی یک Client در یک سرور register می شود ، آن سرور سعی در تکثیر Client در سرورهای دیگر دارد اما هیچ تضمینی ارائه نمی دهد. ثبت نام سرویس ها دارای یک Time-To-Live (TTL) کوتاه است که نیاز به heartbeat داشتن client با سرورها را دارد. و در صورت قطع باعث می شوند تا از بین بروند و از رجیستری خارج شوند. درخواست های Discovery می تواند به هر سرویسی هدایت شود ، که به دلیل روش تکثیر در دیگر سرورها می تواند داده های منقضی یا مفقود شده را ارائه دهد. البته این مدل ساده امکان مدیریت cluster آسان و مقیاس پذیری بالا را فراهم می کند.

ابزار ZooKeeper

ابزار ZooKeeper دارای node های سرور است که برای کار به یک حد نصاب node نیاز دارد (معمولاً اکثریت ساده). که برای ساخت سیستم های پیچیده توزیع شده استفاده می شود.

این ابزار فضای ذخیره Key / Value را فراهم می کند: عملیات خواندن کاملاً مداوم و در دسترس بودن در برابر پارتیشن بندی شبکه گاهی فدا می شود.

مفاهیم ارائه شده توسط ZooKeeper برای ساخت سیستم های ServiceDiscovery جذاب است، اما تأکید بر اینکه این ویژگی ها باید ساخته شوند مهم است. ZooKeeper فقط یک فضای ابتدایی K / V را فراهم می کند و به توسعه دهندگان برنامه نیاز دارد که سیستم خود را برای ServiceDiscovery ارائه کنند.

ابزار ZooKeeper با استفاده از ephemeral nodes سیستمی پیچیده تر از سیستم ضربان قلب ارائه می دهد و پیچیدگی سمت client بیشتری دارد. همه client ها باید ارتباطات فعال خود را با سرورهای ZooKeeper برقرار کرده و این ارتباط را حفظ کنند. و علاوه بر این نگهداشت این ابزار نیاز به دانش فنی بالاتری نسبت به Eureka و Consul دارد و فرایند رفع اشکال کمی پیچیده تر است.

ابزار Consul

کنسول مجموعه ای از ویژگی های مورد نیاز برای پشتیبانی از معماری سرویس گرا را فراهم می کند. شامل ServiceDiscovery، سیستم Health check بهتر، قفل کردن، Key / Value، امکان چند مرکز داده ، سیستم event و ACL است. هم کنسول و ابزارهای اکوسیستم آن مانند consul-template و envconsul سعی می کنند تغییرات برنامه را به حداقل برسانند و از نیاز به ادغام با SDK را جلوگیری کنند. کنسول به مجموعه ای از سرورها در مرکز داده همراه با یک agent در هر client نیاز دارد، استفاده از agent به اکثر برنامه ها اجازه می دهد تا از کنسول مطلع نباشند ، ثبت سرویس را از طریق تنظیمات و Discovery از طریق DNS یا ماشین های جانبی مانند Ribbon یا دیگر loadbalancer ها انجام می دهند.

سرورها با استفاده از پروتکل Raft وضعیت را تکرار می کنند. کنسول از مجموعه ای از health checkها شامل TCP ، HTTP ، اسکریپت های سازگار با Nagios / Sensu یا TTL مانند Eureka پشتیبانی می کند. clientها برخلاف heartbeat متمرکز که مقیاس پذیری را دچار چالش می کند، در یک health check توزیع شده شرکت می کنند. به طوری که دیگر client ها نیز در این فرایند دخیل هستند. درخواست های Discovery به رهبر منتخب کنسول منتقل می شود. کنسول می تواند به عنوان سرویس قفل کننده برای انتخابات رهبر و هماهنگی cluster مورد استفاده قرار گیرد. Eureka سیستم مشابهی را ارائه نمی دهد و معمولاً به ZooKeeper برای اینچنین سرویس هایی نیاز دارد.

نتیجه گیری

در صورتی که از نسخه های spring cloud پایین تر از 2.4 استفاده می کنید می توانید با استفاده از ابزارهای ارائه شده Netflix سیستمی پایدار را مدیریت نمایید اما اگر از نسخه 2.4 یا بالاتر برای پروژه های جدید استفاده خواهید کرد پیشنهاد می شود کنسول را به جهت هزینه نگهداشت پایین تر و پشتیبانی spring cloud از آن استفاده نمایید.