يستكشف هذا المقال قرارنا بالابتعاد عن البنية التفاعلية في مشروعنا البرمجي. سوف نتعمق في المبادئ الأساسية للأنظمة التفاعلية، وفوائد الإدخال/الإخراج غير المحظورة، والتحديات التي واجهناها مع النهج التفاعلي.
رد الفعل يشمل مجموعة من المبادئ والإرشادات التي تهدف إلى بناء أنظمة وتطبيقات موزعة سريعة الاستجابة، وتتميز بـ:
إحدى الفوائد الرئيسية للأنظمة التفاعلية هي استخدامها للإدخال/الإخراج غير المحظور. يتجنب هذا الأسلوب حظر سلاسل الرسائل أثناء عمليات الإدخال/الإخراج، مما يسمح لخيط واحد بمعالجة طلبات متعددة في نفس الوقت. يمكن أن يؤدي ذلك إلى تحسين كفاءة النظام بشكل كبير مقارنةً بحظر الإدخال/الإخراج التقليدي.
في تعدد العمليات التقليدية، تشكل عمليات الحظر تحديات كبيرة في تحسين الأنظمة (الشكل 1). التطبيقات الجشعة التي تستهلك ذاكرة زائدة تكون غير فعالة وتعاقب التطبيقات الأخرى، وغالبًا ما تتطلب طلبات للحصول على موارد إضافية مثل الذاكرة أو وحدة المعالجة المركزية أو الأجهزة الافتراضية الأكبر حجمًا.
الشكل 1 - الخيوط المتعددة التقليدية
تعد عمليات الإدخال/الإخراج جزءًا لا يتجزأ من الأنظمة الحديثة، وتعد إدارتها بكفاءة أمرًا بالغ الأهمية لمنع السلوك الجشع. تستخدم الأنظمة التفاعلية عمليات الإدخال/الإخراج غير المحظورة، مما يتيح لعدد قليل من سلاسل عمليات نظام التشغيل التعامل مع العديد من عمليات الإدخال/الإخراج المتزامنة.
على الرغم من أن عمليات الإدخال/الإخراج غير المحظورة توفر فوائد كبيرة، إلا أنها تقدم نموذج تنفيذ جديدًا متميزًا عن الأطر التقليدية. ظهرت البرمجة التفاعلية لمعالجة هذه المشكلة، حيث إنها تخفف من عدم كفاءة مؤشرات ترابط النظام الأساسي أثناء عمليات الحظر (الشكل 2).
الشكل 2 - حلقة الحدث التفاعلي
يستفيد Quarkus من محرك تفاعلي مدعوم من Eclipse Vert.x وNetty، مما يسهل تفاعلات الإدخال/الإخراج غير المحظورة. Mutiny، الأسلوب المفضل لكتابة التعليمات البرمجية التفاعلية باستخدام Quarkus، يتبنى نموذجًا يحركه الحدث، حيث يتم تشغيل ردود الفعل من خلال الأحداث المستلمة.
يقدم Mutiny نوعين يعتمدان على الأحداث والكسل:
على الرغم من أن الأنظمة التفاعلية توفر فوائد، إلا أننا واجهنا العديد من التحديات أثناء التطوير:
"في الواقع، فإن نسبة الوقت المستغرق في القراءة مقابل الكتابة تزيد كثيرًا عن 10 إلى 1. نحن نقرأ باستمرار التعليمات البرمجية القديمة كجزء من الجهد المبذول لكتابة تعليمات برمجية جديدة. ...[وبالتالي،] تسهيل القراءة يجعل من السهل من الأسهل الكتابة."
― روبرت سي. مارتن، الكود النظيف: دليل لمهارة البرمجيات الرشيقة
إليك مثال على التعليمات البرمجية التفاعلية باستخدام 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 الحاجة إلى اتباع نهج تفاعلي في العديد من الحالات.
"مشروع لوم سيقضي على البرمجة التفاعلية"
―براين جويتز
في الختام، قرارنا بالابتعاد عن أسلوب الهندسة التفاعلية هو نهج عملي لقابلية صيانة مشروعنا على المدى الطويل. في حين أن الأنظمة التفاعلية توفر فوائد محتملة، فإن التحديات التي قدمتها لفريقنا تفوق تلك المزايا في سياقنا المحدد.
الأهم من ذلك أن هذا التحول لم يؤثر على الأداء. هذه نتيجة إيجابية، لأنها توضح أن البنية غير التفاعلية (الحتمية) جيدة التصميم يمكنها تقديم الأداء اللازم دون التعقيد المرتبط بالبنية التفاعلية في حالتنا.
بينما نتطلع إلى المستقبل، يظل التركيز على بناء قاعدة تعليمات برمجية ليست وظيفية فحسب، بل يسهل أيضًا فهمها وصيانتها للمطورين من جميع مستويات الخبرة. وهذا لا يقلل من وقت التطوير فحسب، بل يعزز أيضًا التعاون بشكل أفضل ومشاركة المعرفة داخل الفريق.
في الرسم البياني أدناه، يمثل المحور السيني التعقيد المتزايد لقاعدة التعليمات البرمجية الخاصة بنا أثناء تطورها، بينما يوضح المحور ص الوقت اللازم لهذه التغييرات التطويرية.
تنصل: جميع الموارد المقدمة هي جزئيًا من الإنترنت. إذا كان هناك أي انتهاك لحقوق الطبع والنشر الخاصة بك أو الحقوق والمصالح الأخرى، فيرجى توضيح الأسباب التفصيلية وتقديم دليل على حقوق الطبع والنشر أو الحقوق والمصالح ثم إرسالها إلى البريد الإلكتروني: [email protected]. سوف نتعامل مع الأمر لك في أقرب وقت ممكن.
Copyright© 2022 湘ICP备2022001581号-3