تم إعداد ترجمة المقال خاصة لطلاب الدورة التدريبية "High Load Architect" .
مقدمة
في بنية Netflix microservice ، قد يكون نقل مجموعات البيانات من نقطة إلى عدة نقاط النهاية أمرًا بالغ الصعوبة. يمكن أن تحتوي مجموعات البيانات هذه على أي شيء من تكوين الخدمة إلى نتائج معالجة الدُفعات. لتحسين الوصول ، غالبًا ما تكون قاعدة البيانات المقيمة ضرورية ، ويجب إرسال التغييرات فور تحديث البيانات.
أحد الأمثلة التي تعكس الحاجة إلى التوزيع الموزع لمجموعة البيانات يشبه هذا: في أي وقت من الأوقات ، ينفذ Netflix عددًا كبيرًا من اختبارات A / B. تغطي هذه الاختبارات العديد من الخدمات والأوامر ، وينبغي أن يكون مشغلو الاختبار قادرين على إعادة التكوين سريعًا. يتطلب أيضًا القدرة على اكتشاف العقد التي لا يمكنها الحصول على أحدث تكوين للاختبار ، والقدرة على الرجوع إلى الإصدارات القديمة في حالة حدوث خطأ ما.
مثال آخر على مجموعة البيانات التي يجب توزيعها ، هو تسلسل مخرجات نموذج التعلم الآلي: يمكن استخدام نتائج عملها من قبل العديد من الفرق ، لكن فرق ML ليست بالضرورة مهتمة بدعم خدمات الوصول دون انقطاع في موقف حرج. بدلاً من الموقف الذي يحتاج فيه كل فريق إلى إنشاء نسخ احتياطية حتى يتمكن من التراجع بإيجاز ، يتم إيلاء اهتمام خاص للتأكد من أن العديد من الفرق يمكنها استخدام نتائج فريق واحد.
بدون دعم على مستوى البنية التحتية ، يحاول كل فريق في نهاية المطاف تطبيق الحل الخاص به ، لكنه يتحول مع فرق مختلفة مع نجاح متفاوت. مجموعات البيانات نفسها ذات أحجام مختلفة ، من بضع بايت إلى عدد قليل من الجيجابايت. من المهم خلق القدرة على مراقبة أداء العمليات واكتشاف الأعطال باستخدام أدوات خاصة حتى يتمكن المشغلون من إجراء تغييرات بسرعة دون الحاجة إلى إنشاء حل خاص بهم.
نشر البياناتفي Netflix ، نستخدم نظام بيانات حانة / فرعي داخلي يسمى Gutenberg. يسمح لك Gutenberg بتوزيع مجموعات البيانات باستخدام الإصدار - يشترك المستلمون في البيانات ويتلقون أحدث إصداراتهم عند نشرها. يبقى كل إصدار من مجموعة البيانات بدون تغيير ويحتوي على تمثيل كامل للبيانات ، أي أنه لا يوجد اعتماد على الإصدارات السابقة. يتيح لك Gutenberg عرض الإصدارات القديمة من البيانات في حالة احتياجك ، على سبيل المثال ، تصحيح الأخطاء أو حل مشكلة البيانات بسرعة أو إعادة تدريب نموذج التعلم الآلي. في هذه المقالة ، سنتحدث عن الهندسة المعمارية رفيعة المستوى في غوتنبرغ.
نموذج البيانات
موضوع واحد -> العديد من الإصداراتتصميم غوتنبرغ المستوى الأعلى هو الموضوع. يقوم الناشر بنشر بيانات داخل الموضوع ، ويقوم المستلمون باستخراجها منه. تتم إضافة المنشور في الموضوع كإصدار منفصل. وتتميز هذه بسياسة تخزين محددة تحدد عدد الإصدارات ، حسب حالة الاستخدام. على سبيل المثال ، يمكنك تكوين سمة لتخزين 10 إصدارات أو إصدارات آخر 10 أيام.
يحتوي كل إصدار على بيانات أولية (مفاتيح وقيم) ومؤشر بيانات. يمكن اعتبار مؤشر البيانات بيانات تعريف خاصة تشير إلى مكان تخزين البيانات المنشورة بالفعل. اليوم ، يدعم Gutenberg مؤشرات البيانات المباشرة (إذا كانت الحمولة مكتوبة بقيمة مؤشر البيانات نفسه) ومؤشرات بيانات S3 (إذا تم تخزين الحمولة في S3). عادةً ما تستخدم مؤشرات البيانات المباشرة عندما تكون البيانات صغيرة (أقل من 1 ميغابايت) ، ويستخدم S3 كتخزين نسخ احتياطي في حالة حجم البيانات كبير.
موضوع واحد -> العديد من المجموعات المنشورةيوفر Gutenberg القدرة على إرسال منشور إلى مجموعة محددة من المستخدمين المستلمين - على سبيل المثال ، يمكن تجميع مجموعة حسب منطقة أو تطبيق أو مجموعة محددة. يمكن استخدام هذا للتحكم في جودة تغييرات البيانات أو للحد من مجموعة البيانات بحيث يمكن لمجموعة فرعية من التطبيقات الاشتراك فيها. يحدد الناشرون منطقة النشر لإصدار معين من البيانات ويمكنهم إضافة مساحات إلى البيانات المنشورة مسبقًا. يرجى ملاحظة أن هذا يعني أن مفهوم أحدث إصدار من البيانات يعتمد على مجال معين - قد يتلقى التطبيقان أحدث إصدارات مختلفة من البيانات حسب منطقة النشر المحددة من قبل الناشر. تعيّن خدمة Gutenberg تطبيقات المستلمين على مناطق النشر قبل تحديد ما يجب إرساله كأحدث إصدار.
استخدام الحالات
حالة الاستخدام الأكثر شيوعًا لجوتنبرج هي توزيع البيانات ذات الأحجام المختلفة من ناشر واحد إلى عدة مستلمين. غالبًا ما يتم تخزين البيانات في ذاكرة المستلم واستخدامها "كذاكرة تخزين مؤقت مشتركة" ، حيث تظل دائمًا متاحة أثناء تنفيذ رمز المستلم ويتم استبدالها ذريًا تحت غطاء المحرك إذا لزم الأمر. يمكن تجميع العديد من حالات الاستخدام هذه في "تكوينات" ، مثل تكوين ذاكرة التخزين المؤقت
Open Connect Appliance ، ومعرفات نوع الجهاز المدعومة ، وبيانات تعريف طريقة الدفع المدعومة ، وتكوينات اختبار A / B. يوفر Gutenberg مجموعة من التجريد بين نشر هذه البيانات وتلقيها ، مما يسمح للناشرين بالتكرار بحرية من خلال تطبيقهم دون التأثير على المستلمين المتلقين للمعلومات. في بعض الحالات ، يتم النشر باستخدام واجهة مستخدم يديرها Gutenberg ، ولن تحتاج الفرق إلى لمس تطبيق النشر الخاص بها على الإطلاق.
استخدام آخر لنظام غوتنبرغ هو مستودع للبيانات التي تم إصدارها. يعد هذا مفيدًا لتطبيقات التعلم الآلي حيث تقوم الفرق بإنشاء النماذج وتدريبها استنادًا إلى البيانات التاريخية ، ومعرفة كيفية تغيرها بمرور الوقت ، ثم تغيير معلمات معينة وتشغيل التطبيق مرة أخرى. في غالب الأحيان في الحسابات التجميعية ، يتم استخدام Gutenberg لتخزين وتوزيع نتائج هذه الحسابات كإصدارات مختلفة من مجموعات البيانات. تشترك حالات الاستخدام عبر الإنترنت في الموضوعات لتوفير بيانات في الوقت الفعلي من أحدث مجموعات الإصدارات ، بينما يمكن للأنظمة الذاتية استخدام البيانات التاريخية من نفس الموضوعات ، على سبيل المثال ، لتدريس نموذج التعلم الآلي.
من المهم أن نلاحظ أن غوتنبرغ غير مصمم كنظام للأحداث ، فهو مخصص فقط للتحكم في الإصدار وتوزيع البيانات. على وجه الخصوص ، المنشورات المتكررة لا تعني أن المشترك مطلوب لاستلام كل نسخة. عندما يطلب تحديثًا ، سيتلقى أحدث إصدار ، حتى لو كان إصداره الحالي بعيدًا عن الإصدار الحالي. تعد أنظمة pub-sub أو أنظمة الأحداث التقليدية أكثر ملاءمة للرسائل الصغيرة التي يتم إرسالها بالتتابع. بمعنى أنه يمكن للمستلمين إنشاء فكرة عن مجموعة البيانات بالكامل عن طريق استهلاك دفق الأحداث بأكمله (المضغوط). ومع ذلك ، فإن Gutenberg يهدف إلى نشر واستخدام تمثيل كامل وغير قابل للتغيير لمجموعة البيانات.
التنمية والهندسة المعمارية
يتكون Gutenberg من خدمة gRPC وواجهة برمجة تطبيقات REST ، بالإضافة إلى مكتبة عملاء Java التي تستخدم واجهة برمجة تطبيقات gRPC.
العمارة عالية المستوىزبون
تتعامل مكتبة عميل Gutenberg مع مهام مثل إدارة الاشتراك وتحميل / تفريغ S3 ومقاييس
Atlas والمعلمات التي يمكن تكوينها باستخدام خصائص
Archaius . تتفاعل مع خدمة Gutenberg من خلال gRPC ، باستخدام
Eureka لاكتشاف الخدمات.
منشور
عادةً ما يستخدم الناشرون واجهات برمجة التطبيقات عالية المستوى لنشر السلاسل والملفات وصفائف البايت. بناءً على حجم البيانات ، يمكن نشرها كمؤشر مباشر على البيانات أو تحميلها على S3 ، ثم نشرها كمؤشر بيانات S3. يمكن للعميل تحميل الحمولة النافعة إلى S3 نيابة عن الناشر أو نشر بيانات تعريف الحمولة النافعة الموجودة بالفعل في S3 فقط.
يتم نسخ مؤشرات البيانات المباشرة تلقائيًا على مستوى العالم. يتم تحميل البيانات المنشورة في S3 افتراضيًا بواسطة الناشر في عدة مناطق ، على الرغم من أنه يمكن تخصيصها أيضًا.
إدارة الاشتراك
توفر مكتبة العميل إدارة اشتراك المستلم. يتيح ذلك للمستخدمين إنشاء اشتراكات لمواضيع معينة تستخرج منها المكتبة البيانات (على سبيل المثال ، من S3) من أجل نقلها إلى المستلم الذي حدده المستخدم. تعمل الاشتراكات وفقًا لنموذج الاستطلاع - يطلبون تحديثًا جديدًا من الخدمة كل 30 ثانية ، وإرسال النسخة التي تلقوها آخر مرة. لن يستخدم العملاء المشتركون إصدارًا أقدم من البيانات أكثر من الإصدار الذي لديهم حاليًا إذا لم يكن ثابتًا (راجع "التسامح مع الخطأ" أدناه). طلب المنطق المتكرر سلكي وقابل للتكوين. على سبيل المثال ، يمكن للمستخدمين تكوين Gutenberg لاستخدام الإصدارات القديمة من البيانات في حالة تعطل عملية التنزيل أو معالجة أحدث إصدار من البيانات عند بدء التشغيل ، وغالبًا ما يكون ذلك للعمل مع تغييرات البيانات التي لا تتوافق مع التعليقات. يوفر Gutenberg أيضًا اشتراكًا تم تكوينه مسبقًا يخزن أحدث البيانات وتحت غطاء محرك السيارة يقوم بتحديثها تلقائيًا عند وصول التغييرات. يفي هذا بمعظم حالات استخدام الاشتراك حيث يهتم المشتركون فقط بالقيمة الحالية في أي وقت معين ، مما يتيح للمستخدمين تحديد قيمة افتراضية ، على سبيل المثال ، لموضوع لم يتم نشره من قبل (على سبيل المثال ، إذا تم استخدام السمة للتهيئة) ، أو إذا كان هناك خطأ اعتمادًا على الموضوع (لتجنب حظر تشغيل الخدمة عندما تكون هناك قيمة افتراضية صالحة).
مستلم API
يوفر Gutenberg أيضًا واجهات برمجة التطبيقات (API) عالية المستوى للعميل ، والتي تحتوي على واجهات برمجة تطبيقات gRPC منخفضة المستوى وتتيح وظائف إضافية وشفافية في تنفيذ الاستعلام. أحد الأمثلة على ذلك هو تنزيل البيانات لموضوع وإصدار معين ، والذي تستخدمه على نطاق واسع المكونات المتصلة بـ
Netflix Hollow . مثال آخر هو استلام أحدث نسخة من موضوع في وقت معين - وهي حالة شائعة الاستخدام لنماذج تصحيح الأخطاء أو تعليم الآلة.
الاستدامة و "الشفافية" للعميل
تم تصميم Gutenberg مع التركيز على السماح ببدء خدمات المستلمين بنجاح ، بدلاً من ضمان أنها تبدأ بأحدث البيانات. لهذا السبب ، تم إنشاء مكتبة العميل باستخدام منطق النسخ الاحتياطي لمعالجة الحالات عندما لا تتمكن من التفاعل مع خدمة Gutenberg. في حالة فشل طلبات HTTP ، يقوم العميل بتحميل ذاكرة التخزين المؤقت لبيانات التعريف الاحتياطية للموضوع المنشور من S3 ويعمل معه. تحتوي ذاكرة التخزين المؤقت هذه على كافة المعلومات الخاصة بتحديد ما إذا كان سيتم تطبيق التحديث ومكان استرجاع البيانات (إما من بيانات تعريف المنشور نفسها أو من S3). يسمح ذلك للعملاء باسترداد البيانات (التي قد تكون قديمة ، وفقًا للحالة الحالية لذاكرة التخزين المؤقت الاحتياطية) دون استخدام الخدمة.
تتمثل إحدى ميزات توفير مكتبة عميل في القدرة على الحصول على مقاييس يمكن استخدامها للإبلاغ عن مشكلات البنية الأساسية بشكل عام والأخطاء في تطبيقات محددة. يتم استخدام هذه المقاييس اليوم بواسطة فريق Gutenberg لمراقبة توزيع SLI للمنشورات والتنبيهات في حالة حدوث مشكلات نموذجية. يستخدم بعض العملاء أيضًا هذه المقاييس للإبلاغ عن أخطاء خاصة بالتطبيقات ، على سبيل المثال ، فشل المنشورات الفردية أو رفض موضوع معين.
الخادم
Gutenberg هو تطبيق
Governator / Tomcat يوفر نقاط نهاية gRPC و REST. يستخدم نظام مجموعة كاساندرا المنسوخ عالمياً لتخزين وتوزيع بيانات تعريف المنشور في كل منطقة. يتم قياس مثيلات معالجة طلبات المستلمين بشكل منفصل عن المثيلات التي تعالج طلبات النشر. هناك حوالي 1000 مرة طلبات أكثر للنشر من طلبات النشر. بالإضافة إلى ذلك ، يتيح لك ذلك إزالة الاعتماد على حقيقة المنشور عند الاستلام ، وبالتالي لن تؤثر الزيادة المفاجئة في المنشورات على الاستلام ، والعكس صحيح.
يقوم كل مثيل في Cluster Request Cluster بمعالجة ذاكرة التخزين المؤقت الخاصة به في المنشورات الحديثة ، وسحبها من Cassandra كل بضع ثوانٍ. يعد ذلك ضروريًا لمعالجة عدد كبير من طلبات الاستلام الواردة من العملاء الموقعين دون نقل حركة المرور إلى نظام Cassandra. بالإضافة إلى ذلك ، تحمي ذاكرات التخزين المؤقت التي تحتوي على مجموعة طلبات ttl الصغيرة من طفرات الاستعلام التي قد تؤدي إلى إبطاء كاساندرا بدرجة كبيرة بحيث تؤثر على المنطقة بأكملها. واجهنا مواقف عندما تسببت أخطاء مفاجئة تزامنت مع إعادة توزيع المجموعات الكبيرة في حدوث انقطاع في خدمة جوتنبرج. بالإضافة إلى ذلك ، نستخدم
محدد التزامن التكيفي الموجود في التطبيق الأصلي لقمع التطبيقات ذات السلوك غير الصحيح دون التأثير على الآخرين.
في الحالات التي يتم فيها نشر البيانات في S3 في العديد من المناطق ، يقرر الخادم الجزء الذي سيتم إرساله مرة أخرى إلى العميل لتنزيله ، اعتمادًا على مكان وجود العميل. كما يسمح للخدمة بتزويد العميل بجزء في المنطقة "الأقرب" أو إجبار العميل على الانتقال إلى منطقة أخرى إذا تم فصل المنطقة الحالية لسبب أو لآخر.
قبل إعادة بيانات الاشتراك إلى المستلمين ، يقوم Gutenberg أولاً بفحص البيانات للتأكد من تناسقها. إذا فشل التحقق ، وتلقى المشترك بالفعل بعض البيانات ، فلن تُرجع الخدمة أي شيء ، مما يعني في الواقع أن التحديث غير متوفر. إذا لم يتلق عميل المشترك أي بيانات بعد (عادة ما يعني ذلك أنه قد بدأ لتوه) ، تطلب الخدمة محفوظات الموضوع وترجع القيمة الأخيرة التي تجتاز فحص التناسق. ويرجع ذلك إلى حقيقة أننا لاحظنا تأخيرات عرضية في النسخ المتماثل على مستوى كاساندرا ، حيث بحلول الوقت الذي يطلب فيه المشتركون بيانات جديدة ، كانت البيانات الوصفية المرتبطة بأحدث إصدار منشور قد تم نسخها جزئيًا فقط. يمكن أن يؤدي ذلك إلى تلقي العميل لبيانات غير مكتملة ، مما يؤدي إلى أخطاء أو أخطاء في طلب البيانات في منطق العمل. يؤدي إجراء عمليات التحقق من التناسق هذه على الخادم إلى حماية المستلمين من التنبيهات ذات التناسق المحتمل التي تأتي مع اختيار خدمة مستودع البيانات.
تعد القدرة على مراقبة منشورات الموضوعات والمواقع التي تستخدم هذه المواضيع مهمة مهمة لتدقيق وجمع معلومات الاستخدام. لجمع هذه البيانات ، تعترض الخدمة الطلبات المقدمة من الناشرين والمستلمين (كلا طلبات تحديث البيانات من المشتركين وغيرهم) وفهرستها في Elasticsearch باستخدام
خط أنابيب بيانات
Keystone . لذلك لدينا الفرصة للحصول على بيانات لرصد الموضوعات التي يتم استخدامها والتي لم تعد موجودة. ننشر روابط متعمقة بلوحة معلومات Kibana من واجهة المستخدم الداخلية بحيث يمكن لمالكي السمات إدارة المشتركين بشكل مستقل.
بالإضافة إلى المجموعات التي تتعامل مع طلبات الناشر والمستلم ، تطلق خدمة Gutenberg مجموعة أخرى تعالج الطلبات الدورية. على وجه الخصوص ، يحل مشكلتين:
- كل بضع دقائق ، يتم جمع أحدث المنشورات والبيانات الوصفية وإرسالها إلى S3. يؤدي هذا إلى بدء تشغيل ذاكرة التخزين المؤقت الاحتياطية ، والتي يستخدمها العميل ، كما هو موضح أعلاه.
- يقوم أداة تجميع مجمعي البيانات المهملة بحذف إصدارات الموضوعات التي لا تتوافق مع سياسات الاستبقاء الخاصة بهم. كما أنه يحذف البيانات المرتبطة به (على سبيل المثال ، كائنات S3) ويساعد على ضمان دورة حياة محددة جيدًا للبيانات.
خطأ التسامح
ربط
تحدث عمليات النشر غير الناجحة في عالم تطوير التطبيقات ، وتعد الاستعادة إلى الإصدارات السابقة استراتيجية شائعة لحل هذه المشكلات. تعمل البنية التي تعتمد على البيانات على تعقيد الموقف ، لأن السلوك يتحدد بالبيانات التي تتغير بمرور الوقت.
البيانات التي وزعتها غوتنبرغ التأثيرات وفي كثير من الحالات تسيطر على سلوك النظام. هذا يعني أنه إذا حدث خطأ ما ، فأنت بحاجة إلى طريقة للتراجع إلى إصدار جيد وثبت من البيانات. لتخفيف الموقف ، يتيح Gutenberg "ربط" السمة بإصدار معين. تتجاوز المسامير أحدث إصدار من البيانات وتجبر العميل على الترقية إلى هذا الإصدار ، مما يسمح لك بإصلاح الموقف الحرج بسرعة ، بدلاً من محاولة معرفة كيفية نشر أحدث إصدار من العمل. يمكنك أيضًا تطبيق الربط على منطقة النشر حتى يتمكن المستلمون من هذه المنطقة فقط من استخدام البيانات. تتخطى المسامير أيضًا البيانات المنشورة أثناء الربط النشط ، ولكن عندما يتم حذف الدبوس ، سيتلقى العملاء أحدث إصدار ، والذي قد يكون أحدث إصدار مثبت أو إصدار جديد تم نشره أثناء تثبيت الإصدار القديم.
النشر المتسلسل
عند نشر تعليمات برمجية جديدة ، يوصى غالبًا بإنشاء مجموعات جديدة تحتوي على مجموعة فرعية من حركة المرور أو نشرها تدريجيًا أو تقليل مخاطر النشر بطريقة أو بأخرى. , , .
, Gutenberg, —
Spinnaker . , . , . , , , , , . , AWS- .
Gutenberg Netflix . Gutenberg , 6 . – , 1-2 , 12 .
24- , , . , 200, 7. - , , Hollow. , , , – 60, – 4.
, Gutenberg:
- : Gutenberg Java-, Node.JS Python-. , REST API Gutenberg . , Node.JS Python.
- : Gutenberg . Gutenberg.
- : , . , .
- : , Gutenberg, Gutenberg . , .
- : , , . , Elasticsearch.
- : Netflix – . , Gutenberg , .
هذا كل شيء. .