Ruby på Skinner (Rails, RoR) er en velkendt web applikationsrammeværk skrevet i Ruby programmeringssprog. Pub/Sub er et kort navn for softwaredesignmønstre kaldet Udgiv-abonnement. Jeg vil forklare, hvordan kommunikation mellem softwarekomponenter i Rails kan håndteres af Pub/Sub.

Hvad er Pub/sub?

Pub/sub er et softwaredesignmønster, der giver service-til-service-kommunikation. Service
indebærer en af de to roller: udgiver (som producerer) eller modtager (som forbruger). Hvad er
der skal forbruges, bestemmes som en begivenhed eller en besked eller en notifikation. I
I denne artikel bruges de i flæng om det samme.
Den tjeneste, der producerer, ved ikke, hvem der forbruger. Den tjeneste, der forbruger, ved ikke
kender beskedens oprindelse. De kan forblive ukendte for hinanden. Det er forskelligt fra
beskedkøer, hvor den komponent, der sender beskeden, ofte kender dens destination
- Denne måde at sende beskeder på giver dig mulighed for at sende beskeder hvor som helst. Denne mekanisme er en kerne
af Pub/sub og det betyder, at de er afkoblede.

For at udtrykke deres fælles interesser skal de have en fælles forståelse. Det er derfor,
Begge roller har en implicit stokkemekanisme, hvor producenten af en besked og modtageren af den
forbruger af meddelelsen mødes. Denne mekanisme kaldes emne, abonnement eller topic. Den er
ansvarlig for at kategorisere meddelelser til emner, er det i bund og grund et tilstandsløst meddelelsesfilter.
Emner fungerer som radiostationer. En udgiver producerer beskeden til emnet,
abonnenter modtager straks beskeden fra emnet. På grund af den afkoblede
tjenester, er den mest effektive måde at udveksle beskeder på at håndtere dem asynkront.

Rails uden Pub/Sub

Som standard er der ingen Rails-overhead for softwaredesignmønstre til overførsel af beskeder mellem komponenter. Udviklere bruger standard objektorienteret programmering (OOP) paradigme: sende parametre til funktioner, bede om klasser om værdier.

Når applikationen er ret ukompliceret, kan det være nok. Når applikationen vokser, skal nogle operationer f.eks. udføres asynkront, og så er projekt har brug for en abstraktion, der løser det data arbejdsgang. I stedet for at genopfinde hjulet kan udviklere implementere Pub/sub for at udfylde denne mangel på abstraktion.

Fordele ved Pub/Sub med Rails

• Undgå tilbagekaldelser af aktive poster.
• Ved at tilføje asynkron parallel behandling til et system øges ydeevnen, pålideligheden og skalerbarhed er forbedret.
• Beskeder kan sendes asynkront til forskellige dele af systemet.
• Giver mulighed for at sende beskeder asynkront til forskellige dele af et system.
• Afkobling - tilføjelse eller ændring af en funktionalitet vil ikke påvirke noget, fordi Pub/Sub
  giver dig mulighed for at ændre, hvordan alting interagerer.
• Beskedforbrugeren behøver ikke længere regelmæssigt at tjekke for opdateringer eller nye
  information. Det reducerer leveringsforsinkelsen, som kan være særligt problematisk i systemer
  uden tolerance over for forsinkelser.
• Der er ingen grænse for, hvor mange abonnenter systemet kan håndtere, for det kan ændre sig,
  opgradere, formere sig eller forsvinde når som helst.

Ulemper ved Pub/Sub med Rails

• Den største ulempe ved Pub/sub-systemer er deres afkobling af udgiver og
  abonnent.

Rails Pub/Sub introducerer

Eksempler på kilde i Rails blev skrevet ved hjælp af biblioteket
Pub/Sub på Rails (i Rubys nomenklatur kaldes et bibliotek for gem): Du finder flere detaljer i gem'ens readme. Implementeringen er sammensat af moduler:

1. Domæne,
2. Begivenhed,
3. Hændelseshåndtering,
4. Udgiver af begivenheden,
5. Abonnement.

Domæne

Beskriver forretningslogik for at give kontekst til Pub/Sub og derfor gøre den ren. Kode.

 modul Notifikationer
   extend PubSub::Domæne
 slutning

 modul Rapporter
   extend PubSub::Domæne
 slut

Begivenhed

Det er en klasse, som beskriver, hvad der skete. Erklær klassens navn så selvbeskrivende med det, der skete, som muligt, for eksempel: annulleret, ændret, oprettet, ødelagt, sendt, opdateret. Begivenhedsnavne kan se ud som: ProfitAndLossStatementCreatedEvent, som betyder, at der blev oprettet et årsregnskab.

 class Reports::ProfitAndLossStatementCreatedEvent < PubSub::DomainEvent
   attribut :profit_and_loss_statement_id, Types::Strict::Integer
 end

Udgiver af begivenheder

Klasse, der kan udsende hændelser. Eksemplet viser oprettelse af en servicerapport. Når rapporten er oprettet, udsendes hændelsen for oprettelsen af rapporten.

klasse Reports::ProfitAndLossStatementService
   inkluderer PubSub::Emit
    def udfør
     emit(:report_profit_and_loss_statement_created, profit_and_loss_statement_id: id) if result.ok?
   end
 end

Hændelseshåndtering

Denne klasse skal udføres som svar på håndtering af en hændelse.

modul Notifikationer
 class ReportsProfitAndLossStatementCreatedHandler < PubSub::DomainEventHandler
   def kald
     ReportMailer.profit_and_loss_statement(profit_and_loss_statement).deliver_now
   slut

   privat

   def opgørelse_overskud_og_tab
     ProfitAndLossStatement.find(event_data.profit_and_loss_statement_id)
   slut
 end
end

Abonnement

Begivenheder er bundet til deres behandlere gennem abonnementer.

meddelelser:
 reports__profit_and_loss_statement_created: async

Eksempler på brugsscenarier:

• "Følg"-funktionen i sociale netværk,
• Tingenes internet,
• Mailing,
• Meddelelse om genererede filer.

Lignende mønstre

1. EventBus - komponenter kan sende begivenheder til EventBus uden at vide, hvem der vil samle dem op, eller hvor mange respondenter der vil komme. reagere,
2. Observatør - opretholder subjektet en liste over afhængige personer, kaldet observatører, og giver dem besked, når deres tilstand ændres,
3. Sammenlægning - Ved polling spørger klienter med jævne mellemrum systemet, om der er nye begivenheder eller data.

Ædelstene

• https://github.com/edisonywh/rocketman

• https://github.com/krisleech/wisper

• https://github.com/stevo/pubsubpåSkinner

Sammenfatning

Pub/sub er ikke en almindelig tilgang i Ruby in Rails. Som introduceret i artiklen kan dette mønster give mange fordele til projektet - det kan gøre koden ren, afkoble tjenester og gøre dem let skalerbare.