Habr mengubah dunia. Kami telah ngeblog selama lebih dari setahun sekarang. Sekitar enam bulan yang lalu, kami menerima umpan balik yang sepenuhnya logis dari Khabrovites: βDodo, di mana pun Anda mengatakan bahwa Anda memiliki sistem sendiri. Dan apakah sistem ini? Dan mengapa rantai pizza membutuhkannya?
Kami duduk, berpikir dan menyadari bahwa Anda benar. Kami mencoba menjelaskan semuanya dengan jari kami, tetapi hasilnya robek dan tidak ada deskripsi lengkap tentang sistem tersebut. Maka dimulailah perjalanan panjang mengumpulkan informasi, mencari penulis dan menulis serangkaian artikel tentang Dodo IS. Ayo pergi!
Ucapan Terima Kasih: Terima kasih telah berbagi umpan balik Anda dengan kami. Berkat dia, kami akhirnya mendeskripsikan sistem, menyusun radar teknis, dan akan segera meluncurkan deskripsi besar tentang proses kami. Tanpa Anda, kami akan duduk di sana selama 5 tahun lagi.
Seri artikel "Apa itu Dodo IS?" menceritakan tentang:
- Monolit awal di Dodo IS (2011-2015). (Sedang berlangsung...)
- Jalur back office: pangkalan dan bus terpisah. (kamu di sini)
- Jalur sisi klien: fasad di atas pangkalan (2016-2017). (Sedang berlangsung...)
- Sejarah layanan mikro nyata. (2018-2019). (Sedang berlangsung...)
- Selesai menggergaji monolit dan stabilisasi arsitektur. (Sedang berlangsung...)
Jika Anda tertarik untuk mengetahui hal lain - tulis di komentar.
Opini tentang deskripsi kronologis dari penulis
Saya rutin mengadakan pertemuan untuk karyawan baru dengan topik "Arsitektur Sistem". Kami menyebutnya "Intro to Dodo IS Architecture" dan ini merupakan bagian dari proses orientasi untuk developer baru. Menceritakan dalam satu atau lain bentuk tentang arsitektur kita, tentang fitur-fiturnya, saya telah melahirkan pendekatan historis tertentu untuk deskripsi tersebut.
Secara tradisional, kami melihat sistem sebagai sekumpulan komponen (teknis atau tingkat yang lebih tinggi), modul bisnis yang berinteraksi satu sama lain untuk mencapai beberapa tujuan. Dan jika tampilan seperti itu dibenarkan untuk desain, maka itu kurang cocok untuk deskripsi dan pemahaman. Ada beberapa alasan di sini:
- Realitas berbeda dari apa yang ada di atas kertas. Tidak semuanya berjalan seperti yang diinginkan. Dan kami tertarik pada bagaimana hal itu sebenarnya terjadi dan bekerja.
- Penyajian informasi yang konsisten. Bahkan, Anda bisa pergi secara kronologis dari awal hingga keadaan saat ini.
- Dari yang sederhana sampai yang kompleks. Tidak secara universal, tetapi dalam kasus kami memang demikian. Arsitektur berpindah dari pendekatan yang lebih sederhana ke yang lebih kompleks. Seringkali melalui kerumitan, masalah kecepatan dan stabilitas implementasi diselesaikan, serta lusinan properti lain dari daftar persyaratan non-fungsional ( dikatakan dengan baik tentang kompleksitas yang kontras dengan persyaratan lain).
Pada tahun 2011, arsitektur Dodo IS terlihat seperti ini:
Pada tahun 2020, ini menjadi sedikit lebih rumit dan menjadi seperti ini:
Bagaimana evolusi ini terjadi? Mengapa bagian-bagian berbeda dari sistem dibutuhkan? Keputusan arsitektur apa yang dibuat dan mengapa? Mari kita cari tahu dalam rangkaian artikel ini.
Masalah pertama tahun 2016: mengapa layanan harus meninggalkan monolit
Artikel pertama dari siklus tersebut adalah tentang layanan yang pertama kali dipisahkan dari monolit. Untuk menempatkan Anda dalam konteks, saya akan memberi tahu Anda masalah apa yang kami miliki dalam sistem pada awal 2016, yang harus kami tangani dengan pemisahan layanan.
Satu database MySql, di mana semua aplikasi yang ada pada saat itu di Dodo IS menulis catatannya. Konsekuensinya adalah:
- Beban berat (dengan 85% permintaan dihitung untuk membaca).
- Basis telah tumbuh. Karena itu, biaya dan dukungannya menjadi masalah.
- Titik kegagalan. Jika satu aplikasi menulis ke database tiba-tiba mulai melakukannya lebih aktif, maka aplikasi lain merasakannya sendiri.
- Inefisiensi dalam penyimpanan dan kueri. Seringkali data disimpan dalam beberapa struktur yang nyaman untuk beberapa skenario tetapi tidak cocok untuk yang lain. Indeks mempercepat beberapa operasi, tetapi dapat memperlambat yang lain.
- Beberapa masalah telah dihapus dengan tergesa-gesa membuat cache dan replika baca ke pangkalan (ini akan menjadi artikel terpisah), tetapi mereka hanya memungkinkan mereka untuk mengulur waktu dan tidak menyelesaikan masalah secara mendasar.
Masalahnya adalah keberadaan monolit itu sendiri. Konsekuensinya adalah:
- Rilis tunggal dan langka.
- Kesulitan dalam pengembangan bersama sejumlah besar orang.
- Ketidakmampuan untuk menghadirkan teknologi baru, kerangka kerja dan perpustakaan baru.
Masalah dengan alas dan monolit telah dijelaskan berkali-kali, misalnya, dalam konteks crash di awal tahun 2018 (, ΠΈ ), jadi saya tidak akan tinggal terlalu banyak. Izinkan saya mengatakan bahwa kami ingin memberikan lebih banyak fleksibilitas saat mengembangkan layanan. Pertama-tama, ini menyangkut mereka yang paling banyak dimuat dan di-root di seluruh sistem - Auth dan Tracker.
Jalur Back Office: Pangkalan dan Bus Terpisah
Navigasi Bab
Skema monolit 2016
Berikut adalah blok utama monolit Dodo IS 2016, dan tepat di bawahnya adalah transkrip tugas utama mereka.
Pengiriman Kasir. Akuntansi untuk kurir, mengeluarkan pesanan ke kurir.
Pusat kontak. Penerimaan pesanan melalui operator.
situs. Situs web kami (dodopizza.ru, dodopizza.co.uk, dodopizza.by, dll.).
Auth. Layanan otorisasi dan otentikasi untuk back office.
Π’ΡΠ΅ΠΊΠ΅Ρ. Pesan pelacak di dapur. Layanan untuk menandai status kesiapan saat menyiapkan pesanan.
Meja kas Restoran. Menerima pesanan di restoran, antarmuka kasir.
Ekspor. Mengunggah laporan dalam 1C untuk akuntansi.
Notifikasi dan tagihan. Perintah suara di dapur (misalnya, "Pizza baru tiba") + pencetakan faktur untuk kurir.
Manajer Shift. Antarmuka untuk pekerjaan manajer shift: daftar pesanan, grafik kinerja, transfer karyawan ke shift.
Manajer kantor. Antarmuka untuk pekerjaan franchisee dan manajer: penerimaan karyawan, laporan pekerjaan pizzeria.
Papan Skor Restoran. Tampilan menu di TV di restoran pizza.
admin. Pengaturan di restoran pizza tertentu: menu, harga, akuntansi, kode promo, promosi, spanduk situs web, dll.
Rekening Pribadi Karyawan. Jadwal kerja karyawan, informasi tentang karyawan.
Papan Motivasi Dapur. Layar terpisah yang tergantung di dapur dan menampilkan kecepatan pembuat pizza.
Komunikasi. Mengirim sms dan email.
Penyimpanan File. Layanan sendiri untuk menerima dan mengeluarkan file statis.
Upaya pertama untuk memecahkan masalah membantu kami, tetapi itu hanya jeda sementara. Mereka tidak menjadi solusi sistem, jadi jelas bahwa sesuatu harus dilakukan dengan pangkalan. Misalnya, membagi database umum menjadi beberapa database yang lebih terspesialisasi.
Mulai Membongkar Monolith: Pemisahan Autentikasi dan Pelacak
Layanan utama yang kemudian merekam dan membaca dari database lebih dari yang lain:
- Aut. Layanan otorisasi dan otentikasi untuk back office.
- Pelacak. Pesan pelacak di dapur. Layanan untuk menandai status kesiapan saat menyiapkan pesanan.
Apa yang dilakukan Auth?
Auth adalah layanan di mana pengguna masuk ke back office (ada pintu masuk independen terpisah di sisi klien). Juga diminta dalam permintaan untuk memastikan bahwa hak akses yang diperlukan ada dan bahwa hak-hak ini tidak berubah sejak login terakhir. Melalui itu, perangkat memasuki restoran pizza.
Misalnya, kami ingin membuka tampilan dengan status pesanan selesai di TV yang tergantung di aula. Kemudian kita buka auth.dodopizza.ru, pilih "Login as a device", muncul kode yang bisa dimasukkan di halaman khusus di komputer manajer shift, yang menunjukkan jenis perangkat (device). TV itu sendiri akan beralih ke antarmuka restoran pizza yang diinginkan dan mulai menampilkan nama pelanggan yang pesanannya sudah siap di sana.
Muatan dari mana?
Setiap pengguna yang masuk di back office pergi ke database, ke tabel pengguna untuk setiap permintaan, menarik pengguna melalui kueri sql dan memeriksa apakah dia memiliki akses dan hak yang diperlukan ke halaman ini.
Setiap perangkat melakukan hal yang sama hanya dengan tabel perangkat, memeriksa peran dan aksesnya. Sejumlah besar permintaan ke database master menyebabkan pemuatannya dan pemborosan sumber daya database umum untuk operasi ini.
Bongkar Autentikasi
Auth memiliki domain yang terisolasi, yaitu data tentang pengguna, login, atau perangkat memasuki layanan (untuk saat ini) dan tetap di sana. Jika seseorang membutuhkannya, maka dia akan pergi ke layanan ini untuk mendapatkan data.
DULU. Skema asli pekerjaan adalah sebagai berikut:
Saya ingin menjelaskan sedikit cara kerjanya:
- Permintaan dari luar datang ke backend (ada Asp.Net MVC), disertai cookie sesi, yang digunakan untuk mendapatkan data sesi dari Redis(1). Itu berisi informasi tentang akses, dan kemudian akses ke pengontrol terbuka (3,4), atau tidak.
- Jika tidak ada akses, Anda harus melalui prosedur otorisasi. Di sini, untuk kesederhanaan, ini ditampilkan sebagai bagian dari jalur dengan atribut yang sama, meskipun merupakan transisi ke halaman login. Dalam kasus skenario positif, kami akan mendapatkan sesi yang diselesaikan dengan benar dan pergi ke Backoffice Controller.
- Jika ada data, maka Anda perlu memeriksa relevansinya di database pengguna. Apakah perannya telah berubah, haruskah dia tidak diizinkan di halaman sekarang? Dalam hal ini, setelah menerima sesi (1), Anda harus langsung ke database dan memeriksa akses pengguna menggunakan lapisan logika otentikasi (2). Selanjutnya, baik ke halaman login, atau pergi ke controller. Sistem yang begitu sederhana, tetapi tidak terlalu standar.
- Jika semua prosedur dilewati, maka kita lewati lebih jauh dalam logika di pengontrol dan metode.
Data pengguna dipisahkan dari semua data lain, disimpan dalam tabel keanggotaan terpisah, fungsi dari lapisan logika AuthService mungkin menjadi metode api. Batasan domain didefinisikan dengan cukup jelas: pengguna, peran mereka, mengakses data, memberikan dan mencabut akses. Semuanya terlihat sedemikian rupa sehingga dapat dibawa keluar dalam layanan terpisah.
MENJADI. Jadi mereka melakukannya:
Pendekatan ini memiliki sejumlah masalah. Misalnya, memanggil metode di dalam proses tidak sama dengan memanggil layanan eksternal melalui http. Latensi, keandalan, pemeliharaan, transparansi operasi sangat berbeda. Andrey Morevskiy berbicara lebih detail tentang masalah tersebut dalam laporannya. .
Layanan autentikasi dan, dengan itu, layanan perangkat digunakan untuk back office, yaitu untuk layanan dan antarmuka yang digunakan dalam produksi. Autentikasi untuk layanan klien (seperti situs web atau aplikasi seluler) terjadi secara terpisah tanpa menggunakan Auth. Pemisahan memakan waktu sekitar satu tahun, dan sekarang kami membahas topik ini lagi, mentransfer sistem ke layanan otentikasi baru (dengan protokol standar).
Mengapa perpisahan begitu lama?
Ada banyak masalah di sepanjang jalan yang memperlambat kami:
- Kami ingin memindahkan data pengguna, perangkat, dan autentikasi dari database khusus negara menjadi satu. Untuk melakukan ini, kami harus menerjemahkan semua tabel dan penggunaan dari pengidentifikasi int ke pengidentifikasi UUId global (baru-baru ini mengerjakan ulang kode ini dan proyek sumber terbuka ). Menyimpan data pengguna (karena ini adalah informasi pribadi) memiliki keterbatasan dan untuk beberapa negara perlu menyimpannya secara terpisah. Tetapi id global pengguna harus.
- Banyak tabel dalam database memiliki informasi audit tentang pengguna yang melakukan operasi. Ini membutuhkan mekanisme tambahan untuk konsistensi.
- Setelah pembuatan layanan api, ada periode transisi yang panjang dan bertahap ke sistem lain. Peralihan harus mulus bagi pengguna dan membutuhkan pekerjaan manual.
Skema pendaftaran perangkat di restoran pizza:
Arsitektur umum setelah ekstraksi layanan Auth dan Perangkat:
Catatan. Untuk tahun 2020, kami sedang mengerjakan Auth versi baru, yang didasarkan pada standar otorisasi OAuth 2.0. Standar ini cukup rumit, tetapi berguna untuk mengembangkan layanan autentikasi pass-through. Di dalam artikel "Β» kami Alexey Chernyaev mencoba menceritakan tentang standar sesederhana dan sejelas mungkin agar Anda menghemat waktu untuk mempelajarinya.
Apa yang dilakukan Pelacak?
Sekarang tentang yang kedua dari layanan yang dimuat. Pelacak melakukan peran ganda:
- Di satu sisi, tugasnya adalah menunjukkan kepada karyawan di dapur pesanan apa yang sedang dikerjakan, produk apa yang perlu dimasak sekarang.
- Di sisi lain, mendigitalkan semua proses di dapur.
Saat produk baru muncul dalam pesanan (misalnya, pizza), produk tersebut masuk ke stasiun pelacak Peluncuran. Di stasiun ini, ada pembuat pizza yang mengambil roti dengan ukuran yang dibutuhkan dan menggulungnya, setelah itu dia mencatat di tablet pelacak bahwa dia telah menyelesaikan tugasnya dan memindahkan dasar adonan yang sudah digulung ke stasiun berikutnya - "Inisiasi" .
Di sana, pembuat pizza berikutnya mengisi pizza, lalu mencatat di tablet bahwa dia telah menyelesaikan tugasnya dan memasukkan pizza ke dalam oven (ini juga merupakan stasiun terpisah yang harus dicatat di tablet). Sistem seperti itu sudah ada sejak awal di Dodo dan sejak awal keberadaan Dodo IS. Ini memungkinkan Anda untuk sepenuhnya melacak dan mendigitalkan semua transaksi. Selain itu, pelacak menyarankan cara memasak produk tertentu, memandu setiap jenis produk sesuai dengan skema pembuatannya, menyimpan waktu memasak yang optimal untuk produk, dan melacak semua operasi pada produk.
Beginilah tampilan layar tablet di stasiun pelacak "Raskatka"
Muatan dari mana?
Setiap pizza memiliki sekitar lima tablet dengan pelacak. Pada tahun 2016, kami memiliki lebih dari 100 restoran pizza (dan sekarang lebih dari 600). Setiap tablet membuat permintaan ke backend setiap 10 detik sekali dan menghapus data dari tabel pesanan (koneksi dengan klien dan alamat), komposisi pesanan (koneksi dengan produk dan indikasi kuantitas), tabel akuntansi motivasi (the waktu menekan dilacak di dalamnya). Saat pembuat pizza mengklik produk di pelacak, entri di semua tabel ini diperbarui. Tabel pesanan bersifat umum, juga berisi sisipan saat menerima pesanan, pembaruan dari bagian lain sistem dan banyak bacaan, misalnya, di TV yang tergantung di restoran pizza dan menampilkan pesanan yang sudah selesai kepada pelanggan.
Selama periode berjuang dengan beban, ketika semuanya dan semuanya di-cache dan ditransfer ke replika basis asinkron, operasi dengan pelacak ini terus berlanjut ke basis master. Seharusnya tidak ada kelambatan, data harus mutakhir, tidak sinkron tidak dapat diterima.
Selain itu, kurangnya tabel dan indeks sendiri tidak memungkinkan penulisan kueri yang lebih spesifik yang disesuaikan untuk penggunaannya. Misalnya, mungkin efisien bagi pelacak untuk memiliki indeks restoran pizza di tabel pesanan. Kami selalu menghapus pesanan pizza dari basis data pelacak. Pada saat yang sama, untuk menerima pesanan, tidak begitu penting restoran pizza mana yang termasuk, yang lebih penting klien mana yang membuat pesanan ini. Dan berarti ada indeks pada klien diperlukan. Pelacak juga tidak perlu menyimpan id tanda terima tercetak atau promosi bonus yang terkait dengan pesanan di tabel pesanan. Informasi ini tidak menarik bagi layanan pelacak kami. Dalam database monolitik umum, tabel hanya bisa menjadi kompromi antara semua pengguna. Ini adalah salah satu masalah awal.
DULU. Arsitektur aslinya adalah:
Bahkan setelah dipisahkan menjadi proses terpisah, sebagian besar basis kode tetap sama untuk layanan yang berbeda. Segala sesuatu di bawah pengontrol adalah tunggal dan tinggal di repositori yang sama. Kami menggunakan metode layanan umum, repositori, basis umum, di mana tabel umum diletakkan.
Bongkar Pelacak
Masalah utama dengan pelacak adalah data harus disinkronkan antara database yang berbeda. Ini juga merupakan perbedaan utamanya dari pemisahan layanan Auth, urutan dan statusnya dapat berubah dan harus ditampilkan di layanan yang berbeda.
Kami menerima pesanan di Checkout Restoran (ini adalah layanan), itu disimpan di database dalam status "Diterima". Setelah itu, dia harus pergi ke pelacak, di mana dia akan mengubah statusnya beberapa kali lagi: dari "Dapur" menjadi "Dikemas". Pada saat yang sama, beberapa pengaruh eksternal dari Kasir atau antarmuka Shift Manager dapat terjadi dengan pesanan. Saya akan memberikan status pesanan dengan deskripsinya di tabel:
Skema untuk mengubah status pesanan terlihat seperti ini:
Status berubah di antara sistem yang berbeda. Dan di sini pelacak bukanlah sistem final tempat data ditutup. Kami telah melihat beberapa kemungkinan pendekatan untuk mempartisi dalam kasus seperti ini:
- Kami memusatkan semua tindakan pesanan dalam satu layanan. Dalam kasus kami, opsi ini membutuhkan terlalu banyak layanan untuk bekerja dengan pesanan. Jika kami berhenti di situ, kami akan mendapatkan monolit kedua. Kami tidak akan memecahkan masalah.
- Satu sistem membuat panggilan ke yang lain. Opsi kedua sudah lebih menarik. Tetapi dengan itu, rantai panggilan dimungkinkan (), konektivitas komponen lebih tinggi, lebih sulit untuk dikelola.
- Kami mengatur acara, dan setiap layanan berkomunikasi satu sama lain melalui acara ini. Akibatnya, itu adalah opsi ketiga yang dipilih, yang menurutnya semua layanan mulai bertukar acara satu sama lain.
Fakta bahwa kami memilih opsi ketiga berarti bahwa pelacak akan memiliki basis datanya sendiri, dan untuk setiap perubahan dalam urutan, itu akan mengirimkan acara tentang ini, yang berlangganan layanan lain dan yang juga termasuk dalam basis data master. Untuk melakukan ini, kami membutuhkan beberapa layanan yang akan memastikan pengiriman pesan antar layanan.
Pada saat itu, kami sudah memiliki RabbitMQ di tumpukan, karenanya keputusan akhir untuk menggunakannya sebagai perantara pesan. Diagram menunjukkan transisi pesanan dari Kasir Restoran melalui Pelacak, di mana statusnya berubah dan tampilannya di antarmuka Pesanan Manajer. MENJADI:
Urutan jalur langkah demi langkah
Jalur pesanan dimulai di salah satu layanan sumber pesanan. Inilah Kasir Restoran:
- Di kasir, pesanan sudah benar-benar siap, dan saatnya mengirimkannya ke pelacak. Acara tempat pelacak berlangganan dilemparkan.
- Pelacak, menerima pesanan untuk dirinya sendiri, menyimpannya ke basis datanya sendiri, membuat acara "Pesanan Diterima oleh Pelacak" dan mengirimkannya ke RMQ.
- Ada beberapa penangan yang sudah berlangganan bus acara per pesanan. Bagi kami, yang membuat sinkronisasi dengan basis monolitik itu penting.
- Pawang menerima suatu peristiwa, memilih darinya data yang penting untuknya: dalam kasus kami, ini adalah status pesanan "Diterima oleh Pelacak" dan memperbarui entitas pesanannya di basis data utama.
Jika seseorang membutuhkan pesanan dari pesanan tabel monolitik, Anda juga dapat membacanya dari sana. Misalnya, antarmuka Pesanan di Shift Manager membutuhkan ini:
Semua layanan lain juga dapat berlangganan untuk memesan acara dari pelacak untuk menggunakannya sendiri.
Jika setelah beberapa saat pesanan mulai bekerja, maka statusnya pertama-tama berubah di database-nya (database Pelacak), dan kemudian acara "OrderIn Progress" segera dibuat. Itu juga masuk ke RMQ, dari mana ia disinkronkan dalam database monolitik dan dikirim ke layanan lain. Mungkin ada berbagai masalah di sepanjang jalan, detail lebih lanjut tentangnya dapat ditemukan di laporan Zhenya Peshkov .
Arsitektur final setelah perubahan pada Auth dan Tracker
Menyimpulkan hasil antara: Awalnya, saya memiliki ide untuk mengemas sembilan tahun sejarah sistem Dodo IS menjadi satu artikel. Saya ingin berbicara dengan cepat dan sederhana tentang tahapan evolusi. Namun, duduk untuk materi, saya menyadari bahwa semuanya jauh lebih rumit dan menarik daripada yang terlihat.
Merefleksikan manfaat (atau ketiadaan) dari materi semacam itu, saya sampai pada kesimpulan bahwa pengembangan berkelanjutan tidak mungkin dilakukan tanpa catatan peristiwa yang lengkap, retrospeksi mendetail, dan analisis keputusan masa lalu saya.
Saya harap bermanfaat dan menarik bagi Anda untuk belajar tentang jalan kami. Sekarang saya dihadapkan pada pilihan bagian mana dari sistem Dodo IS untuk dijelaskan di artikel selanjutnya: tulis di komentar atau pilih.
Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. , silakan.
Bagian mana dari Dodo IS yang ingin Anda ketahui di artikel berikutnya?
-
24,1%Monolit awal di Dodo IS (2011-2015)14
-
24,1%Masalah pertama dan solusinya (2015-2016)14
-
20,7%Jalur sisi klien: fasad di atas basis (2016-2017)12
-
36,2%Sejarah layanan mikro sejati (2018-2019)21
-
44,8%Penggergajian monolit yang lengkap dan stabilisasi arsitektur26
-
29,3%Tentang rencana lebih lanjut untuk pengembangan sistem17
-
19,0%Saya tidak ingin tahu apa-apa tentang Dodo IS11
58 pengguna memilih. 6 pengguna abstain.
Sumber: www.habr.com