قمنا بحل الخطأ الكبير 429 باستخدام بوابة Kubernetes وتوفير 30٪ من تكلفة الخادم
في الشهر الماضي، كاد فريقنا أن ينهار:13 في المائة من طلبات تحليل العناوين المستخدمين تم رفضها مباشرة 429بعد نصف يوم من التحقق من الخلفية ، وجدت أن قواعد الحد من التيار التي تم تخصيصها بشكل منفصل لكل خدمة صغيرة كانت ميتة جدًا ، وزاد حجم حركة المرور لوحدة الاستفسار اللوجستية ثلاث مرات ، وغيرها من الموارد الفارغة لا يمكن استخدامها في الماضي.
كنا نعتقد دائما أن بوابة Kubernetes هي مكون معقد يستخدمها الشركات الكبيرة، حتى خطى على هذه الحفرة قبل أن يتم إجبارها على الانترنت، واستغرق أقل من أسبوع، وكانت أفضل بكثير مما كنا نتوقع.
ما هي بوابة Kubernetes؟
ببساطة ، هو مدخل حركة المرور الموحد لمجموعة Kubernetes بأكملها ، حيث تأتي جميع الطلبات الخارجية أولاً ، ثم يتم إرسالها إلى الخدمات الخلفية المقابلة ، ونحن نستخدم نسخة مفتوحة المصدر واحدة قادرة على تحمل 12000 طلب في الثانية ، والفريق الصغير لا يحتاج إلى الاختناقات في الأداء.
ثلاث فوائد حقًا حصلت عليها
الأول هو الأكثر بديهية: قواعد الحد من التيار أخيرًا لا تحتاج إلى كل خدمة بشكل منفصل.في السابق ، حثنا على تغيير عتبة الحد من التيار لسبعة وثمانية خدمات صغيرة ، وتغيير مشكلة واحدة ، والآن مباشرة في طبقة البوابة للقيام بالحد من التيار الديناميكي ، يمكن أن تميل موارد الخادم الفارغة تلقائيًا إلى وحدات عالية الحركة ، وهذا عيد الميلاد حثنا على انخفاض الخطأ 429 مباشرة إلى 0.
والثاني هو تكاليف المقاطعة.في السابق ، من أجل تحمل ذروة الخدمات الأساسية الثلاثة ، قمنا بتخصيص خادمين إضافيين ، معظم استخدام الموارد في معظم الوقت 20٪ فقط ، والآن يمكن للبوابة أن تقوم بتوازن الحمل تلقائيًا ، قمنا بتقليص القدرة مباشرة على 6 خوادم ، وحساب تكلفة السحابة الشهرية بنسبة 30٪.
والثالث هو عدم الحاجة إلى جعل الطرف الخلفي يتغير مرارًا وتكرارًا عبر المجالات والتصديق على هذه المنطقات العامة.قبل كل خدمة جديدة على الإنترنت، والخلفية يجب أن تكتب مرة أخرى JWT التحقق من الشفرة، والآن مباشرة في طبقة البوابة مع قواعد يتم الانتهاء من ذلك، ونحن الخلفية 3 الناس يمكن أن تخرج على الأقل نصف يوم في الأسبوع لكتابة الشفرة التجارية.
لا تسمعوا فقط، وهذه الحفرة لدينا خطوة قوية.
الحفرة الأولى هي حفرة افتراضية جدا من وقت انتهاء الإعدادات.في اليوم الأول من التشغيل على الإنترنت ، وجدنا أن 5٪ من طلبات تحليل العنوان انتهى وقتها الزمني ، والتحقق من نصف يوم لم يجد أن وقت انتهاء الوقت الافتراضي للبوابة هو 30 ثانية ، ولكن خدمة تحليل العنوان الخاصة بنا نفسها ستشغل لأطول 40 ثانية ، واستأنف القواعد على الفور ، يجب عليك التحقق من عتبة وقت انتهاء واجهة الأعمال الخاصة بك قبل التشغيل على الإنترنت.
الحفرة الثانية هي عدم كومة جميع الوظائف في البداية.في البداية كنا نريد أن السجلات، الحد من التيار، WAF، إصدار درجة الرمادي جميع وظائف في وقت واحد، والنتيجة خطأ في كتابة تكوين أدى إلى انقطاع مدخل العنقود بأكملها لمدة 20 دقيقة، وبعد ذلك نحن أولا فقط فتح التوجيه والحد من التيار، تشغيل 3 أيام مستقرة ثم إضافة مهام أخرى ببطء، لم تكن هناك مشكلة مرة أخرى.
هل تريد استخدامها؟معايير الحكم التي نقدمها بسيطة.
الحالات المناسبة:
- عدد الخدمات الصغيرة لديك أكثر من 5 ، وتحتاج إلى تغيير عدة أماكن ذهابًا وإيابًا في كل تكوين عام
- في كثير من الأحيان يواجه الذروة في حركة المرور ، لا يمكن تحديد الموارد بمرونة بين الخدمات المختلفة
- فريق الخلفية أقل من 5 أشخاص لا يريد أن يضيع وقته في تكرار المنطق العام.
لا تتخبط في الحالة:
- لديك 2 الخدمات الصغيرة ، حركة المرور مستقرة على مدار السنة ، الآن مع إعادة توجيه NGINX لا توجد أي مشاكل
- لا أحد في الفريق يعرف أساسيات Kubernetes ، لا تتواصل مع التقنيات الجديدة
نصيحتان حقيقيتان للفريق الصغير الذي يبدأ لأول مرة
لا تحتاج إلى التشابك في اختيار النموذج ، فريق صغير مباشرة باستخدام APISIX أو Kong مفتوح المصدر ، وثائق دعم كاملة ، واجهت مشاكل للبحث عن حل أساسي ، لا تحتاج إلى شراء نسخة تجارية ، وظائف الإصدار المجاني كافية تمامًا.
قبل التشغيل على الإنترنت ، قم بقطع 10٪ من حركة المرور لمدة 24 ساعة ، مع التركيز على ما إذا كان هناك وقت مضى ، وطلب تم اعتراضه عن طريق الخطأ ، لا توجد مشكلة في قطع الكمية الكاملة ، لا تأتي مرة واحدة لتوجيه جميع حركة المرور.
أخيرًا ، ما يسأله الجميع كثيرًا: لم يدرس أحدنا البوابة على وجه التحديد قبل النهاية الخلفية الثلاثة ، واستغرق الأمر يومين للانتهاء من الوثائق الرسمية ، وليس معقدًا كما تعتقد.
هل كان هذا مفيدًا؟