TL؛ DR: وصف بنية خادم العميل لنظام إدارة تكوين الشبكة الداخلي لدينا، QControl. يعتمد على بروتوكول نقل ثنائي الطبقة يعمل مع الرسائل المعبأة بـ gzip دون فك الضغط بين نقاط النهاية. تتلقى أجهزة التوجيه ونقاط النهاية الموزعة تحديثات التكوين، ويسمح البروتوكول نفسه بتثبيت مرحلات وسيطة محلية. النظام مبني على المبدأ ("المستقر الحديث"، الموضح أدناه) ويستخدم لغة استعلام JMESpath مع محرك قوالب Jinja لعرض ملفات التكوين.
تدير Qrator Labs شبكة لتخفيف الهجمات موزعة عالميًا. تعمل شبكتنا على مبدأ Anycast، ويتم الإعلان عن الشبكات الفرعية عبر BGP. نظرًا لكوننا شبكة BGP Anycast موجودة فعليًا في عدة مناطق من الأرض، يمكننا معالجة وتصفية حركة المرور غير المشروعة بالقرب من قلب الإنترنت - مشغلي المستوى الأول.
ومن ناحية أخرى، فإن كونك شبكة موزعة جغرافيًا ليس بالأمر السهل. يعد الاتصال بين نقاط تواجد الشبكة أمرًا بالغ الأهمية لمزود خدمة الأمان للحصول على تكوين متسق لجميع عقد الشبكة وتحديثها في الوقت المناسب. لذلك، من أجل توفير أعلى مستوى ممكن من الخدمة الأساسية للمستهلك، كنا بحاجة إلى إيجاد طريقة لمزامنة بيانات التكوين بشكل موثوق عبر القارات.
في البداية كانت الكلمة. وسرعان ما أصبح بروتوكول اتصالات بحاجة إلى التحديث.
حجر الزاوية في وجود QControl، وفي الوقت نفسه السبب الرئيسي لإنفاق قدر كبير من الوقت والموارد على بناء هذا النوع من البروتوكول، هو الحاجة إلى الحصول على مصدر موثوق واحد للتكوين، وفي النهاية، مزامنة نقاط التواجد لدينا معها. كان التخزين بحد ذاته مجرد أحد المتطلبات العديدة أثناء تطوير QControl. بالإضافة إلى ذلك، كنا بحاجة أيضًا إلى التكامل مع الخدمات الحالية والمخططة في نقاط التواجد (POP)، والأساليب الذكية (والقابلة للتخصيص) للتحقق من صحة البيانات، فضلاً عن التحكم في الوصول. بالإضافة إلى ذلك، أردنا أيضًا التحكم في مثل هذا النظام باستخدام الأوامر بدلاً من إجراء تعديلات على الملفات. قبل QControl، كان يتم إرسال البيانات إلى نقاط التواجد يدويًا تقريبًا. إذا كانت إحدى نقاط التواجد غير متاحة ونسينا تحديثها لاحقًا، فسينتهي الأمر بالتكوين غير متزامن وسنضطر إلى إضاعة الوقت في إعادة تشغيله مرة أخرى.
ونتيجة لذلك، توصلنا إلى المخطط التالي:
يكون خادم التكوين مسؤولاً عن التحقق من صحة البيانات وتخزينها؛ ويحتوي جهاز التوجيه على العديد من نقاط النهاية التي تتلقى وتبث تحديثات التكوين من العملاء وفرق الدعم إلى الخادم، ومن الخادم إلى نقاط التواجد.
لا تزال جودة الاتصال بالإنترنت تختلف بشكل كبير حول العالم - لتوضيح هذه النقطة، دعونا نلقي نظرة على استعراض منتصف المدة البسيط من براغ، جمهورية التشيك إلى سنغافورة وهونج كونج.
مترو الأنفاق من براغ إلى سنغافورة
نفس الشيء بالنسبة لهونج كونج
الكمون العالي يعني سرعة أقل. وبالإضافة إلى ذلك، هناك فقدان الحزمة. عرض القناة لا يعوض هذه المشكلة، والتي يجب أن تؤخذ بعين الاعتبار دائمًا عند بناء الأنظمة اللامركزية.
يمثل التكوين الكامل لنقطة التواجد كمية كبيرة من البيانات التي يجب إرسالها إلى العديد من المستلمين عبر اتصالات غير موثوقة. لحسن الحظ، على الرغم من أن التكوين يتغير باستمرار، إلا أنه يحدث بزيادات صغيرة.
تصميم مستقر حديث
يمكننا القول أن بناء شبكة موزعة على أساس مبدأ التحديثات المتزايدة هو حل واضح إلى حد ما. ولكن هناك الكثير من المشاكل مع الاختلافات. نحتاج إلى حفظ جميع الاختلافات بين النقاط المرجعية، وأن نكون قادرين أيضًا على إعادة إرسالها في حالة فقد شخص ما جزءًا من البيانات. يجب على كل وجهة تطبيقها بتسلسل محدد بدقة. عادةً، في حالة الوجهات المتعددة، يمكن أن تستغرق هذه العملية وقتًا طويلاً. يجب أن يكون المتلقي أيضًا قادرًا على طلب الأجزاء المفقودة، وبالطبع، يجب على الجزء المركزي الاستجابة لمثل هذا الطلب بشكل صحيح، وإرسال البيانات المفقودة فقط.
ونتيجة لذلك، توصلنا إلى حل مثير للاهتمام إلى حد ما - لدينا طبقة مرجعية واحدة فقط، ثابتة، دعنا نسميها مستقرة، وفرق واحد فقط لها - حديث. يعتمد كل حديث على آخر مستقر تم إنشاؤه ويكفي لإعادة بناء بيانات التكوين. وبمجرد وصول القطعة الجديدة إلى وجهتها، لن تكون هناك حاجة إلى القطعة القديمة.
كل ما تبقى هو إرسال تكوين مستقر جديد من وقت لآخر، على سبيل المثال لأن الأخير أصبح كبيرًا جدًا. المهم أيضًا هنا هو أننا نرسل كل هذه التحديثات في وضع البث/البث المتعدد، دون القلق بشأن المستلمين الفرديين وقدرتهم على تجميع أجزاء من البيانات معًا. بمجرد أن نتأكد من أن كل شخص لديه الإسطبل الصحيح، فإننا نرسل فقط الإسطبل الجديد. هل يستحق التوضيح أن هذا يعمل؟ يعمل. يتم تخزين الإسطبل مؤقتًا على خادم التكوين والمستلمين، ويتم إنشاء الأحدث حسب الحاجة.
بنية النقل على مستويين
لماذا بنينا وسائل النقل لدينا على مستويين؟ الإجابة بسيطة جدًا - أردنا فصل التوجيه عن المنطق عالي المستوى، آخذين الإلهام من نموذج OSI بطبقات النقل والتطبيق الخاصة به. استخدمنا Thrift لدور بروتوكول النقل، وتنسيق تسلسل msgpack للتنسيق عالي المستوى لرسائل التحكم. هذا هو السبب في أن جهاز التوجيه (الذي يقوم بإجراء البث المتعدد/البث/الترحيل) لا ينظر داخل msgpack، ولا يقوم بفك محتوياتها أو حزمها مرة أخرى، ويقوم فقط بإعادة توجيه البيانات.
Thrift (من الإنجليزية - "thrift"، تُنطق [θrift]) هي لغة وصف الواجهة تُستخدم لتحديد وإنشاء الخدمات للغات برمجة مختلفة. إنه إطار عمل لاستدعاءات الإجراءات عن بعد (RPC). يجمع بين مسار البرامج ومحرك إنشاء التعليمات البرمجية لتطوير الخدمات التي تعمل بكفاءة وسهولة بين اللغات.
لقد اخترنا إطار عمل Thrift بسبب RPC ودعم العديد من اللغات. كالعادة، الأجزاء السهلة كانت العميل والخادم. ومع ذلك، تبين أن جهاز التوجيه صعب الكسر، ويرجع ذلك جزئيًا إلى عدم وجود حل جاهز أثناء تطويرنا.
هناك خيارات أخرى، مثل protobuf / gRPC، ومع ذلك، عندما بدأنا مشروعنا، كان gRPC جديدًا تمامًا ولم نجرؤ على أخذه في الاعتبار.
بالطبع، كان بإمكاننا (وفي الواقع كان ينبغي لنا) أن نبني دراجتنا الخاصة. سيكون من الأسهل إنشاء بروتوكول لما نحتاج إليه لأن بنية خادم العميل سهلة التنفيذ نسبيًا مقارنة ببناء جهاز توجيه على Thrift. بطريقة أو بأخرى، هناك تحيز تقليدي تجاه البروتوكولات المكتوبة ذاتيًا وتطبيقات المكتبات الشعبية (لسبب وجيه)؛ بالإضافة إلى ذلك، أثناء المناقشات يُطرح السؤال دائمًا: "كيف سننقل هذا إلى لغات أخرى؟" لذلك قمنا على الفور بطرح فكرة الدراجة.
يشبه Msgpack JSON، ولكنه أسرع وأصغر. إنه تنسيق تسلسل بيانات ثنائي يسمح بتبادل البيانات بين لغات متعددة.
في المستوى الأول لدينا توفير الحد الأدنى من المعلومات اللازمة لجهاز التوجيه لإعادة توجيه الرسالة. في المستوى الثاني توجد هياكل msgpack مجمعة.
لقد اخترنا msgpack لأنه أسرع وأكثر إحكاما مقارنة بـ JSON. ولكن الأهم من ذلك، أنه يدعم أنواع البيانات المخصصة، مما يسمح لنا باستخدام ميزات رائعة مثل تمرير الثنائيات الأولية أو الكائنات الخاصة التي تشير إلى عدم وجود بيانات، وهو ما كان مهمًا لمخططنا "المستقر حديثًا".
JMESPath
JMESPath هي لغة استعلام JSON.
هذا هو بالضبط ما يبدو عليه الوصف الذي حصلنا عليه من وثائق JMESPath الرسمية، لكنه في الواقع يفعل أكثر من ذلك بكثير. يسمح لك JMESPath بالبحث عن الأشجار الفرعية وتصفيتها في بنية شجرة عشوائية، وتطبيق التغييرات على البيانات بسرعة. كما يسمح لك بإضافة عوامل تصفية خاصة وإجراءات تحويل البيانات. على الرغم من أن الأمر يتطلب بالطبع جهدًا عقليًا لفهمه.
جنجا
بالنسبة لبعض المستهلكين، نحتاج إلى تحويل التكوين إلى ملف - لذلك نستخدم محرك القالب وJinja هو الخيار الواضح. وبمساعدتها، نقوم بإنشاء ملف تكوين من القالب والبيانات المستلمة في الوجهة.
لإنشاء ملف تكوين، نحتاج إلى طلب JMESPath، وقالب لموقع الملف في FS، وقالب للتكوين نفسه. إنها أيضًا فكرة جيدة في هذه المرحلة توضيح أذونات الملف. تم دمج كل هذا بنجاح في ملف واحد - قبل بدء قالب التكوين، قمنا بوضع رأس بتنسيق YAML يصف الباقي.
على سبيل المثال:
---
selector: "[@][[email protected]._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}
من أجل إنشاء ملف تكوين لخدمة جديدة، نقوم فقط بإضافة ملف قالب جديد. لا يلزم إجراء أي تغييرات على الكود المصدري أو البرنامج في نقاط التواجد.
ما الذي تغير منذ أن تم إطلاق QControl؟ أول وأهم شيء هو التسليم المتسق والموثوق لتحديثات التكوين لجميع العقد في الشبكة. والثاني هو الحصول على أداة قوية للتحقق من التكوين وإجراء تغييرات عليه من قبل فريق الدعم لدينا، وكذلك من قبل مستهلكي الخدمة.
لقد تمكنا من القيام بكل هذا باستخدام نظام التحديث المستقر الأخير لتبسيط الاتصال بين خادم التكوين ومستلمي التكوين. استخدام بروتوكول ثنائي الطبقة لدعم طريقة مستقلة عن المحتوى لتوجيه البيانات. تم بنجاح دمج محرك توليد التكوين المعتمد على Jinja في شبكة تصفية موزعة. يدعم هذا النظام مجموعة واسعة من طرق التكوين للأجهزة الطرفية الموزعة وغير المتجانسة.
شكرا لمساعدتكم في كتابة المواد. , , .
بريد.
المصدر: www.habr.com