Kasaysayan ng Dodo IS Architecture: The Back Office Path

Binabago ni Habr ang mundo. Mahigit isang taon na kaming nagba-blog. Mga anim na buwan na ang nakalipas nakatanggap kami ng medyo lohikal na feedback mula sa mga residente ng Khabrovsk: “Dodo, sinasabi mo kahit saan na mayroon kang sariling sistema. Anong klaseng sistema ito? At bakit kailangan ito ng pizzeria chain?"

Umupo kami at nag-isip at napagtanto namin na tama ka. Sinusubukan naming ipaliwanag ang lahat gamit ang aming mga daliri, ngunit lumalabas ito sa mga punit-punit na piraso at walang buong paglalarawan ng system kahit saan. Kaya nagsimula ang mahabang paglalakbay ng pagkolekta ng impormasyon, paghahanap ng mga may-akda at pagsulat ng serye ng mga artikulo tungkol sa Dodo IS. Tara na!

Mga Pasasalamat: Salamat sa pagbabahagi ng iyong feedback sa amin. Salamat sa kanya, inilarawan namin sa wakas ang system, nag-compile ng isang technoradar, at malapit nang maglabas ng malaking paglalarawan ng aming mga proseso. Kung wala ka, 5 years pa kaming uupo ng ganito.

Serye ng mga artikulong "Ano ang Dodo IS?" nagsasabi tungkol sa:

1. Maagang monolith sa Dodo IS (2011-2015). (Isinasagawa...)
2. Backoffice path: magkahiwalay na base at bus. (Narito ka)
3. Ang landas sa gilid ng kliyente: harapan sa ibabaw ng base (2016-2017). (Isinasagawa...)
4. Ang kasaysayan ng mga tunay na microservice. (2018-2019). (Isinasagawa...)
5. Natapos ang paglalagari ng monolith at pagpapapanatag ng arkitektura. (Isinasagawa...)

Kung interesado kang matuto ng iba pa, sumulat sa mga komento.

Opinyon sa kronolohikal na paglalarawan mula sa may-akda
Ako ay regular na nagdaraos ng isang pulong para sa mga bagong empleyado sa paksang "System Architecture". Tinatawag namin itong "Intro sa Dodo IS Architecture" at bahagi ito ng proseso ng onboarding para sa mga bagong developer. Ang pakikipag-usap sa isang anyo o iba pa tungkol sa aming arkitektura, tungkol sa mga tampok nito, bumuo ako ng isang tiyak na makasaysayang diskarte sa paglalarawan.

Ayon sa kaugalian, tinitingnan namin ang isang sistema bilang isang hanay ng mga bahagi (teknikal o mas mataas na antas), mga module ng negosyo na nakikipag-ugnayan sa isa't isa upang makamit ang ilang layunin. At habang ang ganitong pananaw ay makatwiran para sa disenyo, hindi ito ganap na angkop para sa paglalarawan at pag-unawa. Mayroong ilang mga kadahilanan:

• Iba ang realidad sa nasa papel. Hindi lahat ay gumagana ayon sa plano. At kami ay interesado sa kung paano aktwal na naging at gumagana ang lahat.
• Pare-parehong paglalahad ng impormasyon. Sa katunayan, maaari kang pumunta ayon sa pagkakasunod-sunod mula sa simula hanggang sa kasalukuyang estado.
• Mula sa simple hanggang sa kumplikado. Hindi unibersal, ngunit sa aming kaso ito ay gayon. Ang arkitektura ay lumipat mula sa mas simpleng paraan patungo sa mas kumplikado. Kadalasan, sa pamamagitan ng komplikasyon, ang mga problema sa bilis at katatagan ng pagpapatupad, pati na rin ang dose-dosenang iba pang mga pag-aari mula sa listahan ng mga di-functional na kinakailangan (dito mahusay na pinag-uusapan tungkol sa contrasting complexity sa iba pang mga kinakailangan).

Noong 2011, ganito ang hitsura ng arkitektura ng Dodo IS:

Pagsapit ng 2020, naging mas kumplikado ito at naging ganito:

Paano nangyari ang ebolusyon na ito? Bakit kailangan ang iba't ibang bahagi ng system? Anong mga desisyon sa arkitektura ang ginawa at bakit? Alamin natin sa seryeng ito ng mga artikulo.

Ang mga unang problema ng 2016: bakit dapat umalis ang mga serbisyo sa monolith?

Ang mga unang artikulo sa serye ay tungkol sa mga serbisyo na unang humiwalay sa monolith. Para mailagay ka sa konteksto, sasabihin ko sa iyo kung anong mga problema namin sa system sa simula ng 2016, na kinailangan naming harapin ang paghihiwalay ng mga serbisyo.

Isang solong database ng MySql kung saan isinulat ng lahat ng application na umiiral sa Dodo IS ang kanilang mga talaan noong panahong iyon. Ang mga kahihinatnan ay:

• Mabigat na pagkarga (na may 85% ng mga kahilingan na binabasa).
• Lumalaki ang base. Dahil dito, naging isyu ang gastos at suporta.
• Isang punto ng kabiguan. Kung ang isang application na sumusulat sa database ay biglang nagsimulang gawin ito nang mas aktibo, pagkatapos ay naramdaman ng ibang mga application ang epekto.
• Inefficiency sa storage at mga query. Kadalasan ang data ay nakaimbak sa ilang istraktura na maginhawa para sa ilang mga sitwasyon ngunit hindi para sa iba. Pinapabilis ng mga index ang ilang operasyon, ngunit maaaring pabagalin ang iba.
• Ang ilan sa mga problema ay nalutas sa pamamagitan ng dali-daling ginawang mga cache at read-replicas sa mga database (tatalakayin ito sa isang hiwalay na artikulo), ngunit pinahintulutan lamang nila kaming makakuha ng oras at hindi nalutas sa panimula ang problema.

Ang problema ay ang pagkakaroon ng monolith mismo. Ang mga kahihinatnan ay:

• Natatangi at bihirang paglabas.
• Ang kahirapan ay sa collaborative development ng isang malaking bilang ng mga tao.
• Kawalan ng kakayahang magpakilala ng mga bagong teknolohiya, bagong frameworks at library.

Ang mga problema sa base at monolith ay inilarawan nang maraming beses, halimbawa, sa konteksto ng mga pag-crash sa unang bahagi ng 2018 (Maging tulad ng Munch, o ilang salita tungkol sa teknikal na utang, Ang araw na huminto si Dodo IS. Asynchronous na script и Ang kwento ng ibong Dodo mula sa pamilya Phoenix. Ang Great Fall of the Dodo IS), kaya hindi na ako magtatagal. Sabihin ko lang na gusto naming magbigay ng higit na kakayahang umangkop kapag bumubuo ng mga serbisyo. Una sa lahat, ito ay nag-aalala sa mga pinaka-load at root sa buong system - Auth at Tracker.

Ang Back Office Path: Magkahiwalay na Base at Bus

Pag-navigate sa Kabanata

1. Scheme ng monolith 2016
2. Nagsisimula kaming i-unload ang monolith: paghihiwalay ng Auth at Tracker
   
3. Ano ang ginagawa ni Auth?
4. Saan nanggagaling ang mga load?
5. Pagbabawas ng Auth
6. Ano ang ginagawa ng Tracker?
7. Saan nanggagaling ang mga load?
8. Pag-unload ng Tracker

Scheme ng monolith 2016

Narito ang mga pangunahing bloke ng 2016 Dodo IS monolith, at sa ibaba lamang ay isang breakdown ng kanilang mga pangunahing gawain.

Delivery cash desk. Accounting para sa mga courier, nag-isyu ng mga order sa mga courier.
Contact center. Pagtanggap ng mga order sa pamamagitan ng operator.
Lugar. Ang aming mga website (dodopizza.ru, dodopizza.co.uk, dodopizza.by, atbp.).
May-akda. Serbisyo ng awtorisasyon at pagpapatunay para sa backoffice.
Трекер. Tagasubaybay ng order sa kusina. Serbisyo para sa pagmamarka ng mga katayuan ng pagiging handa kapag naghahanda ng isang order.
Cash desk ng restaurant. Pagkuha ng mga order sa isang restaurant, mga interface ng cashier.
I-export. Pag-upload ng mga ulat sa 1C para sa accounting.
Mga alerto at invoice. Mga voice command sa kusina (halimbawa, "Dumating na ang bagong pizza") + pag-print ng mga invoice para sa mga courier.
Tagapamahala ng Shift. Mga interface para sa trabaho ng isang shift manager: listahan ng mga order, productivity chart, pagdadala ng mga empleyado sa mga shift.
Tagapamahala ng Opisina. Mga interface para sa gawain ng mga franchisee at tagapamahala: pagtanggap ng mga empleyado, mga ulat sa gawain ng pizzeria.
Lupon ng restawran. Pagpapakita ng mga menu sa mga TV sa mga pizzeria.
Admin. Mga setting para sa isang partikular na pizzeria: menu, mga presyo, accounting, mga code na pang-promosyon, mga promosyon, mga banner para sa site, atbp.
Personal na Account ng Empleyado. Mga iskedyul ng trabaho ng empleyado, impormasyon tungkol sa mga empleyado.
Lupon ng Pagganyak sa Kusina. Isang hiwalay na screen na nakasabit sa kusina at ipinapakita ang bilis ng mga gumagawa ng pizza.
Pakikipag-usap. Nagpapadala ng sms at email.
FileStorage. Sariling serbisyo para sa pagtanggap at pag-isyu ng mga static na file.

Ang mga unang pagtatangka na lutasin ang mga problema ay nakatulong sa amin, ngunit ang mga ito ay pansamantalang pahinga lamang. Hindi sila naging mga solusyon sa sistema, kaya malinaw na may kailangang gawin sa mga base. Halimbawa, hatiin ang pangkalahatang database sa ilang higit pang dalubhasa.

Nagsisimula kaming i-unload ang monolith: paghihiwalay ng Auth at Tracker

Ang mga pangunahing serbisyo na pagkatapos ay sumulat at nagbasa mula sa database nang higit sa iba:

1. Awth. Serbisyo ng awtorisasyon at pagpapatunay para sa backoffice.
2. Tagasubaybay. Tagasubaybay ng order sa kusina. Serbisyo para sa pagmamarka ng mga katayuan ng pagiging handa kapag naghahanda ng isang order.

Ano ang ginagawa ni Auth?

Ang Auth ay isang serbisyo kung saan nag-log in ang mga user sa back office (mayroong hiwalay na independiyenteng pag-log in sa panig ng kliyente). Ito ay isinangguni din sa kahilingan upang matiyak na ang mga tamang karapatan sa pag-access ay naroroon at ang mga karapatang ito ay hindi nagbago mula noong huling pag-login. Ang mga device ay pumapasok sa mga pizzeria sa pamamagitan nito.

Halimbawa, gusto naming magbukas ng display na may status ng mga nakumpletong order sa TV na nakasabit sa hall. Pagkatapos ay binuksan namin ang auth.dodopizza.ru, piliin ang "Mag-login bilang device", lilitaw ang isang code na maaaring maipasok sa isang espesyal na pahina sa computer ng shift manager, na nagpapahiwatig ng uri ng device (device). Ang TV mismo ay pupunta sa nais na interface ng pizzeria nito at magsisimulang ipakita doon ang mga pangalan ng mga customer na handa na ang mga order.

Saan nanggagaling ang mga load?

Ang bawat naka-log-in na backoffice na gumagamit ay pumupunta sa database para sa bawat kahilingan, sa talahanayan ng gumagamit, hinila ang user mula doon sa pamamagitan ng isang sql query at tinitingnan kung mayroon siyang kinakailangang access at mga karapatan sa pahinang ito.

Pareho lang ang ginagawa ng bawat isa sa mga device sa talahanayan ng device, sinusuri ang papel nito at ang mga access nito. Ang isang malaking bilang ng mga kahilingan sa master database ay humahantong sa paglo-load at pag-aaksaya ng mga pangkalahatang mapagkukunan ng database sa mga operasyong ito.

Pagbabawas ng Auth

Ang Auth ay may nakahiwalay na domain, iyon ay, ang data tungkol sa mga user, mga login o device ay pumapasok sa serbisyo (kasalukuyang hinaharap) at nananatili doon. Kung may nangangailangan sa kanila, pupunta siya sa serbisyong ito para sa data.

AY. Ang daloy ng trabaho sa una ay ganito:

Gusto kong ipaliwanag nang kaunti kung paano ito gumana:

1. Dumating ang isang panlabas na kahilingan sa backend (Asp.Net MVC doon), na may dalang cookie ng session, na ginagamit upang makakuha ng data ng session mula sa Redis(1). Maaaring naglalaman ito ng impormasyon tungkol sa mga pag-access, at pagkatapos ay bukas ang access sa controller (3,4), o hindi.
2. Kung walang access, kailangan mong dumaan sa pamamaraan ng awtorisasyon. Dito, para sa pagiging simple, ito ay ipinapakita bilang bahagi ng landas sa parehong katangian, kahit na ito ay isang paglipat sa pahina ng pag-login. Sa kaso ng isang positibong senaryo, makakatanggap kami ng isang session na napuno nang tama at pupunta sa Backoffice Controller.
3. Kung mayroong data, kailangan mong suriin ito para sa kaugnayan sa database ng gumagamit. Nagbago na ba ang role niya, hindi ba dapat siya payagan sa page ngayon? Sa kasong ito, pagkatapos matanggap ang session (1), kailangan mong direktang pumunta sa database at suriin ang access ng user gamit ang authentication logic layer (2). Susunod, pumunta sa pahina ng pag-login o pumunta sa controller. Ito ay isang simpleng sistema, ngunit hindi ganap na pamantayan.
4. Kung ang lahat ng mga pamamaraan ay nakumpleto, pagkatapos ay laktawan namin ang higit pa sa lohika sa mga controllers at pamamaraan.

Ang data ng user ay pinaghihiwalay mula sa lahat ng iba pang data, ito ay naka-imbak sa isang hiwalay na talahanayan ng pagiging miyembro, ang mga function mula sa AuthService logic layer ay maaaring maging mga pamamaraan ng API. Ang mga hangganan ng domain ay malinaw na tinukoy: ang mga gumagamit, ang kanilang mga tungkulin, pag-access ng data, pagpapalabas at pagbawi ng pag-access. Ang lahat ay mukhang maaari itong ilipat sa isang hiwalay na serbisyo.

NAGING. Iyon ang ginawa nila:

Ang diskarte na ito ay may ilang mga problema. Halimbawa, ang pagtawag sa isang paraan sa loob ng isang proseso ay hindi katulad ng pagtawag sa isang panlabas na serbisyo sa pamamagitan ng http. Ang latency, reliability, supportability, at transparency ng operasyon ay ganap na naiiba. Si Andrey Morevsky ay nagsalita nang mas detalyado tungkol sa eksaktong mga problemang ito sa kanyang ulat "50 shade ng microservices".

Ang serbisyo ng pagpapatunay at kasama nito ang serbisyo ng device ay ginagamit para sa back office, iyon ay, para sa mga serbisyo at mga interface na ginagamit sa produksyon. Ang pagpapatotoo para sa mga serbisyo ng kliyente (tulad ng isang website o mobile application) ay nangyayari nang hiwalay nang hindi gumagamit ng Auth. Humigit-kumulang isang taon ang paghihiwalay, at ngayon ay muli kaming nagtatrabaho sa paksang ito, inililipat ang system sa mga bagong serbisyo sa pagpapatunay (na may mga karaniwang protocol).

Bakit nagtagal ang paghihiwalay?
Maraming problema sa daan na nagpabagal sa amin:

1. Nais naming ilipat ang data tungkol sa mga user, device at pagpapatotoo mula sa mga database ng bansa sa isa. Para magawa ito, kinailangan naming ilipat ang lahat ng mga talahanayan at paggamit mula sa int identifier patungo sa pandaigdigang UUId identifier (kamakailan naming muling ginawa ang code na ito Roman Bukin "Uuid - ang malaking kwento ng isang maliit na istraktura" at open-source na proyekto Primitives). Ang pag-iimbak ng data ng user (dahil ito ay personal na impormasyon) ay may mga limitasyon at para sa ilang mga bansa ay kinakailangan itong iimbak nang hiwalay. Ngunit dapat mayroong pandaigdigang user ID.
2. Maraming mga talahanayan sa database ang may impormasyon sa pag-audit tungkol sa user na nagsagawa ng operasyon. Nangangailangan ito ng karagdagang mekanismo upang matiyak ang pagkakapare-pareho.
3. Pagkatapos ng paglikha ng mga serbisyo ng API, nagkaroon ng mahaba at unti-unting panahon ng paglipat sa ibang system. Ang mga switch ay kailangang mangyari nang walang putol para sa mga user at kinakailangang manu-manong trabaho.

Scheme para sa pagpaparehistro ng isang device sa isang pizzeria:

Pangkalahatang arkitektura pagkatapos paghiwalayin ang serbisyo ng Auth at Mga Device:

Nota. Para sa 2020, gumagawa kami ng bagong bersyon ng Auth, na nakabatay sa pamantayan ng awtorisasyon ng OAuth 2.0. Ang pamantayang ito ay medyo kumplikado, ngunit kapaki-pakinabang para sa pagbuo ng isang end-to-end na serbisyo sa pagpapatunay. Sa artikulong "Mga subtlety ng awtorisasyon: pangkalahatang-ideya ng teknolohiya ng OAuth 2.0» sinubukan naming pag-usapan ni Alexey Chernyaev ang pamantayan nang simple at malinaw hangga't maaari upang makatipid ka ng oras sa pag-aaral nito.

Ano ang ginagawa ng Tracker?

Ngayon tungkol sa pangalawa ng mga na-load na serbisyo. Ang tracker ay gumaganap ng dalawahang tungkulin:

• Sa isang banda, ang gawain nito ay ipakita sa mga empleyado sa kusina kung anong mga order ang kasalukuyang isinasagawa, kung anong mga produkto ang kailangang ihanda ngayon.
• Sa kabilang banda, i-digitize ang lahat ng proseso sa kusina.

Kapag lumitaw ang isang bagong produkto (halimbawa, pizza) sa isang order, pupunta ito sa "Rolling" tracker station. Sa istasyong ito mayroong isang tagagawa ng pizza na kumukuha ng isang tinapay na may kinakailangang laki at igulong ito, pagkatapos nito ay minarkahan niya sa tracker tablet na nakumpleto na niya ang kanyang gawain at ipinapasa ang inilunsad na dough base sa susunod na istasyon - "Pagpupuno" .

Doon, ang susunod na gumagawa ng pizza ay nangunguna sa pizza, pagkatapos ay minarkahan sa tablet na nakumpleto na niya ang kanyang gawain at inilalagay ang pizza sa oven (ito ay isa ring hiwalay na istasyon na kailangang markahan sa tablet). Ang ganitong sistema ay naroroon sa simula pa lamang sa Dodo at sa simula pa lamang ng Dodo IS. Pinapayagan ka nitong ganap na subaybayan at i-digitize ang lahat ng mga operasyon. Bilang karagdagan, ang tagasubaybay ay nagmumungkahi kung paano maghanda ng isang partikular na produkto, isinasagawa ang bawat uri ng produkto ayon sa sarili nitong mga scheme ng pagmamanupaktura, iniimbak ang pinakamainam na oras ng pagluluto para sa produkto, at sinusubaybayan ang lahat ng mga operasyon sa produkto.

Ito ang hitsura ng screen ng tablet sa istasyon ng Raskatka tracker.

Saan nanggagaling ang mga load?

Ang bawat pizzeria ay may mga limang tablet na may tracker. Noong 2016 mayroon kaming higit sa 100 pizzeria (at ngayon ay mayroon nang higit sa 600). Ang bawat isa sa mga tablet ay humihiling sa backend bawat 10 segundo at nangongolekta ng data mula sa talahanayan ng order (link sa kliyente at address), komposisyon ng order (link sa produkto at indikasyon ng dami), at talahanayan ng pagganyak (sinusubaybayan nito ang oras ng pagpindot). Kapag nag-click ang gumagawa ng pizza sa isang produkto sa tracker, ina-update ang mga tala sa lahat ng talahanayang ito. Ang talahanayan ng order ay pangkalahatan; sabay-sabay itong naglalaman ng mga pagpapasok kapag tumatanggap ng isang order, mga update mula sa iba pang mga bahagi ng system, at maraming mga pagbabasa, halimbawa, sa isang TV na nakabitin sa isang pizzeria at nagpapakita ng mga handa na order sa mga customer.

Sa panahon ng pakikibaka sa mga naglo-load, nang ang lahat at ang lahat ay na-cache at inilipat sa isang asynchronous na kopya ng database, ang mga operasyong ito kasama ang tracker ay nagpatuloy na pumunta sa master database. Dapat walang lag dito, dapat up-to-date ang data, hindi katanggap-tanggap ang out of sync.

Gayundin, ang kakulangan ng aming sariling mga talahanayan at mga index sa mga ito ay hindi nagpapahintulot sa amin na magsulat ng mas partikular na mga query na iniakma para sa aming paggamit. Halimbawa, maaaring maging epektibo para sa isang tracker na magkaroon ng index para sa isang pizzeria sa talahanayan ng mga order nito. Palagi kaming nag-scrape ng mga order ng pizzeria mula sa database ng tracker. Kasabay nito, upang tanggapin ang isang order, hindi napakahalaga kung saang pizzeria ito nahuhulog, ang mas mahalaga ay kung aling kliyente ang gumawa ng order na ito. Nangangahulugan ito na kailangang mayroong index sa kliyente. Hindi rin kailangan para sa tracker na iimbak ang id ng naka-print na resibo o mga promo ng bonus na nauugnay sa order sa talahanayan ng order. Ang aming serbisyo ng tracker ay hindi interesado sa impormasyong ito. Sa isang karaniwang monolitikong database, ang mga talahanayan ay maaari lamang maging isang kompromiso sa pagitan ng lahat ng mga gumagamit. Ito ay isa sa mga orihinal na problema.

AY. Sa una ang arkitektura ay ganito:

Kahit na pagkatapos na ihiwalay sa magkakahiwalay na proseso, karamihan sa base ng code ay nanatiling karaniwan sa iba't ibang serbisyo. Ang lahat ng nasa ibaba ng mga controller ay pinag-isa at nanirahan sa isang repositoryo. Ang mga karaniwang pamamaraan ng mga serbisyo, mga repositoryo, at isang karaniwang database na naglalaman ng mga karaniwang talahanayan ay ginamit.

Pag-unload ng Tracker

Ang pangunahing problema sa tracker ay ang data ay dapat na naka-synchronize sa pagitan ng iba't ibang mga database. Ito rin ang pangunahing pagkakaiba nito mula sa dibisyon ng serbisyo ng Auth; ang pagkakasunud-sunod at ang katayuan nito ay maaaring magbago at dapat na ipakita sa iba't ibang mga serbisyo.

Tumatanggap kami ng mga order sa Restaurant Checkout (ito ay isang serbisyo), ito ay nakaimbak sa database sa katayuang "Tinanggap". Pagkatapos nito, dapat itong pumunta sa tracker, kung saan babaguhin nito ang katayuan nito nang maraming beses: mula sa "Kusina" hanggang sa "Naka-pack". Sa kasong ito, maaaring mangyari ang ilang panlabas na impluwensya mula sa Cashier o sa interface ng Shift Manager sa order. Ibibigay ko ang mga katayuan ng order kasama ang kanilang mga paglalarawan sa talahanayan:

Ang scheme ng pagbabago ng status ng order ay ganito ang hitsura:

Ang mga katayuan ay nagbabago sa pagitan ng iba't ibang mga sistema. At dito ang tracker ay hindi ang huling sistema kung saan naka-lock ang data. Nakita namin ang ilang posibleng paraan para sa paghihiwalay sa ganitong kaso:

1. Itinutuon namin ang lahat ng pagkilos ng order sa isang serbisyo. Sa aming kaso, ang pagpipiliang ito ay nangangailangan ng masyadong maraming serbisyo upang maproseso ang order. Kung kami ay tumigil doon, kami ay natapos sa isang pangalawang monolith. Hindi namin nalutas ang mga problema.
2. Ang isang sistema ay tumatawag sa isa pa. Ang pangalawang pagpipilian ay mas kawili-wili. Ngunit kasama nito, posible ang mga kadena ng mga tawag (mga pagkabigo ng cascading), ang pagkakakonekta ng mga bahagi ay mas mataas, at ito ay mas mahirap pangasiwaan.
3. Nag-aayos kami ng mga kaganapan, at ang bawat serbisyo ay nagpapalitan sa isa't isa sa pamamagitan ng mga kaganapang ito. Bilang isang resulta, ang pangatlong opsyon ay pinili, ayon sa kung saan ang lahat ng mga serbisyo ay nagsisimulang makipagpalitan ng mga kaganapan sa bawat isa.

Ang katotohanan na pinili namin ang pangatlong opsyon ay nangangahulugan na ang tracker ay magkakaroon ng sarili nitong database, at para sa bawat pagbabago sa pagkakasunud-sunod ay magpapadala ito ng kaganapan tungkol dito, kung saan magsu-subscribe ang iba pang mga serbisyo at isasama rin sa master database. Para magawa ito, kailangan namin ng ilang serbisyo na magtitiyak sa paghahatid ng mga mensahe sa pagitan ng mga serbisyo.

Sa oras na iyon, mayroon na kaming RabbitMQ sa stack, kaya ang huling desisyon na gamitin ito bilang isang broker ng mensahe. Ipinapakita ng diagram ang paglipat ng isang order mula sa Restaurant Cashier sa pamamagitan ng Tracker, kung saan binago nito ang status nito at ang pagpapakita nito sa interface ng Manager's Orders. NAGING:

Mag-order ng landas nang hakbang-hakbang
Magsisimula ang path ng order sa isa sa mga serbisyo ng pinagmulan ng order. Narito ang Restaurant Cashier:

1. Ganap na handa ang order sa Checkout, at oras na para ipadala ito sa tracker. Ang kaganapan kung saan naka-subscribe ang tracker ay itinapon.
2. Ang tracker, na tumatanggap ng isang order, ay nagse-save nito sa sarili nitong database, ginagawa ang kaganapang "Order Accepted by Tracker" at ipinapadala ito sa RMQ.
3. Naka-subscribe na ang ilang handler sa custom na event bus. Para sa amin, ang isa na nag-synchronize sa monolithic database ay mahalaga.
4. Natanggap ng handler ang kaganapan, pinipili mula dito ang data na mahalaga para dito: sa aming kaso, ito ang katayuan ng order na "Tinanggap ng Tracker" at ina-update ang entity ng order nito sa pangunahing database.

Kung kailangan ng isang tao ng isang order na partikular mula sa talahanayan ng mga monolitikong order, maaari rin nilang basahin ito mula doon. Halimbawa, ito ang kailangan ng interface ng Mga Order sa Shift Manager:

Ang lahat ng iba pang mga serbisyo ay maaari ding mag-subscribe upang mag-order ng mga kaganapan mula sa tracker upang magamit ang mga ito para sa kanilang sarili.

Kung pagkaraan ng ilang oras ay kinuha ang isang order sa produksyon, ang katayuan nito ay unang nagbabago sa database nito (Tracker database), at pagkatapos ay ang kaganapang "OrderInWork" ay agad na nabuo. Pumapasok din ito sa RMQ, kung saan ito ay naka-synchronize sa isang monolitikong database at inihatid sa iba pang mga serbisyo. Maaaring may iba't ibang problema sa landas na ito; ang higit pang mga detalye tungkol sa mga ito ay matatagpuan sa ulat ni Zhenya Peshkov tungkol sa mga detalye ng pagpapatupad ng Eventual Consistency sa Tracker.

Panghuling arkitektura pagkatapos ng mga pagbabago sa Auth at Tracker

Upang ibuod: Sa una, nagkaroon ako ng ideya na i-package ang siyam na taong kasaysayan ng Dodo IS system sa isang artikulo. Nais kong mabilis at simpleng pag-usapan ang mga yugto ng ebolusyon. Gayunpaman, nang maupo upang pag-aralan ang materyal, napagtanto ko na ang lahat ay mas kumplikado at kawili-wili kaysa sa tila.

Sa pagninilay-nilay sa mga benepisyo (o kakulangan nito) ng naturang materyal, ako ay dumating sa konklusyon na ang tuluy-tuloy na pag-unlad ay imposible nang walang ganap na mga salaysay ng mga kaganapan, detalyadong retrospective at pagsusuri ng mga nakaraang desisyon ng isang tao.

Umaasa ako na nakita mong kapaki-pakinabang at kawili-wiling malaman ang tungkol sa aming paglalakbay. Ngayon ay nahaharap ako sa isang pagpipilian kung aling bahagi ng sistema ng Dodo IS ang ilalarawan sa susunod na artikulo: sumulat sa mga komento o bumoto.

Ang mga rehistradong user lamang ang maaaring lumahok sa survey. Mag-sign in, pakiusap

Anong bahagi ng Dodo IS ang gusto mong matutunan sa susunod na artikulo?

• 24,1%Maagang monolith sa Dodo IS (2011-2015)14

• 24,1%Mga unang problema at mga solusyon nito (2015-2016)14

• 20,7%Landas ng bahagi ng kliyente: facade sa itaas ng base (2016-2017)12

• 36,2%Kasaysayan ng mga totoong microservice (2018-2019)21

• 44,8%Nakumpleto ang pagputol ng monolith at pagpapapanatag ng arkitektura26

• 29,3%Tungkol sa karagdagang mga plano para sa pagpapaunlad ng sistema17

• 19,0%Wala akong gustong malaman tungkol sa Dodo IS11

58 user ang bumoto. 6 na user ang umiwas.

Pinagmulan: www.habr.com