Bir bildirim sistemi yöneticisi yazmam gerekiyor.
İşte benim gereksinimlerim:
Tamamen farklı olabilecek farklı platformlarda bir Bildirim gönderebilmem gerekiyor (örneğin, SMS veya E-posta gönderebilmem gerekiyor).
Bazen bildirim, belirli bir platformdaki tüm alıcılar için aynı olabilir, ancak bazen platform başına alıcı (veya birkaç) başına bildirim olabilir.
Her bildirim platforma özgü veri yükü içerebilir (örneğin bir MMS bir ses veya görüntü içerebilir).
Sistemin ölçeklendirilebilir olması gerekiyor, uygulamayı veya sunucuyu kilitlemeden çok miktarda bildirim gönderebilmeliyim.
Bu iki aşamalı bir işlemdir, önce müşteri bir mesaj yazabilir ve gönderilecek bir platform seçebilir ve bildirimlerin daha sonra gerçek zamanlı olarak işlenmesi için oluşturulmalıdır.
Daha sonra sistemin bildirimi platform sağlayıcısına göndermesi gerekir.
Şimdilik biraz olsa bitirdim ama ne kadar ölçeklenebilir olacağını ya da iyi bir tasarım olup olmadığını bilmiyorum.
Aşağıdaki nesneleri (sözde bir dilde) düşündüm:
genel bir Notificationnesne:
class Notification {
String $message;
Payload $payload;
Collection<Recipient> $recipients;
}
Aşağıdaki nesnelerle ilgili sorun, 1.000.000 alıcı olduğumda ne olur? RecipientNesne çok küçük olsa bile , çok fazla bellek alacaktır.
Ayrıca alıcı başına bir Bildirim de oluşturabilirim, ancak bazı platform sağlayıcıları toplu iş olarak göndermemi gerektiriyor, bu da birden fazla Alıcı ile bir Bildirim tanımlamam gerektiği anlamına geliyor.
Her oluşturulan bildirim, bir DB veya Redis gibi kalıcı bir depoda saklanabilir.
Ölçeklenebilir olduğundan emin olmak için bunu daha sonra toplamak iyi olur mu?
İkinci adımda, bu bildirimi işleme koymam gerekiyor.
Ancak bildirimi doğru platform sağlayıcısına nasıl ayırt edebilirim?
Bir MMSNotificationgenişletme gibi bir nesne kullanmalı mıyım abstract Notification? ya da benzeri bir şey Notification.setType('MMS')?
Aynı anda birçok bildirimin işlenmesine izin vermek için, RabbitMQ gibi bir mesajlaşma kuyruk sisteminin doğru araç olabileceğini düşünüyorum. Bu mu?
Bir çok bildirimi sıraya koymamı ve birkaç çalışanı bildirip işlem yapmamı sağlayacaktı. Peki ya alıcıları yukarıda görüldüğü gibi gruplandırmam gerekiyorsa?
Sonra, her birini NotificationProcessorekleyebileceğim bir nesneyi platform sağlayıcısına bağlamak ve bildirimde bulunmaktan sorumlu olacağını hayal ediyorum .NotificationHandlerNotificationHandler
EventManagerTakılabilir davranışa izin vermek için bir de kullanabilirim .
Herhangi bir geri bildirim veya fikir?
Zaman ayırdığınız için teşekkürler.
Not: PHP'de çalışmaya alışkınım ve muhtemelen istediğim dil.
Düzenleme (morphunreal'in cevabına göre)
- Saniyede kaç mesaj gönderiyorsunuz (Geçerli / başlangıç seviyelerini tanımlayın, sistemin yeniden tasarlanmadan önce kullanması gereken bir maksimum seviye tanımlayın)
- Sistemin hangi donanım kısıtlamaları var (sistem için mevcut bellek, işlemci vb.)
- Donanım nasıl ölçeklenir (yani daha fazla sunucu, bulut bilişim vb. Eklemek)
- Hangi diller / sistemler bildirimde bulunacak?
Kendi başıma, bildirim programlı olarak oluşturmak için ancak bir kullanıcı arabiriminden yapılandırılmış olarak sorumluyum.
- Jeneratör mesajın alıcılarını biliyor mu (?) Veya başka bir yolla mı sağlanıyor (örneğin, belirli uyarı türleri için iş kuralları belirli alıcılara gidiyor)
Belirli bir alıcıya, bir alıcı grubuna (örneğin bir etiket sistemi kullanarak) veya tüm platform için bir bildirim oluşturmak mümkün olmalıdır.
- CC / BCC / Read makbuzlarını eklemek için iş kuralları var mı
Evet. Bunun gerçekten platforma özgü olduğunu ve okuma veya cc'nin tüm platformlarda bulunmadığını unutmayın.
- Jeneratör gönderdiği mesajın türünü biliyor mu (yani, SMS / e-posta) veya alıcıya mı bağlı
Bununla birlikte, alıcı, platformla ilgili olduğundan ve platformların verileri ele almanın farklı bir yolu olduğu için, UI'nin görüntülerin, bir sesin veya başka bir şeyin kurulmasına izin vermek için platforma özgü olması muhtemeldir.
- Jeneratör gönderilen / alınan / okunan iletilerin onaylanmasını gerektirir mi?
Peki, sistem hataya açık olmalı, ancak bir kural kümesi tanımlamak için hatayı ele almak istiyoruz, örneğin, sunucuya erişilemiyorsa, bildirim daha sonraki işlemler için tekrar yapılmalı, ancak bildirim yanlışsa (veya Platform sağlayıcısı tarafından tanımlandığı gibi) yeniden doldurulmamalı, bildirilmemelidir.
- İleti kaynaklarının / alıcılarının geçmişini saklamak için gereksinimler var mı (ne kadar süreyle?)
Evet, muhtemelen bazı istatistikler ve raporlar hazırlamak istiyoruz. * Bildirim Bitiş Noktalarını Tanımla
Mesaj göndermek için hangi servisler kullanılıyor? Bazıları klasik REST web hizmeti, bazıları ise egzotik protokol, gerçekten sağlayıcıya bağlı.
Hangi geri bildirim / onay sağlanır (senkron / asenkron)
Bağımlı olarak, bazıları senkronizedir ve bir hatayı cevaplarken, bazılarının hataları kontrol etmek için daha sonra çekilmeleri gerekir.
- Yeni bitiş noktaları eklemek olası mıdır [öyle olsa bile, soyutlanması gerekebilir]
Evet, aslında, uygulamamız büyüyor ve muhtemelen yeni bir sağlayıcı ekleyebilmek istiyoruz, ancak yılda 1 veya 2 gibi bir oranın oranı.