Bu makale, bir IoT çözümünü üretim ortamına taşırken göz önünde bulundurmanız gereken öğelerin listesini içerir.
Dağıtım damgalarını kullanma
Damgalar, tanımlı sayıda cihazı destekleyen temel çözüm bileşenlerinin ayrı birimleridir. Her kopya damga olarak adlandırılır. veya ölçek birimi. Örneğin, bir damga pulu belirli bir cihaz popülasyonu, IoT Hub'ı, bir Event Hub veya başka bir yönlendirme uç noktası ve bir işleme bileşeninden oluşabilir. Her damga, tanımlı bir cihaz popülasyonu destekler. Damga damgasının tutabileceği en fazla cihaz sayısını seçersiniz. Cihaz popülasyonu arttıkça çözümün farklı bölümlerini bağımsız olarak ölçeklendirmek yerine damga örnekleri eklersiniz.
Damga pulları eklemek yerine IoT çözümünüzün tek bir örneğini üretime taşırsanız aşağıdaki sınırlamalarla karşılaşabilirsiniz:
Ölçek sınırları: Tek örneğiniz ölçeklendirme sınırlarıyla karşılaşabilir. Örneğin, çözümünüz gelen bağlantı sayısı, ana bilgisayar adları, TCP yuvaları veya diğer kaynakların sayısıyla ilgili sınırları olan hizmetleri kullanıyor olabilir.
Doğrusal olmayan ölçeklendirme veya maliyet: Çözüm bileşenleriniz yapılan istek sayısı veya alınan veri miktarıyla doğrusal olarak ölçeklendirilmeyebilir. Bunun yerine, bazı bileşenler için bir eşik karşılandıktan sonra performansta bir düşüş veya maliyet artışı olabilir. Daha fazla kapasiteyle ölçeği artırmak, damga pulları ekleyerek ölçeği genişletme kadar iyi bir strateji olmayabilir.
Müşteri Ayrımı: Belirli müşterilerin verilerini diğer müşterilerin verilerinden yalıtılmış tutmanız gerekebilir. Benzer şekilde, hizmet vermek için diğerlerinden daha fazla sistem kaynağı gerektiren bazı müşterileriniz olabilir ve bunları farklı damgalarda 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ı dağıtımı paylaşabilen daha küçük bir müşteri havuzunuz da olabilir.
Karmaşık dağıtım gereksinimleri: Güncelleştirmeleri hizmetinize denetimli bir şekilde dağıtmanız ve farklı zamanlarda farklı damgalara dağıtmanız gerekebilir.
Güncelleştirme sıklığı: Sisteminizde sık sık güncelleştirmeler yapma konusunda toleranslı olan bazı müşterileriniz olabilirken, bazıları risk almayabilir ve hizmetinizde seyrek güncelleştirmeler yapmak isteyebilir.
Coğrafi veya jeopolitik kısıtlamalar: Gecikme süresini azaltmak veya veri hakimiyeti gereksinimlerine uymak için bazı müşterilerinizi belirli bölgelere dağıtabilirsiniz.
Önceki sorunlardan kaçınmak için hizmetinizi birden çok damgaya göre gruplandırmayı göz önünde bulundurun. Damga pulları birbirinden bağımsız olarak çalışır ve bağımsız olarak dağıtılabilir ve güncelleştirilebilir. Tek bir coğrafi bölge tek bir damga içerebilir veya bölge içinde yatay ölçeği genişletmeye olanak sağlamak için birden çok damga içerebilir. Her damga pulu müşterilerinizin bir alt kümesini içerir.
Geçici bir hata oluştuğunda geri çevirmeyi kullanma
Uzak hizmetler ve kaynaklarla iletişim kuran tüm uygulamaların geçici hatalara karşı duyarlı olması gerekir. Bu durum, özellikle ortamın doğasının ve İnternet üzerinden bağlantının bu tür hatalarla daha sık karşılaşılacağı anlamına geldiği bulutta çalışan uygulamalar için geçerlidir. Geçici hatalar şunlardır:
- Bileşenlere ve hizmetlere anlık ağ bağlantısı kaybı
- Bir hizmetin geçici olarak kullanılamadığı
- Bir hizmet meşgul olduğunda ortaya çıkan zaman aşımları
- Cihazlar aynı anda iletirken oluşan çakışmalar
Bu hatalar genellikle kendi kendine düzeltilir ve eylem uygun bir gecikmeden sonra tekrarlanırsa başarılı olma olasılığı yüksektir. Ancak, yeniden denemeler arasındaki uygun aralıkları belirlemek zordur. Tipik stratejiler aşağıdaki yeniden deneme aralığı 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 geçici bir hata, belki de ağ paketi çakışması veya donanım bileşenindeki ani artış gibi bir olaydan kaynaklanır. 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, hiçbir zaman birden fazla anında yeniden deneme girişimi olmamalıdır ve anında yeniden deneme başarısız olursa üstel geri alma veya geri dönüş eylemleri gibi alternatif stratejilere geçmeniz gerekir.
- Rastgele seçim. Önceki yeniden deneme stratejilerinden herhangi biri, istemcinin birden çok örneğinin sonraki yeniden deneme girişimlerini aynı anda göndermesini önlemek için rastgele bir öğe içerebilir.
Ayrıca aşağıdaki anti-desenlerden de kaçının:
- Uygulamalar, yinelenen yeniden deneme kodu katmanlarını 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 dokunmayla sağlamayı kullanma
Sağlama, bir cihazı Azure IoT Hub'a kaydetme işlemidir. Sağlama, IoT Hub'ın cihazın ve cihazın kullandığı kanıtlama mekanizmasının farkında olmasını 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 sağlayabilirsiniz. DPS'nin kullanılması, alan cihazlarının cihaz yazılımını değiştirmeden IoT Hub'a kaldırılmasına ve yeniden sağlanmasına olanak tanıyan geç bağlamanın avantajını sağlar.
Aşağıdaki örnekte DPS kullanarak test-üretim ortamı geçiş iş akışının nasıl uygulandığı gösterilmektedir.
- Çözüm geliştiricisi Test ve Üretim IoT bulutlarını sağlama hizmetine bağlar.
- Cihaz, artık sağlanmamışsa IoT Hub'ı bulmak için DPS protokolunu uygular. Cihaz başlangıçta Test ortamına sağlanır.
- Cihaz Test ortamına kayıtlı olduğundan oraya bağlanır ve test gerçekleşir.
- Geliştirici cihazı Üretim ortamına yeniden sağlar ve Test hub'ından kaldırır. Test hub'ı cihazı bir sonraki bağlantıda reddeder.
- Cihaz, sağlama akışına bağlanır ve yeniden anlaşma sağlar. DPS artık cihazı Üretim ortamına yönlendirir ve cihaz orada bağlanır ve kimlik doğrulaması yapar.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazarlar:
- Matthew Cosner | Baş Yazılım Mühendisliği Yöneticisi
- Ansley Yeo | Asıl Program Yöneticisi
Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.