🥇Sajarah Arsitéktur Dodo IS: Monolith Awal

Atawa unggal pausahaan bagja jeung monolith a bagja dina cara sorangan.

Ngembangkeun sistem Dodo IS dimimitian langsung, sapertos bisnis Dodo Pizza, dina taun 2011. Ieu dumasar kana pamanggih lengkep jeung total digitization prosés bisnis, jeung sorangan, nu malah lajeng dina 2011 ngabalukarkeun loba patarosan na skepticism. Tapi pikeun 9 taun ayeuna urang geus nuturkeun jalur ieu - kalawan ngembangkeun sorangan, nu dimimitian ku monolith a.

Tulisan ieu mangrupikeun "jawaban" pikeun patarosan "Naha nyerat ulang arsitéktur sareng ngadamel parobihan anu ageung sareng jangka panjang?" balik deui ka artikel saméméhna "Sajarah Arsitéktur Dodo IS: Jalan Kantor Balik". Kuring gé mimitian ku kumaha mimiti ngembangkeun Dodo IS, kumaha arsitéktur aslina kasampak kawas, kumaha modul anyar mucunghul, sarta ku sabab masalah naon kudu nyieun parobahan skala badag.

Runtuyan artikel "Naon Dodo IS?" nyaritakeun ngeunaan:

Monolith mimiti di Dodo IS (2011-2015). (Anjeun aya didieu)
The Back Office Path: Bases misah jeung Beus.
Jalur sisi klien: adul leuwih dasar (2016-2017). (Nuju prosés...)
Sajarah microservices nyata. (2018-2019). (Nuju prosés...)
Réngsé sawing tina monolith sareng stabilisasi arsitéktur. (Nuju prosés...)

Arsitéktur awal

Dina 2011, arsitéktur Dodo IS katingali sapertos kieu:

Modul munggaran dina arsitéktur nyaéta panarimaan pesenan. Prosés bisnis éta:

klien nelepon pizzeria nu;
manajer nyokot telepon;
nampi pesenan ku telepon;
eusian eta dina paralel dina urutan panarimaan panganteur: nyokot kana informasi akun ngeunaan klien, data dina detil urutan, alamat pangiriman.

Antarbeungeut sistem inpormasi katingali sapertos kieu ...

Vérsi munggaran ti Oktober 2011:

Rada ningkat dina Januari 2012

Dodo Pizza Sistim Émbaran Pangiriman Pizza Rumah Makan

Sumberdaya pikeun ngembangkeun urutan kahiji nyokot modul ieu kawates. Urang kedah ngalakukeun seueur, gancang sareng tim alit. Tim leutik nyaéta 2 pamekar anu nempatkeun pondasi pikeun sakabéh sistem hareup.

Kaputusan kahiji maranéhanana nangtukeun nasib tumpukan téhnologi:

Backend on ASP.NET MVC, basa C #. Pamekar éta dotnetchiki, tumpukan ieu akrab jeung pikaresepeun pikeun aranjeunna.
Frontend on Bootstrap na JQuery: panganteur pamaké dina gaya ditulis sorangan jeung Aksara.
database MySQL: euweuh waragad lisénsi, gampang ngagunakeun.
Server dina Windows Server, sabab .NET lajeng ngan bisa dina Windows (urang moal ngabahas Mono).

Sacara fisik, sadaya ieu dinyatakeun dina "dedic di hoster".

Arsitéktur Aplikasi Intake Order

Teras sadayana parantos nyarios ngeunaan jasa mikro, sareng SOA parantos dianggo dina proyék ageung salami 5 taun, contona, WCF dirilis dina 2006. Tapi teras aranjeunna milih solusi anu dipercaya sareng kabuktian.

Yeuh ieu.

Asp.Net MVC nyaéta Razor, anu, upami dipénta ti formulir atanapi ti klien, ngajantenkeun halaman HTML sareng rendering server. Dina klien, CSS jeung JS Aksara geus nembongkeun informasi sarta, upami diperlukeun, ngalakukeun requests AJAX ngaliwatan JQuery.

Requests on server mungkas nepi di *Controller kelas, dimana processing jeung generasi kaca HTML final lumangsung dina metoda. Controllers nyieun requests ka lapisan logika disebut *Services. Masing-masing jasa pakait sareng sababaraha aspék bisnis:

Contona, DepartmentStructureService masihan kaluar informasi ngeunaan pizzerias, on departemén. Departemén mangrupikeun grup pizzeria anu dijalankeun ku franchisee tunggal.
ReceivingOrdersService nampi sareng ngitung komposisi pesenan.
Sareng SmsService ngirim SMS ku nelepon jasa API pikeun ngirim SMS.

Jasa ngolah data tina pangkalan data, disimpen logika bisnis. Unggal jasa ngagaduhan hiji atanapi langkung *Repositories kalayan nami anu pas. Aranjeunna geus ngandung queries kana prosedur disimpen dina database na lapisan mappers. Aya logika bisnis dina panyimpenan, khususna seueur anu ngaluarkeun data ngalaporkeun. ORM henteu dianggo, sadayana ngandelkeun sql tulisan leungeun.

Aya ogé lapisan modél domain sareng kelas pembantu umum, contona, kelas Orde anu nyimpen pesenan. Di tempat anu sami, dina lapisan, aya pembantu pikeun ngarobih téks tampilan dumasar kana mata uang anu dipilih.

Sadaya ieu tiasa diwakilan ku modél sapertos kieu:

Urutan Jalan

Pertimbangkeun cara awal anu saderhana pikeun nyiptakeun pesenan sapertos kitu.

Mimitina, situs éta statik. Éta ngagaduhan harga, sareng di luhur - nomer telepon sareng tulisan "Upami anjeun hoyong pizza - nelepon nomer sareng pesenan." Pikeun mesen, urang kedah ngalaksanakeun aliran saderhana:

Klién ngadatangan situs statik kalayan harga, milih produk sareng nelepon nomer anu didaptarkeun dina situs éta.
Palanggan ngaran produk anu aranjeunna hoyong tambahkeun kana pesenan.
Masihan alamat sareng namina.
Operator narima pesenan.
Urutan dipintonkeun dina panganteur pesenan ditarima.

Eta sadayana dimimitian ku mintonkeun menu nu. A log-in pamaké-operator narima ngan hiji urutan dina hiji waktu. Ku alatan éta, draf karanjang bisa disimpen dina sési na (sési pamaké disimpen dina mémori). Aya obyék Gorobag anu ngandung produk sareng inpormasi palanggan.

Palanggan ngaran produk, operator clicks on + gigireun produk, sarta pamundut dikirim ka server. Émbaran ngeunaan produk ditarik kaluar tina database jeung informasi ngeunaan produk ditambahkeun kana karanjang.

nyarios. Leres, di dieu anjeun moal tiasa narik produk tina pangkalan data, tapi mindahkeun tina frontend. Tapi pikeun kajelasan, kuring nunjukkeun persis jalur tina pangkalan data.

Salajengna, lebetkeun alamat sareng nami klien.

Nalika anjeun klik "Jieun Pesen":

Pamundut dikirim ka OrderController.SaveOrder ().
Kami kéngingkeun Gorobag tina sési, aya produk dina kuantitas anu urang peryogikeun.
Urang suplement Gorobag kalayan informasi ngeunaan klien tur ngalirkeun kana métode AddOrder sahiji kelas ReceivingOrderService, dimana eta disimpen kana database.
Pangkalan data ngagaduhan tabel sareng pesenan, komposisi pesenan, klien, sareng aranjeunna sadayana nyambung.
Antarbeungeut tampilan pesenan mana sareng narik pesenan panganyarna sareng ningalikeunana.

modul anyar

Nyandak pesenan éta penting sareng diperyogikeun. Anjeun teu tiasa ngalakukeun bisnis pizza upami anjeun henteu ngagaduhan pesenan pikeun dijual. Ku alatan éta, sistem mimiti acquire fungsionalitas - kira ti 2012 nepi ka 2015. Salila ieu, seueur blok sistem anu béda-béda muncul, anu kuring bakal nelepon modul, sabalikna tina konsép jasa atawa produk.

Modul mangrupikeun sakumpulan fungsi anu dihijikeun ku sababaraha tujuan bisnis umum. Dina waktos anu sami, aranjeunna sacara fisik dina aplikasi anu sami.

Modul bisa disebut blok sistem. Contona, ieu modul ngalaporkeun, panganteur admin, tracker dahareun di dapur, otorisasina. Ieu kabeh interfaces pamaké béda, malah sababaraha boga gaya visual béda. Dina waktos anu sami, sadayana aya dina kerangka hiji aplikasi, hiji prosés jalan.

Téhnisna, modul dirancang salaku Area (gagasan sapertos kitu tetep aya dina asp.net inti). Aya file misah pikeun frontend, model, kitu ogé kelas controller sorangan. Hasilna, sistem ieu dirobih tina ieu ...

... kana ieu:

Sababaraha modul dilaksanakeun ku situs anu misah (proyék anu tiasa dieksekusi), kusabab fungsionalitas anu misah sareng sabagean kusabab pamekaran anu rada misah, langkung difokuskeun. Ieu:

loka - versi munggaran situs dodopizza.ru.
ekspor: unggah laporan ti Dodo IS pikeun 1C.
Personal - akun pribadi karyawan. Éta dikembangkeun nyalira sareng gaduh titik éntri sareng desain anu misah.
fs - proyék pikeun hosting statics. Engké urang dipindahkeun jauh ti dinya, mindahkeun sakabéh statik kana Akamai CDN.

Sesa blok aya dina aplikasi BackOffice.

Katerangan ngaran:

Kasir - kasir Réstoran.
ShiftManager - panganteur pikeun peran "Shift Manager": statistik operasional dina jualan pizzeria, kamampuhan pikeun nempatkeun produk dina daptar eureun, ngarobah urutan.
OfficeManager - panganteur pikeun peran "Pizzeria Manager" jeung "Franchisee". Di dieu dikumpulkeun fungsi pikeun nyetél pizzeria a, promosi bonus na, narima jeung gawé bareng karyawan, laporan.
PublicScreens - panganteur pikeun TV jeung tablet nongkrong di pizzerias. TV nampilkeun ménu, inpormasi iklan, status pesenan nalika pangiriman.

Aranjeunna nganggo lapisan jasa umum, blok kelas domain Dodo.Core umum, sareng dasar umum. Kadang-kadang maranehna masih bisa mingpin sapanjang transisi ka silih. Kaasup situs individu, sapertos dodopizza.ru atanapi personal.dodopizza.ru, angkat ka jasa umum.

Nalika modul anyar mucunghul, urang diusahakeun make deui kode geus dijieun tina jasa, disimpen prosedur na tabel dina database ka maksimum.

Pikeun pamahaman anu langkung saé ngeunaan skala modul anu dilakukeun dina sistem, ieu diagram ti 2012 kalayan rencana pangwangunan:

Taun 2015, sadayana aya dina peta sareng seueur deui dina produksi.

Panarimaan pesenan parantos janten blok misah tina Pusat Kontak, dimana pesenan ditampi ku operator.
Aya layar umum kalawan ménu jeung informasi nongkrong di pizzerias.
Dapur ngagaduhan modul anu otomatis muterkeun pesen sora "Pizza Anyar" nalika pesenan énggal sumping, sareng ogé nyitak invoice pikeun kurir. Ieu greatly simplifies prosés di dapur, ngamungkinkeun para karyawan teu kaganggu ku angka nu gede ngarupakeun operasi basajan.
Unit pangiriman janten Checkout Pangiriman anu misah, dimana pesenan dikaluarkeun ka kurir anu sateuacana nyandak shift. Waktu gawéna dipertimbangkeun pikeun itungan gaji.

Dina paralel, ti 2012 nepi ka 2015, leuwih ti 10 pamekar mucunghul, 35 pizzerias dibuka, deployed sistem ka Romania jeung disiapkeun pikeun muka toko di Amérika Serikat. Pamekar henteu deui ngurus sadaya tugas, tapi dibagi kana tim. unggal husus dina bagian sorangan tina sistem.

Anu jadi masalah

Kaasup kusabab arsitéktur (tapi henteu ngan).

Rusuh di pangkalan

Hiji basa merenah. Konsistensi bisa dihontal di dinya, sarta di expense parabot diwangun kana database relational. Gawe sareng éta wawuh jeung merenah, utamana lamun aya sababaraha tabel sarta saeutik data.

Tapi leuwih 4 taun pangwangunan, database tétéla boga ngeunaan 600 tabel, 1500 disimpen prosedur, loba nu ogé miboga logika. Hanjakalna, prosedur anu disimpen henteu nyandak seueur kauntungan nalika damel sareng MySQL. Aranjeunna henteu sindangan ku dasarna, sareng nyimpen logika dina aranjeunna nyusahkeun pangwangunan sareng debugging. Paké deui kode ogé hésé.

Seueur tabel henteu ngagaduhan indéks anu cocog, wae, sabalikna, aya loba indexes, nu dijieun hésé nyelapkeun. Ieu diperlukeun pikeun ngaropea ngeunaan 20 tabel - urus nyieun pesenan bisa nyandak ngeunaan 3-5 detik.

Data dina tabél henteu salawasna dina bentuk anu paling pas. Di mana waé éta kedah dilakukeun denormalisasi. Bagian tina data anu ditampi sacara rutin aya dina kolom dina bentuk struktur XML, ieu ningkatkeun waktos palaksanaan, manjangkeun patarosan sareng nyusahkeun pangwangunan.

Pikeun tabel sarua dihasilkeun pisan requests hétérogén. tabél populér ngalaman utamana, kawas tabel didadarkeun di luhur. pemesanan atawa tabél Warung Pizza. Éta dipaké pikeun nembongkeun interfaces operasional di dapur, analytics. Situs sanés ngahubungi aranjeunna (dodopizza.ru), dimana iraha waé seueur pamenta tiasa ngadadak sumping.

Data henteu dikumpulkeun sarta loba itungan lumangsung dina laleur ngagunakeun basa. Ieu nyiptakeun itungan anu teu perlu sareng beban tambahan.

Mindeng kode indit ka database lamun eta teu bisa ngalakukeun kitu. Di tempat anu henteu cekap operasi bulk, dimana waé kedah nyebarkeun hiji pamundut kana sababaraha kode pikeun nyepetkeun sareng ningkatkeun reliabilitas.

Kohési jeung obfuscation dina kode

Modul anu sakuduna nanggungjawaban kana bagian bisnisna henteu ngalakukeun éta jujur. Sababaraha di antarana miboga duplikasi fungsi pikeun kalungguhan. Salaku conto, pemasar lokal anu tanggung jawab kagiatan pamasaran jaringan di kotana kedah nganggo antarmuka "Admin" (pikeun nyiptakeun promosi) sareng antarmuka "Manajer Kantor" (pikeun ningali dampak promosi dina bisnis). Tangtosna, di jero duanana modul nganggo jasa anu sami anu damel sareng promosi bonus.

Jasa (kelas dina hiji proyék badag monolithic) bisa nelepon silih pikeun enrich data maranéhanana.

Kalayan kelas modél sorangan anu nyimpen data, karya dina kode ieu dilumangsungkeun béda. Di mana waé aya konstruktor anu ngamungkinkeun pikeun nangtukeun widang anu diperyogikeun. Tempat ieu dilakukeun ngaliwatan sipat umum. Tangtosna, kéngingkeun sareng ngarobih data tina pangkalan data rupa-rupa.

Logika éta boh dina controller atanapi di kelas jasa.

Ieu sigana masalah leutik, tapi aranjeunna pisan ngalambatkeun pangwangunan sareng ngirangan kualitas, nyababkeun instability sareng bug.

Pajeulitna pangwangunan anu ageung

Kasesahan timbul dina pangwangunan sorangan. Ieu diperlukeun pikeun nyieun blok béda tina sistem, sarta dina paralel. Nyocogkeun kabutuhan unggal komponén kana hiji kode jadi beuki hésé. Teu gampang pikeun satuju sareng mangga sadaya komponén dina waktos anu sami. Ditambahkeun kana ieu watesan dina téknologi, khususna ngeunaan dasar sareng frontend. Ieu diperlukeun pikeun abandon JQuery nuju frameworks tingkat luhur, utamana dina watesan jasa klien (website).

Dina sababaraha bagian sistem, pangkalan data anu langkung cocog pikeun ieu tiasa dianggo.. Salaku conto, engké urang ngagaduhan kasus panggunaan pindah ti Redis ka CosmosDB pikeun nyimpen karanjang pesenan.

Tim sareng pamekar anu kalibet dina widangna jelas-jelas hoyong langkung otonomi pikeun jasana, boh tina segi pamekaran sareng peluncuran. Ngahijikeun konflik, ngaluarkeun masalah. Upami pikeun 5 pamekar masalah ieu teu pati penting, teras ku 10, komo deui kalayan pertumbuhan anu direncanakeun, sadayana bakal langkung serius. Sareng payunna janten pamekaran aplikasi mobile (dimimitian dina 2017, sareng dina 2018 éta. ragrag badag).

Bagian anu béda tina sistem butuh tingkat stabilitas anu béda, tapi kusabab konektipitas sistem anu kuat, kami henteu tiasa nyayogikeun ieu. Kasalahan dina pamekaran fungsi anyar dina panel admin ogé tiasa lumangsung nalika nampi pesenan dina situs, sabab kodeu umum sareng tiasa dianggo deui, pangkalan data sareng data ogé sami.

Ieu meureun bakal mungkin pikeun ngahindarkeun kasalahan ieu sareng masalah dina kerangka arsitéktur monolithic-modular sapertos: ngadamel division tanggung jawab, refactor duanana kode jeung database, jelas misahkeun lapisan ti unggal lianna, monitor kualitas unggal poe. Tapi solusi arsitéktur anu dipilih sareng fokus kana ékspansi gancang tina fungsionalitas sistem nyababkeun masalah dina hal stabilitas.

Kumaha Power of the Mind blog nempatkeun kasir di réstoran

Lamun tumuwuhna jaringan pizzeria (jeung beban) dituluykeun dina Pace sarua, lajeng sanggeus bari ragrag bakal sapertos nu sistem moal naek. Muhun illustrates masalah anu urang mimitian nyanghareupan ku 2015, ieu carita misalna.

Dina blog"Kakuatan pikiran"éta widget nu némbongkeun data dina sharing pikeun sataun sakabéh jaringan. Widget diaksés Dodo publik API, nu nyadiakeun data ieu. Statistik ieu ayeuna sayogi di http://dodopizzastory.com/. Widget ieu dipidangkeun dina unggal halaman sareng ngadamel pamundut dina timer unggal 20 detik. Paménta angkat ka api.dodopizza.ru sareng dipénta:

jumlah pizzerias dina jaringan;
total pendapatan jaringan saprak awal taun;
panghasilan keur kiwari.

Paménta pikeun statistik ngeunaan pendapatan langsung ka pangkalan data sareng mimiti naroskeun data pesenan, ngahijikeun data dina laleur sareng masihan jumlahna.

Meja kas di réstoran angkat ka méja pesenan anu sami, ngabongkar daptar pesenan anu ditampi pikeun dinten ayeuna, sareng pesenan énggal parantos ditambah kana éta. Kasir kasir ngadamel pamenta unggal 5 detik atanapi refresh halaman.

Diagram éta katingali sapertos kieu:

Hiji ragrag, Fyodor Ovchinnikov nulis artikel panjang tur populér dina blog na. Seueur jalma sumping ka blog sareng mimiti maca sadayana taliti. Bari unggal jalma anu datang ieu maca artikel, widget sharing digawé leres tur dipénta API unggal 20 detik.

API disebut prosedur disimpen keur ngitung jumlah sadaya pesenan saprak awal taun pikeun sakabéh pizzerias dina jaringan. Aggregation ieu dumasar kana tabel pesenan, nu pohara populér. Sadaya meja kas sadaya réstoran kabuka dina waktos éta angkat ka dinya. Meja tunai dieureunkeun ngabales, pesenan teu ditarima. Éta ogé henteu katampa tina situs, henteu muncul dina tracker, manajer shift henteu tiasa ningali aranjeunna dina antarmuka na.

Ieu mah hiji-hijina carita. Dina usum gugur 2015, unggal Jumaah beban dina sistem éta kritis. Sababaraha kali urang mareuman API umum, sarta sakali, urang malah kapaksa mareuman situs, sabab euweuh mantuan. Malah aya daptar jasa kalayan pesenan pareum dina beban beurat.

Ti ayeuna, perjuangan urang jeung beban jeung stabilisasi sistem dimimitian (ti gugur 2015 nepi ka gugur 2018). Waktu éta kajadian"ragrag hébat". Salajengna, gagal ogé kadang lumangsung, sababaraha éta sensitip pisan, tapi periode umum instability ayeuna bisa dianggap lulus.

Tumuwuh bisnis gancang

Naha éta henteu tiasa dilakukeun langsung? Ngan kasampak di bagan handap.

Ogé di 2014-2015 aya hiji lawang di Romania jeung hiji lawang di AS keur disiapkeun.

Jaringan tumuwuh gancang pisan, nagara anyar dibuka, format anyar pizzerias mucunghul, contona, pizzeria dibuka di food court. Sadaya ieu merlukeun perhatian signifikan husus pikeun perluasan fungsi Dodo IS. Tanpa sadaya fungsi ieu, tanpa nyukcruk di dapur, akuntansi pikeun produk sareng karugian dina sistem, nunjukkeun ngaluarkeun pesenan di aula food court, urang boro bakal ngobrol ngeunaan arsitéktur "leres" sareng pendekatan "leres" pikeun pangwangunan ayeuna.

Halangan anu sanés pikeun révisi arsitéktur anu pas sareng umumna perhatian kana masalah téknis nyaéta krisis 2014. Hal kawas kieu pencét teuas dina kasempetan pikeun tim tumuwuh, utamana pikeun bisnis ngora kawas Dodo Pizza.

Solusi Gancang Anu Mantuan

Masalah diperlukeun solusi. Sacara konvensional, solusi tiasa dibagi kana 2 kelompok:

Gancang anu mareuman seuneu sareng masihan margin kaamanan anu leutik sareng ngagaleuh waktos urang pikeun robih.
Sistemik jeung, ku kituna, panjang. Reengineering tina sababaraha modul, division tina arsitéktur monolithic kana jasa misah (kalobaannana henteu pisan mikro, tapi jasa makro, sarta aya hal ngeunaan eta. laporan Andrey Morevskiy urang).

Daptar garing tina parobahan gancang nyaéta kieu:

Skala up master dasar

Tangtosna, hal anu munggaran dilakukeun pikeun ngatasi beban nyaéta ningkatkeun kapasitas server. Hal ieu dilakukeun pikeun database master sareng pangladén wéb. Alas, ieu mungkin ngan nepi ka wates nu tangtu, mangka jadi mahal teuing.

Kusabab 2014, kami parantos ngalih ka Azure, kami ogé nyerat ngeunaan topik ieu dina waktos éta dina tulisan "Kumaha Dodo Pizza Nganteurkeun Pizza Nganggo Microsoft Azure Cloud". Tapi sanggeus runtuyan kanaékan dina server pikeun dasarna, aranjeunna datang nepi ngalawan biaya.

réplika dasar pikeun bacaan

Dua réplika dijieun pikeun dasarna:

ReadReplica pikeun requests rujukan. Hal ieu dipaké pikeun maca directories, tipe, kota, jalan, pizzeria, produk (laun robah domain), sarta dina maranéhanana interfaces mana reureuh leutik bisa ditarima. Aya 2 réplika ieu, kami mastikeun kasadiaan dina cara anu sami sareng master.

ReadReplica pikeun Requests Laporan. Database ieu ngagaduhan kasadiaan anu langkung handap, tapi sadaya laporan nuju ka dinya. Hayu aranjeunna gaduh requests beurat pikeun recalculations data badag, tapi maranéhna teu mangaruhan database utama jeung interfaces operasional.

Caches dina kode

Henteu aya caches dimana waé dina kode éta (sadayana). Ieu ngakibatkeun tambahan, teu salawasna perlu, requests ka database dimuat. Cache mimitina dina mémori sareng dina jasa cache éksternal, nyaéta Redis. Sagalana ieu invalidated ku waktu, setélan anu dieusian dina kode.

Sababaraha server backend

Bagian tukang aplikasi ogé kedah diskalakeun pikeun nanganan beban kerja anu ningkat. Ieu diperlukeun pikeun nyieun klaster tina hiji iis-server. Kami parantos ngajadwalkeun deui sési aplikasi ti memori pikeun RedisCache, nu ngamungkinkeun pikeun nyieun sababaraha server balik a balancer beban basajan kalawan round Robin. Mimitina, Redis anu sami dianggo pikeun cache, teras dibagi jadi sababaraha.

Hasilna, arsitéktur janten langkung rumit ...

... tapi sababaraha tegangan dileungitkeun.

Lajeng ieu diperlukeun pikeun redo komponén dimuat, nu urang undertook. Urang bakal ngobrol ngeunaan ieu dina bagian salajengna.

sumber: www.habr.com

Sajarah Arsitéktur Dodo IS: Hiji Monolith Awal