Kuinka valita viestijono

Työskentelen ryhmässä, joka kehittää postipalvelinta: James. Tämä projekti on osa OpenPaaS-hanketta, johon osallistuu useita joukkueita.

Tässä postipalvelimessa meidän on otettava käyttöön hajautettu postijono. Postijono on pakollinen osa SMTP-palvelimia. Se mahdollistaa vastaanotettavien viestien irrottamisen niiden käsittelystä. Nykyinen toteutus perustuu sulautettuun ActiveMQ-palvelimeen, jolla on vuosikymmenten vanha JMS-toteutus. Aika oli tullut pieneen nostoon!

Mutta postijono on monimutkainen järjestelmä ... Sen ei pitäisi olla vain tehokasta työjonoa, vaan myös monia muita lisäominaisuuksia:

  • Tärkeysjärjestys: Voit ehkä antaa etusijalle organisaatiosi sähköpostiviestit roskapostiin verrattuna
  • Viiveet: Ehkä et halua lähettää liian paljon viestejä kerralla. Ehkä joudut odottamaan vähän ennen kuin lähetät sähköpostin uudelleen etäpostipalvelimelle virheiden varalta ...
  • Hallinta: Sähköpostipalvelimen järjestelmänvalvojat odottavat tarkastavansa postijonon sisällön, poistavansa haluamansa elementit muun muassa…

Emme voineet toteuttaa sitä suoraviivaisesti ja tuotantotasolla RabbitMQ: n päällä. Siksi päätimme etsiä vaihtoehtoisia ratkaisuja ja viestijonoja.

Jokaisen OpenPaaS-tiimin käyttäessä viestijonoja, meidän piti valita se, joka sopii paremmin ihmisten tarpeisiin.

Vaatimusten määrittely

Ensimmäinen askel oli oppia kunkin joukkueen vaatimuksista ja sitten tehdä niistä yhteenveto.

Suorittaaksemme tämän päätimme haastatella jokaisen joukkueen johtajan. Määrittelimme luettelon keskusteltavista aiheista:

  • ominaisuudet, jotka ne toteuttavat, ja ne otetaan käyttöön viestijonon päällä
  • rajoitukset, joita he kohtaavat tällä hetkellä
  • kokemusta tämän viestijonoteknologian kanssa

Kaivoimme melko pitkälle ja keskustelimme kuumista aiheista:

  • ainakin kerran Vs korkeintaan kerran
  • saatavuus Vs johdonmukaisuus
  • hallintaominaisuudet: jonon koko, selaa,…

Yhteenvetona voidaan todeta, että OpenPaaS abstrahoi viestijonoteknologiaa viestintäliittymän takana. Tämän sovellusliittymän avulla voidaan julkaista / tilata tiettyjä aiheita, suorittaa lähetyksiä ja jakaa työtä työjonojen avulla.

OpenPaaS käyttää myös viestijonoa, jotta jotkut palvelut voivat kommunikoida keskenään. Tämä sisältää tietoja:

  • postipalvelimelta, James
  • kalenterijärjestelmästä, Saber.
  • Yhteystiedot-palvelusta

Suurin osa käyttötapauksistamme luottaa ainakin yhteen toimitukseen, mutta joillekin niistä olisi hyötyä tarkalleen kerran semantiikka. Meillä on taipumus suosia johdonmukaisuutta ja haluamme niin paljon hallintokykyä kuin pystymme.

Tämän avulla voimme poimia ydinvaatimukset:

  • tarvitsemme perusviestintäominaisuudet
  • Tarvitsemme johdonmukaisuuden, ainakin yhden semanttisen
  • bonuksena edistyneet hallintaominaisuudet

Mutta lisäsimme myös joitain kriteerejä, joita ei haastateltu:

  • hankkeen kypsyys
  • Yhteisö
  • esityksiä,…

Toivottavasti haastattelujen suorittamisen jälkeen ei ollut ristiriitoja, kuten yksi joukkue tarvitsee saatavuuden ja toinen johdonmukaisuus. Nämä haastattelut auttoivat meitä paljon, jotta jotkut toteutukset jäisivät lopulliseen valintoihimme.

Lyhyt luettelo

Viestijonojen toteutuksia on niin paljon, että päätimme rajoittaa ehdokkaiden määrää. Tässä on luettelo valituista tutkittavaksi:

  • RabbitMQ
  • Kafka
  • RocketMQ
  • Qpid
  • Artemis
  • NSQ
  • ZeroMQ

Esitän täällä ne, jotka kiinnittivät huomiota eniten:

RabbitMQ on OpenPaaS: n tällä hetkellä käyttämä viestijono, joten muuttoa ei tarvita. Se tarjoaa hyvän ja kypsän yhteisön. Joistakin klusterointiin liittyvistä ongelmista on ilmoitettu, mukaan lukien viestin katoaminen ja manuaalinen täsmäytyminen osion yhteydessä. Tämän ratkaisun huono kohta on, että se ei sovi Jamesin tarvitsemiin edistyneisiin hallintaominaisuuksiin. Valitsimme sen lisätutkimuksia varten, ja sen dokumentoinnin laatu on ollut ratkaiseva tekijä.

Kafka on huippuluokan suoratoistoalusta. Se täyttää vaaditut ominaisuudet. Jotkut postijonon ominaisuudet ovat helpompi toteuttaa, koska se paljastaa hajautetun lokin. Sen yhteisö on vahva ja kypsä, ja sen uskotaan keskittyvän ensisijaisena huolenaiheeksi. Toisto on ydinkonsepti. Sen arkkitehtuuri on kuitenkin monimutkainen ja siihen sisältyy ZooKeeper-koorumi. Valitsimme myös sen.

RocketMQ on lupaava, vasta syntynyt Apache-projekti. Hyvistä esityksistä ja vaikuttavasta ominaisuuskokonaisuudesta huolimatta yhteisö ei kuitenkaan ole kovin kypsä, keskittyen lähinnä Alibaba -yhtiölle. Hanke on edelleen kehitteillä. Joten olemme vakuuttuneet kaikista sen eduista huolimatta, että sen valitseminen ei olisi viisas valinta.

Artemis on HornetQ, lahjoitettu Apache-säätiölle ja omaksunut ActiveMQ-projektissa. Kivivakaa viestijono, mutta valitettavasti sen klusterointi on vaikeaa. Jotkut vanhan koulun tekniikat (mukaan lukien XML!) Ovat mukana. Siksi päätimme olla tutkimatta tarkemmin.

NSQ on hajautettu viestijärjestelmä. Haluamme haluamiasi viestintämalleja, mutta vain hakkerointi mahdollistaa * kestävyyden *. Klusterointi on ensisijainen kansalaiskonsepti, mutta ominaisuuksien kustannuksella. AMQP: tä ei tueta, toista ei myöskään. Päätimme, että siihen siirtymisen kustannuksia ei kannata maksaa.

Ja sitten lisäämme valita

Sota oli raivostumassa Kafkan ja RabbitMQ: n välillä.

Yksikään edellä esitetyistä tekniikoista ei salli Jamesin tarpeiden tyydyttämistä tyydyttämällä samalla tuotantostandardejamme. Siksi päätimme sulkea pois Jamesin ominaisuudet valinnasta. Sähköpostijonon lisäominaisuudet toteutetaan viestijonon / tietokannan yhdistelmällä.

Sitten strategiastamme tuli tutkia POC: lla RabbitMQ: n käytön rajoituksia.

  • Tarjoimme OpenPaaS-käyttötapausten POC RabbitMQ: n päälle
  • Teimme kokeita dokkeroidun rabbitMQ-klusterin päälle: pysäytimme solmut, tuotimme ja kulutamme erilaisissa solmuissa, julistimme vaihtoja ja jonoja eri solmuissa.
  • Testasimme kestävyyttä, tuotanto / kulutusjärjestystä.

Sitten strategisessa kokouksessa kerrotaan, haluammeko siirtää Kafkaan.