"إذا أراد العامل أن يؤدي عمله بشكل جيد، فعليه أولاً أن يشحذ أدواته." - كونفوشيوس، "مختارات كونفوشيوس. لو لينجونج"
الصفحة الأمامية > برمجة > لماذا قمنا بتجاهل بنية الأنظمة التفاعلية من الكود الخاص بنا؟

لماذا قمنا بتجاهل بنية الأنظمة التفاعلية من الكود الخاص بنا؟

تم النشر بتاريخ 2024-09-02
تصفح:517

يستكشف هذا المقال قرارنا بالابتعاد عن البنية التفاعلية في مشروعنا البرمجي. سوف نتعمق في المبادئ الأساسية للأنظمة التفاعلية، وفوائد الإدخال/الإخراج غير المحظورة، والتحديات التي واجهناها مع النهج التفاعلي.

فهم أسلوب العمارة التفاعلية

رد الفعل يشمل مجموعة من المبادئ والإرشادات التي تهدف إلى بناء أنظمة وتطبيقات موزعة سريعة الاستجابة، وتتميز بـ:

  1. الاستجابة: القدرة على التعامل مع الطلبات بسرعة، حتى في ظل الأحمال الثقيلة.
  2. المرونة: القدرة على التعافي من حالات الفشل بأقل وقت توقف.
  3. المرونة: يمكن التكيف مع أعباء العمل المتغيرة عن طريق توسيع نطاق الموارد وفقًا لذلك.
  4. تعتمد على الرسائل: تستخدم الرسائل غير المتزامنة لتعزيز التسامح مع الأخطاء وفصل المكونات.

إحدى الفوائد الرئيسية للأنظمة التفاعلية هي استخدامها للإدخال/الإخراج غير المحظور. يتجنب هذا الأسلوب حظر سلاسل الرسائل أثناء عمليات الإدخال/الإخراج، مما يسمح لخيط واحد بمعالجة طلبات متعددة في نفس الوقت. يمكن أن يؤدي ذلك إلى تحسين كفاءة النظام بشكل كبير مقارنةً بحظر الإدخال/الإخراج التقليدي.
في تعدد العمليات التقليدية، تشكل عمليات الحظر تحديات كبيرة في تحسين الأنظمة (الشكل 1). التطبيقات الجشعة التي تستهلك ذاكرة زائدة تكون غير فعالة وتعاقب التطبيقات الأخرى، وغالبًا ما تتطلب طلبات للحصول على موارد إضافية مثل الذاكرة أو وحدة المعالجة المركزية أو الأجهزة الافتراضية الأكبر حجمًا.

Why we discarded Reactive systems architecture from our code?

الشكل 1 - الخيوط المتعددة التقليدية


تعد عمليات الإدخال/الإخراج جزءًا لا يتجزأ من الأنظمة الحديثة، وتعد إدارتها بكفاءة أمرًا بالغ الأهمية لمنع السلوك الجشع. تستخدم الأنظمة التفاعلية عمليات الإدخال/الإخراج غير المحظورة، مما يتيح لعدد قليل من سلاسل عمليات نظام التشغيل التعامل مع العديد من عمليات الإدخال/الإخراج المتزامنة.

نموذج التنفيذ التفاعلي

على الرغم من أن عمليات الإدخال/الإخراج غير المحظورة توفر فوائد كبيرة، إلا أنها تقدم نموذج تنفيذ جديدًا متميزًا عن الأطر التقليدية. ظهرت البرمجة التفاعلية لمعالجة هذه المشكلة، حيث إنها تخفف من عدم كفاءة مؤشرات ترابط النظام الأساسي أثناء عمليات الحظر (الشكل 2).

Why we discarded Reactive systems architecture from our code?

الشكل 2 - حلقة الحدث التفاعلي


كواركوس ورد الفعل

يستفيد Quarkus من محرك تفاعلي مدعوم من Eclipse Vert.x وNetty، مما يسهل تفاعلات الإدخال/الإخراج غير المحظورة. Mutiny، الأسلوب المفضل لكتابة التعليمات البرمجية التفاعلية باستخدام Quarkus، يتبنى نموذجًا يحركه الحدث، حيث يتم تشغيل ردود الفعل من خلال الأحداث المستلمة.

يقدم Mutiny نوعين يعتمدان على الأحداث والكسل:

  1. Uni: يصدر حدثًا واحدًا (عنصرًا أو فشلًا)، مناسبًا لتمثيل الإجراءات غير المتزامنة بنتيجة صفر أو واحدة.
  2. متعدد: يُصدر أحداثًا متعددة (n من العناصر، أو فشل واحد، أو إكمال واحد)، مما يمثل تدفقات من العناصر، من المحتمل أن تكون غير محدودة.

التحديات مع رد الفعل

على الرغم من أن الأنظمة التفاعلية توفر فوائد، إلا أننا واجهنا العديد من التحديات أثناء التطوير:

  • التحول النموذجي: تتطلب البرمجة التفاعلية تحولًا أساسيًا في عقليات المطورين، وهو ما قد يمثل تحديًا، خاصة بالنسبة للمطورين المعتادين على البرمجة الحتمية. على عكس الأدوات المساعدة مثل Streams API، يتطلب النهج التفاعلي إصلاحًا شاملاً للعقلية.
  • سهولة قراءة التعليمات البرمجية وفهمها: تشكل التعليمات البرمجية التفاعلية صعوبات بالنسبة للمطورين الجدد لفهمها، مما يؤدي إلى زيادة الوقت المستغرق في فك رموزها وفهمها. التعقيد الذي أدخلته النماذج التفاعلية يفاقم هذه المشكلة.

"في الواقع، فإن نسبة الوقت المستغرق في القراءة مقابل الكتابة تزيد كثيرًا عن 10 إلى 1. نحن نقرأ باستمرار التعليمات البرمجية القديمة كجزء من الجهد المبذول لكتابة تعليمات برمجية جديدة. ...[وبالتالي،] تسهيل القراءة يجعل من السهل من الأسهل الكتابة."
روبرت سي. مارتن، الكود النظيف: دليل لمهارة البرمجيات الرشيقة

  • تحديات التصحيح: ثبت أن تصحيح أخطاء التعليمات البرمجية التفاعلية يكاد يكون مستحيلًا باستخدام مصححات أخطاء IDE القياسية نظرًا لتغليف lambdas لمعظم التعليمات البرمجية. بالإضافة إلى ذلك، يؤدي فقدان تتبعات المكدس ذات المعنى أثناء الاستثناءات إلى عرقلة جهود تصحيح الأخطاء. زيادة جهود التطوير والاختبار: يمكن أن يؤدي التعقيد المتأصل في التعليمات البرمجية التفاعلية إلى دورات تطوير أطول بسبب الوقت اللازم للكتابة والتعديل والاختبار.

إليك مثال على التعليمات البرمجية التفاعلية باستخدام Mutiny لتوضيح التعقيد:

Multi.createFrom().ticks().every(Duration.ofSeconds(15))
    .onItem().invoke(() - > Multi.createFrom().iterable(configs())
    .onItem().transform(configuration - > {
  try {
    return Tuple2.of(openAPIConfiguration,
        RestClientBuilder.newBuilder()
            .baseUrl(new URL(configuration.url()))
            .build(MyReactiveRestClient.class)
            .getAPIResponse());

  } catch (MalformedURLException e) {
    log.error("Unable to create url");

  }
  return null;
}).collect().asList().toMulti().onItem().transformToMultiAndConcatenate(tuples - > {

  AtomicInteger callbackCount = new AtomicInteger();
  return Multi.createFrom().emitter(emitter - > Multi.createFrom().iterable(tuples)
      .subscribe().with(tuple - >
          tuple.getItem2().subscribe().with(response - > {
              emitter.emit(callbackCount.incrementAndGet());

  if (callbackCount.get() == tuples.size()) {
    emitter.complete();
  }
                    })
                ));

}).subscribe().with(s - > {},
Throwable::printStackTrace, () - > doSomethingUponComplete()))
    .subscribe().with(aLong - > log.info("Tic Tac with iteration: "   aLong));

توقعات المستقبل-مشروع المنوال وما بعده

يعد Project Loom، وهو تطور حديث في نظام Java البيئي، بتخفيف المشكلات المرتبطة بعمليات الحظر. من خلال تمكين إنشاء الآلاف من سلاسل المحادثات الافتراضية دون إجراء تغييرات على الأجهزة، من المحتمل أن يلغي Project Loom الحاجة إلى اتباع نهج تفاعلي في العديد من الحالات.

"مشروع لوم سيقضي على البرمجة التفاعلية"
براين جويتز

خاتمة

في الختام، قرارنا بالابتعاد عن أسلوب الهندسة التفاعلية هو نهج عملي لقابلية صيانة مشروعنا على المدى الطويل. في حين أن الأنظمة التفاعلية توفر فوائد محتملة، فإن التحديات التي قدمتها لفريقنا تفوق تلك المزايا في سياقنا المحدد.

الأهم من ذلك أن هذا التحول لم يؤثر على الأداء. هذه نتيجة إيجابية، لأنها توضح أن البنية غير التفاعلية (الحتمية) جيدة التصميم يمكنها تقديم الأداء اللازم دون التعقيد المرتبط بالبنية التفاعلية في حالتنا.

بينما نتطلع إلى المستقبل، يظل التركيز على بناء قاعدة تعليمات برمجية ليست وظيفية فحسب، بل يسهل أيضًا فهمها وصيانتها للمطورين من جميع مستويات الخبرة. وهذا لا يقلل من وقت التطوير فحسب، بل يعزز أيضًا التعاون بشكل أفضل ومشاركة المعرفة داخل الفريق.

في الرسم البياني أدناه، يمثل المحور السيني التعقيد المتزايد لقاعدة التعليمات البرمجية الخاصة بنا أثناء تطورها، بينما يوضح المحور ص الوقت اللازم لهذه التغييرات التطويرية.

Why we discarded Reactive systems architecture from our code?

بيان الافراج تم إعادة نشر هذه المقالة على: https://dev.to/yanev/why-we-discarded-reactive-systems-architecture-from-our-code-19ni?1 إذا كان هناك أي انتهاك، يرجى الاتصال بـ [email protected] لحذفه
أحدث البرنامج التعليمي أكثر>

تنصل: جميع الموارد المقدمة هي جزئيًا من الإنترنت. إذا كان هناك أي انتهاك لحقوق الطبع والنشر الخاصة بك أو الحقوق والمصالح الأخرى، فيرجى توضيح الأسباب التفصيلية وتقديم دليل على حقوق الطبع والنشر أو الحقوق والمصالح ثم إرسالها إلى البريد الإلكتروني: [email protected]. سوف نتعامل مع الأمر لك في أقرب وقت ممكن.

Copyright© 2022 湘ICP备2022001581号-3