Sejarah Seni Bina Dodo IS: Laluan Pejabat Belakang

Habr sedang mengubah dunia. Kami telah berblog selama lebih setahun. Kira-kira enam bulan yang lalu kami menerima maklum balas yang agak logik daripada penduduk Khabrovsk: “Dodo, anda mengatakan di mana-mana bahawa anda mempunyai sistem anda sendiri. Apakah jenis sistem ini? Dan mengapa rangkaian restoran pizza memerlukannya?”

Kami duduk dan berfikir dan menyedari bahawa anda betul. Kami cuba menerangkan segala-galanya dengan jari kami, tetapi ia keluar dengan koyak dan tiada penerangan penuh tentang sistem di mana-mana sahaja. Maka bermulalah perjalanan panjang untuk mengumpul maklumat, mencari pengarang dan menulis satu siri artikel tentang Dodo IS. Mari pergi!

Penghargaan: Terima kasih kerana berkongsi maklum balas anda dengan kami. Terima kasih kepadanya, kami akhirnya menerangkan sistem itu, menyusun technoradar, dan tidak lama lagi akan melancarkan penerangan besar tentang proses kami. Tanpa anda, kami akan duduk seperti ini untuk 5 tahun lagi.

Siri artikel "Apakah Dodo IS?" menceritakan tentang:

1. Monolit awal dalam Dodo IS (2011-2015). (Sedang berjalan...)
2. Laluan belakang pejabat: pangkalan dan bas yang berasingan. (Kamu di sini)
3. Laluan sisi pelanggan: fasad atas pangkalan (2016-2017). (Sedang berjalan…)
4. Sejarah perkhidmatan mikro sebenar. (2018-2019). (Sedang berjalan…)
5. Selesai menggergaji monolit dan penstabilan seni bina. (Sedang berjalan...)

Jika anda berminat untuk belajar apa-apa lagi, tulis dalam komen.

Pendapat mengenai huraian kronologi dari pengarang
Saya kerap mengadakan mesyuarat untuk pekerja baharu mengenai topik "Seni Bina Sistem". Kami memanggilnya "Pengenalan kepada Seni Bina Dodo IS" dan ia adalah sebahagian daripada proses onboarding untuk pembangun baharu. Bercakap dalam satu bentuk atau yang lain tentang seni bina kami, tentang ciri-cirinya, saya membangunkan pendekatan sejarah tertentu untuk penerangan.

Secara tradisinya, kami melihat sistem sebagai satu set komponen (peringkat teknikal atau lebih tinggi), modul perniagaan yang berinteraksi antara satu sama lain untuk mencapai beberapa matlamat. Dan walaupun pandangan sedemikian wajar untuk reka bentuk, ia tidak sepenuhnya sesuai untuk penerangan dan pemahaman. Terdapat beberapa sebab:

• Realiti berbeza dengan apa yang ada di atas kertas. Tidak semuanya berjalan seperti yang dirancang. Dan kami berminat dengan bagaimana semuanya sebenarnya berubah dan berfungsi.
• Penyampaian maklumat yang konsisten. Malah, anda boleh pergi mengikut kronologi dari awal ke keadaan semasa.
• Dari yang mudah kepada yang kompleks. Tidak universal, tetapi dalam kes kami ia begitu. Seni bina beralih daripada pendekatan yang lebih mudah kepada yang lebih kompleks. Selalunya, melalui komplikasi, masalah kelajuan dan kestabilan pelaksanaan, serta berpuluh-puluh sifat lain dari senarai keperluan tidak berfungsi (di sini baik bercakap tentang kontras kerumitan dengan keperluan lain).

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

Menjelang 2020, ia menjadi lebih rumit dan menjadi seperti ini:

Bagaimanakah evolusi ini berlaku? Mengapa bahagian sistem yang berlainan diperlukan? Apakah keputusan seni bina yang dibuat dan mengapa? Mari kita ketahui dalam siri artikel ini.

Masalah pertama 2016: mengapa perkhidmatan harus meninggalkan monolit?

Artikel pertama dalam siri ini adalah mengenai perkhidmatan yang pertama kali dipisahkan daripada monolit. Untuk meletakkan anda dalam konteks, saya akan memberitahu anda masalah yang kami hadapi dalam sistem pada awal tahun 2016, yang perlu kami tangani dengan pengasingan perkhidmatan.

Pangkalan data MySql tunggal di mana semua aplikasi yang wujud pada masa itu dalam Dodo IS menulis rekod mereka. Akibatnya ialah:

• Beban berat (dengan 85% permintaan dibaca).
• Pangkalan itu berkembang. Disebabkan ini, kos dan sokongan menjadi isu.
• Satu titik kegagalan. Jika satu aplikasi menulis ke pangkalan data tiba-tiba mula melakukannya dengan lebih aktif, maka aplikasi lain merasakan kesannya.
• Ketidakcekapan dalam penyimpanan dan pertanyaan. Selalunya data disimpan dalam beberapa struktur yang sesuai untuk beberapa senario tetapi tidak untuk yang lain. Indeks mempercepatkan beberapa operasi, tetapi boleh melambatkan yang lain.
• Beberapa masalah telah diselesaikan dengan tergesa-gesa membuat cache dan replika baca ke pangkalan data (ini akan dibincangkan dalam artikel berasingan), tetapi mereka hanya membenarkan kami untuk mendapatkan masa dan tidak menyelesaikan masalah secara asas.

Masalahnya ialah kehadiran monolit itu sendiri. Akibatnya ialah:

• Keluaran yang unik dan jarang berlaku.
• Kesukarannya adalah dalam pembangunan kolaboratif sebilangan besar orang.
• Ketidakupayaan untuk memperkenalkan teknologi baharu, rangka kerja baharu dan perpustakaan.

Masalah dengan asas dan monolit telah diterangkan berkali-kali, sebagai contoh, dalam konteks ranap pada awal 2018 (Jadilah seperti Munch, atau beberapa perkataan tentang hutang teknikal, Hari Dodo IS berhenti. Skrip tak segerak и Kisah burung Dodo dari keluarga Phoenix. Kejatuhan Besar Dodo IS), jadi saya tidak akan terlalu banyak bercerita. Biar saya katakan bahawa kami ingin memberikan lebih fleksibiliti semasa membangunkan perkhidmatan. Pertama sekali, ini melibatkan mereka yang paling dimuatkan dan berakar dalam keseluruhan sistem - Auth dan Tracker.

Laluan Pejabat Belakang: Pangkalan dan Bas Berasingan

Navigasi Bab

1. Skim monolit 2016
2. Kami mula memunggah monolit: pemisahan Auth dan Tracker
   
3. Apakah yang dilakukan oleh Auth?
4. Dari mana datangnya beban?
5. Memunggah Auth
6. Apakah yang dilakukan oleh Tracker?
7. Dari mana datangnya beban?
8. Memunggah Penjejak

Skim monolit 2016

Berikut ialah blok utama monolit Dodo IS 2016, dan tepat di bawah ialah pecahan tugas utama mereka.

Meja tunai penghantaran. Perakaunan untuk kurier, mengeluarkan pesanan kepada kurier.
Pusat hubungan. Menerima tempahan melalui operator.
Tapak. Tapak web kami (dodopizza.ru, dodopizza.co.uk, dodopizza.by, dsb.).
Auth. Perkhidmatan kebenaran dan pengesahan untuk pejabat belakang.
Tracker. Penjejak pesanan dapur. Perkhidmatan untuk menandakan status kesediaan semasa menyediakan pesanan.
Meja tunai restoran. Mengambil pesanan di restoran, antara muka juruwang.
Eksport. Memuat naik laporan dalam 1C untuk perakaunan.
Makluman dan invois. Arahan suara di dapur (contohnya, "piza baharu telah tiba") + pencetakan invois untuk kurier.
Pengurus Syif. Antara muka untuk kerja pengurus syif: senarai pesanan, carta produktiviti, membawa pekerja ke syif.
Pengurus pejabat. Antara muka untuk kerja francaisi dan pengurus: penerimaan pekerja, laporan mengenai kerja restoran pizza.
Papan restoran. Memaparkan menu pada TV di restoran pizza.
Admin. Tetapan untuk restoran pizza tertentu: menu, harga, perakaunan, kod promosi, promosi, sepanduk untuk tapak, dsb.
Akaun Peribadi Pekerja. Jadual kerja pekerja, maklumat tentang pekerja.
Dewan Motivasi Dapur. Skrin berasingan yang tergantung di dapur dan memaparkan kelajuan pembuat piza.
Komunikasi. Menghantar sms dan e-mel.
FileStorage. Perkhidmatan sendiri untuk menerima dan mengeluarkan fail statik.

Percubaan pertama untuk menyelesaikan masalah telah membantu kami, tetapi ia hanya penangguhan sementara. Mereka tidak menjadi penyelesaian sistem, jadi jelas bahawa sesuatu perlu dilakukan dengan pangkalan. Sebagai contoh, bahagikan pangkalan data umum kepada beberapa pangkalan data yang lebih khusus.

Kami mula memunggah monolit: pemisahan Auth dan Tracker

Perkhidmatan utama yang kemudiannya menulis dan membaca daripada pangkalan data lebih daripada yang lain:

1. Pengesahan. Perkhidmatan kebenaran dan pengesahan untuk pejabat belakang.
2. Penjejak. Penjejak pesanan dapur. Perkhidmatan untuk menandakan status kesediaan semasa menyediakan pesanan.

Apakah yang dilakukan oleh Auth?

Auth ialah perkhidmatan di mana pengguna log masuk ke pejabat belakang (terdapat log masuk bebas yang berasingan di sebelah pelanggan). Ia juga dirujuk dalam permintaan untuk memastikan bahawa hak akses yang betul ada dan hak ini tidak berubah sejak log masuk terakhir. Peranti memasuki restoran pizza melaluinya.

Sebagai contoh, kami ingin membuka paparan dengan status pesanan siap di TV yang tergantung di dewan. Kemudian kami membuka auth.dodopizza.ru, pilih "Log masuk sebagai peranti", kod muncul yang boleh dimasukkan dalam halaman khas pada komputer pengurus syif, menunjukkan jenis peranti (peranti). TV itu sendiri akan pergi ke antara muka restoran pizza yang dikehendaki dan mula memaparkan di sana nama pelanggan yang pesanannya sudah sedia.

Dari mana datangnya beban?

Setiap pengguna backoffice yang log masuk pergi ke pangkalan data untuk setiap permintaan, ke jadual pengguna, menarik keluar pengguna dari sana melalui pertanyaan sql dan menyemak sama ada dia mempunyai akses dan hak yang diperlukan ke halaman ini.

Setiap peranti melakukan perkara yang sama hanya dengan jadual peranti, menyemak peranannya dan aksesnya. Sebilangan besar permintaan kepada pangkalan data induk membawa kepada pemuatan dan pembaziran sumber pangkalan data umum pada operasi ini.

Memunggah Auth

Auth mempunyai domain terpencil, iaitu, data tentang pengguna, log masuk atau peranti memasuki perkhidmatan (pada masa ini akan datang) dan kekal di sana. Jika seseorang memerlukannya, dia akan pergi ke perkhidmatan ini untuk mendapatkan data.

ADALAH. Aliran kerja pada mulanya adalah seperti ini:

Saya ingin menerangkan sedikit bagaimana ia berfungsi:

1. Permintaan luaran datang ke bahagian belakang (Asp.Net MVC di sana), membawa bersamanya kuki sesi, yang digunakan untuk mendapatkan data sesi daripada Redis(1). Ia sama ada mengandungi maklumat tentang akses, dan kemudian akses kepada pengawal dibuka (3,4), atau tidak.
2. Jika tiada akses, anda perlu melalui prosedur kebenaran. Di sini, untuk kesederhanaan, ia ditunjukkan sebagai sebahagian daripada laluan dalam atribut yang sama, walaupun ini adalah peralihan ke halaman log masuk. Dalam kes senario positif, kami akan menerima sesi yang diisi dengan betul dan pergi ke Backoffice Controller.
3. Jika terdapat data, maka anda perlu menyemaknya untuk kesesuaian dalam pangkalan data pengguna. Adakah peranannya telah berubah, patutkah dia tidak dibenarkan di muka surat sekarang? Dalam kes ini, selepas menerima sesi (1), anda perlu pergi terus ke pangkalan data dan semak akses pengguna menggunakan lapisan logik pengesahan (2). Seterusnya, sama ada pergi ke halaman log masuk atau pergi ke pengawal. Ini adalah sistem yang mudah, tetapi tidak sepenuhnya standard.
4. Jika semua prosedur selesai, maka kami melangkau lebih jauh dalam logik dalam pengawal dan kaedah.

Data pengguna diasingkan daripada semua data lain, ia disimpan dalam jadual keahlian yang berasingan, fungsi dari lapisan logik AuthService mungkin menjadi kaedah API. Sempadan domain ditakrifkan dengan agak jelas: pengguna, peranan mereka, data akses, pengeluaran dan pembatalan akses. Semuanya kelihatan seperti ia boleh dialihkan ke perkhidmatan yang berasingan.

MENJADI. Itulah yang mereka lakukan:

Pendekatan ini mempunyai beberapa masalah. Sebagai contoh, memanggil kaedah dalam proses tidak sama dengan memanggil perkhidmatan luaran melalui http. Latensi, kebolehpercayaan, kebolehdukungan dan ketelusan operasi adalah berbeza sama sekali. Andrey Morevsky bercakap dengan lebih terperinci mengenai masalah ini dalam laporannya "50 warna perkhidmatan mikro".

Perkhidmatan pengesahan dan dengannya perkhidmatan peranti digunakan untuk pejabat belakang, iaitu, untuk perkhidmatan dan antara muka yang digunakan dalam pengeluaran. Pengesahan untuk perkhidmatan pelanggan (seperti tapak web atau aplikasi mudah alih) berlaku secara berasingan tanpa menggunakan Auth. Pemisahan mengambil masa kira-kira setahun, dan kini kami sekali lagi mengusahakan topik ini, memindahkan sistem kepada perkhidmatan pengesahan baharu (dengan protokol standard).

Mengapa perpisahan itu mengambil masa yang lama?
Terdapat banyak masalah di sepanjang jalan yang melambatkan kami:

1. Kami ingin memindahkan data tentang pengguna, peranti dan pengesahan daripada pangkalan data negara menjadi satu. Untuk melakukan ini, kami perlu memindahkan semua jadual dan penggunaan daripada pengecam int kepada pengecam UUId global (kami baru-baru ini mengolah semula kod ini Roman Bukin "Uuid - kisah besar struktur kecil" dan projek sumber terbuka Primitif). Menyimpan data pengguna (kerana ini adalah maklumat peribadi) mempunyai hadnya dan bagi sesetengah negara adalah perlu untuk menyimpannya secara berasingan. Tetapi mesti ada ID pengguna global.
2. Banyak jadual dalam pangkalan data mempunyai maklumat audit tentang pengguna yang melakukan operasi. Ini memerlukan mekanisme tambahan untuk memastikan konsistensi.
3. Selepas penciptaan perkhidmatan API, terdapat tempoh pemindahan yang panjang dan beransur-ansur ke sistem lain. Suis terpaksa berlaku dengan lancar untuk pengguna dan memerlukan kerja manual.

Skim untuk mendaftarkan peranti di restoran pizza:

Seni bina umum selepas memisahkan perkhidmatan Auth dan Devices:

Nota. Untuk tahun 2020, kami sedang mengusahakan versi baharu Auth, yang berdasarkan standard keizinan OAuth 2.0. Piawaian ini agak kompleks, tetapi berguna untuk membangunkan perkhidmatan pengesahan hujung ke hujung. Dalam artikel "Kehalusan kebenaran: gambaran keseluruhan teknologi OAuth 2.0» kami Alexey Chernyaev cuba bercakap tentang piawaian semudah dan sejelas mungkin supaya anda menjimatkan masa untuk mempelajarinya.

Apakah yang dilakukan oleh Tracker?

Sekarang mengenai perkhidmatan kedua yang dimuatkan. Penjejak melakukan dua peranan:

• Di satu pihak, tugasnya adalah untuk menunjukkan kepada pekerja di dapur apa pesanan yang sedang dijalankan, produk apa yang perlu disediakan sekarang.
• Sebaliknya, digitalkan semua proses di dapur.

Apabila produk baharu (contohnya, piza) muncul dalam pesanan, produk itu pergi ke stesen penjejak "Rolling". Di stesen ini terdapat pembuat piza yang mengambil roti saiz yang diperlukan dan menggulungnya, selepas itu dia menandakan pada tablet penjejak bahawa dia telah menyelesaikan tugasnya dan menghantar pangkalan doh yang digulung ke stesen seterusnya - "Mengisi" .

Di sana, pembuat piza seterusnya mendahului piza, kemudian menandakan pada tablet bahawa dia telah menyelesaikan tugasnya dan meletakkan piza di dalam ketuhar (ini juga stesen berasingan yang perlu ditanda pada tablet). Sistem sedemikian telah wujud sejak awal lagi di Dodo dan sejak awal Dodo IS. Ia membolehkan anda menjejak dan mendigitalkan sepenuhnya semua operasi. Selain itu, penjejak mencadangkan cara menyediakan produk tertentu, menjalankan setiap jenis produk mengikut skim pembuatannya sendiri, menyimpan masa memasak yang optimum untuk produk dan menjejaki semua operasi pada produk.

Beginilah rupa skrin tablet di stesen penjejak Raskatka.

Dari mana datangnya beban?

Setiap restoran pizza mempunyai kira-kira lima tablet dengan penjejak. Pada tahun 2016 kami mempunyai lebih daripada 100 restoran pizza (dan kini terdapat lebih daripada 600). Setiap tablet membuat permintaan ke bahagian belakang setiap 10 saat dan mengumpul data daripada jadual pesanan (pautan dengan pelanggan dan alamat), komposisi pesanan (pautan dengan produk dan petunjuk kuantiti), dan jadual motivasi (ia menjejaki masa menekan). Apabila pembuat pizza mengklik pada produk pada penjejak, rekod dalam semua jadual ini dikemas kini. Jadual pesanan adalah umum; ia pada masa yang sama mengandungi sisipan semasa menerima pesanan, kemas kini daripada bahagian lain sistem dan banyak bacaan, contohnya, pada TV yang tergantung di restoran pizza dan menunjukkan pesanan siap sedia kepada pelanggan.

Semasa tempoh perjuangan dengan beban, apabila segala-galanya dan semua orang telah di-cache dan dipindahkan ke replika pangkalan data tak segerak, operasi dengan penjejak ini terus pergi ke pangkalan data induk. Seharusnya tiada lag di sini, data mestilah terkini, tidak segerak tidak boleh diterima.

Selain itu, kekurangan jadual dan indeks kami sendiri padanya tidak membenarkan kami menulis pertanyaan yang lebih khusus yang disesuaikan untuk kegunaan kami. Sebagai contoh, mungkin berkesan bagi penjejak untuk mempunyai indeks ke restoran pizza pada jadual pesanannya. Kami sentiasa mengikis pesanan pizza daripada pangkalan data penjejak. Pada masa yang sama, untuk menerima pesanan, tidak begitu penting restoran pizza yang mana ia termasuk, apa yang lebih penting ialah pelanggan yang membuat pesanan ini. Ini bermakna perlu ada indeks pada klien. Penjejak juga tidak perlu menyimpan id resit bercetak atau promosi bonus yang berkaitan dengan pesanan dalam jadual pesanan. Perkhidmatan penjejak kami tidak berminat dengan maklumat ini. Dalam pangkalan data monolitik biasa, jadual hanya boleh menjadi kompromi antara semua pengguna. Ini adalah salah satu masalah asal.

ADALAH. Pada mulanya seni bina adalah seperti ini:

Walaupun selepas dipisahkan ke dalam proses yang berasingan, kebanyakan asas kod kekal biasa untuk perkhidmatan yang berbeza. Segala-galanya di bawah pengawal telah disatukan dan tinggal dalam satu repositori. Kaedah biasa perkhidmatan, repositori dan pangkalan data biasa yang mengandungi jadual biasa telah digunakan.

Memunggah Penjejak

Masalah utama dengan penjejak ialah data mesti disegerakkan antara pangkalan data yang berbeza. Ini juga merupakan perbezaan utamanya daripada pembahagian perkhidmatan Auth; pesanan dan statusnya boleh berubah dan harus dipaparkan dalam pelbagai perkhidmatan.

Kami menerima pesanan di Restoran Checkout (ini adalah perkhidmatan), ia disimpan dalam pangkalan data dalam status "Diterima". Selepas itu, ia harus pergi ke penjejak, di mana ia akan menukar statusnya beberapa kali lagi: daripada "Dapur" kepada "Dibungkus". Dalam kes ini, beberapa pengaruh luaran daripada Juruwang atau antara muka Pengurus Shift mungkin berlaku dengan pesanan. Saya akan memberikan status pesanan dengan penerangannya dalam jadual:

Skim perubahan status pesanan kelihatan seperti ini:

Status berubah antara sistem yang berbeza. Dan di sini penjejak bukanlah sistem terakhir di mana data dikunci. Kami telah melihat beberapa kemungkinan pendekatan untuk pemisahan dalam kes sedemikian:

1. Kami menumpukan semua tindakan pesanan dalam satu perkhidmatan. Dalam kes kami, pilihan ini memerlukan terlalu banyak perkhidmatan untuk memproses pesanan. Jika kami berhenti di sana, kami akan berakhir dengan monolit kedua. Kami tidak akan menyelesaikan masalah.
2. Satu sistem membuat panggilan kepada yang lain. Pilihan kedua lebih menarik. Tetapi dengan itu, rangkaian panggilan adalah mungkin (kegagalan melata), ketersambungan komponen lebih tinggi, dan lebih sukar untuk diurus.
3. Kami menganjurkan acara, dan setiap perkhidmatan bertukar antara satu sama lain melalui acara ini. Akibatnya, pilihan ketiga telah dipilih, mengikut mana semua perkhidmatan mula bertukar acara antara satu sama lain.

Hakikat bahawa kami memilih pilihan ketiga bermakna bahawa penjejak akan mempunyai pangkalan datanya sendiri, dan untuk setiap perubahan dalam susunan ia akan menghantar acara tentang perkara ini, yang mana perkhidmatan lain akan melanggan dan yang juga akan dimasukkan ke dalam pangkalan data induk. Untuk melakukan ini, kami memerlukan beberapa perkhidmatan yang akan memastikan penghantaran mesej antara perkhidmatan.

Pada masa itu, kami sudah mempunyai RabbitMQ dalam timbunan, oleh itu keputusan muktamad untuk menggunakannya sebagai broker mesej. Rajah menunjukkan peralihan pesanan daripada Juruwang Restoran melalui Penjejak, di mana ia menukar status dan paparannya pada antara muka Pesanan Pengurus. MENJADI:

Susun laluan langkah demi langkah
Laluan pesanan bermula pada salah satu perkhidmatan sumber pesanan. Berikut ialah Juruwang Restoran:

1. Pesanan telah sedia sepenuhnya di Checkout, dan tiba masanya untuk menghantarnya kepada penjejak. Acara yang dilanggan oleh penjejak dilemparkan.
2. Penjejak, menerima pesanan, menyimpannya dalam pangkalan datanya sendiri, membuat acara "Pesanan Diterima oleh Penjejak" dan menghantarnya ke RMQ.
3. Beberapa pengendali telah pun melanggan bas acara tersuai. Bagi kami, yang menyegerakkan dengan pangkalan data monolitik adalah penting.
4. Pengendali menerima acara itu, memilih daripadanya data yang penting untuknya: dalam kes kami, ini ialah status pesanan "Diterima oleh Penjejak" dan mengemas kini entiti pesanannya dalam pangkalan data utama.

Jika seseorang memerlukan pesanan secara khusus daripada jadual pesanan monolitik, maka mereka juga boleh membacanya dari sana. Sebagai contoh, inilah yang diperlukan antara muka Pesanan dalam Pengurus Shift:

Semua perkhidmatan lain juga boleh melanggan untuk memesan acara daripada penjejak untuk menggunakannya untuk diri mereka sendiri.

Jika selepas beberapa lama pesanan diambil dalam pengeluaran, statusnya mula-mula berubah dalam pangkalan datanya (pangkalan data Penjejak), dan kemudian acara "OrderInWork" dijana serta-merta. Ia juga masuk ke RMQ, dari mana ia disegerakkan dalam pangkalan data monolitik dan dihantar ke perkhidmatan lain. Mungkin terdapat pelbagai masalah di sepanjang laluan ini; butiran lanjut mengenainya boleh didapati dalam laporan Zhenya Peshkov tentang butiran pelaksanaan Konsistensi Akhirnya dalam Penjejak.

Seni bina akhir selepas perubahan dalam Auth dan Tracker

Untuk Meringkaskan: Pada mulanya, saya mempunyai idea untuk membungkus sejarah sembilan tahun sistem Dodo IS menjadi satu artikel. Saya ingin bercakap dengan cepat dan ringkas tentang peringkat evolusi. Walau bagaimanapun, setelah duduk untuk mengkaji bahan, saya menyedari bahawa segala-galanya jauh lebih kompleks dan menarik daripada yang kelihatan.

Memikirkan faedah (atau kekurangannya) bahan tersebut, saya membuat kesimpulan bahawa pembangunan berterusan adalah mustahil tanpa sejarah peristiwa yang lengkap, retrospektif terperinci dan analisis keputusan masa lalu seseorang.

Saya harap anda mendapati ia berguna dan menarik untuk mengetahui tentang perjalanan kami. Sekarang saya berhadapan dengan pilihan bahagian mana sistem Dodo IS untuk diterangkan dalam artikel seterusnya: tulis dalam komen atau undi.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Apakah bahagian Dodo IS yang anda ingin ketahui dalam artikel seterusnya?

• 24,1% Monolit awal dalam Dodo IS (2011-2015)14

• 24,1% Masalah pertama dan penyelesaiannya (2015-2016)14

• 20,7% Laluan bahagian klien: fasad di atas tapak (2016-2017)12

• 36,2% Sejarah perkhidmatan mikro sebenar (2018-2019)21

• 44,8% Selesai pemotongan monolit dan penstabilan seni bina26

• 29,3% Mengenai rancangan selanjutnya untuk pembangunan sistem17

• 19,0% Saya tidak mahu tahu apa-apa tentang Dodo IS11

58 pengguna mengundi. 6 pengguna berpantang.

Sumber: www.habr.com