من أحد المترجمين: نظرًا لأن Spring Spring هو أحد الأطر الرئيسية التي نبني عليها CUBA ، فإن الأخبار المتعلقة بميزات Spring الجديدة لا تمر دون أن نلاحظها من قبل. التهيئة الكسلية هي إحدى الطرق لتقليل وقت التمهيد الأول للتطبيق ، والذي يعتبر في عصرنا الاستخدام الواسع النطاق للخدمات الدقيقة مقياسًا مهمًا. بالنسبة لأولئك الذين يفضلون قراءة مشاهدة مقاطع الفيديو ، هناك عرض تقديمي مدته 10 دقائق من قبل Josh Long حول موضوع المقال.
يضيف الإصدار الأول الذي تم الإعلان عنه مؤخرًا لـ Spring Boot 2.2 دعمًا للتهيئة البطيئة. في هذه المقالة ، سننظر في وظائف جديدة ونوضح كيفية تمكينها.
ماذا يعني أن تكون كسول؟
يدعم Spring Framework التهيئة البطيئة منذ انتقال الكود المصدري الخاص به إلى أحد عشر عامًا مضت. افتراضيًا ، عند تحديث سياق التطبيق ، يتم إعادة إنشاء كل حبة ويتم تنفيذ التبعيات الخاصة بها. في المقابل ، إذا تم تكوين صندوق للتهيئة البطيئة ، فلن يتم إنشاؤه ولن يتم إيقاف التبعيات الخاصة به حتى يكون ذلك ضروريًا.
تمكين التهيئة البطيئة
في أي إصدار من Spring Boot ، من الممكن تمكين التهيئة البطيئة ، إذا كنت لا تمانع في الحصول على يديك متسخة مع BeanFactoryPostProcessor . يعمل Spring Boot 2.2 ببساطة على تبسيط هذه العملية عن طريق إدخال خاصية جديدة - spring.main.lazy-initialization (هناك أيضًا طرق مكافئة في SpringApplication و SpringApplicationBuilder ). عندما يتم تعيين هذه الخاصية على " true ، سيتم تكوين حبوب التطبيق لاستخدام التهيئة البطيئة.
فوائد التهيئة البطيئة
يمكن أن يقلل التهيئة البطيئة بشكل كبير من وقت بدء التطبيق الخاص بك ، حيث يتم في هذه المرحلة تحميل عدد أقل من الفئات وإنشاء عدد أقل من الصناديق. على سبيل المثال ، عادةً ما يبدأ تطبيق ويب صغير يستخدم Actuator و Spring Security 2.5 ثانية. ومع التهيئة البطيئة ، تستغرق هذه العملية ثانيتين. ستختلف قيم التسارع الدقيق من تطبيق إلى آخر ، اعتمادًا على هيكل الرسم البياني التبعية للحاوية.
ملاحظة المترجم: قمت بتشغيل هذا المثال ، حيث كتبت Spring Boot 2.2 في التبعيات ، ووقت البدء مع التهيئة البطيئة كان 3 ثوانٍ ، وبدون ذلك 4. أعتقد أنه في التطبيقات الأكثر خطورة ، حقق مكسبًا كبيرًا في وقت البدء بسبب استخدام التهيئة البطيئة لن نرى. التحديثات: بناءً على نصيحة alek_sys ، تم تعطيل التحقق من مخطط قاعدة البيانات وتحديثه وتشغيل تهيئة JPA البطيئة لكلا الحالتين - لقد تحولت إلى 2.7 و 3.7 ثانية قبل ظهور Started WebApplication in...
يوفر Spring Boot DevTools تسارعًا كبيرًا في التطوير. بدلاً من إعادة تشغيل JVM والتطبيق في كل مرة تقوم فيها بتغيير شيء ما ، تقوم DevTools بـ "إعادة تشغيل ساخنة" للتطبيق في نفس JVM. من الميزات المهمة لعملية إعادة التشغيل هذه أنها تمنح JIT الفرصة لتحسين الكود الذي يتم تنفيذه عند بدء تشغيل التطبيق. بعد إعادة تشغيل عدة مرات ، يقل الوقت الأولي البالغ 2.5 ثانية بحوالي 80٪ إلى 500 مللي ثانية. مع تهيئة كسول ، الأمور أفضل. تعيين خاصية spring.main.lazy-initialization يُظهر وقت إعادة التشغيل مباشرة في IDE يساوي 400 مللي ثانية.
الجانب الآخر من التهيئة البطيئة
كما هو موضح أعلاه ، يمكن أن يؤدي تضمين التهيئة البطيئة إلى تقليل وقت تشغيل التطبيق بشكل خطير. وربما سيكون لديك رغبة لا تقاوم لاستخدام هذا باستمرار ، أو على الأقل سوف تتساءل لماذا لم يتم تمكين التهيئة البطيئة افتراضيًا. هناك العديد من الآثار السلبية المحتملة التي من الأفضل توضيحها على الفور.
حقيقة أن الطبقات لم يتم تحميلها ولا يتم إنشاء صناديق حتى تكون هناك حاجة إليها ، يمكن أن تخفي المشاكل التي كان من الممكن تحديدها في وقت مبكر من مرحلة تشغيل التطبيق. على سبيل المثال ، قد يكون الافتقار إلى الفئة المطلوبة أو تجاوز سعة الذاكرة أو خطأ مقترن بالتكوين الخاطئ.
في تطبيقات الويب ، يمكن أن تزيد التكوينات البطيئة من زمن انتقال طلبات HTTP التي تسبب تهيئة حاوية. هذا هو عادةً الطلب الأول ، ولكن قد يكون هناك تأثيرات إضافية غير مرغوب فيها تؤثر على موازنة التحميل أو القياس التلقائي.
هل هذا شيء مدرج؟
إذا لم تكن متأكدًا من تأثير التهيئة البطيئة بالضبط على تطبيقك أو إذا كنت تريد التحقق من أن الجوانب الأخرى من الإطار مناسبة لك وتفعل ما تحتاج إليه ، فسيكون من المفيد لك استخدام مصحح أخطاء لهذا الغرض. من خلال تعيين نقطة توقف على مُنشئ bin ، يمكنك أن ترى في اللحظة التي تتم فيها تهيئة الحاوية بالضبط. على سبيل المثال ، في تطبيق ويب تمت كتابته في Spring Boot وتمكين التهيئة البطيئة ، يمكنك ملاحظة أن @Controller التي تحمل علامة توضيحية @Controller لا @Controller إنشاؤها حتى يتم إرسال أول طلب إلى DispatcerServlet Spring MVC أو إلى DispatchHandler Spring WebFlux.
متى يتم تشغيل التهيئة البطيئة؟
كما رأينا أعلاه ، فإن التهيئة البطيئة تقدم تحسينات ملحوظة أثناء تشغيل التطبيق ، ولكن هناك أيضًا جوانب سلبية ، لذلك تحتاج إلى استخدام هذه الميزة بعناية فائقة.
أحد المجالات التي يمكن أن يؤدي فيها التهيئة البطيئة إلى توزيع الأرباح (بدون أي تكاليف إضافية تقريبًا) هو عملية تطوير التطبيق. أثناء قيامك بكتابة تطبيق ما ، يمكن لوقت إعادة التشغيل المخفض الذي توفره التهيئة البطيئة بالاقتران مع DevTools أن يوفر عليك الكثير من الوقت.
في أي مكان آخر يمكنك الحصول على فوائد استخدام التهيئة البطيئة - وهذا في اختبارات التكامل. قد تستخدم بالفعل اختبارات "التقطيع" لتقليل وقت التنفيذ عن طريق الحد من عدد الفاصوليا التي تم تهيئتها في بعض أنواع الاختبارات. التهيئة الكسولة توفر فرصة بديلة لتحقيق نفس النتيجة. إذا كنت في وضع غير صحيح لتغيير بنية التطبيق لاختبارات "التقطيع" ، أو في حالة اختباراتك المحددة ، لا يوجد "تقطيع" مناسب ، ثم سيؤدي تضمين التهيئة البطيئة إلى قصر عدد الصناديق على تلك التي يتم استخدامها في الاختبار فقط. سيؤدي ذلك إلى تقليل وقت تنفيذ الاختبار ، خاصة إذا كانت تعمل في بيئة معزولة أثناء التطوير.
تشغيل التهيئة البطيئة على همز الماضي. وإذا قررت القيام بذلك ، فافعل ذلك بحذر. بالنسبة لتطبيقات الويب ، يمكن لمدير الحاوية الاعتماد على نقطة الدخول /health ، والتي عادة ما تستجيب بسرعة إلى حد ما ، ولكن ضع في اعتبارك أن المكالمات الأولى قد تستغرق وقتًا أطول من المعتاد. يجب أيضًا أن تتذكر حجم الذاكرة المخصص لـ JVM بحيث لا تواجه تجاوز السعة عند تهيئة كافة المكونات.