Artikel ini menyertakan daftar item yang harus Anda pertimbangkan saat memindahkan solusi IoT ke lingkungan produksi.
Menggunakan stempel penyebaran
Stempel adalah unit terpisah dari komponen solusi inti yang mendukung sejumlah perangkat yang ditentukan. Setiap salinan disebut stempel. atau unit skala. Misalnya, stempel mungkin terdiri dari populasi perangkat yang ditetapkan, Azure IoT Hub, Event Hub atau titik akhir perutean lainnya, dan komponen pemrosesan. Setiap stempel mendukung populasi perangkat yang ditentukan. Anda memilih jumlah maksimum perangkat yang dapat ditampung oleh stempel. Seiring bertambahnya populasi perangkat, Anda menambahkan instans stempel daripada secara mandiri meningkatkan berbagai bagian solusi.
Daripada menambahkan stempel, Anda memindahkan satu instans solusi IoT ke produksi, Anda mungkin mengalami batasan berikut:
Batas skala: Instans tunggal Anda dapat mengalami batas penskalaan. Misalnya, solusi Anda mungkin menggunakan layanan yang memiliki batasan jumlah koneksi masuk, nama host, soket TCP, atau sumber daya lainnya.
Penskalaan atau biaya non-linier: Komponen solusi Anda mungkin tidak menskalakan secara linier dengan jumlah permintaan yang dibuat atau jumlah data yang diserap. Sebaliknya, untuk beberapa komponen, mungkin ada penurunan performa atau peningkatan biaya setelah ambang batas terpenuhi. Menaikkan skala dengan lebih banyak kapasitas mungkin bukan strategi yang baik seperti meningkatkan dengan menambahkan stempel.
Pemisahan Pelanggan: Anda mungkin perlu mengisolasi data pelanggan tertentu dari data pelanggan lain. Demikian pula, Anda mungkin memiliki beberapa pelanggan yang memerlukan lebih banyak sumber daya sistem untuk diservis daripada yang lain, dan pertimbangkan untuk mengelompokkannya pada stempel yang berbeda.
Instans tunggal dan multi-penyewa: Anda mungkin memiliki beberapa pelanggan besar yang membutuhkan instans independen mereka sendiri untuk solusi Anda. Anda mungkin juga memiliki kumpulan pelanggan yang lebih kecil yang dapat berbagi penyebaran multi-penyewa.
Persyaratan penyebaran yang kompleks: Anda mungkin perlu menyebarkan pembaruan ke layanan Anda dengan cara yang terkendali dan menyebarkan ke stempel yang berbeda pada waktu yang berbeda.
Frekuensi pembaruan: Anda mungkin memiliki beberapa pelanggan yang toleran untuk sering memperbarui sistem Anda, sementara yang lain mungkin menghindari risiko dan menginginkan pembaruan yang jarang pada layanan Anda.
Pembatasan geografis atau geopolitik: Untuk mengurangi latensi atau mematuhi persyaratan kedaulatan data, Anda dapat menyebarkan beberapa pelanggan Anda ke wilayah tertentu.
Untuk menghindari masalah sebelumnya, pertimbangkan untuk mengelompokkan layanan Anda menjadi beberapa stempel. Stempel beroperasi secara independen satu sama lain dan dapat disebarkan dan diperbarui secara independen. Satu wilayah geografis dapat berisi satu stempel, atau mungkin berisi beberapa stempel untuk memungkinkan peluasan skala horizontal di dalam wilayah tersebut. Setiap stempel berisi subset pelanggan Anda.
Menggunakan back-off ketika terjadi gangguan sementara
Semua aplikasi yang berkomunikasi dengan layanan dan sumber daya jarak jauh harus peka terhadap kesalahan sementara. Hal ini terutama berlaku untuk aplikasi yang berjalan di cloud, di mana sifat lingkungan dan konektivitas melalui internet berarti jenis kesalahan ini cenderung lebih sering ditemui. Kesalahan sementara meliputi:
- Hilangnya sesaat konektivitas jaringan ke komponen dan layanan
- Tidak tersedianya layanan untuk sementara
- Batas waktu yang muncul saat layanan sibuk
- Tabrakan yang disebabkan ketika perangkat mentransmisikan secara bersamaan
Kesalahan-kesalahan ini seringkali dapat terselesaikan dengan sendirinya, dan jika tindakan diulang setelah penundaan yang sesuai, kemungkinan akan berhasil. Namun, menentukan interval yang tepat antara percobaan ulang adalah sulit. Strategi tipikal menggunakan jenis interval coba lagi berikut:
- Back-off eksponensial. Aplikasi menunggu beberapa saat sebelum percobaan ulang pertama, dan kemudian secara eksponensial meningkatkan waktu antara setiap percobaan ulang berikutnya. Misalnya, aplikasi mungkin mencoba lagi operasi setelah 3 detik, 12 detik, 30 detik, dan seterusnya.
- Interval reguler. Aplikasi menunggu periode waktu yang sama antara setiap upaya. Misalnya, mungkin mencoba lagi operasi setiap 3 detik.
- Coba lagi segera. Terkadang kesalahan sementara berlangsung singkat, mungkin karena kejadian seperti tabrakan paket jaringan atau lonjakan komponen perangkat keras. Dalam hal ini, mencoba kembali operasi segera adalah tepat karena mungkin berhasil jika kesalahan telah dibersihkan dalam waktu yang dibutuhkan aplikasi untuk merakit dan mengirim permintaan berikutnya. Namun, tidak boleh ada lebih dari satu upaya percobaan ulang langsung, dan Anda harus beralih ke strategi alternatif, seperti tindakan back-off atau fallback eksponensial, jika percobaan ulang langsung gagal.
- Pengacakan. Salah satu dari strategi percobaan ulang sebelumnya dapat menyertakan elemen pengacakan untuk mencegah beberapa instans klien mengirimkan upaya percobaan ulang berikutnya pada waktu yang sama.
Hindari juga anti-pola berikut:
- Implementasi tidak boleh menyertakan lapisan duplikat kode coba lagi.
- Jangan pernah menerapkan mekanisme coba lagi tanpa akhir.
- Jangan pernah melakukan percobaan ulang langsung lebih dari sekali.
- Hindari menggunakan interval coba lagi yang teratur.
- Cegah beberapa instans dari klien yang sama, atau beberapa contoh klien yang berbeda, dari mengirim percobaan ulang pada saat yang sama.
Menggunakan provisi zero-touch
Pembekalan adalah tindakan mendaftarkan perangkat ke Azure IoT Hub. Pembekalan membuat IoT Hub mengetahui perangkat dan mekanisme pengesahan yang digunakan perangkat. Anda dapat menggunakan Azure IoT Hub Device Provisioning Service (DPS) atau menyediakan secara langsung melalui IoT Hub Registry Manager API. Penggunaan DPS memberikan manfaat pengikatan terlambat, yang memungkinkan penghapusan dan pembekalan ulang perangkat lapangan ke IoT Hub tanpa mengubah perangkat lunak perangkat.
Contoh berikut menunjukkan cara menerapkan alur kerja transisi lingkungan pengujian-ke-produksi menggunakan DPS.
- Pengembang solusi menautkan cloud IoT Uji dan Produksi ke layanan pembekalan.
- Perangkat menerapkan protokol DPS untuk menemukan IoT Hub, jika tidak lagi disediakan. Perangkat tersebut awalnya dibekalkan untuk lingkungan Test.
- Karena perangkat tersebut terdaftar di lingkungan Pengujian, perangkat akan terhubung di sana dan pengujian akan terjadi.
- Pengembang membekali ulang perangkat tersebut ke lingkungan Produksi dan menghapusnya dari hub Pengujian. Hub Pengujian menolak perangkat saat berikutnya terhubung kembali.
- Perangkat tersebut menghubungkan dan menegosiasikan kembali aliran pembekalan. DPS sekarang mengarahkan perangkat ke lingkungan Produksi, dan perangkat tersambung dan mengautentikasi di sana.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Matthew Cosner | Manajer Rekayasa Perangkat Lunak Utama
- Ansley Yeo | Manajer Program Utama
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.