Bir IoT çözümünü testten üretime taşıma
Bu makale, bir IoT çözümünü bir üretim ortamına taşırken göz önünde bulundurmanız gereken öğelerin bir listesini içerir.
Dağıtım damgalarını kullan
Damgalar, tanımlı sayıda cihazı destekleyen temel çözüm bileşenlerinin ayrı birimleridir. Her kopyaya bir Damgadenir. veya ölçek birimi. Örneğin, bir damga bir küme cihazı popülasyonu, IoT Hub, bir olay hub 'ı veya başka bir yönlendirme uç noktası ve bir işlem bileşeni içerebilir. Her damga tanımlı bir cihaz popülasyonu destekler. Damgasının tutabileceği maksimum cihaz sayısını seçersiniz. Cihaz popülasyonu büyüdükçe, çözümün farklı kısımlarını bağımsız olarak ölçeklendirmenin yerine damga örnekleri eklersiniz.
Damga eklemek yerine, IoT çözümünüzün tek bir örneğini üretime taşırsınız, aşağıdaki kısıtlamalarla karşılaşabilirsiniz:
Ölçek sınırları: Tek Örneğinizde ölçekleme limitleriyle karşılaşabilirsiniz. Örneğin, çözümünüz gelen bağlantı sayısı, ana bilgisayar adları, TCP yuvaları veya diğer kaynaklar için sınırlara sahip Hizmetleri kullanıyor olabilir.
Doğrusal olmayan ölçekleme veya maliyet: Çözüm bileşenleriniz, yapılan istek sayısı veya alınan veri miktarı ile doğrusal şekilde ölçeklendirmeyebilir. Bunun yerine, bazı bileşenler için bir eşik karşılandıktan sonra performansta bir azalma veya maliyette artış olabilir. Daha fazla kapasite ile ölçeklendirme, damgalar ekleyerek ölçeği ölçeklendirirken uygun bir strateji olmayabilir.
Müşterilerin ayrımı: Belirli müşterilerin verilerinin diğer müşterilerin verilerinin yalıtılmasını saklamanız gerekebilir. Benzer şekilde, diğer müşterilere daha fazla sistem kaynağı gerektiren bazı müşterileriniz olabilir ve bunları farklı damgalar üzerinde gruplandırmayı düşünebilirsiniz.
Tek ve çok kiracılı örnekler: Çözümünüzün kendi bağımsız örneklerine ihtiyaç duyan bazı büyük müşterileriniz olabilir. Ayrıca, çok kiracılı bir dağıtımı paylaşabilen daha küçük bir müşteri havuzunuz olabilir.
Karmaşık dağıtım gereksinimleri: Güncelleştirmeleri denetimli bir biçimde dağıtmanız ve farklı zamanlara farklı damgalara dağıtmanız gerekebilir.
Güncelleştirme sıklığı: Sisteminizde sık güncelleştirmelere sahip olan bazı müşterileriniz olabilir. diğer bir deyişle, risk karşıtı ve hizmetinizdeki nadir güncelleştirmeler yapmak isteyebilirsiniz.
Coğrafi veya geopolitik kısıtlamalar: Gecikme süresini azaltmak veya veri egemenlik gereksinimleriyle uyum sağlamak için bazı müşterilerinizin belirli bölgelere dağıtımını yapabilirsiniz.
Yukarıdaki sorunlardan kaçınmak için hizmetinizi birden çok damgaya gruplandırmayı düşünün. Damgalar birbirinden bağımsız olarak çalışır ve bağımsız olarak dağıtılabilir ve güncelleştirilir. Tek bir coğrafi bölge tek bir damga içerebilir veya bölge içinde yatay ölçeklendirmeyi sağlamak için birden fazla damga içerebilir. Her damga, müşterilerinizin bir alt kümesini içerir.
Geçici bir hata oluştuğunda geri kapatmayı kullan
Uzak hizmetler ve kaynaklarla iletişim kuran tüm uygulamaların geçici hatalara karşı duyarlı olması gerekir. Bu durum özellikle, ortamda çalışan uygulamaların ve internet üzerinden bağlantının doğasını, bu tür hataların daha sık karşılaştığı anlamına gelir. Geçici hatalar şunlardır:
- Kopan bileşenlere ve hizmetlere ağ bağlantısı kaybı
- Hizmetin geçici olarak kullanım dışı kalması
- Hizmet meşgul olduğunda ortaya çıkan zaman aşımları
- Cihazların eşzamanlı olarak aktarılmasından kaynaklanan çakışmalar
Bu hatalar genellikle kendi kendini düzeltmektedir ve eylem uygun bir gecikmeden sonra yinelenirse başarılı olma olasılığı yüksektir. Ancak yeniden denemeler arasındaki uygun aralıkları belirlemek zor olur. Tipik stratejiler aşağıdaki yeniden deneme aralıkları türlerini kullanır:
- Üstel geri alma. Uygulama ilk yeniden deneme öncesinde kısa bir süre bekler ve sonraki her yeniden deneme arasındaki süreyi üstel olarak artırır. Örneğin, işlemi 3 saniye, 12 saniye, 30 saniye vb. sonra yeniden deneyebilir.
- Düzenli aralıklar. Uygulama her girişimden önce aynı süre boyunca bekler. Örneğin, işlemi 3 saniyede bir yeniden deneyebilir.
- Hemen yeniden deneme. Bazen bir ağ paketi çakışması veya bir donanım bileşenindeki ani artış gibi bir olay nedeniyle geçici bir hata kısa bir süre olabilir. Bu durumda, uygulamanın sonraki isteği toplayıp göndermesi için geçen sürede hata giderildiyse başarılı olabileceği için işlemin hemen yeniden denenmesi uygundur. Ancak, tek başına bir anında yeniden deneme girişimi olmamalıdır ve anında yeniden deneme başarısız olursa üstel geri dönme veya geri dönüş eylemleri gibi alternatif stratejilere geçmeniz gerekir.
- Rastgeleseçim. Önceki yeniden deneme stratejilerinden herhangi biri, istemcinin birden çok örneğinin aynı anda sonraki yeniden deneme girişimlerini göndermesini engellemek için rastgele bir öğe içerebilir.
Aşağıdaki kenar düzenlerini de önleyin:
- Uygulamalar yinelenen yeniden deneme kodu katmanları içermemelidir.
- Hiçbir zaman sonsuz bir yeniden deneme mekanizması uygulamayın.
- Hemen yeniden denemeyi hiçbir zaman birden çok kez gerçekleştirmeyin.
- Düzenli bir yeniden deneme aralığı kullanmaktan kaçının.
- Aynı istemcinin birden çok örneğinin veya farklı istemcilerin birden çok örneğinin aynı anda yeniden denemeler göndermesini önleyin.
Sıfır dokunma sağlamasını kullanma
Sağlama, bir cihazı Azure IoT Hub kaydetme işlemidir. Sağlama, cihazın ve cihazın kullandığı kanıtlama mekanizmasından haberdar IoT Hub sağlar. Azure IoT Hub cihaz sağlama hizmeti 'ni (DPS) kullanabilir veya doğrudan IoT Hub kayıt defteri Yöneticisi API 'leri aracılığıyla temin edebilirsiniz. DPS 'in kullanılması, alan cihazlarının cihaz yazılımını değiştirmeden IoT Hub için kaldırma ve yeniden sağlamayı sağlayan geç bağlamanın avantajlarından yararlanır.
Aşağıdaki örnek, DPS kullanarak bir test-üretim ortamı geçiş iş akışının nasıl uygulanacağını gösterir.
- Çözüm geliştiricisi, test ve üretim IoT bulutlarını sağlama hizmetine bağlar.
- Cihaz artık sağlanmadıysa IoT Hub bulmak için DPS protokolünü uygular. Cihaz başlangıçta test ortamına sağlanır.
- Cihaz, test ortamına kaydedildiğinden, bu, bağlantı kurar ve test gerçekleşir.
- Geliştirici, cihazı üretim ortamına yeniden hazırlar ve test hub 'ından kaldırır. Test Hub 'ı bir dahaki sefer yeniden bağlandığında cihazı reddeder.
- Cihaz, sağlama akışını bağlar ve yeniden görüşür. DPS artık cihazı üretim ortamına yönlendirir ve cihaz bağlantı kurar ve kimlik doğrular.