Eða hvert óánægt fyrirtæki með einliða er óánægt á sinn hátt.
Þróun Dodo IS kerfisins hófst strax, eins og Dodo Pizza viðskiptin, árið 2011. Það var byggt á hugmyndinni um fullkomna og algera stafrænni viðskiptaferla, og , sem jafnvel þá árið 2011 olli miklum spurningum og tortryggni. En í 9 ár höfum við fylgt þessari braut - með okkar eigin þróun, sem hófst með einlitum.
Þessi grein er "svar" við spurningunum "Af hverju að endurskrifa arkitektúrinn og gera svona stórar og langtímabreytingar?" aftur í fyrri grein . Ég ætla að byrja á því hvernig þróun Dodo IS hófst, hvernig upprunalegi arkitektúrinn leit út, hvernig nýjar einingar birtust og vegna hvaða vandamála þurfti að gera stórfelldar breytingar.
Greinaröð "Hvað er Dodo IS?" segir frá:
-
Snemma monolith í Dodo IS (2011-2015). (þú ert hér)
-
.
-
Slóð viðskiptavinarins: framhlið yfir grunninn (2016-2017). (Í vinnslu...)
-
Saga sannrar örþjónustu. (2018-2019). (Í vinnslu...)
-
Lokið við sagun á einlitum og stöðugleika arkitektúrsins. (Í vinnslu...)
Upphafleg arkitektúr
Árið 2011 leit Dodo IS arkitektúrinn svona út:
Fyrsta einingin í arkitektúrnum er pöntunarsamþykki. Viðskiptaferlið var:
-
viðskiptavinurinn hringir á pítsustaðinn;
-
framkvæmdastjórinn tekur upp símann;
-
tekur við pöntun í síma;
-
fyllir það samhliða í pöntunarviðmótinu: tekið er tillit til upplýsinga um viðskiptavininn, upplýsingar um pöntunarupplýsingar, afhendingarheimilis.
Viðmót upplýsingakerfisins leit einhvern veginn svona út ...
Fyrsta útgáfa frá október 2011:
Tilföng til þróunar á fyrstu pöntunareiningunni voru takmörkuð. Við þurftum að gera mikið, fljótt og með litlu teymi. Lítið teymi eru 2 þróunaraðilar sem lögðu grunninn að öllu framtíðarkerfinu.
Fyrsta ákvörðun þeirra réð örlögum tæknibunkans:
-
Bakendi á ASP.NET MVC, C# tungumáli. Hönnuðir voru dotnetchiki, þessi stafli var kunnuglegur og skemmtilegur fyrir þá.
-
Frontend á Bootstrap og JQuery: notendaviðmót á sjálfskrifuðum stílum og skriftum.
-
MySQL gagnagrunnur: enginn leyfiskostnaður, auðvelt í notkun.
-
Servers á Windows Server, því .NET gæti þá aðeins verið undir Windows (við munum ekki ræða Mono).
Líkamlega kom þetta allt fram í „dedic at the hoster“.
Arkitektúr pöntunarinntöku umsóknar
Þá voru allir að tala um örþjónustur og SOA var notað í stórum verkefnum í 5 ár, til dæmis kom WCF út árið 2006. En þá völdu þeir áreiðanlega og sannaða lausn.
Hérna er það.
Asp.Net MVC er Razor, sem, samkvæmt beiðni frá eyðublaði eða frá viðskiptavin, gerir HTML síðu með miðlara flutningi. Á biðlaranum sýna CSS og JS forskriftir þegar upplýsingar og, ef nauðsyn krefur, framkvæma AJAX beiðnir í gegnum JQuery.
Beiðnir á þjóninum lenda í *Controller flokkum, þar sem vinnsla og gerð loka HTML síðunnar fer fram í aðferðinni. Stýringar gera beiðnir um lag af rökfræði sem kallast *Þjónusta. Hver þjónusta samsvaraði einhverjum þáttum fyrirtækisins:
-
Til dæmis, DepartmentStructureService gaf út upplýsingar um pizzerias, um deildir. Deild er hópur pítsustaða sem rekinn er af einum sérleyfishafa.
-
ReceivingOrdersService samþykkti og reiknaði út samsetningu pöntunarinnar.
-
Og SmsService sendi SMS með því að hringja í API þjónustu til að senda SMS.
Þjónusta unnu gögn úr gagnagrunninum, geymd viðskiptarökfræði. Hver þjónusta hafði eina eða fleiri *Geymslur með viðeigandi nafni. Þær innihéldu þegar fyrirspurnir að geymdum verklagsreglum í gagnagrunninum og lag af kortara. Það var viðskiptarökfræði í geymslunum, sérstaklega mikið í þeim sem gáfu út skýrslugögn. ORM var ekki notað, allir treystu á handskrifaða sql.
Það var líka lag af lénslíkaninu og algengum hjálparflokkum, til dæmis Order flokkurinn sem geymdi pöntunina. Á sama stað, í laginu, var hjálpartæki til að umbreyta birtingartexta í samræmi við valinn gjaldmiðil.
Allt þetta er hægt að tákna með slíku líkani:
Panta leið
Íhugaðu einfaldaða upphaflega leið til að búa til slíka pöntun.
Upphaflega var vefurinn kyrrstæður. Það voru verð á því og ofan á - símanúmer og áletrunina "Ef þú vilt pizzu - hringdu í númerið og pantaðu." Til að panta þurfum við að útfæra einfalt flæði:
-
Viðskiptavinurinn heimsækir kyrrstæða síðu með verðum, velur vörur og hringir í númerið sem skráð er á síðunni.
-
Viðskiptavinurinn nefnir vörurnar sem hann vill bæta við pöntunina.
-
Gefur upp heimilisfang sitt og nafn.
-
Rekstraraðili samþykkir pöntunina.
-
Pöntunin birtist í viðmóti samþykktra pantana.
Það byrjar allt með því að sýna valmyndina. Innskráður notandi-rekstraraðili tekur aðeins við einni pöntun í einu. Þess vegna er hægt að geyma drög að körfu í lotunni hans (lota notandans er geymd í minni). Það er körfuhlutur sem inniheldur vörur og upplýsingar um viðskiptavini.
Viðskiptavinurinn nefnir vöruna, rekstraraðilinn smellir á + við hliðina á vörunni og beiðni er send á netþjóninn. Upplýsingar um vöruna eru dregnar út úr gagnagrunninum og upplýsingum um vöruna bætt í körfuna.
Athugið. Já, hér er ekki hægt að draga vöruna úr gagnagrunninum, heldur flytja hana frá framendanum. En til glöggvunar sýndi ég nákvæmlega leiðina úr gagnagrunninum.
Næst skaltu slá inn heimilisfang og nafn viðskiptavinar.
Þegar þú smellir á "Búa til pöntun":
-
Beiðnin er send til OrderController.SaveOrder().
-
Við fáum körfu frá fundinum, það eru vörur í því magni sem við þurfum.
-
Við bætum við körfunni með upplýsingum um viðskiptavininn og sendum þær í AddOrder aðferðina í ReceivingOrderService bekknum, þar sem þær eru vistaðar í gagnagrunninn.
-
Gagnagrunnurinn hefur töflur með pöntuninni, samsetningu pöntunarinnar, viðskiptavininn og þær eru allar tengdar.
-
Pöntunarviðmótið fer og dregur út nýjustu pantanir og sýnir þær.
Nýjar einingar
Það var mikilvægt og nauðsynlegt að taka við pöntuninni. Þú getur ekki stundað pizzuviðskipti ef þú ert ekki með pöntun til að selja. Þess vegna byrjaði kerfið að öðlast virkni - um það bil frá 2012 til 2015. Á þessum tíma birtust margar mismunandi blokkir kerfisins, sem ég mun kalla einingar, öfugt við hugtakið þjónustu eða vara.
Eining er mengi aðgerða sem eru sameinuð af einhverju sameiginlegu viðskiptamarkmiði. Á sama tíma eru þeir líkamlega í sama forritinu.
Einingar má kalla kerfisblokkir. Til dæmis er þetta skýrslugerðareining, stjórnendaviðmót, , heimild. Þetta eru allt mismunandi notendaviðmót, sum hafa jafnvel mismunandi sjónrænan stíl. Á sama tíma er allt innan ramma eins umsóknar, eins keyrandi ferlis.
Tæknilega séð voru einingarnar hannaðar sem svæði (slík hugmynd var jafnvel áfram í ). Það voru aðskildar skrár fyrir framenda, gerðir, sem og eigin stýringarflokka. Fyrir vikið var kerfinu breytt úr þessu ...
... inn í þetta:
Sumar einingar eru útfærðar af aðskildum vefsvæðum (executable verkefni), vegna algjörlega aðskildrar virkni og að hluta til vegna örlítið aðskildrar, markvissari þróunar. Þetta:
-
Vefsíða - síða dodopizza.ru.
-
útflutningur: hleður upp skýrslum frá Dodo IS fyrir 1C.
-
Starfsfólk - persónulegur reikningur starfsmanns. Það var þróað sérstaklega og hefur sinn aðgangsstað og sérstaka hönnun.
-
fs - verkefni til að hýsa truflanir. Seinna fluttum við frá því og færðum allar truflanir yfir á Akamai CDN.
Restin af kubbunum voru í BackOffice forritinu.
Útskýring á nafni:
-
Gjaldkeri - Gjaldkeri á veitingastað.
-
ShiftManager - viðmót fyrir "Shift Manager" hlutverkið: rekstrartölfræði um sölu pizzustaðanna, hæfni til að setja vörur á stöðvunarlista, breyta röð.
-
OfficeManager - viðmót fyrir "Pizzeria Manager" og "Franchisee" hlutverkin. Hér eru safnaðar aðgerðir til að setja upp pítsustað, bónuskynningar þess, móttöku og vinnu með starfsmönnum, skýrslum.
-
PublicScreens - tengi fyrir sjónvörp og spjaldtölvur sem hanga á pítsustöðum. Sjónvörp sýna valmyndir, auglýsingaupplýsingar, pöntunarstöðu við afhendingu.
Þeir notuðu sameiginlegt þjónustulag, sameiginlegan Dodo.Core lénsflokksblokk og sameiginlegan grunn. Stundum gátu þeir samt leitt umskiptin til hvors annars. Þar á meðal einstakar síður, eins og dodopizza.ru eða personal.dodopizza.ru, fóru í almenna þjónustu.
Þegar nýjar einingar birtust reyndum við að endurnýta þegar búið til þjónustukóða, geymdar aðferðir og töflur í gagnagrunninum að hámarki.
Til að fá betri skilning á umfangi eininga sem gerðar eru í kerfinu er hér skýringarmynd frá 2012 með þróunaráætlunum:
Árið 2015 var allt komið á kortið og enn meira í framleiðslu.
-
Samþykki pöntunar hefur vaxið í sérstakan blokk í tengiliðamiðstöðinni, þar sem pöntunin er samþykkt af símafyrirtækinu.
-
Það voru opinberir skjáir með matseðlum og fróðleik hangandi á pítsustöðum.
-
Í eldhúsinu er eining sem spilar sjálfkrafa raddskilaboðin „Ný pizza“ þegar ný pöntun berst og prentar einnig út reikning fyrir sendimanninn. Þetta einfaldar mjög ferlana í eldhúsinu, gerir starfsmönnum kleift að láta ekki trufla sig af miklum fjölda einfaldra aðgerða.
-
Sendingareiningin varð að sérstakri afhendingarstöð, þar sem pöntunin var gefin út til sendiboðans sem hafði áður tekið vaktina. Tekið var tillit til vinnutíma hans við launaútreikning.
Samhliða, frá 2012 til 2015, birtust meira en 10 verktaki, 35 pítsuhús opnuðu, sendu kerfið til Rúmeníu og undirbjuggu opnun verslana í Bandaríkjunum. Hönnuðir sinntu ekki lengur öllum verkefnum heldur var þeim skipt í teymi. hver sérhæfði sig í sínum hluta kerfisins.
Vandamál
Þar á meðal vegna arkitektúrsins (en ekki aðeins).
Ringulreið í grunninum
Einn grunnur er þægilegur. Hægt er að ná samræmi í því og á kostnað verkfæra sem eru innbyggð í venslagagnagrunna. Vinna með það er kunnuglegt og þægilegt, sérstaklega ef það eru fáar töflur og lítil gögn.
En yfir 4 ára þróun reyndist gagnagrunnurinn hafa um það bil 600 töflur, 1500 vistaðar aðferðir, margar hverjar höfðu líka rökfræði. Því miður, geymdar aðferðir hafa ekki mikla kosti þegar unnið er með MySQL. Þau eru ekki í skyndiminni af grunninum og að geyma rökfræði í þeim flækir þróun og villuleit. Endurnotkun kóða er líka erfið.
Margar töflur voru ekki með viðeigandi vísitölum, einhvers staðar, þvert á móti, var mikið af vísitölum, sem gerði það erfitt að setja inn. Það var nauðsynlegt að breyta um 20 töflum - viðskiptin til að búa til pöntun gætu tekið um 3-5 sekúndur.
Gögnin í töflunum voru ekki alltaf á viðeigandi formi. Einhvers staðar var nauðsynlegt að gera afeðlun. Hluti af þeim gögnum sem fengust reglulega var í dálki í formi XML uppbyggingu, þetta jók framkvæmdartímann, lengdi fyrirspurnirnar og flækti þróunina.
Til sömu borðum voru framleidd mjög ólíkar beiðnir. Vinsæl borð þjáðust sérstaklega, eins og borðið sem nefnt er hér að ofan. pantanir eða borðum Pizzeria. Þau voru notuð til að sýna rekstrarviðmót í eldhúsinu, greiningar. Önnur síða hafði samband við þá (), þar sem á hverjum tíma gætu allt í einu komið margar beiðnir.
Gögnin voru ekki tekin saman og margir útreikningar fóru fram á flugu með því að nota grunninn. Þetta skapaði óþarfa útreikninga og aukið álag.
Oft fór kóðinn í gagnagrunninn þegar hann gat ekki gert það. Einhvers staðar væri ekki nóg af magnaðgerðum, einhvers staðar þyrfti að dreifa einni beiðni í nokkrar í gegnum kóðann til að flýta fyrir og auka áreiðanleika.
Samheldni og rugl í kóða
Einingar sem áttu að bera ábyrgð á sínum hluta af starfseminni gerðu það ekki heiðarlega. Sumir þeirra höfðu tvíverknað í hlutverkum. Til dæmis þurfti staðbundinn markaðsmaður sem er ábyrgur fyrir markaðsvirkni netkerfisins í sinni borg að nota bæði „Admin“ viðmótið (til að búa til kynningar) og „Office Manager“ viðmótið (til að skoða áhrif kynninga á fyrirtækið). Auðvitað notaði inni í báðum einingum sömu þjónustuna og virkaði með bónuskynningum.
Þjónusta (flokkar innan eins einhæfs stórs verkefnis) gætu hringt hver í aðra til að auðga gögn sín.
Með líkanaflokkunum sjálfum sem geyma gögn, vinna í kóðanum var unnin á annan hátt. Einhvers staðar voru smiðir þar sem hægt var að tilgreina nauðsynlega reiti. Einhvers staðar var þetta gert í gegnum opinberar eignir. Auðvitað var margvíslegt að fá og umbreyta gögnum úr gagnagrunninum.
Rökfræðin var annað hvort í stýringum eða þjónustuflokkunum.
Þetta virðast vera minniháttar vandamál, en þau hægðu mjög á þróun og lækkuðu gæði, sem leiddi til óstöðugleika og galla.
Flækjustig stórrar þróunar
Erfiðleikar komu upp í þróuninni sjálfri. Það var nauðsynlegt að gera mismunandi blokkir af kerfinu, og samhliða. Það varð sífellt erfiðara að passa þarfir hvers íhluta í einn kóða. Það var ekki auðvelt að vera sammála og gleðja alla þættina á sama tíma. Við þetta bættust takmarkanir í tækni, sérstaklega með tilliti til grunns og framenda. Það var nauðsynlegt að yfirgefa jQuery í átt að ramma á háu stigi, sérstaklega hvað varðar þjónustu við viðskiptavini (vefsíðu).
Sums staðar í kerfinu mætti nota gagnagrunna sem henta betur fyrir þetta.. Til dæmis, seinna áttum við það notagildi að flytja frá Redis til CosmosDB til að geyma pöntunarkörfu.
Teymi og þróunaraðilar sem taka þátt á sínu sviði vildu greinilega meira sjálfræði fyrir þjónustu sína, bæði hvað varðar þróun og útsetningu. Sameina átök, losa vandamál. Ef fyrir 5 verktaki er þetta vandamál óverulegt, þá með 10, og jafnvel meira með fyrirhuguðum vexti, myndi allt verða alvarlegra. Og framundan átti að vera þróun farsímaforrits (það byrjaði árið 2017 og árið 2018 var það ).
Mismunandi hlutar kerfisins kröfðust mismunandi stöðugleika, en vegna sterkrar tengingar kerfisins gátum við ekki veitt þetta. Villa í þróun nýrrar aðgerðar í stjórnborðinu gæti vel hafa átt sér stað í samþykki pöntunar á síðunni, því kóðinn er algengur og endurnýtanlegur, gagnagrunnurinn og gögnin eru líka þau sömu.
Líklega væri hægt að komast hjá þessum mistökum og vandamálum innan ramma slíkrar einhæfrar mátbyggingar: gera ábyrgðarskiptingu, endurnýja bæði kóðann og gagnagrunninn, aðgreina lögin greinilega frá hvort öðru, fylgjast með gæðum á hverjum degi. En byggingarlausnirnar sem voru valdar og áherslan á hraða útvíkkun á virkni kerfisins leiddu til vandamála hvað varðar stöðugleika.
Hvernig Power of the Mind bloggið setti sjóðvélarnar á veitingahúsum
Ef vöxtur pizzerianetsins (og álagsins) héldi áfram á sama hraða, þá myndu lækkanirnar eftir smá stund verða slíkar að kerfið myndi ekki hækka. Sýnir vel vandamálin sem við byrjuðum að standa frammi fyrir árið 2015, hér er slík saga.
Í blogginu "” var búnaður sem sýndi gögn um tekjur fyrir árið á öllu netinu. Græjan fékk aðgang að Dodo public API, sem veitir þessi gögn. Þessi tölfræði er nú aðgengileg kl . Græjan var sýnd á hverri síðu og óskaði eftir tímamæli á 20 sekúndna fresti. Beiðnin fór á api.dodopizza.ru og bað um:
-
fjöldi pizzerias í netinu;
-
heildartekjur netkerfisins frá áramótum;
-
tekjur í dag.
Beiðnin um tölfræði um tekjur fór beint í gagnagrunninn og byrjaði að biðja um gögn um pantanir, safna gögnum á flugu og gefa út upphæðina.
Afgreiðsluborð á veitingastöðum fóru í sömu pantanatöflu, affermdu lista yfir pantanir sem bárust fyrir daginn í dag og nýjum pöntunum var bætt við. Kassavélar sendu beiðnir sínar á 5 sekúndna fresti eða á síðu endurnýjun.
Skýringarmyndin leit svona út:
Eitt haust skrifaði Fjodor Ovchinnikov langa og vinsæla grein á bloggið sitt. Margir komu á bloggið og fóru að lesa allt vel. Á meðan allir sem komu voru að lesa greinina virkaði tekjugræjan rétt og bað um API á 20 sekúndna fresti.
API kallaði geymt verklag til að reikna út summan af öllum pöntunum frá áramótum fyrir allar pizzur í keðjunni. Söfnunin var byggð á pöntunartöflunni sem er mjög vinsæl. Þar fara allir peningaborð allra opinna veitingastaða á þeim tíma. Peningakassar hættu að svara, pöntunum var ekki tekið. Þeir voru heldur ekki teknir af síðunni, komu ekki fram á rekja spor einhvers, vaktstjóri gat ekki séð þá í viðmóti sínu.
Þetta er ekki eina sagan. Haustið 2015, á hverjum föstudegi var álagið á kerfið mikilvægt. Nokkrum sinnum slökkvum við á opinbera API og einu sinni þurftum við jafnvel að slökkva á síðunni, því ekkert hjálpaði. Það var meira að segja listi yfir þjónustu með lokunarpöntun undir miklu álagi.
Héðan í frá hefst barátta okkar við álag og fyrir stöðugleika kerfisins (frá hausti 2015 til hausts 2018). Það var þegar það gerðist"". Ennfremur komu líka stundum upp bilanir, sumar voru mjög viðkvæmar, en almennt óstöðugleikatímabil má nú líta svo á að sé liðið.
Hraður vöxtur fyrirtækja
Af hverju var ekki hægt að gera það strax? Skoðaðu bara eftirfarandi töflur.
Einnig á árunum 2014-2015 var opnun í Rúmeníu og opnun í Bandaríkjunum var í undirbúningi.
Netið stækkaði mjög hratt, ný lönd voru opnuð, ný snið pítsuhúsa komu fram, til dæmis var pizzeria opnuð við matarsalinn. Allt þetta krafðist verulegrar athygli sérstaklega að stækkun Dodo IS aðgerða. Án allra þessara aðgerða, án þess að fylgjast með í eldhúsinu, gera grein fyrir vörum og tapi í kerfinu, sýna útgáfu pöntunar í sal matarréttarins, værum við varla að tala um „réttan“ arkitektúr og „rétta“ nálgun við þróun núna.
Önnur hindrun fyrir tímanlega endurskoðun byggingarlistarinnar og almennt athygli á tæknilegum vandamálum var kreppan 2014. Hlutir sem þessir bitna hart á tækifærum fyrir lið til að vaxa, sérstaklega fyrir ung fyrirtæki eins og Dodo Pizza.
Fljótlegar lausnir sem hjálpuðu
Vandamál þarfnast lausna. Venjulega er hægt að skipta lausnum í 2 hópa:
-
Fljótlegir sem slökkva eldinn og gefa lítið öryggi og kaupa okkur tíma til að breyta til.
-
Kerfisbundin og því löng. Endurhönnun fjölda eininga, skipting einhæfs arkitektúrs í aðskildar þjónustur (flestar þeirra eru alls ekki ör, heldur makróþjónustur, og það er eitthvað um það ).
Þurr listi yfir skyndibreytingar er sem hér segir:
Skala upp grunnmeistarann
Auðvitað er það fyrsta sem er gert til að takast á við álag að auka getu netþjónsins. Þetta var gert fyrir aðalgagnagrunninn og fyrir vefþjóna. Því miður, þetta er aðeins hægt upp að vissum mörkum, þá verður það of dýrt.
Síðan 2014 höfum við flutt til Azure, við skrifuðum líka um þetta efni á þeim tíma í greininni "". En eftir nokkrar hækkanir á þjóninum fyrir grunninn komust þeir á móti kostnaðinum.
Grunn eftirlíkingar til að lesa
Tvær eftirlíkingar voru gerðar fyrir grunninn:
Lesa eftirmynd vegna tilvísunarbeiðna. Það er notað til að lesa möppur, tegund, borg, götu, pítsustað, vörur (hægt breytt lén) og í þeim viðmótum þar sem lítil töf er ásættanleg. Það voru 2 af þessum eftirlíkingum, við tryggðum framboð þeirra á sama hátt og meistararnir.
Lestu eftirmynd fyrir skýrslubeiðnir. Þessi gagnagrunnur var með minna framboð en allar skýrslur fóru í hann. Láttu þá hafa miklar beiðnir um mikla endurútreikninga á gögnum, en þeir hafa ekki áhrif á aðalgagnagrunninn og rekstrarviðmót.
Skyndiminni í kóða
Það voru engin skyndiminni neins staðar í kóðanum (yfirleitt). Þetta leiddi til viðbótar, ekki alltaf nauðsynlegar, beiðna í hlaðna gagnagrunninn. Skyndiminni voru fyrst bæði í minni og á ytri skyndiminni þjónustu, það var Redis. Allt var ógilt með tímanum, stillingarnar voru tilgreindar í kóðanum.
Margir bakendaþjónar
Einnig þurfti að stækka bakenda forritsins til að takast á við aukið vinnuálag. Það var nauðsynlegt að búa til klasa úr einum iis-þjóni. Við höfum breytt tímasetningu úr minni til RedisCache, sem gerði það mögulegt að búa til nokkra netþjóna á bak við einfaldan hleðslujafnara með hringrás. Í fyrstu var sama Redis notað og í skyndiminni, síðan var því skipt í nokkur.
Fyrir vikið hefur arkitektúrinn orðið flóknari ...
… en eitthvað af spennunni var fjarlægt.
Og þá var nauðsynlegt að endurtaka hlaðna íhluti, sem við tókum að okkur. Við munum tala um þetta í næsta hluta.
Heimild: www.habr.com