Melanjutkan bagian pertama artikel “IOT di mana Anda tidak menunggu. Pengembangan dan pengujian (bagian 1) ” tidak lama kemudian. Kali ini saya akan memberi tahu Anda apa arsitektur proyek itu dan penggaruk seperti apa yang kami injak ketika kami mulai menguji solusi kami.Penafian: tidak ada satu tong sampah pun yang dipukul dengan keras.
Arsitektur proyek
Kami mendapat proyek khas layanan mikro. Lapisan layanan microser dari "level bawah" menerima data dari perangkat dan sensor, menyimpannya di Kafka, setelah itu layanan microser yang berorientasi bisnis dapat bekerja dengan data yang diterima dari Kafka untuk menunjukkan kondisi perangkat saat ini, membangun analisis, dan menyempurnakan model mereka.
Kafka dalam proyek IoT menjadi sangat keren. Dibandingkan dengan sistem lain seperti RabbitMQ, Kafka memiliki beberapa keunggulan:- Bekerja dengan aliran : data mentah dari sensor dapat diproses untuk mendapatkan aliran. Dan dengan stream, Anda dapat dengan fleksibel mengkonfigurasi apa yang ingin Anda filter di dalamnya, dan streaming mudah dilakukan (buat stream data baru)
- : Kafka , , , . - , - , . , Kafka , . , , , .
Backend
Pertama, mari kita lihat pada backend yang akrab bagi kita, seluruh lapisan bisnis aplikasi dibangun di tumpukan Java dan Spring yang sama. Untuk menguji aplikasi layanan mikro dalam lingkungan nyata, kami menggunakan pustaka wadah uji. Ini memungkinkan Anda untuk dengan mudah menggunakan binding eksternal (Kafka, PostgreSQL, MongoDB, dll.) Di Docker.Pertama, kami menaikkan wadah yang diperlukan di Docker, meluncurkan aplikasi dan pada contoh nyata kami sudah menjalankan data uji.Tentang bagaimana tepatnya kita melakukan ini, saya berbicara secara detail di Heisenbug 2019 Piter dalam laporan "Wars Layanan Mikro: JUnit Episode 5 - TestContainers Strikes Back":Mari kita lihat contoh kecil bagaimana tampilannya. Layanan tingkat bawah mengambil data dari perangkat dan melemparkannya ke Kafka. Dan layanan Heat Map dari bagian bisnis mengambil data dari kafka dan membuat peta panas.
Mari kita uji menerima data dengan layanan Heat Map (via Kafka)@KafkaTestContainer
@SpringBootTest
class KafkaIntegrationTest {
@Autowired
private KafkaTemplate kafkaTemplate;
@Test
void sendTest() {
kafkaTemplate.send(TOPIC_NAME, MEASSAGE_BODY)
}
}
Kami sedang menulis uji SpringBoot integrasi reguler, namun, ini berbeda dalam gaya konfigurasi lingkungan pengujian berbasis anotasi. Anotasi @KafkaTestContainerdiperlukan untuk membesarkan Kafka. Untuk menggunakannya, Anda harus menghubungkan perpustakaan:pegas-uji-kafkaKetika aplikasi dimulai, Pegas dimulai dan wadah Kafka dimulai pada Docker. Kemudian dalam tes kita menggunakannya kafkaTemplate, menyuntikkannya ke dalam test case dan mengirimkan data ke Kafka untuk menguji logika pemrosesan data baru dari topik.Semua ini terjadi pada contoh Kafka normal, tidak ada opsi yang disematkan, tetapi hanya versi yang berputar dalam produksi.
Layanan Heat Map menggunakan MongoDB sebagai penyimpanan, dan tes untuk MongoDB terlihat serupa:@MongoDbDataTest
class SensorDataRecordServiceTest {
@Autowired
private SensorDataRecordRepository repository;
@Test
@MongoDataSet(value ="sensor_data.json")
void findSingle() {
var log = repository.findAllByDeviceId("001");
assertThat(log).hasSize(1);
...
}
}
Anotasi @MongoDbDataTestmeluncurkan MongoDB di Docker mirip dengan Kafka. Setelah aplikasi diluncurkan, kita bisa menggunakan repositori untuk bekerja dengan MongoDB.Untuk menggunakan fungsi ini dalam pengujian Anda, yang Anda perlukan hanyalah menghubungkan pustaka:spring-test-mongo.Ngomong-ngomong, ada banyak kegunaan lain di sana, misalnya, Anda dapat memuat basis data ke dalam database melalui anotasi sebelum menjalankan tes, @MongoDataSetseperti pada contoh di atas, atau menggunakan anotasi, @ExpectedMongoDataSetverifikasi bahwa setelah menyelesaikan test case di database, set data yang tepat yang kami harapkan telah muncul.Saya akan bercerita lebih banyak tentang bekerja dengan data uji di Heisenbug 2020 Piter , yang akan diadakan secara online 15-18 Juni.
Menguji hal-hal spesifik IoT
Jika bagian bisnis adalah backend biasa, maka bekerja dengan data dari perangkat berisi banyak garu dan spesifik yang terkait dengan perangkat keras.Anda memiliki perangkat, dan Anda harus memasangkannya. Untuk ini, Anda akan memerlukan dokumentasi. Itu baik ketika Anda memiliki sepotong besi dan dok di atasnya. Namun, semuanya dimulai dengan cara yang berbeda: hanya ada dokumentasi, dan perangkat masih dalam perjalanan. Kami merekam sebuah aplikasi kecil, yang secara teori seharusnya berhasil, tetapi begitu perangkat nyata tiba, harapan kami dihadapkan dengan kenyataan.Kami berpikir bahwa input akan berupa format biner, dan perangkat mulai memberi kami beberapa file XML. Dan dalam bentuk yang begitu sulit, aturan pertama untuk proyek IoT lahir:Jangan pernah percaya dokumentasinya!
Pada prinsipnya, data yang diterima dari perangkat kurang lebih jelas: Time- ini adalah cap waktu, DevEUI- pengidentifikasi perangkat, LrrLATdan LrrLON- koordinat.
Tapi apa itu payload_hex? Kami melihat 8 digit, apa yang ada di dalamnya? Apakah jarak ke tempat sampah, tegangan sensor, tingkat sinyal, sudut kemiringan, suhu, atau semua yang diambil bersamaan? Pada titik tertentu, kami berpikir bahwa pabrikan Cina dari perangkat ini mengetahui semacam pengarsipan Feng Shui dan mampu mengemas segala sesuatu yang mungkin dalam 8 digit. Tetapi jika Anda melihat di atas, Anda dapat melihat bahwa waktu ditulis dalam baris reguler dan mengandung bit 3 kali lebih banyak, yaitu byte jelas tidak ada yang disimpan. Akibatnya, ternyata khusus di firmware ini, setengah dari sensor di perangkat dimatikan, dan Anda harus menunggu firmware baru.Sementara mereka menunggu, kami membuat bangku tes di kantor, yang, pada kenyataannya, adalah kotak kardus biasa. Kami memasang perangkat ke sampulnya dan melemparkan barang kantor ke dalam kotak. Kami juga membutuhkan salinan uji mobil pengangkut, dan perannya dimainkan oleh mesin salah satu pengembang dalam proyek tersebut.Sekarang kami melihat di peta di mana kotak kardus berdiri, dan kami tahu ke mana pengembang pergi (spoiler: bekerja-rumah, dan pada hari Jumat malam tidak ada yang membatalkan bar).
Namun, sistem dengan bangku tes tidak bertahan lama, karena ada perbedaan besar dari wadah nyata. Sebagai contoh, jika kita berbicara tentang accelerometer, maka kita memutar kotak dari sisi ke sisi dan menerima bacaan dari sensor, dan semuanya tampak bekerja. Namun kenyataannya ada beberapa keterbatasan.
Dalam versi pertama perangkat, sudut tidak diukur dalam nilai absolut, tetapi dalam nilai relatif. Dan ketika kotak dimiringkan lebih dari delta yang diperbaiki pada firmware, sensor mulai bekerja secara salah atau bahkan tidak dapat memperbaiki belokan.
Tentu saja, semua kesalahan ini diperbaiki dalam proses, tetapi pada awalnya perbedaan antara kotak dan wadah membawa banyak masalah. Dan kami mengebor tangki dari semua sisi, sambil memutuskan bagaimana menempatkan sensor di dalam wadah, sehingga ketika mengangkat tangki dengan mobil pengangkut, kami secara akurat mencatat bahwa sampah dibongkar.Selain masalah dengan sudut kemiringan, pada awalnya kami tidak memperhitungkan apa sampah sebenarnya dalam wadah. Dan jika kita melempar polystyrene dan bantal ke dalam kotak itu, maka pada kenyataannya orang memasukkan semuanya ke dalam wadah, bahkan semen dan pasir. Dan sebagai hasilnya, sekali sensor menunjukkan bahwa wadah itu kosong, meskipun sebenarnya sudah penuh. Ternyata, seseorang selama perbaikan melemparkan bahan penyerap suara yang keren, yang meredam sinyal dari sensor.Pada titik ini, kami memutuskan untuk setuju dengan pemilik pusat bisnis di mana kantor berada untuk memasang sensor pada wadah sampahnya. Kami melengkapi situs di depan kantor, dan sejak saat itu kehidupan dan kehidupan sehari-hari pengembang proyek berubah secara dramatis. Biasanya pada awal hari kerja Anda ingin minum kopi, membaca berita, dan di sini Anda memiliki seluruh kaset penuh dengan sampah, secara harfiah:
Saat menguji sensor suhu, seperti dalam kasus accelerometer, kenyataan menghadirkan skenario baru. Nilai ambang untuk suhu cukup sulit untuk dipilih sehingga kita tahu pada waktunya sensor aktif, dan jangan mengucapkan selamat tinggal padanya. Misalnya, di musim panas, wadah memanaskan sangat banyak di bawah matahari, dan pengaturan suhu ambang terlalu rendah dipenuhi dengan pemberitahuan konstan dari sensor. Dan jika perangkat benar-benar terbakar, dan seseorang mulai memadamkannya, maka Anda perlu mempersiapkan tangki diisi dengan air ke atas, maka seseorang akan menjatuhkannya, dan mereka akan memadamkannya di lantai. Dalam skenario ini, sensor jelas tidak akan bertahan.Pada titik tertentu, firmware baru datang kepada kami (apakah Anda ingat kami menunggu?). Kami menggulungnya di sensor, dan protokol komunikasi dengan sensor pecah lagi. Selamat tinggal XML, dan tahan format biner lagi. Saya ingin berharap pada saat ini bahwa sekarang ini sesuai dengan dokumentasi, tetapi ... tidak!Oleh karena itu, aturan kedua: baca aturan pertama. Artinya - jangan pernah mempercayai dokumentasinya.
Apa yang bisa dilakukan? Misalnya, lakukan rekayasa terbalik: kita duduk dengan konsol, mengumpulkan data, memutar-mutar sensor, meletakkan sesuatu di depannya, mencoba mengidentifikasi pola. Jadi Anda dapat mengisolasi jarak, status wadah dan checksum. Namun, beberapa data sulit ditafsirkan, karena produsen perangkat China kami tampaknya menyukai sepeda. Dan untuk mengemas angka floating-point dalam format biner untuk menafsirkan sudut kemiringan, mereka memutuskan untuk mengambil dua byte dan membaginya dengan 35.
Dan dalam keseluruhan cerita ini, sangat membantu kami bahwa lapisan bawah layanan yang bekerja dengan perangkat diisolasi dari atas, dan semua data dituangkan melalui kafka, kontrak yang disetujui dan diamankan.Ini banyak membantu dalam hal pengembangan, karena jika level bawahnya pecah, maka kami diam-diam melihat layanan bisnis, karena kontraknya kaku di dalamnya. Oleh karena itu, aturan kedua ini untuk mengembangkan proyek IoT adalah mengisolasi layanan dan menggunakan kontrak.Laporan itu masih jauh lebih menarik: simulasi, pengujian beban, dan secara umum, saya akan menyarankan Anda untuk melihat laporan ini.
Pada bagian ketiga saya akan berbicara tentang model simulasi, tetap disini!