ثبت سرویس در برابر حمل داده
در معماری Consul، بخش کنترلی فهرستی از سرویس‌ها و نشانی‌های آنها را نگه می‌دارد. بخش داده جایی است که بارهای کاری، داده کاربردی را با یکدیگر مبادله می‌کنند. فرایند Consul مستقیماً در مسیر عبور همه درخواست‌های برنامه قرار نمی‌گیرد؛ در حالت مش سرویس، پراکسی‌ها و درگاه‌ها می‌توانند بخشی از مسیر داده باشند.
سرورهای Consul برای توافق بر وضعیت ثبت‌شده از Raft استفاده می‌کنند و داده موردنیاز باید میان راه‌اندازی‌های مجدد باقی بماند. سامانه همچنین از اطلاعات هماهنگی شبکه و ارتباط میان عامل‌ها استفاده می‌کند. این مسئولیت‌ها را نباید با دسترس‌پذیری خود سرویس تجاری یکی دانست.
نمونه پیشنهادی تحریریه
سه سرویس فرضی سفارش، پرداخت و گزارش را در یک آزمایشگاه در نظر بگیرید. ابتدا برای هرکدام تعریف کنید «سالم» دقیقاً چیست: بازبودن پورت، پاسخ HTTP یا توان خواندن داده لازم؟ معیار را متناسب با وظیفه سرویس انتخاب کنید و نتیجه را از دید یک مصرف‌کننده واقعی هم آزمایش کنید.
سپس نشانی یکی از نمونه‌ها را تغییر دهید و مسیر رسیدن مصرف‌کننده به مقصد جدید را دنبال کنید. زمان به‌روزرسانی اطلاعات، رفتار کش و نحوه برخورد برنامه با اتصال قبلی را ثبت کنید. تغییر موفق در کاتالوگ، به‌تنهایی نشان نمی‌دهد همه اتصال‌های موجود فوراً مقصد تازه را انتخاب کرده‌اند.
خرابی کنترل و داده را جدا کنید
پیشنهاد ما طراحی دو آزمایش مستقل است: اختلال در دریافت اطلاعات جدید سرویس، و اختلال در خود پاسخ برنامه. هرکدام می‌تواند نشانه و مسیر بازیابی متفاوتی داشته باشد. پیش از اجرای آزمایش، روش برگشت و محدوده اثر را مشخص کنید.
در گزارش، از جمله کلی «Consul قطع شد» فاصله بگیرید و بگویید کدام کار شکست خورد: ثبت سرویس، مشاهده وضعیت، پیدا کردن مقصد یا برقراری ارتباط. این زبان دقیق، انتخاب اقدام اصلاحی را آسان‌تر می‌کند و مانع تغییر بی‌ربط در چند لایه می‌شود.
مرز اعتماد
برای یک طراحی سازمانی فرضی، مالک مجوز ثبت سرویس، تغییر پیکربندی و مشاهده کاتالوگ را جدا کنید. ثبت یک نام معتبر نباید بدون سیاست روشن، مجوز دسترسی نامحدود به همه برنامه‌ها ایجاد کند.
همچنین پشتیبان و رویه بازگردانی وضعیت بخش کنترلی را تمرین کنید. معیار موفقیت بهتر است بازگشت رفتار قابل‌سنجش برنامه باشد، نه فقط بالا آمدن فرایندها. این تفکیک میان اطلاعات مدیریتی و ترافیک کاربردی، مهم‌ترین نکته عملی در خواندن نمودار معماری است.
کاتالوگ سرویس چه چیزی را می‌داند؟
کاتالوگ اطلاعاتی درباره نمونه‌های ثبت‌شده سرویس، نشانی آنها و وضعیت بررسی سلامت نگه می‌دارد. این اطلاعات برای پیدا کردن مقصد مفید است، اما خود درخواست تجاری را اجرا نمی‌کند. اگر سرویس پرداخت در کاتالوگ سالم دیده می‌شود، هنوز ممکن است یک عملیات مشخص آن به دلیل خطای داده یا وابستگی بیرونی شکست بخورد. طراحی بررسی سلامت باید این تفاوت را در نظر بگیرد و از یک نشانه محدود نتیجه سلامت کامل همه قابلیت‌ها نگیرد.
برای هر سرویس، نام منطقی را از نمونه اجرایی جدا کنید. چند نمونه ممکن است یک نام خدمت را ارائه دهند ولی شناسه، نشانی و وضعیت مستقل داشته باشند. اگر یک نمونه جابه‌جا می‌شود، ثبت جدید و حذف اطلاعات قدیمی باید هماهنگ باشد. باقی ماندن نشانی منقضی در کش مصرف‌کننده می‌تواند پس از اصلاح کاتالوگ هم خطا بسازد. بنابراین زمان کش و رفتار تلاش مجدد برنامه، بخشی از کار کشف سرویس است و فقط به سرورهای Consul مربوط نمی‌شود.
عامل محلی و سرور مسئولیت یکسان ندارند
در استقرارهای متداول، عامل نزدیک بار کاری ثبت‌ها و بررسی‌های محلی را مدیریت می‌کند و سرورها وضعیت مشترک را هماهنگ می‌کنند. تعداد فرایندهای در حال اجرا به تنهایی میزان تحمل خرابی را نشان نمی‌دهد؛ نقش هر فرایند و محل استقرار آن اهمیت دارد. چند سرور روی یک میزبان یا یک دامنه خرابی مشترک، همان استقلال چند میزبان جدا را ندارند. پیش از تغییر تعداد اعضا، فرض خرابی را مشخص کنید: قطع یک فرایند، میزبان یا بخش شبکه؟
همچنین همه ارتباط‌های داخلی یک کار انجام نمی‌دهند. انتشار اطلاعات عضویت، درخواست‌های کنترلی و توافق بر وضعیت می‌توانند مسیرها و نیازهای متفاوت داشته باشند. باز بودن یک پورت خاص اثبات نمی‌کند همه ارتباط‌های لازم برقرار است. هنگام بررسی شبکه، از مستندات همان نسخه و نقش استقرار استفاده کنید و فهرست دقیق ارتباط‌ها را بسنجید. باز کردن گسترده همه پورت‌ها معمولاً راهی برای پنهان کردن نبود نقشه ارتباط است و تشخیص مشکل بعدی را دشوارتر می‌کند.
Raft و مفهوم اکثریت
در بخش سروری، توافق بر تغییرات به دسترسی به اکثریت لازم وابسته است. این طراحی برای جلوگیری از تصمیم‌های ناسازگار اهمیت دارد، اما به معنای ادامه نامحدود نوشتن در هر تقسیم شبکه نیست. اگر اکثریت لازم در دسترس نباشد، برخی عملیات مدیریتی ممکن است متوقف شوند. این رفتار را نباید فوراً به عنوان خطای نرم‌افزار تعبیر کرد. ابتدا وضعیت اعضا، رهبر و ارتباط میان آنها را بررسی کنید و فرض معماری درباره خرابی را با وضعیت واقعی مقایسه کنید.
افزودن سرور بیشتر همیشه راه ساده افزایش ظرفیت نیست. تعداد اعضای رأی‌دهنده بر هماهنگی و عملیات نگهداری اثر دارد و باید مطابق راهنمای نسخه و اندازه محیط انتخاب شود. برای تیم عملیات، دانستن اینکه کدام اعضا برای تصمیم‌گیری لازم‌اند از دیدن تعداد کلی ماشین‌ها مهم‌تر است. در آزمایشگاه، یک سرور را متوقف کنید و توان خواندن و ثبت تغییر را جدا بسنجید. سپس بازگشت عضو و همگام شدن وضعیت را بررسی کنید، نه فقط شروع دوباره فرایند را.
سلامت فنی و آمادگی تجاری
بررسی باز بودن پورت نشان می‌دهد فرایندی اتصال را می‌پذیرد، اما ممکن است آن فرایند به پایگاه داده لازم دسترسی نداشته باشد. بررسی HTTP نیز بسته به پیاده‌سازی می‌تواند بسیار سطحی یا پرهزینه باشد. برای هر سرویس، معیار سلامت را با هدف انتخاب مقصد هماهنگ کنید. بررسی‌ای که همه وابستگی‌های دور را فراخوانی می‌کند ممکن است با یک مشکل مشترک همه نمونه‌ها را هم‌زمان ناسالم نشان دهد؛ بررسی بسیار ساده نیز نمونه غیرقابل استفاده را سالم نگه می‌دارد.
یک مثال مناسب، جداسازی زنده بودن فرایند از آماده بودن برای پذیرش کار است. سرویسی که در حال بارگذاری داده است شاید زنده باشد ولی هنوز نباید ترافیک تازه دریافت کند. هنگام توقف نیز بهتر است خروج از انتخاب مقصد و پایان درخواست‌های موجود با هم هماهنگ شوند. با یک درخواست طولانی آزمایشی، رفتار این مرز را بررسی کنید. حذف فوری فرایند قبل از تخلیه اتصال‌ها می‌تواند خطا ایجاد کند حتی اگر اطلاعات کاتالوگ خیلی سریع به‌روز شود.
DNS و رابط برنامه‌نویسی دو روش مصرف اطلاعات‌اند
مصرف‌کننده می‌تواند بسته به طراحی از DNS یا رابط برنامه‌نویسی برای یافتن سرویس استفاده کند. هر روش رفتار کش، خطا و به‌روزرسانی خودش را دارد. در روش DNS، کتابخانه سیستم‌عامل یا برنامه ممکن است پاسخ را بیشتر از انتظار تیم نگه دارد. در روش رابط برنامه‌نویسی نیز مدیریت اتصال، زمان انتظار و پاسخ ناموفق اهمیت دارد. بنابراین آزمایش کشف باید از داخل همان برنامه یا محیط اجرایی انجام شود، نه فقط با یک ابزار پرس‌وجوی دستی روی ماشین مدیر.
برای بررسی تغییر نشانی، یک نمونه را با مقصدی دارای پاسخ متمایز جایگزین کنید و زمان دیده شدن مقصد جدید را ثبت کنید. سپس نمونه قدیمی را از دسترس خارج کنید و رفتار اتصال‌های موجود را ببینید. اگر برنامه فقط در آغاز اجرا نام را حل می‌کند، تغییر کاتالوگ ممکن است تا راه‌اندازی دوباره دیده نشود. این نتیجه باید به تیم توسعه منتقل شود، زیرا اصلاح آن احتمالاً در منطق مصرف اطلاعات است و نه در سرعت تکثیر سرورها.
مش سرویس و مسیر داده
در حالت استفاده از مش، پراکسی‌ها می‌توانند ارتباط میان بارهای کاری را حمل کنند و اطلاعات کنترلی لازم را از سامانه مدیریت دریافت کنند. این نقش با کاتالوگ ساده تفاوت دارد. خرابی بخش کنترلی ممکن است بر دریافت پیکربندی تازه اثر بگذارد، در حالی که برخی ارتباط‌های موجود با اطلاعات قبلی ادامه پیدا کنند. رفتار دقیق به پیکربندی و نسخه وابسته است و باید آزمایش شود. از این امکان نباید نتیجه گرفت که کنترل برای همیشه قابل حذف است یا همه اتصال‌های جدید موفق خواهند بود.
برای فهم مرزها، دو آزمایش جدا بسازید: در اول ارتباط برنامه با پراکسی یا مقصد را مختل کنید و در دوم تنها مسیر دریافت اطلاعات کنترلی را قطع کنید. نتیجه درخواست موجود، اتصال تازه و تغییر سیاست را جدا ثبت کنید. این سه عملیات ممکن است رفتار متفاوتی داشته باشند. گزارش دقیق باید بگوید کدام عملیات شکست خورده، نه اینکه با یک عنوان کلی کل سامانه را از کارافتاده اعلام کند.
ACL، هویت سرویس و تغییرات مجاز
مجوز خواندن کاتالوگ، ثبت سرویس و تغییر تنظیمات باید متناسب با مسئولیت حساب باشد. اعتبارنامه یک برنامه عادی نباید برای راحتی به مجوز مدیریت همه محیط تبدیل شود. اگر همان برنامه آسیب ببیند، دامنه اثر اعتبارنامه تعیین می‌کند مهاجم تا کجا می‌تواند اطلاعات سرویس یا پیکربندی را تغییر دهد. برای هر اعتبارنامه، مالک، محل استفاده و روش لغو مشخص کنید و اطلاعات حساس را در گزارش عیب‌یابی منتشر نکنید.
ثبت یک نام سرویس نباید بدون کنترل مناسب به جعل هویت یک خدمت مهم منجر شود. در طراحی مش و سیاست ارتباط، نام، هویت و مجوز را با هم بررسی کنید. آزمون منفی باید نشان دهد یک بار کاری با اعتبارنامه محدود نمی‌تواند خودش را به جای سرویس حساس ثبت کند یا سیاست ارتباط دیگران را تغییر دهد. این آزمایش را در محیط جدا انجام دهید و نتیجه رد درخواست را همراه با گزارش قابل پیگیری نگه دارید.
پشتیبان‌گیری از کنترل و بازیابی رفتار
پشتیبان وضعیت کنترلی با پشتیبان داده برنامه‌ها فرق دارد. بازیابی کاتالوگ یا تنظیمات، پایگاه داده پرداخت یا فایل‌های سرویس را بازنمی‌گرداند. فهرست داده‌های تحت پوشش هر پشتیبان را مشخص کنید تا هنگام حادثه انتظار اشتباه شکل نگیرد. همچنین روش بازیابی باید با نسخه و شیوه استقرار سازگار باشد. یک فایل پشتیبان که هرگز در محیط جدا بازگردانی نشده، تضمین کافی برای زمان بازیابی نیست.
در تمرین بازیابی، علاوه بر بالا آمدن اعضا، ثبت یک سرویس آزمایشی، پیدا کردن آن از مصرف‌کننده و انجام درخواست واقعی را بررسی کنید. اعتبارنامه‌ها، گواهی‌ها و نشانی‌های وابسته نیز باید پس از بازگردانی درست کار کنند. اگر داده قدیمی بازگردانده می‌شود، درباره ثبت‌های منقضی و تفاوت با وضعیت واقعی تصمیم بگیرید. معیار پایان تمرین، بازگشت مسیر کاربردی قابل سنجش است و نه صرفاً سبز شدن وضعیت فرایندها در یک پنل مدیریتی.
