Kasaysayan ng Arkitektura ng Dodo IS: Isang Maagang Monolith

O ang bawat malungkot na kumpanya na may monolith ay hindi masaya sa sarili nitong paraan.

Ang pagbuo ng Dodo IS system ay nagsimula kaagad, tulad ng negosyo ng Dodo Pizza, noong 2011. Ito ay batay sa ideya ng kumpleto at kabuuang digitization ng mga proseso ng negosyo, at sa kanilang sarili, na kahit noong 2011 ay nagdulot ng maraming katanungan at pag-aalinlangan. Ngunit sa loob ng 9 na taon ngayon ay sinusunod namin ang landas na ito - sa aming sariling pag-unlad, na nagsimula sa isang monolith.

Ang artikulong ito ay isang "sagot" sa mga tanong na "Bakit muling isulat ang arkitektura at gumawa ng mga malakihan at pangmatagalang pagbabago?" bumalik sa nakaraang artikulo "Kasaysayan ng Arkitektura ng Dodo IS: Ang Daan ng Back Office". Magsisimula ako sa kung paano nagsimula ang pagbuo ng Dodo IS, kung paano ang hitsura ng orihinal na arkitektura, kung paano lumitaw ang mga bagong module, at dahil sa kung anong mga problema ang kailangang gawin ng malalaking pagbabago.

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

1. Maagang monolith sa Dodo IS (2011-2015). (Narito ka)

2. Ang Back Office Path: Magkahiwalay na Base at Bus.

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...)

Paunang arkitektura

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

Ang unang module sa arkitektura ay ang pagtanggap ng order. Ang proseso ng negosyo ay:

• ang kliyente ay tumawag sa pizzeria;

• kinuha ng manager ang telepono;

• tumatanggap ng isang order sa pamamagitan ng telepono;

• pinupuno ito nang kahanay sa interface ng pagtanggap ng order: isinasaalang-alang nito ang impormasyon tungkol sa kliyente, data sa mga detalye ng order, address ng paghahatid. 

Ang interface ng sistema ng impormasyon ay mukhang ganito ...

Unang bersyon mula Oktubre 2011:

Bahagyang napabuti noong Enero 2012

Dodo Pizza Information System Delivery Pizza Restaurant

Ang mga mapagkukunan para sa pagbuo ng unang order na pagkuha ng module ay limitado. Marami kaming kailangang gawin, mabilis at may maliit na koponan. Ang isang maliit na team ay 2 developer na naglatag ng pundasyon para sa buong hinaharap na sistema.

Tinukoy ng kanilang unang desisyon ang kapalaran ng stack ng teknolohiya:

• Backend sa ASP.NET MVC, C# na wika. Ang mga developer ay dotnetchiki, ang stack na ito ay pamilyar at kaaya-aya sa kanila.

• Frontend sa Bootstrap at JQuery: mga user interface sa mga self-written na estilo at script. 

• MySQL database: walang gastos sa lisensya, madaling gamitin.

• Mga server sa Windows Server, dahil ang .NET noon ay maaari lamang sa ilalim ng Windows (hindi namin tatalakayin ang Mono).

Sa pisikal, ang lahat ng ito ay ipinahayag sa "dedic at the hoster". 

Arkitektura ng Application Intake ng Order

Pagkatapos ay pinag-uusapan na ng lahat ang tungkol sa mga microservice, at ginamit ang SOA sa malalaking proyekto sa loob ng 5 taon, halimbawa, inilabas ang WCF noong 2006. Ngunit pagkatapos ay pinili nila ang isang maaasahan at napatunayang solusyon.

Heto na.

Ang Asp.Net MVC ay Razor, na, kapag hiniling mula sa isang form o mula sa isang kliyente, ay nag-render ng isang HTML na pahina na may pag-render ng server. Sa kliyente, ang mga script ng CSS at JS ay nagpapakita na ng impormasyon at, kung kinakailangan, nagsasagawa ng mga kahilingan sa AJAX sa pamamagitan ng JQuery.

Ang mga kahilingan sa server ay napupunta sa mga *Controller classes, kung saan ang pagproseso at pagbuo ng panghuling pahina ng HTML ay nagaganap sa pamamaraan. Gumagawa ang mga controllers ng mga kahilingan sa isang layer ng logic na tinatawag na *Services. Ang bawat isa sa mga serbisyo ay tumutugma sa ilang aspeto ng negosyo:

• Halimbawa, ang DepartmentStructureService ay nagbigay ng impormasyon sa mga pizzeria, sa mga departamento. Ang departamento ay isang pangkat ng mga pizzeria na pinapatakbo ng iisang franchisee.

• Ang ReceivingOrdersService ay tinanggap at kinakalkula ang komposisyon ng order.

• At nagpadala ang SmsService ng SMS sa pamamagitan ng pagtawag sa mga serbisyo ng API upang magpadala ng SMS.

Pinoproseso ng mga serbisyo ang data mula sa database, nakaimbak na lohika ng negosyo. Ang bawat serbisyo ay may isa o higit pang *Repositories na may naaangkop na pangalan. Naglalaman na sila ng mga query sa mga naka-imbak na pamamaraan sa database at isang layer ng mga mapper. Nagkaroon ng lohika ng negosyo sa mga storage, lalo na sa mga nag-isyu ng data ng pag-uulat. Hindi ginamit ang ORM, lahat ay umasa sa hand-written sql. 

Nagkaroon din ng layer ng modelo ng domain at mga karaniwang klase ng helper, halimbawa, ang klase ng Order na nag-imbak ng order. Sa parehong lugar, sa layer, mayroong isang katulong para sa pag-convert ng display text ayon sa napiling pera.

Ang lahat ng ito ay maaaring kinakatawan ng tulad ng isang modelo:

Paraan ng Order

Isaalang-alang ang isang pinasimple na paunang paraan upang lumikha ng ganoong order.

Sa una, ang site ay static. May mga presyo ito, at sa itaas - isang numero ng telepono at ang inskripsiyon na "Kung gusto mo ng pizza - tawagan ang numero at mag-order." Upang mag-order, kailangan naming ipatupad ang isang simpleng daloy: 

• Bumisita ang kliyente sa isang static na site na may mga presyo, pumipili ng mga produkto at tumawag sa numerong nakalista sa site.

• Pinangalanan ng customer ang mga produkto na gusto nilang idagdag sa order.

• Ibinigay ang kanyang address at pangalan.

• Tinatanggap ng operator ang order.

• Ang order ay ipinapakita sa tinatanggap na interface ng mga order.

Nagsisimula ang lahat sa pagpapakita ng menu. Ang isang naka-log-in na user-operator ay tumatanggap lamang ng isang order sa isang pagkakataon. Samakatuwid, ang draft cart ay maaaring maimbak sa kanyang session (ang session ng user ay nakaimbak sa memorya). May Cart object na naglalaman ng mga produkto at impormasyon ng customer.

Pinangalanan ng customer ang produkto, nag-click ang operator + sa tabi ng produkto, at isang kahilingan ang ipinadala sa server. Ang impormasyon tungkol sa produkto ay kinukuha mula sa database at ang impormasyon tungkol sa produkto ay idinaragdag sa cart.

Nota. Oo, dito hindi mo maaaring hilahin ang produkto mula sa database, ngunit ilipat ito mula sa frontend. Ngunit para sa kalinawan, ipinakita ko nang eksakto ang landas mula sa database. 

Susunod, ipasok ang address at pangalan ng kliyente. 

Kapag na-click mo ang "Gumawa ng Order":

• Ang kahilingan ay ipinadala sa OrderController.SaveOrder().

• Kumuha kami ng Cart mula sa session, may mga produkto sa dami na kailangan namin.

• Dinadagdagan namin ang Cart ng impormasyon tungkol sa kliyente at ipinapasa ito sa paraan ng AddOrder ng ReceivingOrderService na klase, kung saan ito naka-save sa database. 

• Ang database ay may mga talahanayan na may pagkakasunud-sunod, ang komposisyon ng order, ang kliyente, at lahat sila ay konektado.

• Napupunta ang interface ng pagpapakita ng order at kinukuha ang mga pinakabagong order at ipinapakita ang mga ito.

Mga bagong module

Ang pagkuha ng order ay mahalaga at kailangan. Hindi ka makakagawa ng negosyo ng pizza kung wala kang order na ibenta. Samakatuwid, nagsimulang makakuha ng pag-andar ang system - humigit-kumulang mula 2012 hanggang 2015. Sa panahong ito, maraming iba't ibang mga bloke ng system ang lumitaw, na tatawagin ko mga module, taliwas sa konsepto ng serbisyo o produkto. 

Ang module ay isang hanay ng mga function na pinagsama ng ilang karaniwang layunin sa negosyo. Kasabay nito, sila ay pisikal na nasa parehong aplikasyon.

Ang mga module ay maaaring tawaging mga bloke ng system. Halimbawa, ito ay isang module ng pag-uulat, mga interface ng admin, tagasubaybay ng pagkain sa kusina, awtorisasyon. Ang mga ito ay lahat ng iba't ibang mga interface ng gumagamit, ang ilan ay may iba't ibang mga visual na estilo. Kasabay nito, ang lahat ay nasa loob ng balangkas ng isang aplikasyon, isang prosesong tumatakbo. 

Sa teknikal, ang mga module ay idinisenyo bilang Area (ang ganoong ideya ay nanatili pa rin sa asp.net core). Mayroong hiwalay na mga file para sa frontend, mga modelo, pati na rin ang kanilang sariling mga klase ng controller. Bilang isang resulta, ang sistema ay binago mula dito ...

... sa ito:

Ang ilang mga module ay ipinatupad sa pamamagitan ng hiwalay na mga site (maipapatupad na proyekto), dahil sa isang ganap na hiwalay na pag-andar at bahagyang dahil sa isang bahagyang hiwalay, mas nakatutok na pag-unlad. ito:

• Lugar - unang bersyon site dodopizza.ru.

• I-export: pag-upload ng mga ulat mula sa Dodo IS para sa 1C. 

• Personal - personal na account ng empleyado. Ito ay binuo nang hiwalay at may sariling entry point at hiwalay na disenyo.

• fs — isang proyekto para sa hosting statics. Nang maglaon ay lumayo kami rito, inilipat ang lahat ng static sa Akamai CDN. 

Ang natitirang mga bloke ay nasa BackOffice application. 

Pagpapaliwanag ng pangalan:

• Cashier - Kahera ng restawran.

• ShiftManager - mga interface para sa papel na "Shift Manager": mga istatistika ng pagpapatakbo sa mga benta ng pizzeria, ang kakayahang maglagay ng mga produkto sa listahan ng hintuan, baguhin ang pagkakasunud-sunod.

• OfficeManager - mga interface para sa mga tungkuling "Pizzeria Manager" at "Franchisee". Narito ang mga nakolektang function para sa pag-set up ng isang pizzeria, mga promosyon ng bonus nito, pagtanggap at pagtatrabaho sa mga empleyado, mga ulat.

• PublicScreens - mga interface para sa mga TV at tablet na nakabitin sa mga pizzeria. Ang mga TV ay nagpapakita ng mga menu, impormasyon sa advertising, katayuan ng order sa paghahatid. 

Gumamit sila ng isang karaniwang layer ng serbisyo, isang karaniwang Dodo.Core domain class block, at isang karaniwang base. Minsan maaari pa rin silang manguna sa mga paglipat sa isa't isa. Kabilang ang mga indibidwal na site, gaya ng dodopizza.ru o personal.dodopizza.ru, ay napunta sa mga pangkalahatang serbisyo.

Nang lumitaw ang mga bagong module, sinubukan naming muling gamitin ang nagawa nang code ng mga serbisyo, mga naka-imbak na pamamaraan at mga talahanayan sa database sa maximum. 

Para sa mas mahusay na pag-unawa sa sukat ng mga module na ginawa sa system, narito ang isang diagram mula 2012 na may mga plano sa pagpapaunlad:

Sa pamamagitan ng 2015, lahat ay nasa mapa at higit pa ay nasa produksyon.

• Ang pagtanggap ng order ay lumago sa isang hiwalay na bloke ng Contact Center, kung saan ang order ay tinatanggap ng operator.

• May mga pampublikong screen na may mga menu at impormasyon na nakasabit sa mga pizzeria.

• Ang kusina ay may module na awtomatikong nagpe-play ng voice message na "Bagong Pizza" kapag may dumating na bagong order, at nagpi-print din ng invoice para sa courier. Ito ay lubos na pinapasimple ang mga proseso sa kusina, pinapayagan ang mga empleyado na hindi magambala ng isang malaking bilang ng mga simpleng operasyon.

• Ang unit ng paghahatid ay naging isang hiwalay na Delivery Checkout, kung saan ang order ay ibinigay sa courier na dating kumuha ng shift. Ang kanyang oras ng pagtatrabaho ay isinasaalang-alang para sa pagkalkula ng suweldo. 

Kaayon, mula 2012 hanggang 2015, higit sa 10 developer ang lumitaw, 35 pizzeria ang nagbukas, nag-deploy ng system sa Romania at naghanda para sa pagbubukas ng mga outlet sa Estados Unidos. Ang mga developer ay hindi na humarap sa lahat ng mga gawain, ngunit nahahati sa mga koponan. bawat isa ay nagdadalubhasa sa sarili nitong bahagi ng sistema. 

Mga Problema

Kasama dahil sa arkitektura (ngunit hindi lamang).

Kaguluhan sa base

Ang isang base ay maginhawa. Ang pagkakapare-pareho ay maaaring makamit dito, at sa gastos ng mga tool na binuo sa mga relational database. Ang pagtatrabaho dito ay pamilyar at maginhawa, lalo na kung mayroong ilang mga talahanayan at maliit na data.

Ngunit sa paglipas ng 4 na taon ng pag-unlad, ang database ay lumabas na may humigit-kumulang 600 mga talahanayan, 1500 na nakaimbak na mga pamamaraan, na marami sa mga ito ay mayroon ding lohika. Sa kasamaang palad, ang mga naka-imbak na pamamaraan ay hindi nagdudulot ng maraming kalamangan kapag nagtatrabaho sa MySQL. Hindi sila naka-cache ng base, at ang pag-iimbak ng lohika sa mga ito ay nagpapalubha sa pag-unlad at pag-debug. Mahirap din ang muling paggamit ng code.

Maraming mga talahanayan ang walang angkop na mga index, sa isang lugar, sa kabaligtaran, mayroong maraming mga index, na nagpahirap sa pagpasok. Kinakailangang baguhin ang humigit-kumulang 20 talahanayan - ang transaksyon upang lumikha ng isang order ay maaaring tumagal nang humigit-kumulang 3-5 segundo. 

Ang data sa mga talahanayan ay hindi palaging nasa pinakaangkop na anyo. Sa isang lugar ito ay kinakailangan upang gawin ang denormalization. Ang bahagi ng regular na natatanggap na data ay nasa isang column sa anyo ng isang XML na istraktura, pinataas nito ang oras ng pagpapatupad, pinahaba ang mga query at kumplikado ang pagbuo.

Sa parehong mga talahanayan ay ginawa napaka magkakaibang mga kahilingan. Lalo na nagdusa ang mga sikat na talahanayan, tulad ng talahanayang nabanggit sa itaas. order o mga mesa pizzeria. Ginamit ang mga ito upang ipakita ang mga interface ng pagpapatakbo sa kusina, analytics. Nakipag-ugnayan sa kanila ang isa pang site (dodopizza.ru), kung saan sa anumang oras ay maaaring biglang dumating ang maraming kahilingan. 

Ang data ay hindi pinagsama-sama at maraming kalkulasyon ang naganap sa mabilisang gamit ang base. Lumikha ito ng mga hindi kinakailangang kalkulasyon at karagdagang pagkarga. 

Kadalasan ang code ay napupunta sa database kapag hindi ito nagawa. Sa isang lugar na walang sapat na maramihang pagpapatakbo, sa isang lugar na kakailanganing ikalat ang isang kahilingan sa ilan sa pamamagitan ng code upang mapabilis at mapataas ang pagiging maaasahan. 

Cohesion at obfuscation sa code

Ang mga module na dapat ay responsable para sa kanilang bahagi ng negosyo ay hindi ginawa ito nang tapat. Ang ilan sa kanila ay nagkaroon ng pagdoble ng mga tungkulin para sa mga tungkulin. Halimbawa, ang isang lokal na nagmemerkado na responsable para sa aktibidad ng marketing ng network sa kanyang lungsod ay kailangang gumamit ng parehong interface ng "Admin" (upang lumikha ng mga promosyon) at ang interface ng "Office Manager" (upang tingnan ang epekto ng mga promosyon sa negosyo). Siyempre, sa loob ng parehong mga module ay ginamit ang parehong serbisyo na nagtrabaho sa mga promosyon ng bonus.

Ang mga serbisyo (mga klase sa loob ng isang monolitikong malaking proyekto) ay maaaring tumawag sa isa't isa upang pagyamanin ang kanilang data.

Sa mismong mga klase ng modelo na nag-iimbak ng data, ang trabaho sa code ay natupad sa ibang paraan. Sa isang lugar mayroong mga konstruktor kung saan posible na tukuyin ang mga kinakailangang field. Sa isang lugar ito ay ginawa sa pamamagitan ng mga pampublikong pag-aari. Siyempre, ang pagkuha at pagbabago ng data mula sa database ay iba-iba. 

Ang lohika ay nasa mga controller o sa mga klase ng serbisyo. 

Ang mga ito ay tila maliliit na isyu, ngunit lubos nilang pinabagal ang pag-unlad at pinababa ang kalidad, na humahantong sa kawalang-tatag at mga bug. 

Ang pagiging kumplikado ng isang malaking pag-unlad

Ang mga paghihirap ay lumitaw sa mismong pag-unlad. Kinakailangan na gumawa ng iba't ibang mga bloke ng system, at kahanay. Ang paglalagay ng mga pangangailangan ng bawat bahagi sa isang solong code ay naging lalong mahirap. Hindi madaling sumang-ayon at mangyaring lahat ng mga bahagi nang sabay-sabay. Idinagdag dito ang mga limitasyon sa teknolohiya, lalo na tungkol sa base at frontend. Kinailangan na iwanan ang jQuery patungo sa mga high-level na framework, lalo na sa mga tuntunin ng mga serbisyo ng kliyente (website).

Sa ilang bahagi ng system, maaaring gamitin ang mga database na mas angkop para dito.. Halimbawa, nang maglaon ay nagkaroon kami ng kaso ng paggamit ng paglipat mula sa Redis patungo sa CosmosDB upang mag-imbak ng basket ng order. 

Ang mga koponan at developer na kasangkot sa kanilang larangan ay malinaw na nais ng higit na awtonomiya para sa kanilang mga serbisyo, kapwa sa mga tuntunin ng pag-unlad at paglulunsad. Pagsamahin ang mga salungatan, ilabas ang mga isyu. Kung para sa 5 mga developer ang problemang ito ay hindi gaanong mahalaga, kung gayon sa 10, at higit pa sa nakaplanong paglago, ang lahat ay magiging mas seryoso. At sa unahan ay ang pagbuo ng isang mobile application (nagsimula ito noong 2017, at noong 2018 ito ay malaking pagkahulog). 

Ang iba't ibang bahagi ng system ay nangangailangan ng iba't ibang antas ng katatagan, ngunit dahil sa malakas na pagkakakonekta ng system, hindi namin ito maibigay. Ang isang error sa pagbuo ng isang bagong function sa admin panel ay maaaring naganap sa pagtanggap ng isang order sa site, dahil ang code ay karaniwan at magagamit muli, ang database at data ay pareho din.

Posibleng maiwasan ang mga pagkakamali at problemang ito sa loob ng balangkas ng naturang monolithic-modular na arkitektura: gumawa ng dibisyon ng responsibilidad, refactor ang code at database, malinaw na paghiwalayin ang mga layer sa isa't isa, subaybayan ang kalidad araw-araw. Ngunit ang mga napiling solusyon sa arkitektura at ang pagtutok sa mabilis na pagpapalawak ng functionality ng system ay humantong sa mga problema sa mga tuntunin ng katatagan.

Paano inilalagay ng Power of the Mind blog ang mga cash register sa mga restaurant

Kung ang paglago ng network ng pizzeria (at pag-load) ay nagpatuloy sa parehong bilis, pagkatapos ng ilang sandali ang talon ay magiging tulad na ang sistema ay hindi tumaas. Mahusay na naglalarawan ng mga problema na sinimulan nating harapin noong 2015, narito ang isang kuwento. 

Sa blog"Kapangyarihan ng isip” ay isang widget na nagpakita ng data sa kita para sa taon ng buong network. Na-access ng widget ang Dodo public API, na nagbibigay ng data na ito. Ang istatistikang ito ay kasalukuyang magagamit sa http://dodopizzastory.com/. Ang widget ay ipinakita sa bawat pahina at gumawa ng mga kahilingan sa isang timer bawat 20 segundo. Napunta ang kahilingan sa api.dodopizza.ru at hiniling:

• ang bilang ng mga pizzeria sa network;

• kabuuang kita ng network mula noong simula ng taon;

• kita para sa araw na ito.

Ang kahilingan para sa mga istatistika sa kita ay dumiretso sa database at nagsimulang humiling ng data sa mga order, pagsasama-sama ng data sa mabilisang at pagbibigay ng halaga. 

Ang mga cash desk sa mga restaurant ay pumunta sa parehong talahanayan ng mga order, naglabas ng listahan ng mga order na natanggap para sa araw na ito, at ang mga bagong order ay idinagdag dito. Ginawa ng mga cash register ang kanilang mga kahilingan tuwing 5 segundo o sa pag-refresh ng pahina.

Ang diagram ay ganito ang hitsura:

Isang taglagas, sumulat si Fyodor Ovchinnikov ng isang mahaba at tanyag na artikulo sa kanyang blog. Maraming tao ang pumunta sa blog at sinimulang basahin nang mabuti ang lahat. Habang binabasa ng bawat isa sa mga taong dumating ang artikulo, gumagana nang maayos ang widget ng kita at humiling ng API bawat 20 segundo.

Ang API ay tumawag ng nakaimbak na pamamaraan upang kalkulahin ang kabuuan ng lahat ng mga order mula noong simula ng taon para sa lahat ng pizzeria sa network. Ang pagsasama-sama ay batay sa talahanayan ng mga order, na napakapopular. Ang lahat ng mga cash desk ng lahat ng bukas na restaurant sa oras na iyon ay pumunta dito. Ang mga cash desk ay tumigil sa pagtugon, ang mga order ay hindi tinanggap. Hindi rin sila tinanggap mula sa site, hindi lumitaw sa tracker, hindi sila nakikita ng shift manager sa kanyang interface. 

Hindi lang ito ang kwento. Sa taglagas ng 2015, tuwing Biyernes ang pag-load sa system ay kritikal. Ilang beses naming pinatay ang pampublikong API, at minsan, kinailangan pa naming i-off ang site, dahil walang nakatulong. Nagkaroon pa nga ng listahan ng mga serbisyong may shutdown order sa ilalim ng mabibigat na karga.

Mula ngayon, ang aming pakikibaka sa mga naglo-load at para sa pagpapapanatag ng system ay nagsisimula (mula taglagas 2015 hanggang taglagas 2018). Noon nangyari yun"malaking pagkahulog". Dagdag pa, ang mga pagkabigo ay minsan din naganap, ang ilan ay napakasensitibo, ngunit ang pangkalahatang panahon ng kawalang-tatag ay maaari na ngayong ituring na lumipas.

Mabilis na paglago ng negosyo

Bakit hindi ito magawa kaagad? Tingnan lamang ang mga sumusunod na tsart.

Noong 2014-2015 din ay nagkaroon ng opening sa Romania at inihahanda ang opening sa USA.

Mabilis na lumago ang network, binuksan ang mga bagong bansa, lumitaw ang mga bagong format ng pizzeria, halimbawa, binuksan ang isang pizzeria sa food court. Ang lahat ng ito ay nangangailangan ng makabuluhang pansin partikular sa pagpapalawak ng mga function ng Dodo IS. Kung wala ang lahat ng mga pag-andar na ito, nang walang pagsubaybay sa kusina, pag-account para sa mga produkto at pagkalugi sa system, pagpapakita ng pagpapalabas ng isang order sa food court hall, halos hindi namin pag-uusapan ang "tama" na arkitektura at ang "tama" na diskarte sa pag-unlad ngayon.

Ang isa pang hadlang sa napapanahong rebisyon ng arkitektura at sa pangkalahatan ay ang atensyon sa mga teknikal na problema ay ang krisis ng 2014. Ang mga bagay na tulad nito ay tumama nang husto sa mga pagkakataon para sa mga koponan na lumago, lalo na para sa isang batang negosyo tulad ng Dodo Pizza.

Mabilis na Solusyon na Nakatulong

Ang mga problema ay nangangailangan ng solusyon. Conventionally, ang mga solusyon ay maaaring nahahati sa 2 grupo:

• Mga mabilis na napatay ang apoy at nagbibigay ng maliit na margin ng kaligtasan at binibigyan tayo ng oras upang magbago.

• Systemic at, samakatuwid, mahaba. Reengineering ng isang bilang ng mga module, paghahati ng isang monolitikong arkitektura sa magkakahiwalay na mga serbisyo (karamihan sa kanila ay hindi lahat ng micro, ngunit sa halip ay mga serbisyong macro, at mayroong isang bagay tungkol dito Ang ulat ni Andrey Morevskiy). 

Ang tuyong listahan ng mga mabilisang pagbabago ay ang mga sumusunod:

I-scale up ang base master

Siyempre, ang unang bagay na ginagawa upang makitungo sa mga naglo-load ay upang madagdagan ang kapasidad ng server. Ginawa ito para sa master database at para sa mga web server. Sa kasamaang palad, ito ay posible lamang hanggang sa isang tiyak na limitasyon, pagkatapos ito ay nagiging masyadong mahal.

Mula noong 2014, lumipat kami sa Azure, isinulat din namin ang tungkol sa paksang ito sa oras na iyon sa artikulong "Paano Naghahatid ng Pizza ang Dodo Pizza Gamit ang Microsoft Azure Cloud". Ngunit pagkatapos ng isang serye ng mga pagtaas sa server para sa base, sila ay dumating laban sa gastos. 

Base replika para sa pagbabasa

Dalawang replika ang ginawa para sa base:

ReadReplica para sa mga kahilingan sa sanggunian. Ito ay ginagamit upang basahin ang mga direktoryo, uri, lungsod, kalye, pizzeria, mga produkto (dahan-dahang binago ang domain), at sa mga interface kung saan ang isang maliit na pagkaantala ay katanggap-tanggap. Mayroong 2 sa mga replika na ito, tiniyak namin ang kanilang kakayahang magamit sa parehong paraan tulad ng mga masters.

ReadReplica para sa Mga Kahilingan sa Ulat. Ang database na ito ay may mas mababang kakayahang magamit, ngunit lahat ng mga ulat ay napunta dito. Hayaan silang magkaroon ng mabibigat na kahilingan para sa malaking recalculations ng data, ngunit hindi ito nakakaapekto sa pangunahing database at mga interface ng pagpapatakbo. 

Mga cache sa code

Walang mga cache saanman sa code (sa lahat). Ito ay humantong sa karagdagang, hindi palaging kinakailangan, mga kahilingan sa na-load na database. Ang mga cache ay una sa parehong nasa memorya at sa isang panlabas na serbisyo ng cache, iyon ay Redis. Ang lahat ay hindi wasto ng oras, ang mga setting ay tinukoy sa code.

Maramihang backend server

Ang backend ng application ay kailangan ding i-scale para mahawakan ang mga tumaas na workload. Kinailangan na gumawa ng isang kumpol mula sa isang iis-server. Nag-reschedule kami sesyon ng aplikasyon mula sa memorya hanggang sa RedisCache, na naging posible na gumawa ng ilang mga server sa likod ng isang simpleng load balancer na may round robin. Sa una, ang parehong Redis ay ginamit bilang para sa mga cache, pagkatapos ay nahati ito sa ilan. 

Bilang isang resulta, ang arkitektura ay naging mas kumplikado ...

… ngunit naalis ang ilan sa tensyon.

At pagkatapos ay kinakailangan na gawing muli ang mga na-load na bahagi, na aming ginawa. Pag-uusapan natin ito sa susunod na bahagi.

Pinagmulan: www.habr.com