Arsitektur referensi ini menunjukkan serverless, arsitektur berbasis peristiwa yang menyerap aliran data, memproses data, dan menulis hasilnya ke database back-end.
Sistem
Alur kerja
- Peristiwa tiba di Azure Event Hubs.
- Aplikasi Fungsi dipicu untuk menangani peristiwa.
- Peristiwa disimpan dalam database Azure Cosmos DB.
- Jika Aplikasi Fungsi gagal menyimpan peristiwa dengan sukses, peristiwa disimpan ke antrean Penyimpanan untuk diproses nanti.
Komponen
Azure Event Hubs menyerap aliran data. Event Hubs dirancang untuk skenario streaming data dengan throughput tinggi.
Catatan
Untuk skenario Internet of Things (IoT), kami menyarankan Azure IoT Hub. IoT Hub memiliki titik akhir bawaan yang kompatibel dengan API Azure Event Hubs, sehingga Anda dapat menggunakan salah satu layanan dalam arsitektur ini tanpa perubahan besar dalam pemrosesan back-end. Untuk informasi selengkapnya, lihat Menghubungkan Perangkat IoT ke Azure: IoT Hub dan Event Hubs.
Aplikasi Fungsi. Azure Functions adalah opsi komputasi tanpa server. Ini menggunakan model yang digerakkan oleh peristiwa, di mana sepotong kode (fungsi) dipanggil oleh pemicu. Dalam arsitektur ini, ketika peristiwa tiba di Pusat Aktivitas, mereka memicu fungsi yang memproses peristiwa dan menulis hasilnya ke penyimpanan.
Aplikasi Fungsi cocok untuk memproses catatan individual dari Pusat Aktivitas. Untuk skenario pemrosesan aliran yang lebih kompleks, pertimbangkan Apache Spark menggunakan Azure Databricks, atau Azure Stream Analytics.
Azure Cosmos DB. Azure Cosmos DB adalah layanan database multi-model yang tersedia dalam mode berbasis konsumsi tanpa server. Untuk skenario ini, fungsi pemrosesan peristiwa menyimpan rekaman JSON, menggunakan Azure Cosmos DB untuk NoSQL.
Penyimpanan antrean. Penyimpanan antrean digunakan untuk pesan tanpa tujuan. Jika terjadi kesalahan saat memproses suatu peristiwa, fungsi tersebut menyimpan data peristiwa dalam antrean huruf mati untuk diproses nanti. Untuk informasi selengkapnya, lihat bagian Ketahanan nanti di artikel ini.
Azure Monitor. Monitor mengumpulkan metrik performa tentang layanan Azure yang disebarkan dalam solusi. Dengan memvisualisasikan ini di dasbor, Anda bisa mendapatkan visibilitas ke dalam kesehatan solusi.
Azure Pipelines. Alur adalah layanan integrasi berkelanjutan (CI) dan pengiriman berkelanjutan (CD) yang membangun, menguji, dan menyebarkan aplikasi.
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.
Ketersediaan
Penyebaran yang ditampilkan di sini berada di satu wilayah Azure. Untuk pendekatan yang lebih tangguh terhadap pemulihan bencana, manfaatkan fitur distribusi geografis di berbagai layanan:
- Pusat Acara. Buat dua namespace layanan Pusat Aktivitas, namespace layanan primer (aktif) dan namespace layanan sekunder (pasif). Pesan secara otomatis dirutekan ke namespace layanan aktif kecuali Anda gagal ke namespace layanan sekunder. Untuk informasi selengkapnya, lihat Azure Event Hubs- Pemulihan Bencana Geo.
- Aplikasi Fungsi. Sebarkan aplikasi fungsi kedua yang menunggu untuk dibaca dari namespace layanan Pusat Aktivitas sekunder. Fungsi ini menulis ke akun penyimpanan sekunder untuk antrean surat mati.
- Azure Cosmos DB. Azure Cosmos DB mendukung beberapa wilayah tulis, yang memungkinkan penulisan ke wilayah mana pun yang Anda tambahkan ke akun Azure Cosmos DB Anda. Jika Anda tidak mengaktifkan fitur multi-penulisan, Anda masih dapat melakukan failover ke wilayah penulisan utama. SDK klien Azure Cosmos DB dan pengikatan Azure Function secara otomatis menangani failover, sehingga Anda tidak perlu memperbarui pengaturan konfigurasi aplikasi apa pun.
- Azure Storage. Gunakan penyimpanan RA-GRS untuk antrean surat mati. Ini membuat replika hanya-baca di wilayah lain. Jika wilayah utama menjadi tidak tersedia, Anda dapat membaca item yang saat ini ada dalam antrean. Selain itu, sediakan akun penyimpanan lain di wilayah sekunder tempat fungsi dapat menulis setelah failover.
Skalabilitas
Event Hubs
Kapasitas throughput Azure Event Hubs diukur dalam unit throughput. Anda dapat menskalakan hub peristiwa secara otomatis dengan mengaktifkan perluas otomatis, yang secara otomatis memperluas skala unit throughput berdasarkan lalu lintas, hingga jumlah maksimum yang dikonfigurasi.
Pemicu Azure Event Hubs dalam aplikasi fungsi diskalakan sesuai dengan jumlah partisi di hub peristiwa. Setiap partisi diberikan satu instans fungsi pada satu waktu. Untuk memaksimalkan throughput, terima peristiwa dalam batch, bukan satu per satu.
Azure Cosmos DB
Azure Cosmos DB tersedia dalam dua mode kapasitas yang berbeda:
- Tanpa server, untuk beban kerja dengan lalu lintas yang terputus-putus atau tidak dapat diprediksi dan rasio lalu lintas rata-rata ke puncak yang rendah.
- Throughput yang diprovisikan, untuk beban kerja dengan lalu lintas berkelanjutan yang membutuhkan performa yang dapat diprediksi.
Untuk memastikan beban kerja Anda dapat diskalakan, penting untuk memilih kunci partisi yang sesuai saat Anda membuat kontainer Azure Cosmos DB. Berikut adalah beberapa karakteristik kunci partisi yang baik:
- Ruang nilai kuncinya besar.
- Akan ada pemerataan pembacaan/penulisan per nilai kunci, menghindari tombol pintas.
- Data maksimum yang disimpan untuk setiap nilai kunci tunggal tidak akan melebihi ukuran partisi fisik maksimum (20 GB).
- Kunci partisi untuk dokumen tidak akan berubah. Anda tidak dapat memperbarui kunci partisi pada dokumen yang ada.
Dalam skenario untuk arsitektur referensi ini, fungsi menyimpan tepat satu dokumen per perangkat yang mengirim data. Fungsi ini terus memperbarui dokumen dengan status perangkat terbaru menggunakan operasi upsert. ID Perangkat adalah kunci partisi yang baik untuk skenario ini karena penulisan akan didistribusikan secara merata di seluruh kunci, dan ukuran setiap partisi akan dibatasi secara ketat karena ada satu dokumen untuk setiap nilai kunci. Untuk informasi selengkapnya tentang kunci partisi, lihat Partisi dan penskalaan di Azure Cosmos DB.
Ketahanan
Saat menggunakan pemicu Pusat Aktivitas dengan Functions, tangkap pengecualian dalam loop pemrosesan Anda. Jika terjadi pengecualian yang tidak tertangani, waktu proses Functions tidak mencoba ulang pesan tersebut. Jika pesan tidak dapat diproses, masukkan pesan ke dalam antrean surat mati. Gunakan proses out-of-band untuk memeriksa pesan dan menentukan tindakan korektif.
Kode berikut menunjukkan bagaimana fungsi penyerapan menangkap pengecualian dan menempatkan pesan yang belum diproses ke antrean surat mati.
[Function(nameof(RawTelemetryFunction))]
public async Task RunAsync([EventHubTrigger("%EventHubName%", Connection = "EventHubConnection")] EventData[] messages,
FunctionContext context)
{
_telemetryClient.GetMetric("EventHubMessageBatchSize").TrackValue(messages.Length);
DeviceState? deviceState = null;
// Create a new CosmosClient
var cosmosClient = new CosmosClient(Environment.GetEnvironmentVariable("COSMOSDB_CONNECTION_STRING"));
// Get a reference to the database and the container
var database = cosmosClient.GetDatabase(Environment.GetEnvironmentVariable("COSMOSDB_DATABASE_NAME"));
var container = database.GetContainer(Environment.GetEnvironmentVariable("COSMOSDB_DATABASE_COL"));
// Create a new QueueClient
var queueClient = new QueueClient(Environment.GetEnvironmentVariable("DeadLetterStorage"), "deadletterqueue");
await queueClient.CreateIfNotExistsAsync();
foreach (var message in messages)
{
try
{
deviceState = _telemetryProcessor.Deserialize(message.Body.ToArray(), _logger);
try
{
// Add the device state to Cosmos DB
await container.UpsertItemAsync(deviceState, new PartitionKey(deviceState.DeviceId));
}
catch (Exception ex)
{
_logger.LogError(ex, "Error saving on database", message.PartitionKey, message.SequenceNumber);
var deadLetterMessage = new DeadLetterMessage { Issue = ex.Message, MessageBody = message.Body.ToArray(), DeviceState = deviceState };
// Convert the dead letter message to a string
var deadLetterMessageString = JsonConvert.SerializeObject(deadLetterMessage);
// Send the message to the queue
await queueClient.SendMessageAsync(deadLetterMessageString);
}
}
catch (Exception ex)
{
_logger.LogError(ex, "Error deserializing message", message.PartitionKey, message.SequenceNumber);
var deadLetterMessage = new DeadLetterMessage { Issue = ex.Message, MessageBody = message.Body.ToArray(), DeviceState = deviceState };
// Convert the dead letter message to a string
var deadLetterMessageString = JsonConvert.SerializeObject(deadLetterMessage);
// Send the message to the queue
await queueClient.SendMessageAsync(deadLetterMessageString);
}
}
}
Kode yang ditampilkan juga mencatat pengecualian ke Application Insights. Anda dapat menggunakan kunci partisi dan nomor urut untuk menghubungkan pesan surat mati dengan pengecualian di log.
Pesan dalam antrean surat mati harus memiliki informasi yang cukup sehingga Anda dapat memahami konteks kesalahannya. Dalam contoh ini, DeadLetterMessage kelas berisi pesan pengecualian, data isi peristiwa asli, dan pesan peristiwa yang dideserialisasi (jika tersedia).
public class DeadLetterMessage
{
public string? Issue { get; set; }
public byte[]? MessageBody { get; set; }
public DeviceState? DeviceState { get; set; }
}
Gunakan Azure Monitor untuk memantau pusat aktivitas. Jika Anda melihat ada input tetapi tidak ada output, itu berarti pesan tidak sedang diproses. Dalam hal ini, masuk ke Log Analytics dan cari pengecualian atau kesalahan lainnya.
DevOps
Gunakan infrastruktur sebagai kode (IaC) jika memungkinkan. IaC mengelola infrastruktur, aplikasi, dan sumber daya penyimpanan dengan pendekatan deklaratif seperti Azure Resource Manager. Itu akan membantu dalam mengotomatiskan penyebaran menggunakan DevOps sebagai solusi integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD). template harus diversi dan disertakan sebagai bagian dari alur rilis.
Saat membuat templat, kelompokkan sumber daya sebagai cara untuk mengatur dan mengisolasinya per beban kerja. Cara umum untuk memikirkan beban kerja adalah aplikasi serverless tunggal atau jaringan virtual. Tujuan isolasi beban kerja adalah untuk mengaitkan sumber daya ke tim, sehingga tim DevOps dapat mengelola semua aspek sumber daya tersebut secara mandiri dan menjalankan CI/CD.
Saat Anda menyebarkan layanan, Anda perlu memantaunya. Pertimbangkan untuk menggunakan Application Insights guna memungkinkan pengembang memantau performa dan mendeteksi masalah.
Pemulihan dari bencana
Penyebaran yang ditampilkan di sini berada di satu wilayah Azure. Untuk pendekatan yang lebih tangguh terhadap pemulihan bencana, manfaatkan fitur distribusi geografis di berbagai layanan:
Pusat Acara. Buat dua namespace layanan Pusat Aktivitas, namespace layanan primer (aktif) dan namespace layanan sekunder (pasif). Pesan secara otomatis dirutekan ke namespace layanan aktif kecuali Anda gagal ke namespace layanan sekunder. Untuk informasi selengkapnya, lihat Azure Event Hubs- Pemulihan Bencana Geo.
Aplikasi Fungsi. Sebarkan aplikasi fungsi kedua yang menunggu untuk dibaca dari namespace layanan Pusat Aktivitas sekunder. Fungsi ini menulis ke akun penyimpanan sekunder untuk antrean surat mati.
Azure Cosmos DB. Azure Cosmos DB mendukung beberapa wilayah tulis, yang memungkinkan penulisan ke wilayah mana pun yang Anda tambahkan ke akun Azure Cosmos DB Anda. Jika Anda tidak mengaktifkan fitur multi-penulisan, Anda masih dapat melakukan failover ke wilayah penulisan utama. SDK klien Azure Cosmos DB dan pengikatan Azure Function secara otomatis menangani failover, sehingga Anda tidak perlu memperbarui pengaturan konfigurasi aplikasi apa pun.
Azure Storage. Gunakan penyimpanan RA-GRS untuk antrean surat mati. Ini membuat replika hanya-baca di wilayah lain. Jika wilayah utama menjadi tidak tersedia, Anda dapat membaca item yang saat ini ada dalam antrean. Selain itu, sediakan akun penyimpanan lain di wilayah sekunder tempat fungsi dapat menulis setelah failover.
Pengoptimalan biaya
Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.
Gunakan kalkulator Harga Azure untuk memperkirakan biaya. Berikut adalah beberapa pertimbangan lain untuk Azure Functions dan Azure Cosmos DB.
Azure Functions
Azure Functions mendukung dua model hosting:
- Paket konsumsi. Daya komputasi dialokasikan secara otomatis saat kode Anda berjalan.
- Paket Azure App Service. Satu set mesin virtual (VM) dialokasikan untuk kode Anda. Paket App Service menentukan jumlah Mesin Virtual dan ukuran Mesin Virtual.
Dalam arsitektur ini, setiap peristiwa yang tiba di Pusat Aktivitas memicu fungsi yang memproses peristiwa itu. Dari perspektif biaya, sarannya adalah menggunakan paket konsumsi karena Anda hanya membayar untuk sumber daya komputasi yang Anda gunakan.
Azure Cosmos DB
Dengan Microsoft Azure Cosmos DB, Anda membayar operasi yang Anda lakukan terhadap database dan untuk penyimpanan yang dikonsumsi data Anda.
- Operasi database. Cara Anda dikenai biaya untuk operasi database Anda bergantung pada jenis akun Azure Cosmos DB yang Anda gunakan.
- Dalam mode tanpa server, Anda tidak perlu menyediakan throughput apa pun saat membuat sumber daya di akun Azure Cosmos DB Anda. Di akhir periode penagihan, Anda akan ditagih sejumlah Unit Permintaan yang digunakan oleh operasi database Anda.
- Dalam mode throughput yang disediakan, Anda menentukan throughput yang Anda butuhkan dalam Unit Permintaan per detik (RU/dtk), dan mendapatkan tagihan per jam untuk throughput yang disediakan maksimum untuk jam tertentu. Catatan: Karena model throughput yang disediakan mendedikasikan sumber daya ke kontainer atau database, Anda akan dikenakan biaya untuk throughput yang telah disediakan meskipun Anda tidak menjalankan beban kerja apa pun.
- Penyimpanan. Anda dikenakan biaya dengan tarif tetap untuk jumlah total penyimpanan (dalam GB) yang digunakan oleh data dan indeks Anda selama jam tertentu.
Dalam arsitektur referensi ini, fungsi menyimpan tepat satu dokumen per perangkat yang mengirim data. Fungsi ini terus memperbarui dokumen dengan status perangkat terbaru, menggunakan operasi upsert, yang hemat biaya dalam hal penyimpanan yang dikonsumsi. Untuk informasi selengkapnya, lihat Model harga Azure Cosmos DB.
Gunakan kalkulator kapasitas Azure Cosmos DB untuk mendapatkan perkiraan cepat biaya beban kerja.
Menyebarkan skenario ini
Implementasi referensi untuk arsitektur ini tersedia di GitHub.
Langkah berikutnya
- Pengantar Azure Functions
- Selamat datang di Microsoft Azure Cosmos DB
- Apa itu Azure Queue Storage?
- Gambaran Umum Azure Monitor
- Dokumentasi Azure Pipelines