🥇Sejarah Seni Bina Dodo IS: Monolith Awal

Atau setiap syarikat yang tidak berpuas hati dengan monolit tidak berpuas hati dengan caranya sendiri.

Pembangunan sistem Dodo IS bermula serta-merta, seperti perniagaan Dodo Pizza, pada tahun 2011. Ia berdasarkan idea pendigitalan lengkap dan menyeluruh proses perniagaan, dan sendiri, yang walaupun pada tahun 2011 menimbulkan banyak persoalan dan keraguan. Tetapi selama 9 tahun sekarang kami telah mengikuti jalan ini - dengan pembangunan kami sendiri, yang bermula dengan monolit.

Artikel ini ialah "jawapan" kepada soalan "Mengapa menulis semula seni bina dan membuat perubahan berskala besar dan jangka panjang?" kembali kepada artikel sebelum ini "Sejarah Seni Bina Dodo IS: Cara Pejabat Belakang". Saya akan mulakan dengan cara pembangunan Dodo IS bermula, bagaimana rupa seni bina asal, cara modul baharu muncul, dan disebabkan masalah apakah perubahan besar-besaran yang perlu dibuat.

Siri artikel "Apakah Dodo IS?" menceritakan tentang:

Monolit awal dalam Dodo IS (2011-2015). (kamu di sini)
Laluan Pejabat Belakang: Pangkalan dan Bas Berasingan.
Laluan sisi pelanggan: fasad atas pangkalan (2016-2017). (Sedang berjalan…)
Sejarah perkhidmatan mikro sebenar. (2018-2019). (Sedang berjalan…)
Selesai menggergaji monolit dan penstabilan seni bina. (Sedang berjalan...)

Seni bina awal

Pada tahun 2011, seni bina Dodo IS kelihatan seperti ini:

Modul pertama dalam seni bina ialah penerimaan pesanan. Proses perniagaan adalah:

pelanggan memanggil restoran pizza;
pengurus mengangkat telefon;
menerima pesanan melalui telefon;
mengisinya secara selari dalam antara muka penerimaan pesanan: ia mengambil kira maklumat tentang pelanggan, data pada butiran pesanan, alamat penghantaran.

Antara muka sistem maklumat kelihatan seperti ini ...

Versi pertama dari Oktober 2011:

Diperbaiki sedikit pada Januari 2012

Sistem Maklumat Dodo Pizza Delivery Pizza Restaurant

Sumber untuk pembangunan modul pengambilan pesanan pertama adalah terhad. Kami terpaksa melakukan banyak perkara, cepat dan dengan pasukan yang kecil. Pasukan kecil ialah 2 pembangun yang meletakkan asas untuk keseluruhan sistem masa hadapan.

Keputusan pertama mereka menentukan nasib timbunan teknologi:

Bahagian belakang pada ASP.NET MVC, bahasa C#. Pembangunnya adalah dotnetchiki, timbunan ini biasa dan menyenangkan mereka.
Frontend pada Bootstrap dan JQuery: antara muka pengguna pada gaya dan skrip yang ditulis sendiri.
Pangkalan data MySQL: tiada kos lesen, mudah digunakan.
Pelayan pada Pelayan Windows, kerana .NET kemudiannya hanya boleh berada di bawah Windows (kami tidak akan membincangkan Mono).

Secara fizikal, semua ini dinyatakan dalam "dedic at the hoster".

Senibina Aplikasi Pengambilan Pesanan

Kemudian semua orang sudah bercakap tentang perkhidmatan mikro, dan SOA telah digunakan dalam projek besar selama 5 tahun, contohnya, WCF dikeluarkan pada tahun 2006. Tetapi kemudian mereka memilih penyelesaian yang boleh dipercayai dan terbukti.

Ini dia.

Asp.Net MVC ialah Razor, yang, atas permintaan daripada borang atau daripada klien, menghasilkan halaman HTML dengan pemaparan pelayan. Pada klien, skrip CSS dan JS sudah memaparkan maklumat dan, jika perlu, lakukan permintaan AJAX melalui JQuery.

Permintaan pada pelayan berakhir dalam kelas *Controller, di mana pemprosesan dan penjanaan halaman HTML akhir berlaku dalam kaedah. Pengawal membuat permintaan kepada lapisan logik yang dipanggil *Perkhidmatan. Setiap perkhidmatan sepadan dengan beberapa aspek perniagaan:

Sebagai contoh, DepartmentStructureService memberikan maklumat tentang restoran pizza, mengenai jabatan. Jabatan ialah sekumpulan restoran pizza yang dikendalikan oleh seorang pemegang francais.
ReceivingOrdersService menerima dan mengira komposisi pesanan.
Dan SmsService menghantar SMS dengan menghubungi perkhidmatan API untuk menghantar SMS.

Perkhidmatan memproses data daripada pangkalan data, logik perniagaan yang disimpan. Setiap perkhidmatan mempunyai satu atau lebih *Repositori dengan nama yang sesuai. Mereka sudah mengandungi pertanyaan kepada prosedur tersimpan dalam pangkalan data dan lapisan pemeta. Terdapat logik perniagaan dalam storan, terutamanya banyak dalam storan yang mengeluarkan data pelaporan. ORM tidak digunakan, semua orang bergantung pada sql tulisan tangan.

Terdapat juga lapisan model domain dan kelas pembantu biasa, contohnya, kelas Pesanan yang menyimpan pesanan itu. Di tempat yang sama, dalam lapisan, terdapat pembantu untuk menukar teks paparan mengikut mata wang yang dipilih.

Semua ini boleh diwakili oleh model sedemikian:

Cara Pesanan

Pertimbangkan cara awal yang dipermudahkan untuk membuat pesanan sedemikian.

Pada mulanya, tapak itu statik. Ia mempunyai harga padanya, dan di atasnya - nombor telefon dan tulisan "Jika anda mahu piza - hubungi nombor dan pesan." Untuk memesan, kami perlu melaksanakan aliran mudah:

Pelanggan melawat tapak statik dengan harga, memilih produk dan menghubungi nombor yang disenaraikan di tapak.
Pelanggan menamakan produk yang mereka mahu tambah pada pesanan.
Memberi alamat dan namanya.
Operator menerima pesanan.
Pesanan dipaparkan dalam antara muka pesanan yang diterima.

Semuanya bermula dengan memaparkan menu. Pengendali pengguna log masuk hanya menerima satu pesanan pada satu masa. Oleh itu, troli draf boleh disimpan dalam sesinya (sesi pengguna disimpan dalam ingatan). Terdapat objek Cart yang mengandungi produk dan maklumat pelanggan.

Pelanggan menamakan produk, pengendali mengklik + di sebelah produk, dan permintaan dihantar ke pelayan. Maklumat tentang produk dikeluarkan daripada pangkalan data dan maklumat tentang produk ditambahkan pada troli.

Nota. Ya, di sini anda tidak boleh menarik produk dari pangkalan data, tetapi memindahkannya dari bahagian hadapan. Tetapi untuk kejelasan, saya menunjukkan dengan tepat laluan dari pangkalan data.

Seterusnya, masukkan alamat dan nama pelanggan.

Apabila anda mengklik "Buat Pesanan":

Permintaan dihantar ke OrderController.SaveOrder().
Kami mendapat Troli dari sesi, terdapat produk dalam kuantiti yang kami perlukan.
Kami menambah Troli dengan maklumat tentang pelanggan dan menyampaikannya kepada kaedah AddOrder kelas ReceivingOrderService, di mana ia disimpan ke pangkalan data.
Pangkalan data mempunyai jadual dengan susunan, komposisi pesanan, pelanggan, dan semuanya bersambung.
Antara muka paparan pesanan pergi dan mengeluarkan pesanan terkini dan memaparkannya.

Modul baru

Mengambil pesanan itu penting dan perlu. Anda tidak boleh melakukan perniagaan pizza jika anda tidak mempunyai pesanan untuk dijual. Oleh itu, sistem mula memperoleh fungsi - kira-kira dari 2012 hingga 2015. Pada masa ini, banyak blok sistem yang berbeza muncul, yang akan saya panggil modul, bertentangan dengan konsep perkhidmatan atau produk.

Modul ialah satu set fungsi yang disatukan oleh beberapa matlamat perniagaan yang sama. Pada masa yang sama, mereka secara fizikal dalam aplikasi yang sama.

Modul boleh dipanggil blok sistem. Contohnya, ini ialah modul pelaporan, antara muka pentadbir, penjejak makanan di dapur, kebenaran. Ini semua adalah antara muka pengguna yang berbeza, malah ada yang mempunyai gaya visual yang berbeza. Pada masa yang sama, semuanya berada dalam rangka satu aplikasi, satu proses yang sedang berjalan.

Secara teknikal, modul direka bentuk sebagai Kawasan (idea sedemikian masih kekal dalam teras asp.net). Terdapat fail berasingan untuk bahagian hadapan, model, serta kelas pengawal mereka sendiri. Akibatnya, sistem telah diubah daripada ini ...

... ke dalam ini:

Sesetengah modul dilaksanakan oleh tapak berasingan (projek boleh laksana), disebabkan oleh fungsi yang berasingan sepenuhnya dan sebahagiannya disebabkan oleh pembangunan yang lebih tertumpu sedikit berasingan. ini:

Tapak - versi pertama tapak dodopizza.ru.
Eksport: memuat naik laporan daripada Dodo IS untuk 1C.
Peribadi - akaun peribadi pekerja. Ia dibangunkan secara berasingan dan mempunyai pintu masuk sendiri dan reka bentuk berasingan.
fs — projek untuk statik pengehosan. Kemudian kami beralih daripadanya, memindahkan semua statik ke CDN Akamai.

Selebihnya blok berada dalam aplikasi BackOffice.

Penjelasan nama:

Juruwang - Juruwang restoran.
ShiftManager - antara muka untuk peranan "Pengurus Shift": statistik operasi pada jualan pizza, keupayaan untuk meletakkan produk pada senarai hentian, menukar pesanan.
OfficeManager - antara muka untuk peranan "Pizzeria Manager" dan "Francaisi". Berikut adalah fungsi yang dikumpul untuk menubuhkan restoran pizza, promosi bonusnya, menerima dan bekerja dengan pekerja, laporan.
PublicScreens - antara muka untuk TV dan tablet yang tergantung di restoran pizza. TV memaparkan menu, maklumat pengiklanan, status pesanan semasa penghantaran.

Mereka menggunakan lapisan perkhidmatan biasa, blok kelas domain Dodo.Core biasa dan pangkalan biasa. Kadang-kadang mereka masih boleh memimpin peralihan antara satu sama lain. Termasuk tapak individu, seperti dodopizza.ru atau personal.dodopizza.ru, pergi ke perkhidmatan am.

Apabila modul baharu muncul, kami cuba menggunakan semula kod perkhidmatan yang telah dibuat, prosedur tersimpan dan jadual dalam pangkalan data secara maksimum.

Untuk pemahaman yang lebih baik tentang skala modul yang dibuat dalam sistem, berikut ialah rajah dari 2012 dengan rancangan pembangunan:

Menjelang 2015, segala-galanya berada di peta dan lebih banyak lagi dalam pengeluaran.

Penerimaan pesanan telah berkembang menjadi blok berasingan Pusat Hubungan, di mana pesanan itu diterima oleh pengendali.
Terdapat skrin awam dengan menu dan maklumat tergantung di restoran pizza.
Dapur mempunyai modul yang secara automatik memainkan mesej suara "Pizza Baharu" apabila pesanan baharu tiba, dan juga mencetak invois untuk kurier. Ini sangat memudahkan proses di dapur, membolehkan pekerja tidak terganggu oleh sejumlah besar operasi mudah.
Blok penghantaran menjadi Daftar Keluar Penghantaran yang berasingan, di mana pesanan dikeluarkan kepada kurier yang sebelum ini mengambil syif. Waktu kerjanya diambil kira untuk pengiraan gaji.

Secara selari, dari 2012 hingga 2015, lebih daripada 10 pemaju muncul, 35 restoran pizza dibuka, menggunakan sistem ke Romania dan bersedia untuk pembukaan cawangan di Amerika Syarikat. Pembangun tidak lagi menangani semua tugas, tetapi dibahagikan kepada pasukan. masing-masing pakar dalam bahagian sistemnya sendiri.

Masalah

Termasuk kerana seni bina (tetapi bukan sahaja).

Kekacauan di pangkalan

Satu pangkalan adalah mudah. Konsistensi boleh dicapai di dalamnya, dan dengan mengorbankan alat yang dibina ke dalam pangkalan data hubungan. Bekerja dengannya adalah biasa dan mudah, terutamanya jika terdapat sedikit jadual dan sedikit data.

Tetapi selama 4 tahun pembangunan, pangkalan data ternyata mempunyai kira-kira 600 jadual, 1500 prosedur tersimpan, kebanyakannya juga mempunyai logik. Malangnya, prosedur tersimpan tidak membawa banyak kelebihan apabila bekerja dengan MySQL. Mereka tidak dicache oleh pangkalan, dan menyimpan logik di dalamnya merumitkan pembangunan dan penyahpepijatan. Penggunaan semula kod juga sukar.

Banyak jadual tidak mempunyai indeks yang sesuai, di suatu tempat, sebaliknya, terdapat banyak indeks, yang menjadikannya sukar untuk dimasukkan. Ia adalah perlu untuk mengubah suai kira-kira 20 jadual - transaksi untuk membuat pesanan boleh mengambil masa kira-kira 3-5 saat.

Data dalam jadual tidak selalu dalam bentuk yang paling sesuai. Di suatu tempat adalah perlu untuk melakukan penyahnormalan. Sebahagian daripada data yang kerap diterima adalah dalam lajur dalam bentuk struktur XML, ini meningkatkan masa pelaksanaan, memanjangkan pertanyaan dan merumitkan pembangunan.

Untuk jadual yang sama telah dihasilkan sangat permintaan heterogen. Jadual popular mengalami terutamanya, seperti jadual yang dinyatakan di atas. pesanan atau meja restoran pizza. Ia digunakan untuk memaparkan antara muka operasi di dapur, analitik. Laman web lain menghubungi mereka (dodopizza.ru), di mana pada bila-bila masa banyak permintaan boleh tiba-tiba datang.

Data tidak diagregatkan dan banyak pengiraan berlaku dengan cepat menggunakan pangkalan. Ini mencipta pengiraan yang tidak perlu dan beban tambahan.

Selalunya kod pergi ke pangkalan data apabila ia tidak dapat melakukannya. Di suatu tempat tidak terdapat operasi pukal yang mencukupi, di suatu tempat adalah perlu untuk menyebarkan satu permintaan kepada beberapa melalui kod untuk mempercepat dan meningkatkan kebolehpercayaan.

Kohesi dan kekeliruan dalam kod

Modul yang sepatutnya bertanggungjawab untuk bahagian perniagaan mereka tidak melakukannya dengan jujur. Sebahagian daripada mereka mempunyai pertindihan fungsi untuk peranan. Sebagai contoh, pemasar tempatan yang bertanggungjawab untuk aktiviti pemasaran rangkaian di bandarnya terpaksa menggunakan kedua-dua antara muka "Pentadbir" (untuk membuat promosi) dan antara muka "Pengurus Pejabat" (untuk melihat kesan promosi pada perniagaan). Sudah tentu, di dalam kedua-dua modul menggunakan perkhidmatan yang sama yang berfungsi dengan promosi bonus.

Perkhidmatan (kelas dalam satu projek besar monolitik) boleh menghubungi satu sama lain untuk memperkayakan data mereka.

Dengan kelas model itu sendiri yang menyimpan data, kerja dalam kod telah dijalankan secara berbeza. Di suatu tempat terdapat pembina yang membolehkan anda menentukan medan yang diperlukan. Di suatu tempat ini dilakukan melalui harta awam. Sudah tentu, mendapatkan dan mengubah data daripada pangkalan data adalah pelbagai.

Logiknya sama ada dalam pengawal atau dalam kelas perkhidmatan.

Ini nampaknya isu kecil, tetapi ia sangat memperlahankan pembangunan dan mengurangkan kualiti, yang membawa kepada ketidakstabilan dan pepijat.

Kerumitan pembangunan yang besar

Kesukaran timbul dalam pembangunan itu sendiri. Ia adalah perlu untuk membuat blok sistem yang berbeza, dan selari. Memasang keperluan setiap komponen ke dalam satu kod menjadi semakin sukar. Ia tidak mudah untuk bersetuju dan menggembirakan semua komponen pada masa yang sama. Ditambah dengan ini adalah batasan dalam teknologi, terutamanya berkaitan dengan asas dan bahagian hadapan. Ia adalah perlu untuk meninggalkan jQuery ke arah rangka kerja peringkat tinggi, terutamanya dari segi perkhidmatan pelanggan (laman web).

Di sesetengah bahagian sistem, pangkalan data yang lebih sesuai untuk ini boleh digunakan.. Sebagai contoh, kemudian kami mempunyai kes penggunaan untuk berpindah dari Redis ke CosmosDB untuk menyimpan bakul pesanan.

Pasukan dan pembangun yang terlibat dalam bidang mereka jelas mahukan lebih autonomi untuk perkhidmatan mereka, baik dari segi pembangunan dan pelancaran. Gabungkan konflik, lepaskan isu. Jika untuk 5 pemaju masalah ini tidak penting, maka dengan 10, dan lebih-lebih lagi dengan pertumbuhan yang dirancang, semuanya akan menjadi lebih serius. Dan di hadapan adalah pembangunan aplikasi mudah alih (ia bermula pada 2017, dan pada 2018 ia telah kejatuhan besar).

Bahagian sistem yang berbeza memerlukan tahap kestabilan yang berbeza, tetapi disebabkan ketersambungan sistem yang kuat, kami tidak dapat menyediakannya. Ralat dalam pembangunan fungsi baru dalam panel pentadbir mungkin berlaku dalam penerimaan pesanan di tapak, kerana kod itu biasa dan boleh digunakan semula, pangkalan data dan data juga sama.

Ia mungkin mungkin untuk mengelakkan kesilapan dan masalah ini dalam rangka seni bina modular monolitik: membuat pembahagian tanggungjawab, memfaktorkan semula kedua-dua kod dan pangkalan data, memisahkan lapisan antara satu sama lain dengan jelas, memantau kualiti setiap hari. Tetapi penyelesaian seni bina yang dipilih dan tumpuan pada pengembangan pesat fungsi sistem membawa kepada masalah dari segi kestabilan.

Bagaimana blog Power of the Mind meletakkan daftar tunai di restoran

Jika pertumbuhan rangkaian restoran pizza (dan beban) berterusan pada kadar yang sama, maka selepas beberapa ketika air terjun akan menjadi sedemikian rupa sehingga sistem tidak akan naik. Baik menggambarkan masalah yang kita mula hadapi pada tahun 2015, inilah kisahnya.

Dalam blog"Kuasa minda” ialah widget yang menunjukkan data hasil untuk tahun keseluruhan rangkaian. Widget mengakses API awam Dodo, yang menyediakan data ini. Statistik ini kini tersedia di http://dodopizzastory.com/. Widget ditunjukkan pada setiap halaman dan membuat permintaan pada pemasa setiap 20 saat. Permintaan pergi ke api.dodopizza.ru dan meminta:

bilangan restoran pizza dalam rangkaian;
jumlah hasil rangkaian sejak awal tahun;
pendapatan untuk hari ini.

Permintaan untuk statistik tentang hasil terus ke pangkalan data dan mula meminta data tentang pesanan, mengagregat data dengan segera dan memberikan jumlahnya.

Meja tunai di restoran pergi ke jadual pesanan yang sama, memunggah senarai pesanan yang diterima untuk hari ini, dan pesanan baharu telah ditambahkan padanya. Daftar tunai membuat permintaan mereka setiap 5 saat atau penyegaran pada halaman.

Rajah kelihatan seperti ini:

Satu musim gugur, Fyodor Ovchinnikov menulis artikel yang panjang dan popular di blognya. Ramai orang datang ke blog dan mula membaca semuanya dengan teliti. Semasa setiap orang yang datang sedang membaca artikel, widget hasil berfungsi dengan betul dan meminta API setiap 20 saat.

API memanggil prosedur tersimpan untuk mengira jumlah semua pesanan sejak awal tahun untuk semua pizza dalam rangkaian. Pengagregatan adalah berdasarkan jadual pesanan, yang sangat popular. Semua meja tunai semua restoran terbuka pada masa itu pergi ke sana. Meja tunai berhenti bertindak balas, pesanan tidak diterima. Mereka juga tidak diterima dari tapak, tidak muncul pada penjejak, pengurus syif tidak dapat melihat mereka dalam antara mukanya.

Ini bukan satu-satunya cerita. Menjelang musim luruh 2015, setiap hari Jumaat beban pada sistem adalah kritikal. Beberapa kali kami mematikan API awam, dan sekali, kami terpaksa mematikan tapak, kerana tiada apa yang membantu. Malah terdapat senarai perkhidmatan dengan perintah penutupan di bawah beban berat.

Mulai sekarang, perjuangan kami dengan beban dan untuk penstabilan sistem bermula (dari musim luruh 2015 hingga musim luruh 2018). Ketika itulah ia berlaku"kejatuhan yang hebat". Selanjutnya, kegagalan juga kadangkala berlaku, ada yang sangat sensitif, tetapi tempoh umum ketidakstabilan kini boleh dianggap berlalu.

Pertumbuhan perniagaan yang pesat

Mengapa ia tidak dapat dilakukan dengan segera? Lihat sahaja carta berikut.

Juga pada 2014-2015 terdapat pembukaan di Romania dan pembukaan di Amerika Syarikat sedang disediakan.

Rangkaian berkembang dengan cepat, negara baru dibuka, format baru pizza muncul, contohnya, restoran pizza dibuka di medan selera. Semua ini memerlukan perhatian yang ketara khususnya kepada pengembangan fungsi Dodo IS. Tanpa semua fungsi ini, tanpa pengesanan di dapur, mengira produk dan kerugian dalam sistem, memaparkan pengeluaran pesanan di dewan medan selera, kita tidak akan bercakap tentang seni bina "betul" dan pendekatan "betul" untuk pembangunan sekarang.

Satu lagi halangan kepada semakan seni bina yang tepat pada masanya dan secara amnya perhatian kepada masalah teknikal ialah krisis 2014. Perkara seperti ini menjejaskan peluang pasukan untuk berkembang, terutamanya untuk perniagaan muda seperti Dodo Pizza.

Penyelesaian Pantas yang Membantu

Masalah memerlukan penyelesaian. Secara konvensional, penyelesaian boleh dibahagikan kepada 2 kumpulan:

Yang pantas yang memadamkan api dan memberikan margin keselamatan yang kecil dan memberi kita masa untuk berubah.
Sistemik dan, oleh itu, panjang. Kejuruteraan semula beberapa modul, pembahagian seni bina monolitik kepada perkhidmatan yang berasingan (kebanyakan daripada mereka sama sekali bukan mikro, tetapi perkhidmatan makro, dan ada sesuatu mengenainya Laporan Andrey Morevskiy).

Senarai kering perubahan pantas adalah seperti berikut:

Tingkatkan induk asas

Sudah tentu, perkara pertama yang dilakukan untuk menangani beban adalah untuk meningkatkan kapasiti pelayan. Ini dilakukan untuk pangkalan data induk dan untuk pelayan web. Malangnya, ini mungkin hanya sehingga had tertentu, kemudian ia menjadi terlalu mahal.

Sejak 2014, kami telah berpindah ke Azure, kami juga menulis mengenai topik ini pada masa itu dalam artikel "Bagaimana Dodo Pizza menghantar piza menggunakan awan Microsoft Azure". Tetapi selepas beberapa siri peningkatan dalam pelayan untuk pangkalan, mereka menghadapi kos.

Replika asas untuk bacaan

Dua replika telah dibuat untuk pangkalan:

BacaReplika untuk permintaan rujukan. Ia digunakan untuk membaca direktori, jenis, bandar, jalan, restoran pizza, produk (domain perlahan-lahan ditukar) dan dalam antara muka yang kelewatan kecil boleh diterima. Terdapat 2 daripada replika ini, kami memastikan ketersediaannya dengan cara yang sama seperti induk.

ReadReplica untuk Permintaan Laporan. Pangkalan data ini mempunyai ketersediaan yang lebih rendah, tetapi semua laporan pergi kepadanya. Biarkan mereka mempunyai permintaan berat untuk pengiraan semula data yang besar, tetapi mereka tidak menjejaskan pangkalan data utama dan antara muka operasi.

Cache dalam kod

Tiada cache di mana-mana dalam kod (sama sekali). Ini membawa kepada permintaan tambahan, tidak selalu diperlukan, kepada pangkalan data yang dimuatkan. Cache adalah pertama sekali dalam memori dan pada perkhidmatan cache luaran, iaitu Redis. Semuanya telah tidak sah mengikut masa, tetapan telah ditentukan dalam kod.

Berbilang pelayan bahagian belakang

Bahagian belakang aplikasi juga perlu diskalakan untuk mengendalikan beban kerja yang meningkat. Ia adalah perlu untuk membuat kluster daripada satu iis-server. Kami telah menjadualkan semula sesi permohonan daripada ingatan kepada RedisCache, yang memungkinkan untuk membuat beberapa pelayan di belakang pengimbang beban mudah dengan round robin. Pada mulanya, Redis yang sama digunakan seperti untuk cache, kemudian ia dibahagikan kepada beberapa.

Akibatnya, seni bina menjadi lebih rumit ...

… tetapi beberapa ketegangan telah dihilangkan.

Dan kemudian adalah perlu untuk membuat semula komponen yang dimuatkan, yang kami lakukan. Kami akan bercakap tentang ini dalam bahagian seterusnya.

Sumber: www.habr.com

Sejarah Seni Bina Dodo IS: Monolit Awal