Dobrá strategie pro Message Queuing?

hlasů
9

Jsem v současné době projektování aplikace, kterou jsem nakonec chcete přesunout do Windows Azure. V krátkodobém horizontu však bude spuštěna na serveru, který mi bude hostit sám.

Aplikace se skládá z několika samostatných webových aplikací - některé z nich jsou v podstatě WCF služby, které přijímají data a některé z nich jsou místa pro uživatele pro správu dat. Kromě toho, že budou muset být pracovník služba běžící na pozadí, které bude zpracovávat informace různými způsoby.

Jsem velmi ráda používat oddělený architekturu pro toto. V ideálním případě jsem chtěl komponenty (tj Web Apps a pracovník služba) vědět, co nejméně o sobě. Vypadá to, že pomocí fronty zpráv bude nejlepší řešení tady - webové aplikace mohou Zařadí zprávy s pracovních jednotek do fronty a pracovník servisu můžete vyzvednout je a zpracovávat je podle potřeby.

Nicméně chci vypracovat dobrou sadu technologií, jak toho dosáhnout, vzhledem k tomu, že budu nakonec stěhuje do Azure a chtějí, aby se minimalizovalo množství re-práce budu muset dělat, když se stěhují do oblak , Azure má fronty složku postavený ve kterém vypadá ideální pro mé potřeby. Co bych chtěl udělat, je vytvořit něco sám, který bude napodobovat to tak přesně, jak je to možné.

Vypadá to, že existuje několik možností (já používám .NET Windows, s back-end SQL Server 2005) - ty jsem našel tak daleko jsou:

  • MSMQ
  • SQL Server service broker
  • Válcování mé vlastní použití databázové tabulky a některé uložené procs

Napadlo mě, jestli někdo má nějaké návrhy na to - nebo jestli někdo udělal něco podobného a má radu o co dělat /, aby se zabránilo. Uvědomuji si, že každá situace je jiná, ale v tomto případě si myslím, moje požadavky na obsluhu front jsou dost generické tak bych rád slyšel někdo jiný myšlenky o nejlepší způsob, jak to udělat.

Díky předem,

John

Položena 27/08/2009 v 00:55
zdroj uživatelem
V jiných jazycích...                            


3 odpovědí

hlasů
18

Pokud máte Azure na mysli, možná byste měli začít rovnou na Azure jako API a semnatics se výrazně liší mezi Azure front a některé z MSMQ nebo SSB.

Rychlým 3048 metrů srovnání MSMQ vs. SSB (nechám vlastní tabulky-as-fronty mimo srovnání, jak to opravdu záleží, jak jej realizovat ...)

  • Nasazení : MSMQ je součástí Windows, SSB je SQL compoenent. SSB vyžaduje SQL instance ukládat všechny zprávy, takže disconencted klienti potřebují přístup k instanci (může být Express). MSMQ vyžaduje nasazení MSMQ na straně klienta (součást operačního systému, ale volitelně nainstalovat).
  • Programovatelnost : MSMQ nabízí plnohodnotnou podporou, WCF kanál. SSB nabízí pouze experimentální WCF kanál na http://ssbwcf.codeplex.com
  • Výkon : SSB bude výrazně rychlejší než MSMQ v transakčním režimu. MSMQ bude rychlejší, pokud nechal pracovat v režimu untransacted (best effort, neuspořádané, dodávka)
  • Queriability : SSB fronty může být SELECTE-ed uppon (zobrazit libovolný vzkaz, plný SQL JOIN / KDE / objednávka / GROUP výkon) může být, MSMQ fronty nakoukla (jen další zpráva)
  • Obnovitelnost : SSB fronty jsou začleněny do databáze, takže jsou zálohovány a obnoveny s databází, vedení consitent stav se stavem aplikace. MSMQ fronty jsou zálohovány v zálohování souborů subsytem NT tak, aby zálohy v synchronizace (koherentní) fronta a databáze musí být pozastavena.
  • Transakce (protože každá Enqueue / dequeue je vždy doprovázena aktualizaci databáze): SSB je plně integrována do SQL tak dequeueing a enqueueing místní transakční operace. MSMQ je samostatná TM (Transaction Manager), takže fronta / dequeue musí být Distributed Transaction operace zapsat i SQL a MSMQ v transakci.
  • Řízení a monitoring : jak equaly špatné. Whatsoever žádné nářadí.
  • Korelovaný Zprávy zpracování: SSB může blokovat zpracování korelované zprávy od concurent závity přes vestavěný skupinové konverzace zamykání .
  • Driven událost : SSB má aktivace pro spuštění uložené procedury MSMQ používá Aktivace Windows službu. Podobný. SSB má však vlastní vyvažování zátěže capalities vzhledem ke způsobu WAITFOR (příjem) a MAX_QUEUE_READERS komunikovat.
  • Dostupnost : SSB rozšiřuje na SQL Server High Availability příběhu, může pracovat buď v clusterovém nebo v databázi miroring prostředí. MSMQ jezdí pouze shlukování příběh Windows. Database Mirroring je mnohem levnější než shlukování ve formě roztoku HA.

Dále bych dodal, že SSB a MSMQ se značně liší v úrovni finan primitivní nabízejí: SSB primitivní je konverzace , zatímco MSMQ primitivní je zpráva . Myslím, TCP vs. UDP sémantiky.

Odpovězeno 27/08/2009 v 01:27
zdroj uživatelem

hlasů
10

Pick fronty zadní konec, který pracuje pro vás, nebo že je vhodnější pro vaše prostředí. @Remus dal velkou srovnání mezi MSMQ a SSB. MSMQ bude snazší, kdo realizovat, ale má některé pozoruhodné omezení, zatímco SSB se bude cítit velmi těžký jako jeho na druhém konci spektra.

Mít to váš Way
Pro minimalizaci přepracování od vás aplikace, abstraktní fronty přístup za rozhraní, a pak poskytují implementace pro frontu dopravou se nakonec rozhodne jít s. Když je čas přejít na Azure nebo jiné fronty dopravy, stačí poskytnout novou implementaci svého rozhraní.

Dostanete se řídit sémantiku, jak chcete komunikovat s fronty poskytnout konzistentní použitelné API z vašich aplikací.

Hrubou představu by mohlo být:

interface IQueuedTransport
{
  void SendMessage(XmlDocument);
  XmlDocument ReceiveMessage();
}

public class MSMQTransport : IQueuedTransport {}
public class AzureQueueTransport : IQueuedTransport {}

Nesmíte být budování be-all front dopravu, jen to, co vyhovuje vašim potřebám. Pokud pracujete s XML, projít xml. Pokud pracujete v bytovými poli, projít bajt matice. :)

Hodně štěstí!
Z

Odpovězeno 27/08/2009 v 02:13
zdroj uživatelem

hlasů
0

Použijte Win32 přihrádky pošty . Budou spolehlivá na jednom serveru, jsou snadno implementovat, a nevyžadují žádné další software.

Odpovězeno 03/03/2011 v 00:28
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more