Kuidas valida sõnumijärjekorda

Töötan meeskonnas, kes arendab meiliserverit: James. See projekt on OpenPaaS projekti alamrühm, mis hõlmab mitut meeskonda.

Selles meiliserveris peame rakendama hajutatud e-posti järjekorda. E-posti järjekord on SMTP-serverite kohustuslik komponent. See võimaldab lahti ühendada sõnumite töötlemise. Praegune teostus põhineb manustatud ActiveMQ serveril, millel on aastakümneid vana JMS-i juurutamine. Aeg oli saabunud väikeseks tõstmiseks!

Kuid postijärjekord on keeruline süsteem ... See peaks mitte ainult olema tõhus tööjärjekord, vaid ka paljud täiendavad funktsioonid tuleks rakendada:

  • Prioriteet: võiksite oma rämpspostiga võrreldes oma organisatsiooni e-kirjadele kõrgema prioriteedi anda
  • Viivitused: võib-olla ei taha te korraga liiga palju kirju saata. Võib-olla peate natuke ootama, enne kui e-posti uuesti e-posti serverisse saadetakse, kui tõrkeid otsitakse ...
  • Haldamine: meiliserveri administraatorid loodavad muu hulgas kontrollida e-posti järjekorra sisu, eemaldada muu hulgas soovitud elemendid…

RabbitMQ peal ei saanud me seda otsekoheselt ja tootmistasemel viisil rakendada. Seetõttu otsustasime otsida alternatiivseid lahendusi ja sõnumijärjekordi.

Iga OpenPaaS-i meeskond, kes kasutas sõnumijärjekordi, pidime valima ühe, mis sobib paremini inimeste vajadustega.

Nõuete määratlemine

Esimene samm oli õppida tundma iga meeskonna nõudeid, seejärel teha neist kokkuvõte.

Selle teostamiseks otsustasime intervjueerida iga meeskonna juhte. Me määratlesime arutatavate teemade loendi:

  • funktsioonid, mida nad rakendavad ja rakendavad sõnumijärjekorra ülaosas
  • piirangud, millega nad praegu kokku puutuvad
  • kogemus selle sõnumijärjekorra tehnoloogiaga

Kaevasime üsna kaugele ja arutasime kuumaid teemasid:

  • vähemalt üks kord Vs korraga
  • saadavus Vs järjepidevus
  • haldusvõimalused: järjekorra suurus, sirvimine,…

Kokkuvõtteks võib öelda, et OpenPaaS abstraheerib sõnumite järjekorra tehnoloogiat sõnumside API taga. See API võimaldab avaldada / tellida konkreetseid teemasid, teha saateid ja jagada tööjärjekordade abil tööd.

OpenPaaS kasutab ka teadete järjekorda, et võimaldada mõnel teenusel nende vahel suhelda. See sisaldab teavet:

  • meiliserverist, James
  • kalendrisüsteemist, Sabre.
  • kontaktide teenusest

Enamik meie kasutusjuhtumeid tugineb vähemalt ühele kohaletoimetamisele, kuid mõnel neist oleks täpselt ühe korra semantilisus kasulik. Me eelistame järjepidevust ja soovime võimalikult palju juhtimisvõimalusi.

See võimaldab meil välja tuua põhinõuded:

  • vajame põhilisi sõnumsidevõimalusi
  • vajame järjepidevust, vähemalt ühte semantilist
  • boonusena täiustatud juhtimisvõimalused

Kuid lisasime ka mõned kriteeriumid, mille osas intervjuusid ei tehtud:

  • projekti küpsus
  • kogukond
  • etendused,…

Loodetavasti ei olnud pärast intervjuude korraldamist vastuolusid, näiteks üks meeskond vajab saadavust ja teine ​​järjekindlust. Need intervjuud aitasid meid palju, et jätta mõned rakendused meie lõplikust valikust välja.

Lühike nimekiri

Sõnumijärjekordade rakendusi on nii palju, et otsustasime kandidaatide arvu piirata. Siin on valitud uuringuks valitud nimekiri:

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

Esitan siin need, mis meie tähelepanu kõige enam köitsid:

RabbitMQ on sõnumijärjekord, mida OpenPaaS praegu kasutab, seega pole migratsioon vajalik. See pakub head ja küpset kogukonda. Teatatud on mõnedest klastritega seotud probleemidest, sealhulgas teate kadumine ja käsitsi ühitamine jaotuse korral. Selle lahenduse halb külg on see, et see ei sobi Jamesi jaoks vajalikele täpsematele haldusfunktsioonidele. Valisime selle edasiseks uurimiseks ja selle dokumentatsiooni kvaliteet on olnud määrav tegur.

Kafka on tipptasemel voogesituse platvorm. See täidab soovitud funktsioone. Kuna see paljastab hajutatud logi, on mõned postijärjekorra funktsioonid hõlpsamini rakendatavad. Selle kogukond on tugev ja küps ning arvatakse, et see on peamine probleem. Taasesitus on põhikontseptsioon. Selle arhitektuur on siiski keeruline ja hõlmab ZooKeeperi kvoorumit. Valisime ka selle.

RocketMQ on paljutõotav, äsja sündinud Apache-projekt. Hoolimata headest esitustest ja muljetavaldavast funktsioonikomplektist, pole kogukond siiski eriti küps, peamiselt Alibaba ettevõtte ümber. Projekt on alles väljatöötamisel. Seega otsustasime kõigist selle eelistest hoolimata, et selle valimine pole tark valik.

Artemis on HornetQ, annetatud sihtasutusele Apache ja vastu võetud projekti ActiveMQ poolt. Kindel sõnumijärjekord, kuid selle koondamine on kahjuks raske. Kaasatud on mõned vana kooli tehnikad (sealhulgas XML!). Seega otsustasime edasist uurimist mitte jätkata.

NSQ on detsentraliseeritud sõnumsidesüsteem. Meie soovitud sõnumside mudeleid toetatakse, kuid ainult häkkimine võimaldab saavutada * vastupidavuse *. Klastrimine on peamine kodanike mõiste, kuid funktsioonide hinnaga. AMQP-d ei toetata, ega korrata. Otsustasime, et sinna siirdamise kulusid ei tasu tasuda.

Ja siis lisame valida

Kafka ja RabbitMQ vahel puhkes sõda.

Ükski ülaltoodud tehnoloogiatest ei võimalda Jamesi vajadusi rahuldaval viisil täita, samal ajal meie tootmisstandarditele vastavaks. Seega otsustasime Jamesi funktsioonid valikust välja jätta. E-posti järjekorra täpsemad võimalused rakendatakse koos sõnumijärjekorra / andmebaasi kombinatsiooniga.

Seejärel hakkas meie strateegia koos POC-ga uurima RabbitMQ kasutamise piiranguid.

  • Pakkusime RabbitMQ peale OpenPaaS-i kasutamise juhtumite POC-d
  • Tegime katsed dokitud rabbitMQ klastri peal: peatusime sõlmed, tootsime ja tarbime erinevatel sõlmedel, kuulutasime vahetusi ja järjekordi erinevatel sõlmedel.
  • Testisime vastupidavust, tootmise / tarbimise järjekorda.

Strateegiline koosolek annab siis teada, kas me soovime Kafkasse kolida.