کشف سرویس: نگاهی عمیق به مکانیزم‌های بررسی سلامت

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

کشف سرویس چیست؟

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

ابزارهای محبوب کشف سرویس عبارتند از:

• Consul: یک راهکار سرویس مش با قابلیت‌های کشف سرویس، پیکربندی و تقسیم‌بندی.
• Etcd: یک ذخیره‌ساز کلید-مقدار توزیع‌شده که معمولاً برای کشف سرویس در کوبرنتیز استفاده می‌شود.
• ZooKeeper: یک سرویس متمرکز برای نگهداری اطلاعات پیکربندی، نام‌گذاری، ارائه همگام‌سازی توزیع‌شده و خدمات گروهی.
• Kubernetes DNS: یک مکانیزم کشف سرویس مبتنی بر DNS که در کوبرنتیز تعبیه شده است.
• Eureka: یک رجیستری سرویس که عمدتاً در محیط‌های Spring Cloud استفاده می‌شود.

اهمیت بررسی‌های سلامت

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

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

انواع بررسی‌های سلامت

چندین نوع بررسی سلامت وجود دارد که می‌توان برای نظارت بر سلامت سرویس‌ها از آنها استفاده کرد. رایج‌ترین انواع عبارتند از:

بررسی‌های سلامت HTTP

بررسی‌های سلامت HTTP شامل ارسال یک درخواست HTTP به یک اندپوینت (endpoint) خاص در سرویس و تأیید کد وضعیت پاسخ است. کد وضعیت 200 (OK) معمولاً نشان‌دهنده سلامت سرویس است، در حالی که کدهای وضعیت دیگر (مانند 500 Internal Server Error) نشان‌دهنده یک مشکل هستند. پیاده‌سازی بررسی‌های سلامت HTTP ساده است و می‌توان از آنها برای تأیید عملکرد اولیه سرویس استفاده کرد. به عنوان مثال، یک بررسی سلامت ممکن است اندپوینت `/health` یک سرویس را بررسی کند. در یک برنامه Node.js با استفاده از Express، این کار می‌تواند به سادگی زیر باشد:

app.get('/health', (req, res) => {
  res.status(200).send('OK');
});

نمونه‌های پیکربندی:

Consul

{
  "service": {
    "name": "payment-service",
    "port": 8080,
    "check": {
      "http": "http://localhost:8080/health",
      "interval": "10s",
      "timeout": "5s"
    }
  }
}

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: payment-service
spec:
  containers:
  - name: payment-service-container
    image: payment-service:latest
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 10

بررسی‌های سلامت TCP

بررسی‌های سلامت TCP شامل تلاش برای برقراری یک اتصال TCP به یک پورت خاص در سرویس است. اگر اتصال با موفقیت برقرار شود، سرویس سالم در نظر گرفته می‌شود. بررسی‌های سلامت TCP برای تأیید اینکه سرویس روی پورت صحیح در حال گوش دادن است و اتصالات را می‌پذیرد، مفید هستند. آنها ساده‌تر از بررسی‌های HTTP هستند زیرا لایه برنامه را بازرسی نمی‌کنند. یک بررسی اولیه، در دسترس بودن پورت را تأیید می‌کند.

نمونه‌های پیکربندی:

Consul

{
  "service": {
    "name": "database-service",
    "port": 5432,
    "check": {
      "tcp": "localhost:5432",
      "interval": "10s",
      "timeout": "5s"
    }
  }
}

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: database-service
spec:
  containers:
  - name: database-service-container
    image: database-service:latest
    ports:
    - containerPort: 5432
    livenessProbe:
      tcpSocket:
        port: 5432
      initialDelaySeconds: 15
      periodSeconds: 20

بررسی‌های سلامت با اجرای دستور

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

نمونه‌های پیکربندی:

Consul

{
  "service": {
    "name": "monitoring-service",
    "port": 80,
    "check": {
      "args": ["/usr/local/bin/check_disk_space.sh"],
      "interval": "30s",
      "timeout": "10s"
    }
  }
}

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: monitoring-service
spec:
  containers:
  - name: monitoring-service-container
    image: monitoring-service:latest
    command: ["/usr/local/bin/check_disk_space.sh"]
    livenessProbe:
      exec:
        command: ["/usr/local/bin/check_disk_space.sh"]
      initialDelaySeconds: 60
      periodSeconds: 30

بررسی‌های سلامت سفارشی

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

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

پیاده‌سازی بررسی‌های سلامت

پیاده‌سازی بررسی‌های سلامت معمولاً شامل مراحل زیر است:

1. تعریف معیارهای سلامت: مشخص کنید چه چیزی یک سرویس سالم را تشکیل می‌دهد. این ممکن است شامل زمان پاسخ، استفاده از CPU، استفاده از حافظه، وضعیت اتصال به پایگاه داده و در دسترس بودن منابع خارجی باشد.
2. پیاده‌سازی اندپوینت‌ها یا اسکریپت‌های بررسی سلامت: اندپوینت‌ها (مانند `/health`) یا اسکریپت‌هایی ایجاد کنید که بررسی‌های سلامت را انجام داده و یک کد وضعیت یا کد خروج مناسب را برمی‌گردانند.
3. پیکربندی ابزار کشف سرویس: ابزار کشف سرویس خود (مانند Consul, Etcd, Kubernetes) را برای اجرای دوره‌ای بررسی‌های سلامت و به‌روزرسانی رجیستری سرویس بر اساس آن، پیکربندی کنید.
4. نظارت بر نتایج بررسی سلامت: نتایج بررسی سلامت را برای شناسایی مشکلات احتمالی و انجام اقدامات اصلاحی نظارت کنید.

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

بهترین شیوه‌ها برای بررسی‌های سلامت

در اینجا برخی از بهترین شیوه‌ها برای پیاده‌سازی بررسی‌های سلامت آورده شده است:

• بررسی‌های سلامت را سبک نگه دارید: بررسی‌های سلامت باید سریع باشند و منابع حداقلی را مصرف کنند. از منطق پیچیده یا عملیات ورودی/خروجی خودداری کنید. هدف، بررسی‌هایی است که در چند میلی‌ثانیه کامل شوند.
• از انواع مختلف بررسی‌های سلامت استفاده کنید: انواع مختلفی از بررسی‌های سلامت را ترکیب کنید تا دید جامع‌تری از سلامت سرویس به دست آورید. به عنوان مثال، از یک بررسی سلامت HTTP برای تأیید عملکرد اولیه سرویس و یک بررسی سلامت با اجرای دستور برای تأیید در دسترس بودن منابع خارجی استفاده کنید.
• وابستگی‌ها را در نظر بگیرید: اگر یک سرویس به سرویس‌ها یا منابع دیگری وابسته است، بررسی‌هایی برای آن وابستگی‌ها در بررسی سلامت خود بگنجانید. این می‌تواند به شناسایی مشکلاتی کمک کند که ممکن است از معیارهای سلامت خود سرویس بلافاصله آشکار نباشند. به عنوان مثال، اگر سرویس شما به یک پایگاه داده وابسته است، یک بررسی برای اطمینان از سلامت اتصال به پایگاه داده اضافه کنید.
• از فواصل زمانی و تایم‌اوت‌های مناسب استفاده کنید: فاصله زمانی و تایم‌اوت بررسی سلامت را متناسب با سرویس خود پیکربندی کنید. فاصله زمانی باید به اندازه‌ای مکرر باشد که مشکلات را به سرعت تشخیص دهد، اما نه آنقدر مکرر که بار غیرضروری بر سرویس وارد کند. تایم‌اوت باید به اندازه‌ای طولانی باشد که به بررسی سلامت اجازه تکمیل دهد، اما نه آنقدر طولانی که تشخیص مشکلات را به تأخیر بیندازد. یک نقطه شروع رایج، فاصله زمانی 10 ثانیه و تایم‌اوت 5 ثانیه است، اما این مقادیر ممکن است نیاز به تنظیم بر اساس سرویس و محیط خاص داشته باشند.
• خطاهای گذرا را به درستی مدیریت کنید: منطقی برای مدیریت صحیح خطاهای گذرا پیاده‌سازی کنید. یک شکست در بررسی سلامت ممکن است نشان‌دهنده یک مشکل جدی نباشد. استفاده از یک آستانه یا مکانیزم تلاش مجدد را برای جلوگیری از حذف زودهنگام یک سرویس از رجیستری سرویس در نظر بگیرید. به عنوان مثال، ممکن است لازم باشد یک سرویس سه بار متوالی در بررسی سلامت شکست بخورد تا ناسالم در نظر گرفته شود.
• اندپوینت‌های بررسی سلامت را امن کنید: از اندپوینت‌های بررسی سلامت در برابر دسترسی غیرمجاز محافظت کنید. اگر اندپوینت بررسی سلامت اطلاعات حساسی مانند معیارهای داخلی یا داده‌های پیکربندی را افشا می‌کند، دسترسی را فقط به کلاینت‌های مجاز محدود کنید. این کار را می‌توان از طریق احراز هویت یا لیست سفید IP انجام داد.
• بررسی‌های سلامت را مستند کنید: هدف و پیاده‌سازی هر بررسی سلامت را به وضوح مستند کنید. این به سایر توسعه‌دهندگان کمک می‌کند تا نحوه کار بررسی‌های سلامت و نحوه عیب‌یابی مشکلات را درک کنند. اطلاعاتی درباره معیارهای سلامت، اندپوینت یا اسکریپت بررسی سلامت و کدهای وضعیت یا کدهای خروج مورد انتظار را شامل کنید.
• اصلاح و بازیابی را خودکار کنید: بررسی‌های سلامت را با سیستم‌های اصلاح خودکار ادغام کنید. هنگامی که یک سرویس ناسالم تشخیص داده شد، به طور خودکار اقداماتی را برای بازگرداندن سرویس به حالت سالم فعال کنید. این ممکن است شامل راه‌اندازی مجدد سرویس، افزایش تعداد نمونه‌ها یا بازگشت به نسخه قبلی باشد.
• از تست‌های دنیای واقعی استفاده کنید: بررسی‌های سلامت باید ترافیک واقعی کاربر و وابستگی‌ها را شبیه‌سازی کنند. فقط بررسی نکنید که آیا سرور در حال اجرا است؛ اطمینان حاصل کنید که می‌تواند درخواست‌های معمول را مدیریت کرده و با منابع لازم تعامل داشته باشد.

نمونه‌ها در تکنولوژی‌های مختلف

بیایید به نمونه‌هایی از پیاده‌سازی بررسی سلامت در تکنولوژی‌های مختلف نگاهی بیندازیم:

جاوا (Spring Boot)

@RestController
public class HealthController {

    @GetMapping("/health")
    public ResponseEntity<String> health() {
        // Perform checks here, e.g., database connection
        boolean isHealthy = true; // Replace with actual check

        if (isHealthy) {
            return new ResponseEntity<>("OK", HttpStatus.OK);
        } else {
            return new ResponseEntity<>("Error", HttpStatus.INTERNAL_SERVER_ERROR);
        }
    }
}

پایتون (Flask)

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/health')
def health_check():
    # Perform checks here
    is_healthy = True  # Replace with actual check

    if is_healthy:
        return jsonify({'status': 'OK'}), 200
    else:
        return jsonify({'status': 'Error'}), 500

if __name__ == '__main__':
    app.run(debug=True, host='0.0.0.0', port=5000)

Go

package main

import (
    "fmt"
    "net/http"
)

func healthHandler(w http.ResponseWriter, r *http.Request) {
    // Perform checks here
    isHealthy := true // Replace with actual check

    if isHealthy {
        w.WriteHeader(http.StatusOK)
        fmt.Fprint(w, "OK")
    } else {
        w.WriteHeader(http.StatusInternalServerError)
        fmt.Fprint(w, "Error")
    }
}

func main() {
    http.HandleFunc("/health", healthHandler)
    fmt.Println("Server listening on port 8080")
    http.ListenAndServe(":8080", nil)
}

بررسی‌های سلامت و توازن بار (Load Balancing)

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

نمونه‌هایی از لود بالانسرهایی که با بررسی‌های سلامت ادغام می‌شوند عبارتند از:

• HAProxy
• NGINX Plus
• Amazon ELB
• Google Cloud Load Balancing
• Azure Load Balancer

مانیتورینگ و هشداردهی

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

ابزارهای مانیتورینگ محبوبی که با بررسی‌های سلامت ادغام می‌شوند عبارتند از:

• Prometheus
• Datadog
• New Relic
• Grafana
• Nagios

نتیجه‌گیری

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

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

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