🥇Sejarah arsitektur Dodo IS: monolit awal

Utawa saben perusahaan sing ora seneng karo monolit ora seneng karo cara dhewe.

Pangembangan sistem Dodo IS wiwit langsung, kaya bisnis Dodo Pizza - ing taun 2011. Iki adhedhasar ide digitalisasi proses bisnis lengkap lan total, lan dhewe, kang malah banjur ing 2011 wungu akeh pitakonan lan skeptisism. Nanging 9 taun saiki kita wis ngetutake dalan iki - kanthi pangembangan dhewe, sing diwiwiti kanthi monolit.

Artikel iki minangka "jawaban" kanggo pitakonan "Napa nulis ulang arsitektur lan nggawe owah-owahan gedhe-gedhe lan jangka panjang?" menyang artikel sadurunge "Sajarah arsitektur Dodo IS: dalan kantor mburi". Aku bakal miwiti karo carane pangembangan Dodo IS wiwit, apa arsitektur awal katon kaya, carane modul anyar muncul, lan amarga saka masalah apa owah-owahan gedhe-gedhe kudu digawe.

Seri artikel "Apa Dodo IS?" nyritakake babagan:

Monolith awal ing Dodo IS (2011-2015). (Sampeyan kene)
The Back Office Path: Bases kapisah lan Bus.
Path sisih klien: fasad liwat pangkalan (2016-2017). (Ing proses…)
Sajarah microservices bener. (2018-2019). (Ing proses ...)
Rampung sawing saka monolith lan stabil saka arsitektur. (Ing proses ...)

Arsitektur primordial

Ing 2011, arsitektur Dodo IS katon kaya iki:

Modul pisanan ing arsitektur yaiku acceptance order. Proses bisnis kaya iki:

pelanggan nelpon pizzeria;
Manager njupuk munggah telpon;
njupuk pesenan liwat telpon;
Ing wektu sing padha, ngisi ing antarmuka panampa pesenan: informasi babagan klien, data babagan rincian pesenan, lan alamat pangiriman dianggep.

Antarmuka sistem informasi katon kaya iki ...

Versi pisanan saka Oktober 2011:

Luwih apik ing Januari 2012

Sistem informasi Dodo Pizza Delivery Pizza Restaurant

Sumber daya kanggo ngembangake modul njupuk urutan pisanan diwatesi. Sampeyan kudu nindakake akeh, cepet lan karo tim cilik. Tim cilik kalebu 2 pangembang sing nggawe dhasar kanggo kabeh sistem ing mangsa ngarep.

Kaputusan pisanan nemtokake nasib tumpukan teknologi ing mangsa ngarep:

Backend ing ASP.NET MVC, basa C #. Pangembang padha dotnetters; tumpukan iki akrab lan nyenengake kanggo wong-wong mau.
Frontend ing Bootstrap lan JQuery: antarmuka panganggo adhedhasar gaya lan skrip khusus.
Database MySQL: ora ana biaya lisensi, gampang digunakake.
Server ing Windows Server, amarga .NET banjur mung bisa ing Windows (kita ora bakal ngrembug Mono).

Secara fisik, iki kabeh ditulis ing "meja hoster".

Arsitektur aplikasi nampa pesenan

Ing wektu kasebut, kabeh wong wis ngomong babagan layanan mikro, lan SOA wis digunakake ing proyek gedhe sajrone 5 taun, contone, WCF dirilis ing taun 2006. Nanging banjur padha milih solusi sing dipercaya lan buktiaken.

Punika.

Asp.Net MVC punika Razor, kang, ing request saka wangun utawa saka klien, mrodhuksi kaca HTML karo Rendering ing server. Ing klien, skrip CSS lan JS wis nampilake informasi lan, yen perlu, nindakake panjalukan AJAX liwat JQuery.

Panyuwunan ing server tiba ing kelas *Controller, ing ngendi metode pangolahan lan ngasilake kaca HTML pungkasan. Kontroler nggawe panjalukan menyang lapisan logika sing diarani *Services. Saben layanan cocog karo sawetara aspek bisnis:

Contone, DepartmentStructureService nyedhiyakake informasi babagan pizzeria lan departemen. Departemen minangka klompok pizzeria sing dikelola dening siji franchisee.
ReceivingOrdersService nampa lan ngitung isi pesenan.
Lan SmsService ngirim SMS kanthi nelpon layanan API kanggo ngirim SMS.

Layanan ngolah data saka database lan nyimpen logika bisnis. Saben layanan duwe siji utawa luwih *Repositori kanthi jeneng sing cocog. Dheweke wis ngemot pitakon babagan prosedur sing disimpen ing database lan lapisan mappers. Repositori kasebut duwe logika bisnis, utamane akeh sing ngasilake data laporan. ORM ora digunakake, kabeh wong ngandelake sql sing ditulis tangan.

Ana uga lapisan model domain lan kelas helper umum, contone, kelas Order, sing nyimpen pesenan kasebut. Ing kana, ing lapisan kasebut, ana helper kanggo ngowahi teks tampilan miturut mata uang sing dipilih.

Kabeh iki bisa diwakili dening model iki:

Cara pesenan

Ayo nimbang cara awal sing disederhanakake kanggo nggawe pesenan kasebut.

Wiwitane situs kasebut statis. Ana rega, lan ing sisih ndhuwur ana nomer telpon lan tulisan "Yen sampeyan pengin pizza, nelpon nomer lan pesen." Kanggo pesen, kita kudu ngleksanakake aliran prasaja:

Klien menyang situs web statis kanthi rega, milih produk lan nelpon nomer sing dituduhake ing situs web kasebut.
Pelanggan menehi jeneng produk sing pengin ditambahake menyang pesenan.
Menehi alamat lan jeneng.
Operator nampa pesenan.
Urutan ditampilake ing antarmuka pesenan sing ditampa.

Iku kabeh diwiwiti karo tampilan menu. Pangguna operator sing mlebu mung nampa pesenan siji-sijine. Mulane, draf cart bisa disimpen ing sesi (sesi pangguna disimpen ing memori). Ana obyek Cart ngemot produk lan informasi pelanggan.

Klien menehi jeneng produk, operator ngeklik + jejere produk, lan panjalukan dikirim menyang server. Informasi babagan produk ditarik metu saka database lan informasi babagan produk ditambahake menyang cart.

komentar. Ya, ing kene sampeyan ora kudu narik produk metu saka database, nanging nransfer saka mburi ngarep. Nanging kanggo gamblang, aku nuduhake persis path saka basa.

Sabanjure, ketik alamat lan jeneng klien.

Nalika sampeyan ngeklik "Gawe pesenan":

We ngirim panjalukan kanggo OrderController.SaveOrder ().
We njaluk Cart saka sesi, ana produk ing jumlahe kita kudu.
We nambah Cart karo informasi bab klien lan pass menyang cara AddOrder saka kelas ReceivingOrderService, ngendi iku disimpen ing database.
Database duwe tabel kanthi urutan, isi pesenan, klien, lan kabeh disambungake.
Antarmuka tampilan pesenan dadi lan narik pesenan paling anyar lan ditampilake.

modul anyar

Nampa pesenan iku penting lan perlu. Sampeyan ora bisa mbukak bisnis pizza yen sampeyan ora duwe pesenan kanggo ngedol. Mulane, sistem wiwit entuk fungsi - saka kira-kira 2012 kanggo 2015. Sajrone wektu iki, akeh blok sistem sing beda-beda, sing bakal daktelpon modul, minangka lawan saka konsep layanan utawa produk.

Modul minangka sakumpulan fungsi sing digabungake karo sawetara tujuan bisnis sing umum. Kajaba iku, padha dumunung ing aplikasi sing padha.

Modul bisa kasebut pamblokiran sistem. Contone, iki modul laporan, antarmuka admin, tracker produk pawon, wewenang. Iki kabeh antarmuka panganggo sing beda, sawetara malah duwe gaya visual sing beda. Kajaba iku, kabeh ana ing siji aplikasi, siji proses mlaku.

Secara teknis, modul kasebut dirancang minangka Area (gagasan iki malah tetep ana ing inti asp.net). Ana file kapisah kanggo frontend, model, uga kelas controller dhewe. Akibaté, sistem kasebut diowahi saka ...

... iki:

Sawetara modul dileksanakake dening situs sing kapisah (proyek sing bisa dieksekusi), amarga fungsi sing kapisah lan sebagian amarga pembangunan sing rada kapisah lan luwih fokus. Iki:

situs - versi pisanan situs web dodopizza.ru.
kaca: ngundhuh laporan saka Dodo IS kanggo 1C.
Personal - akun pribadi karyawan. Iki dikembangake kanthi kapisah lan duwe titik entri dhewe lan desain sing kapisah.
fs - proyek kanggo hosting statis. Mengko kita pindhah saka iku, mindhah kabeh isi statis menyang Akamai CDN.

Blok sing isih ana ing aplikasi BackOffice.

Katrangan jeneng:

Kasir - kasir restoran.
ShiftManager - antarmuka kanggo peran "Shift Manager": statistik operasional babagan dodolan pizzeria, kemampuan kanggo nyelehake produk ing dhaptar mandeg, ngganti pesenan.
OfficeManager - antarmuka kanggo peran "Pizzeria Manager" lan "Franchisee". Ing kene sampeyan bisa nemokake fungsi kanggo nyetel pizzeria, promosi bonus, nampa lan nggarap karyawan, lan laporan.
PublicScreens - antarmuka kanggo TV lan tablet nggandhol ing pizzerias. TV nampilake menu, informasi pariwara, lan status pesenan nalika dikirim.

Dheweke nggunakake lapisan layanan umum, blok umum kelas domain Dodo.Core, lan basis umum. Kadhangkala dheweke isih bisa nuntun saben liyane. Kajaba iku, situs individu, kayata dodopizza.ru utawa personal.dodopizza.ru, uga ngakses layanan umum.

Nalika modul anyar katon, kita nyoba kanggo nggunakake maneh sabisa kode wis digawe kanggo layanan, disimpen tata cara lan tabel ing database.

Kanggo pangerten sing luwih apik babagan ukuran modul sing digawe ing sistem, ing ngisor iki diagram saka 2012 kanthi rencana pangembangan:

Ing 2015, kabeh wis ana ing trek lan luwih akeh lagi ing produksi.

Penerimaan pesenan wis berkembang dadi blok kapisah saka Pusat Kontak, ing ngendi pesenan ditampa dening operator.
Layar umum karo menu lan informasi wis katon ing pizzerias.
Pawon duwe modul sing kanthi otomatis muter pesen swara "Pizza Anyar" nalika pesenan anyar teka, lan uga nyithak invoice kanggo kurir. Iki banget nyederhanakake proses ing pawon lan ngidini karyawan ora bakal diganggu dening akeh operasi sing gampang.
Blok pangiriman dadi Kasir Pengiriman sing kapisah, ing ngendi pesenan kasebut dikirim menyang kurir, sing sadurunge njupuk shift. Jam kerjane digatekake kanggo ngitung gajine.

Ing podo karo, saka 2012 nganti 2015, luwih saka 10 pangembang muncul, 35 pizzerias dibukak, sistem iki disebarake kanggo Romania lan disiapake kanggo mbukak titik ing AS. Pangembang ora melu kabeh tugas, nanging dipérang dadi tim. saben specialized ing bagean dhewe saka sistem.

Masalah

Kalebu amarga arsitektur (nanging ora mung).

Chaos ing dhasar

Dasar siji trep. Sampeyan bisa entuk konsistensi, lan kanthi biaya alat sing dibangun ing basis data hubungan. Nggarap iku menowo lan trep, utamané yen ana sawetara tabel lan data sethitik.

Nanging luwih saka 4 taun pembangunan, database ngemot udakara 600 tabel, 1500 prosedur sing disimpen, akeh sing uga duwe logika. Sayange, prosedur sing disimpen ora menehi akeh keuntungan nalika nggarap MySQL. Padha ora cached dening database, lan nyimpen logika ing wong complicates pembangunan lan debugging. Nganggo maneh kode uga angel.

Akeh tabel ora duwe indeks sing cocog, nang endi wae, ing nalisir, ana akeh indeks, kang digawe selipan angel. Kira-kira 20 tabel kudu diowahi-transaksi kanggo nggawe pesenan bisa njupuk udakara 3-5 detik.

Data ing tabel ora mesthi ana ing wangun sing paling cocok. Nang endi wae perlu kanggo nindakake denormalisasi. Sawetara data sing ditampa kanthi rutin ana ing kolom ing wangun struktur XML, sing nambah wektu eksekusi, pitakon sing luwih dawa lan pangembangan sing rumit.

Tabel padha tundhuk banget panjalukan heterogen. Tabel populer, kaya tabel kasebut ing ndhuwur, utamané kena pengaruh pesenan utawa tabel pizzeria. Padha digunakake kanggo nampilake antarmuka operasional ing pawon lan analytics. Situs kasebut uga ngubungi dheweke (dodopizza.ru), ing ngendi akeh panjaluk bisa tiba-tiba teka ing wektu tartamtu.

Data ora dikumpulake lan akeh petungan njupuk Panggonan ing fly nggunakake basa. Iki nggawe petungan sing ora perlu lan beban tambahan.

Asring kode kasebut mlebu ing basis data nalika ora bisa ditindakake. Nang endi wae ana lack of operasi akeh, nang endi wae iku bakal perlu kanggo pamisah siji request menyang sawetara liwat kode kanggo nyepetake lan nambah linuwih.

Kohesi lan Kebingungan ing Kode

Modul-modul sing mesthine tanggung jawab kanggo bagean bisnis kasebut ora nindakake kanthi jujur. Sawetara wong duwe duplikasi fungsi kanggo peran. Contone, pemasar lokal sing tanggung jawab kanggo kegiatan pemasaran jaringan ing kuthane kudu nggunakake antarmuka "Admin" (kanggo nyetel promosi) lan antarmuka "Manajer Kantor" (kanggo ndeleng pengaruh promosi ing bisnis). Mesthi, ing loro modul digunakake layanan padha, kang makarya karo promosi bonus.

Layanan (kelas ing siji proyek gedhe monolitik) bisa nelpon saben liyane kanggo nambah data.

Kanthi kelas model dhewe sing nyimpen data, karya ing kode iki digawa metu beda. Nang endi wae ana konstruktor sing bisa sampeyan nemtokake lapangan sing dibutuhake. Nang endi wae iki ditindakake liwat properti umum. Mesthine, njupuk lan ngowahi data saka basis data maneka warna.

Logika kasebut ana ing pengontrol utawa kelas layanan.

Iki koyone kaya masalah cilik, nanging banget kalem pembangunan lan suda kualitas, anjog kanggo kahanan kang ora tetep lan kewan omo.

Komplek pembangunan gedhe

Kesulitan muncul ing pangembangan dhewe. Sampeyan perlu kanggo nggawe pamblokiran beda saka sistem, lan ing podo karo. Dadi saya angel nyukupi kabutuhan saben komponen dadi siji kode. Iku ora gampang kanggo setuju lan please kabeh komponen ing wektu sing padha. Ditambahake iki ana watesan ing teknologi, utamane babagan dhasar lan mburi ngarep. Sampeyan kudu ninggalake JQuery kanggo milih kerangka tingkat dhuwur, utamane babagan layanan klien (situs web).

Sawetara bagéan saka sistem bisa nggunakake database sing luwih cocok kanggo iki. Contone, mengko kita duwe precedent kanggo ngalih saka Redis kanggo CosmosDB kanggo nyimpen cart pesenan.

Tim lan pangembang sing kerja ing wilayah kasebut kanthi jelas pengin luwih bebas kanggo layanane, ing babagan pangembangan lan babagan peluncuran. Konflik nalika gabung, masalah nalika rilis. Yen kanggo 5 pangembang masalah iki ora pati penting, banjur karo 10, lan malah luwih karo wutah ngrancang, kabeh bakal dadi luwih serius. Lan apa sing bakal teka yaiku pangembangan aplikasi seluler (diwiwiti ing 2017, lan ing 2018 ana tiba gedhe).

Bagean sistem sing beda-beda mbutuhake indikator stabilitas sing beda, nanging amarga panyambungan sistem sing kuwat, kita ora bisa nyedhiyakake iki. Kesalahan nalika ngembangake fungsi anyar ing panel admin bisa uga ngasilake pesenan ing situs kasebut, amarga kode kasebut umum lan bisa digunakake maneh, database lan data uga padha.

Sampeyan bisa uga bisa ngindhari kesalahan lan masalah kasebut ing kerangka arsitektur monolitik-modular kasebut: nggawe pamisahan tanggung jawab, refactor kode lan basis data, kanthi jelas misahake lapisan saka saben liyane, lan ngawasi kualitas saben dina. Nanging solusi arsitektur sing dipilih lan fokus kanthi cepet ngembangake fungsi sistem kasebut nyebabake masalah babagan stabilitas.

Kepiye blog Power of Mind nempatake kasir ing restoran

Yen wutah saka jaringan pizzeria (lan mbukak) terus ing jangkah sing padha, banjur sawise nalika irungnya bakal dadi sistem ora waras. Crita ing ngisor iki nggambarake masalah-masalah sing kita wiwiti ing taun 2015.

Ing blog"Kekuwatan pikiran"Ana widget sing nuduhake data revenue kanggo taun kanggo kabeh jaringan. Widget kasebut ngakses Dodo API umum, sing nyedhiyakake data iki. Statistik iki saiki kasedhiya ing http://dodopizzastory.com/. Widget ditampilake ing saben kaca lan nggawe panjalukan ing wektu saben 20 detik. Panjaluk kasebut menyang api.dodopizza.ru lan takon:

nomer pizzerias ing jaringan;
total revenue jaringan wiwit awal taun;
revenue dina iki.

A request kanggo statistik revenue langsung menyang database lan wiwit njaluk data ing pesenan, aggregate data langsung ing fly lan ngetokake jumlah.

Dhaptar awis ing restoran tindak menyang meja pesenan sing padha, upload dhaptar pesenan sing ditampa kanggo dina iki, lan pesenan anyar ditambahake. Register kas nggawe panjalukan saben 5 detik utawa nalika kaca dianyari.

Diagram kasebut katon kaya iki:

Sawijining dina ing musim gugur, Fyodor Ovchinnikov nulis artikel sing dawa lan populer ing bloge. Akeh wong teka ing blog lan wiwit maca kabeh kanthi teliti. Nalika saben wong sing teka maca artikel kasebut, widget revenue bisa digunakake kanthi bener lan njaluk API saben 20 detik.

API disebut prosedur disimpen kanggo ngetung jumlah kabeh pesenan wiwit awal taun kanggo kabeh pizzerias ing jaringan. Agregasi adhedhasar tabel pesenan, sing populer banget. Kabeh kasir kabeh restoran sing mbukak ing wektu kasebut. Kasir mandheg nanggapi lan pesenan ora ditampa. Dheweke uga ora ditampa saka situs kasebut, ora katon ing tracker, lan manajer shift ora bisa ndeleng ing antarmuka.

Iki ora mung crita. Ing musim gugur 2015, saben dina Jumuah, beban ing sistem kasebut kritis. Kaping pirang-pirang kita mateni API umum, lan yen kita kudu mateni situs kasebut amarga ora ana sing mbantu. Malah ana dhaptar layanan kanthi urutan mati ing beban sing abot.

Wiwit wektu iki, perjuangan kita karo beban lan stabilisasi sistem diwiwiti (saka musim gugur 2015 nganti musim gugur 2018). Nalika iku kedadeyan"Gugur Agung" Salajengipun, kadhangkala uga ana kegagalan, sawetara sing sensitif banget, nanging periode ketidakstabilan umum saiki bisa dianggep wis rampung.

Wutah bisnis kanthi cepet

Yagene ora bisa "dirampungake kanthi apik"? Deleng grafik ing ngisor iki.

Uga ing 2014-2015 ana bukaan ing Romania lan bukaan ing AS lagi disiapake.

Rantai kasebut tuwuh kanthi cepet, negara-negara anyar dibukak, format pizzeria anyar muncul, contone, pizzeria dibukak ing food court. Kabeh iki mbutuhake perhatian sing signifikan khusus kanggo ngembangake fungsi Dodo IS. Tanpa kabeh fungsi kasebut, tanpa nelusuri ing pawon, nyathet produk lan kerugian ing sistem, nampilake pangiriman pesenan ing balai food court, ora mungkin saiki kita bakal ngomong babagan arsitektur "bener" lan "bener" "pendekatan kanggo pembangunan.

Rintangan liyane kanggo revisi arsitektur pas wektune lan perhatian umum kanggo masalah teknis yaiku krisis 2014. Bab kasebut ngrusak kesempatan tuwuh tim, utamane kanggo bisnis enom kaya Dodo Pizza.

Solusi cepet sing mbantu

Masalah butuh solusi. Umumé, solusi bisa dipérang dadi 2 klompok:

Cepet sing mateni geni lan menehi kita wates cilik saka safety lan tuku wektu kanggo ngganti.
Sistemik lan, mulane, dawa. Reengineering sawetara modul, mbagi arsitektur monolitik dadi layanan sing kapisah (sing umume ora mikro, nanging layanan makro, lan ana liyane babagan iki. laporan dening Andrey Morevsky).

Dhaptar garing owah-owahan cepet yaiku:

Skala munggah master dhasar

Mesthine, sing pertama ditindakake kanggo nglawan beban yaiku nambah kekuwatan server. Iki ditindakake kanggo database master lan server web. Alas, iki mung bisa nganti watesan tartamtu; ngluwihi iku dadi larang banget.

Wiwit 2014, kita wis pindhah menyang Azure; kita uga nulis babagan topik iki ing artikel kasebut "Kepiye Dodo Pizza ngirim pizza nggunakake awan Microsoft Azure" Nanging sawise sawetara server mundhak, biaya basis tekan watesan.

Replika database kanggo maca

Kita nggawe rong replika kanggo dhasar:

ReadReplika kanggo panjalukan direktori. Iki digunakake kanggo maca direktori, kayata kutha, dalan, pizzeria, produk (domain sing diowahi alon-alon), lan ing antarmuka sing wektu tundha cilik bisa ditampa. Ana 2 saka replika iki, kita njamin kasedhiyan ing cara sing padha master.

ReadReplica kanggo panjalukan laporan. Basis data iki nduweni kasedhiyan sing luwih murah, nanging kabeh laporan menyang. Padha uga duwe panjalukan abot kanggo recalculations data ageng, nanging padha ora mengaruhi database utama lan antarmuka operasional.

Cache ing kode

Ora ana cache ing ngendi wae ing kode kasebut (kabeh). Iki ndadékaké kanggo tambahan, ora tansah perlu, panjalukan kanggo database dimuat. Ing wiwitan, cache ana ing memori lan ing layanan cache eksternal, yaiku Redis. Kabeh wis ora valid, setelan kasebut ditemtokake ing kode kasebut.

Multiple server kanggo backend

Ing mburi aplikasi uga kudu scaled kanggo nahan beban tambah. Sampeyan perlu kanggo nggawe kluster saka siji server IIS. Kita pindhah sesi aplikasi saka memori ing RedisCache, kang digawe iku bisa kanggo nggawe sawetara server konco mbukak balancer prasaja karo babak robin. Kaping pisanan, Redis sing padha digunakake kanggo cache, banjur dipérang dadi sawetara.

Akibaté, arsitektur dadi luwih rumit ...

... nanging sawetara saka tension iki lega.

Lan banjur perlu kanggo mbaleni komponen dimuat, kang kita njupuk ing. Kita bakal ngomong babagan iki ing bagean sabanjure.

Source: www.habr.com

Sejarah Arsitektur Dodo IS: Monolith Awal