يعد مبدأ "لا تكرر نفسك" أو DRY مبدأً مهمًا في تطوير البرمجيات. سيوضح لك هذا المنشور كيفية تطبيقه على تكوين Apache APISIX.  مبدأ DRY  "عدم تكرار نفسك" (DRY) هو مبدأ في تطوير البرمجيات يهدف إلى تقليل تكرار المعلومات التي من المرجح أن تتغير، واستبدالها بتجريدات أقل عرضة للتغيير، أو استخدام تطبيع البيانات الذي يتجنب التكرار في المقام الأول.  --  ويكيبيديا - لا تكرر نفسك  الفكرة الرئيسية وراء DRY هي أنه إذا كررت نفسك وتغيرت المعلومات، فيجب عليك تحديث المعلومات المتغيرة في أماكن متعددة. وهذا ليس مجرد جهد إضافي؛ فهناك احتمال أن تنسى الأمر وتجد معلومات مختلفة في أماكن مختلفة. يتميز DRY بإصلاح الأخطاء.  تخيل أن هناك مقتطفًا من التعليمات البرمجية يحتوي على خطأ. تخيل الآن أنك قمت بتكرار المقتطف في مكانين مختلفين. الآن، يجب عليك إصلاح الخطأ في هذين المكانين، وهذا هو الجزء السهل؛ أما الجزء الصعب فهو معرفة التكرار في المقام الأول.  هناك احتمال كبير أن يكون الشخص الذي يقوم بالتكرار والشخص الذي يقوم بالإصلاح مختلفين. إذا تمت إعادة صياغة المقطع بحيث يمكن مشاركته واستدعاؤه من المكانين بدلاً من ذلك، فلن تحتاج إلى إصلاح الخطأ إلا في هذا المكان الواحد.  يربط معظم الأشخاص بين DRY والترميز. ومع ذلك، قد يكون أكثر تقييدًا ويتعارض مع الفكرة الأصلية.  لقد تم صياغة هذا المبدأ بواسطة آندي هانت وديف توماس في كتابهما The Pragmatic Programmer. وقد طبقاه على نطاق واسع ليشمل مخططات قواعد البيانات وخطط الاختبار ونظام البناء وحتى الوثائق.  --  ويكيبيديا - لا تكرر نفسك  تسمح أنظمة تكوين الصوت بالتجفيف أو حتى تشجعه.  DRY في Apache APISIX  يوفر Apache APISIX تكوين DRY في مكانين.  المنبع الجاف  في سياق التجارة الإلكترونية، من المحتمل أن تبدأ رحلتك المبتدئة لتحديد مسار على Apache APISIX على النحو التالي:   routes: - id: 1 name: Catalog uri: /products* upstream: nodes: "catalog:8080": 1  إذا كنت على دراية بـ APISIX، فقد حددنا مسارًا إلى الكتالوج ضمن عنوان URI الخاص بـ   . ومع ذلك، هناك مشكلة: ربما تريد أن يتصفح العملاء المحتملون الكتالوج ولكنك تريد منع الأشخاص من إنشاء المنتجات أو حذفها أو تحديثها. ومع ذلك، يتطابق المسار مع كل طريقة HTTP افتراضيًا. /products  يجب أن نسمح فقط للمستخدمين المعتمدين بإدارة الكتالوج حتى يتمكن الجميع من تصفحه بحرية. لتنفيذ هذا النهج، نحتاج إلى تقسيم المسار إلى قسمين:   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] #1 uri: /products* upstream: #2 nodes: "catalog:8080": 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] #3 uri: /products* plugins: key-auth: ~ #4 upstream: #2 nodes: "catalog:8080": 1  تصفح المباريات  تم تكراره في المنبع!  إدارة المباريات  يمكن فقط للمستهلكين المعتمدين استخدام هذا المسار؛   هو أبسط مكون إضافي لهذا الغرض key-auth  لقد قمنا بإصلاح مشكلة الأمان بأبسط طريقة ممكنة: عن طريق النسخ واللصق. وبذلك، قمنا بتكرار القسم   . إذا احتجنا إلى تغيير الطوبولوجيا،   ، عن طريق إضافة أو إزالة العقد، فيجب علينا القيام بذلك في مكانين. وهذا يتعارض مع مبدأ DRY. upstream على سبيل المثال  في السيناريوهات الواقعية، وخاصة عندما تتضمن حاويات، لن تقوم بتنفيذ   من خلال إدراج   . بل يجب عليك بدلاً من ذلك تنفيذ   الديناميكي لاستيعاب تغييرات الطوبولوجيا. ومع ذلك، تظل النقطة قائمة عندما تحتاج إلى تغيير تكوين اكتشاف الخدمة أو تنفيذه. وبالتالي، تنطبق وجهة نظري على العقد واكتشاف الخدمة على حد سواء. upstream nodes اكتشاف الخدمة  إلى جانب تجريد   ، تقدم APISIX تجريدًا   لتنفيذ DRY. يمكننا إعادة كتابة المقطع أعلاه على النحو التالي: المسار علويًا   upstreams: - id: 1 #1 name: Catalog nodes: "catalog:8080": 1 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /products* upstream_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /products* upstream_id: 1 #2 plugins: key-auth: ~  قم بتعريف المنبع بالمعرف  1  أشر إليه في المسار  إذا حدث أي شيء في الطوبولوجيا، فيجب علينا تحديث التغيير فقط في   الفردي. المنبع  لاحظ أن تحديد   والإشارة إليه باستخدام   هما   . upstream upstream_id أمران متبادلان  تكوين البرنامج الإضافي DRY  منطقة أخرى حيث يمكن أن تساعدك APISIX في تجفيف تكوينك باستخدام تجريد المكونات   . تنفذ APISIX معظم الميزات، إن لم يكن كلها، من خلال المكونات الإضافية الإضافية  لنقم بتنفيذ   على واجهة برمجة التطبيقات الخاصة بنا. نحتاج إلى إعادة كتابة عنوان URL قبل إعادة توجيهه. إصدارات تعتمد على المسار   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1  قم بإزالة البادئة   قبل إعادة التوجيه /v1  كما هو الحال مع   أعلاه، يتم تكرار قسم   . يمكننا أيضًا حساب تكوين المكون الإضافي في كائن   مخصص. المقطع التالي له نفس التأثير مثل المقطع أعلاه: upstream plugins تكوين مكون إضافي   plugin_configs: - id: 1 #1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2  عامل تكوين البرنامج المساعد في كائن مخصص  ارجع إليه  ربما لاحظ القراء الأذكياء أنني أفتقد جزءًا من التكوين: فقد اختفى   بشكل غامض! في الواقع، قمت بإزالته من أجل الوضوح. auth-key  على عكس   والمعرف   ، لا يتعارض       . يمكننا إصلاح المشكلة عن طريق إضافة   المفقود فقط: upstream upstream_id plugins plugin_config_id المضمن مع بعضهما البعض plugin   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 plugins: key-auth: ~ #1  أصلحها!  بهذه الطريقة، يمكنك نقل التكوين المشترك إلى كائن   والاحتفاظ بتكوين محدد في المكان الذي ينطبق عليه. ولكن ماذا لو تم استخدام نفس المكون الإضافي بتكوينات مختلفة في   ومباشرة في   ؟   واضحة جدًا بشأن هذا الأمر: plugin_config plugin_config route الوثائق    >   >   >   >  Consumer Consumer Group Route Plugin Config Service  باختصار، تتغلب إعدادات   في   ما على   . كما تسمح لنا بتوفير متغير   لبرنامج   الإضافي في   وتعيينه فقط في مسار ما. سيجد APISIX المفتاح لكل   ويستخدمه! plugin route plugin_config_id apikey key-auth consumer consumer  خاتمة  لا يتعلق DRY بالكود فقط؛ بل يتعلق بإدارة البيانات بشكل عام. التكوين عبارة عن بيانات وبالتالي يقع تحت هذه المظلة العامة.  توفر APISIX خيارين لـ DRY: أحدهما للإصدار   -   ، والآخر للمكون   -   . الإصدارات الأعلى حصرية؛ تسمح المكونات الإضافية بالتجاوز. upstream upstream_id plugin plugin_config_id  يجب أن تساعدك كلتا الآليتين على تجفيف تكوينك وجعله أكثر قابلية للصيانة على المدى الطويل.   وللمضي قدمًا:   مبدأ عدم تكرار نفسك   أولوية دمج التكوين   نُشرت أصلاً في   في 1 سبتمبر 2024 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

تم إنتاج هذا الصوت باللغة الأصلية للقصة!

طويل جدا؛ ليقرأ

Make resilience your competitive advantage

كيفية تجفيف تكوين Apache APISIX الخاص بك

About Author

تعليقات

شنق العلامات

تم تقديم هذه المقالة في

Related Stories

How can AR, IoT, Blockchain and Chatbots redefine Customer Experience

Top 4 Hiring Trends for Mobile App Developers in 2018

Top 10 Software Consulting Company based on Clutch & Goodfirms Reviews

The shortage of women in tech

How can AR, IoT, Blockchain and Chatbots redefine Customer Experience

Top 4 Hiring Trends for Mobile App Developers in 2018

Top 10 Software Consulting Company based on Clutch & Goodfirms Reviews

The shortage of women in tech

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps