إنترنت الأشياء حيث لم تنتظر. التطوير والاختبار (الجزء 2)

استمرار الجزء الأول من مقالة "إنترنت الأشياء حيث لم تنتظر. التطوير والاختبار (الجزء 1) " لم يمض وقت طويل في المستقبل. هذه المرة سأخبرك ما هي بنية المشروع ونوع المدمة التي خطونا عليها عندما بدأنا في اختبار حلنا.

إخلاء المسؤولية: لم يتم إصابة أي سلة قمامة واحدة بشدة.



هندسة المشروع


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



ذهب كافكا في مشروع إنترنت الأشياء رائعًا جدًا. مقارنة بأنظمة أخرى مثل RabbitMQ ، تتمتع كافكا بالعديد من المزايا:

  • العمل مع التدفقات : يمكن معالجة البيانات الأولية من أجهزة الاستشعار للحصول على دفق. وباستخدام التدفقات ، يمكنك تكوين ما تريد تصفيته بمرونة ، ومن السهل إجراء الدفق (إنشاء تدفقات بيانات جديدة)
  • : Kafka , , , . - , - , . , Kafka , . , , , .

Backend


أولاً ، دعنا نلقي نظرة على الواجهة الخلفية المألوفة لنا ، فإن طبقة الأعمال الكاملة للتطبيق مبنية على نفس مجموعة Java و Spring. لاختبار تطبيقات الخدمات الصغيرة في بيئة حقيقية ، نستخدم مكتبة حاويات الاختبار. يسمح لك بسهولة نشر الارتباطات الخارجية (Kafka ، PostgreSQL ، MongoDB ، إلخ) في Docker.

أولاً ، نرفع الحاوية المطلوبة في Docker ، ونطلق التطبيق ، وفي الحالة الحقيقية ، نقوم بالفعل بتشغيل بيانات الاختبار.

حول كيفية القيام بذلك بالضبط ، تحدثت بالتفصيل في Heisenbug 2019 Piter في تقرير "Microservice Wars: JUnit الحلقة 5 - TestContainers Strikes Back":


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



دعونا نختبر تلقي البيانات باستخدام خدمة الخريطة الحرارية (عبر كافكا)

@KafkaTestContainer
@SpringBootTest
class KafkaIntegrationTest {

    @Autowired
    private KafkaTemplate kafkaTemplate;

    @Test
    void sendTest() {
        kafkaTemplate.send(TOPIC_NAME, MEASSAGE_BODY)

        //     
        //       
        //  
    }
}

نحن نكتب اختبار SpringBoot للتكامل المنتظم ، ومع ذلك ، فإنه يختلف في النمط القائم على التعليقات التوضيحية لتهيئة بيئة الاختبار. @KafkaTestContainerهناك حاجة إلى شرح لرفع كافكا. لاستخدامها ، تحتاج إلى توصيل المكتبة:

spring-test-kafka

عندما يبدأ التطبيق ، يبدأ Spring ويبدأ حاوية Kafka في Docker. ثم في الاختبار الذي نستخدمه kafkaTemplate، قم بحقنه في حالة الاختبار وأرسل البيانات إلى كافكا لاختبار منطق معالجة البيانات الجديدة من الموضوع.

كل هذا يحدث في مثيل كافكا العادي ، ولا توجد خيارات مضمنة ، ولكن فقط الإصدار الذي يدور في الإنتاج.



تستخدم خدمة خريطة التمثيل الحراري MongoDB كمخزن ، ويشبه اختبار MongoDB:

@MongoDbDataTest
class SensorDataRecordServiceTest {

    @Autowired
    private SensorDataRecordRepository repository;

    @Test
    @MongoDataSet(value ="sensor_data.json")
    void findSingle() {
        var log = repository.findAllByDeviceId("001");
        assertThat(log).hasSize(1);
        ...
    }
}

@MongoDbDataTestيطلق التعليق التوضيحي MongoDB في Docker على نحو مشابه لـ Kafka. بعد تشغيل التطبيق ، يمكننا استخدام المستودع للعمل مع MongoDB.

لاستخدام هذه الوظيفة في الاختبارات الخاصة بك ، كل ما تحتاجه هو توصيل المكتبة:

spring-test-mongo

بالمناسبة ، هناك العديد من الفوائد الأخرى هناك ، على سبيل المثال ، يمكنك تحميل قاعدة البيانات إلى قاعدة البيانات من خلال التعليق التوضيحي قبل تنفيذ الاختبار ، @MongoDataSetكما في المثال أعلاه ، أو باستخدام التعليق التوضيحي ، @ExpectedMongoDataSetتحقق من ظهور مجموعة البيانات الدقيقة التي نتوقعها بعد الانتهاء من حالة الاختبار في قاعدة البيانات.

سأخبرك بالمزيد حول العمل مع بيانات الاختبار في Heisenbug 2020 Piter ، التي ستعقد عبر الإنترنت في الفترة من 15 إلى 18 حزيران (يونيو).


اختبار الأشياء الخاصة بإنترنت الأشياء


إذا كان جزء العمل هو الواجهة الخلفية النموذجية ، فإن العمل مع البيانات من الأجهزة يحتوي على الكثير من المجاميع والتفاصيل المتعلقة بالأجهزة.

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

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

لا تصدق الوثائق!

من حيث المبدأ ، كانت البيانات المستلمة من الجهاز أكثر أو أقل وضوحًا: Time- هذا هو الطابع الزمني ، DevEUI- معرف الجهاز ، LrrLATو LrrLON- الإحداثيات.



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

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

الآن رأينا على الخريطة مكان صناديق الكرتون ، وعرفنا أين ذهب المطور (المفسد: منزل العمل ، وفي أمسيات الجمعة لم يقم أحد بإلغاء الشريط).



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



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



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

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

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



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


في مرحلة ما ، جاء إلينا برنامج ثابت جديد (هل تتذكر أننا كنا ننتظره؟). قمنا بتدويره على المستشعرات ، وانكسر بروتوكول الاتصال مع المستشعر مرة أخرى. وداعا XML ، ويعيش التنسيق الثنائي مرة أخرى. أتمنى في هذه اللحظة أن يتوافق الآن مع التوثيق ، ولكن ... لا!
لذلك القاعدة الثانية: اقرأ القاعدة الأولى. هذا - لا تثق أبدًا بالوثائق.
ماذا يمكن ان يفعل؟ على سبيل المثال ، افعل الهندسة العكسية: نجلس مع وحدة التحكم ، نجمع البيانات ، نلف المستشعر ، نضع شيئًا أمامه ، نحاول تحديد الأنماط. حتى تتمكن من عزل المسافة وحالة الحاوية والمجموع الاختباري. ومع ذلك ، كان من الصعب تفسير بعض البيانات ، لأن مصنعي الأجهزة الصينيين لدينا يحبون الدراجات على ما يبدو. ولحزم رقم فاصلة عائمة بتنسيق ثنائي لتفسير زاوية الميل ، قرروا أخذ وحدتي بايت وقسمة على 35.



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

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

في الجزء الثالث سأتحدث عن نموذج محاكاة ، ترقبوا!

All Articles