Atau setiap perusahaan yang tidak bahagia dengan monolit tidak bahagia dengan caranya sendiri.
Pengembangan sistem Dodo IS segera dimulai, seperti halnya bisnis Dodo Pizza, pada tahun 2011. Itu didasarkan pada gagasan digitalisasi proses bisnis yang lengkap dan total, dan , yang pada tahun 2011 itupun menimbulkan banyak pertanyaan dan skeptisisme. Tetapi selama 9 tahun kami telah mengikuti jalan ini - dengan pengembangan kami sendiri, yang dimulai dengan monolit.
Artikel ini adalah "jawaban" untuk pertanyaan "Mengapa menulis ulang arsitektur dan membuat perubahan berskala besar dan jangka panjang?" kembali ke artikel sebelumnya . Saya akan mulai dengan bagaimana pengembangan Dodo IS dimulai, seperti apa arsitektur aslinya, bagaimana modul baru muncul, dan karena masalah apa perubahan skala besar harus dilakukan.
Seri artikel "Apa itu Dodo IS?" menceritakan tentang:
-
Monolit awal di Dodo IS (2011-2015). (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...)
Arsitektur awal
Pada tahun 2011, arsitektur Dodo IS terlihat seperti ini:
Modul pertama dalam arsitektur adalah penerimaan pesanan. Proses bisnis itu adalah:
-
klien menelepon restoran pizza;
-
manajer mengangkat telepon;
-
menerima pesanan melalui telepon;
-
mengisinya secara paralel di antarmuka penerimaan pesanan: memperhitungkan informasi akun tentang klien, data detail pesanan, alamat pengiriman.
Antarmuka sistem informasi terlihat seperti ini ...
Versi pertama dari Oktober 2011:
Sumber daya untuk pengembangan modul pengambilan pesanan pertama terbatas. Kami harus melakukan banyak hal, dengan cepat dan dengan tim kecil. Tim kecil adalah 2 pengembang yang meletakkan dasar untuk seluruh sistem masa depan.
Keputusan pertama mereka menentukan nasib tumpukan teknologi:
-
Backend pada ASP.NET MVC, bahasa C#. Pengembangnya adalah dotnetchiki, tumpukan ini akrab dan menyenangkan bagi mereka.
-
Frontend di Bootstrap dan JQuery: antarmuka pengguna dengan gaya dan skrip yang ditulis sendiri.
-
Basis data MySQL: tanpa biaya lisensi, mudah digunakan.
-
Server di Windows Server, karena .NET hanya bisa di bawah Windows (kami tidak akan membahas Mono).
Secara fisik, semua itu terekspresikan dalam βdedic at the hosterβ.
Arsitektur Aplikasi Penerimaan Pesanan
Kemudian semua orang sudah berbicara tentang layanan mikro, dan SOA digunakan dalam proyek besar selama 5 tahun, misalnya WCF dirilis pada tahun 2006. Tapi kemudian mereka memilih solusi yang andal dan terbukti.
Ini dia.
Asp.Net MVC adalah Razor, yang, atas permintaan dari formulir atau dari klien, merender halaman HTML dengan rendering server. Di klien, skrip CSS dan JS sudah menampilkan informasi dan, jika perlu, melakukan permintaan AJAX melalui JQuery.
Permintaan di server berakhir di kelas *Controller, tempat pemrosesan dan pembuatan halaman HTML akhir berlangsung di dalam metode. Pengontrol membuat permintaan ke lapisan logika yang disebut *Layanan. Setiap layanan berhubungan dengan beberapa aspek bisnis:
-
Misalnya, DepartmentStructureService memberikan informasi tentang restoran pizza, tentang departemen. Departemen adalah sekelompok pizza yang dijalankan oleh satu franchisee.
-
MenerimaPesananLayanan menerima dan menghitung komposisi pesanan.
-
Dan SmsService mengirim SMS dengan memanggil layanan API untuk mengirim SMS.
Layanan memproses data dari database, menyimpan logika bisnis. Setiap layanan memiliki satu atau lebih *Repositori dengan nama yang sesuai. Mereka sudah berisi kueri ke prosedur tersimpan di database dan lapisan pembuat peta. Ada logika bisnis di penyimpanan, terutama yang mengeluarkan data pelaporan. ORM tidak digunakan, semua orang mengandalkan sql tulisan tangan.
Ada juga lapisan model domain dan kelas pembantu umum, misalnya kelas Order yang menyimpan pesanan. Di tempat yang sama, di layer, terdapat helper untuk mengonversi teks tampilan sesuai dengan mata uang yang dipilih.
Semua ini dapat diwakili oleh model seperti itu:
Cara Pemesanan
Pertimbangkan cara awal yang disederhanakan untuk membuat pesanan seperti itu.
Awalnya, situs itu statis. Ada harga di atasnya, dan di atasnya ada nomor telepon dan tulisan "Jika Anda ingin pizza - hubungi nomornya dan pesan." Untuk memesan, kita perlu mengimplementasikan aliran sederhana:
-
Klien mengunjungi situs statis dengan harga, memilih produk, dan menghubungi nomor yang tercantum di situs.
-
Pelanggan menyebutkan produk yang ingin mereka tambahkan ke pesanan.
-
Memberikan alamat dan namanya.
-
Operator menerima pesanan.
-
Pesanan ditampilkan di antarmuka pesanan yang diterima.
Semuanya dimulai dengan menampilkan menu. Operator pengguna yang masuk hanya menerima satu pesanan pada satu waktu. Oleh karena itu, draf kereta dapat disimpan dalam sesinya (sesi pengguna disimpan dalam memori). Ada objek Keranjang yang berisi produk dan informasi pelanggan.
Pelanggan menamai produk, operator mengklik + di sebelah produk, dan permintaan dikirim ke server. Informasi tentang produk ditarik dari database dan informasi tentang produk ditambahkan ke keranjang.
Catatan. Ya, di sini Anda tidak dapat menarik produk dari database, tetapi mentransfernya dari frontend. Tetapi untuk kejelasan, saya menunjukkan dengan tepat jalur dari database.
Selanjutnya, masukkan alamat dan nama klien.
Ketika Anda mengklik "Buat Pesanan":
-
Permintaan dikirim ke OrderController.SaveOrder().
-
Kami mendapatkan Keranjang dari sesi, ada produk dalam jumlah yang kami butuhkan.
-
Kami melengkapi Cart dengan informasi tentang klien dan menyebarkannya ke metode AddOrder dari kelas ReceivingOrderService, tempat penyimpanannya ke database.
-
Basis data memiliki tabel dengan pesanan, komposisi pesanan, klien, dan semuanya terhubung.
-
Antarmuka tampilan pesanan berjalan dan mengeluarkan pesanan terbaru dan menampilkannya.
Modul baru
Mengambil pesanan itu penting dan perlu. Anda tidak dapat melakukan bisnis pizza jika Anda tidak memiliki pesanan untuk dijual. Oleh karena itu, sistem mulai memperoleh fungsionalitas - kira-kira dari tahun 2012 hingga 2015. Selama waktu ini, banyak blok sistem yang berbeda muncul, yang akan saya sebut modul, berlawanan dengan konsep layanan atau produk.
Modul adalah sekumpulan fungsi yang disatukan oleh beberapa tujuan bisnis yang sama. Pada saat yang sama, mereka secara fisik berada dalam aplikasi yang sama.
Modul dapat disebut blok sistem. Misalnya, ini adalah modul pelaporan, antarmuka admin, , otorisasi. Ini semua adalah antarmuka pengguna yang berbeda, beberapa bahkan memiliki gaya visual yang berbeda. Pada saat yang sama, semuanya berada dalam kerangka satu aplikasi, satu proses yang berjalan.
Secara teknis, modul dirancang sebagai Area (ide seperti itu bahkan tetap ada ). Ada file terpisah untuk frontend, model, serta kelas pengontrolnya sendiri. Akibatnya, sistem diubah dari ini ...
... ke dalam ini:
Beberapa modul diimplementasikan oleh situs terpisah (proyek yang dapat dieksekusi), karena fungsionalitas yang sepenuhnya terpisah dan sebagian karena pengembangan yang sedikit terpisah dan lebih fokus. Ini:
-
situs - situs dodopizza.ru.
-
Ekspor: mengunggah laporan dari Dodo IS untuk 1C.
-
Pribadi - akun pribadi karyawan. Itu dikembangkan secara terpisah dan memiliki titik masuknya sendiri dan desain terpisah.
-
fs β sebuah proyek untuk menghosting statika. Kemudian kami menjauh darinya, memindahkan semua statika ke CDN Akamai.
Blok lainnya ada di aplikasi BackOffice.
Penjelasan nama:
-
Kasir - Kasir restoran.
-
ShiftManager - antarmuka untuk peran "Shift Manager": statistik operasional penjualan pizzeria, kemampuan untuk menempatkan produk di daftar berhenti, mengubah pesanan.
-
OfficeManager - antarmuka untuk peran "Pizzeria Manager" dan "Franchisee". Berikut adalah kumpulan fungsi untuk menyiapkan restoran pizza, promosi bonusnya, menerima dan bekerja dengan karyawan, laporan.
-
PublicScreens - antarmuka untuk TV dan tablet yang tergantung di restoran pizza. Menu tampilan TV, informasi iklan, status pesanan pada saat pengiriman.
Mereka menggunakan lapisan layanan umum, blok kelas domain Dodo.Core umum, dan basis umum. Terkadang mereka masih bisa memimpin transisi satu sama lain. Termasuk situs individual, seperti dodopizza.ru atau personal.dodopizza.ru, pergi ke layanan umum.
Ketika modul baru muncul, kami mencoba menggunakan kembali kode layanan yang sudah dibuat, prosedur tersimpan, dan tabel dalam database secara maksimal.
Untuk pemahaman yang lebih baik tentang skala modul yang dibuat dalam sistem, berikut adalah diagram dari tahun 2012 dengan rencana pengembangan:
Pada 2015, semuanya ada di peta dan bahkan lebih banyak lagi yang diproduksi.
-
Penerimaan pesanan telah berkembang menjadi blok terpisah dari Pusat Kontak, tempat pesanan diterima oleh operator.
-
Ada layar publik dengan menu dan informasi tergantung di restoran pizza.
-
Dapur memiliki modul yang secara otomatis memutar pesan suara "Pizza Baru" saat pesanan baru tiba, dan juga mencetak faktur untuk kurir. Ini sangat menyederhanakan proses di dapur, memungkinkan karyawan untuk tidak terganggu oleh sejumlah besar operasi sederhana.
-
Unit pengantaran menjadi Delivery Checkout tersendiri, dimana pesanan dikeluarkan untuk kurir yang sebelumnya mengambil shift. Waktu kerjanya diperhitungkan untuk perhitungan penggajian.
Secara paralel, dari 2012 hingga 2015, lebih dari 10 pengembang muncul, 35 restoran pizza dibuka, menerapkan sistem ke Rumania dan bersiap untuk membuka gerai di Amerika Serikat. Pengembang tidak lagi menangani semua tugas, tetapi dibagi menjadi beberapa tim. masing-masing berspesialisasi dalam bagian sistemnya sendiri.
Masalah
Termasuk karena arsitekturnya (tetapi tidak hanya).
Kekacauan di pangkalan
Satu basis nyaman. Konsistensi dapat dicapai di dalamnya, dan dengan mengorbankan alat yang dibangun ke dalam basis data relasional. Bekerja dengannya sudah biasa dan nyaman, terutama jika hanya ada sedikit tabel dan sedikit data.
Namun selama 4 tahun pengembangan, database tersebut ternyata memiliki sekitar 600 tabel, 1500 prosedur tersimpan, banyak di antaranya juga memiliki logika. Sayangnya, prosedur tersimpan tidak membawa banyak keuntungan saat bekerja dengan MySQL. Mereka tidak di-cache oleh basis, dan menyimpan logika di dalamnya mempersulit pengembangan dan debugging. Penggunaan kembali kode juga sulit.
Banyak tabel tidak memiliki indeks yang sesuai, di suatu tempat, sebaliknya, ada banyak indeks, yang membuatnya sulit untuk dimasukkan. Diperlukan untuk memodifikasi sekitar 20 tabel - transaksi untuk membuat pesanan dapat memakan waktu sekitar 3-5 detik.
Data dalam tabel tidak selalu dalam bentuk yang paling sesuai. Di suatu tempat perlu dilakukan denormalisasi. Bagian dari data yang diterima secara teratur berada dalam kolom dalam bentuk struktur XML, ini meningkatkan waktu eksekusi, memperpanjang kueri, dan mempersulit pengembangan.
Ke tabel yang sama diproduksi sangat permintaan yang heterogen. Tabel populer sangat menderita, seperti tabel yang disebutkan di atas. perintah atau tabel restoran pizza. Mereka digunakan untuk menampilkan antarmuka operasional di dapur, analitik. Situs lain menghubungi mereka (), dimana pada suatu saat bisa saja banyak permintaan yang tiba-tiba datang.
Data tidak dikumpulkan dan banyak perhitungan dilakukan dengan cepat menggunakan pangkalan. Ini menciptakan perhitungan yang tidak perlu dan beban tambahan.
Seringkali kode masuk ke database padahal tidak bisa melakukannya. Di suatu tempat tidak ada operasi massal yang cukup, di suatu tempat perlu menyebarkan satu permintaan ke beberapa permintaan melalui kode untuk mempercepat dan meningkatkan keandalan.
Kohesi dan kebingungan dalam kode
Modul yang seharusnya bertanggung jawab atas bagian bisnisnya tidak melakukannya dengan jujur. Beberapa dari mereka memiliki duplikasi fungsi untuk peran. Misalnya, seorang pemasar lokal yang bertanggung jawab atas aktivitas pemasaran jaringan di kotanya harus menggunakan antarmuka "Admin" (untuk membuat promosi) dan antarmuka "Manajer Kantor" (untuk melihat dampak promosi pada bisnis). Tentu saja, di dalam kedua modul tersebut menggunakan layanan yang sama yang bekerja dengan promosi bonus.
Layanan (kelas dalam satu proyek besar monolitik) dapat memanggil satu sama lain untuk memperkaya data mereka.
Dengan kelas model itu sendiri yang menyimpan data, pekerjaan dalam kode dilakukan secara berbeda. Di suatu tempat ada konstruktor yang memungkinkan untuk menentukan bidang yang diperlukan. Di suatu tempat ini dilakukan melalui properti publik. Tentu saja, mendapatkan dan mengubah data dari database itu beragam.
Logikanya ada di pengontrol atau di kelas layanan.
Ini tampaknya merupakan masalah kecil, tetapi sangat memperlambat pengembangan dan menurunkan kualitas, menyebabkan ketidakstabilan dan bug.
Kompleksitas pembangunan besar
Kesulitan muncul dalam pengembangan itu sendiri. Itu perlu untuk membuat blok sistem yang berbeda, dan secara paralel. Menyesuaikan kebutuhan setiap komponen ke dalam satu kode menjadi semakin sulit. Tidak mudah untuk menyetujui dan menyenangkan semua komponen secara bersamaan. Selain itu, ada keterbatasan dalam teknologi, terutama yang berkaitan dengan basis dan frontend. Itu perlu untuk meninggalkan jQuery menuju kerangka kerja tingkat tinggi, terutama dalam hal layanan klien (situs web).
Di beberapa bagian sistem, database yang lebih cocok untuk ini dapat digunakan.. Misalnya, nanti kami memiliki kasus penggunaan untuk berpindah dari Redis ke CosmosDB untuk menyimpan keranjang pesanan.
Tim dan pengembang yang terlibat di bidangnya jelas menginginkan lebih banyak otonomi untuk layanan mereka, baik dalam hal pengembangan maupun peluncuran. Gabungkan konflik, lepaskan masalah. Jika untuk 5 pengembang masalah ini tidak signifikan, maka dengan 10, dan terlebih lagi dengan pertumbuhan yang direncanakan, semuanya akan menjadi lebih serius. Dan di depan adalah pengembangan aplikasi seluler (dimulai pada 2017, dan pada 2018 itu ).
Bagian yang berbeda dari sistem membutuhkan tingkat stabilitas yang berbeda, tetapi karena konektivitas sistem yang kuat, kami tidak dapat menyediakannya. Kesalahan dalam pengembangan fungsi baru di panel admin bisa jadi terjadi saat menerima pesanan di situs, karena kodenya umum dan dapat digunakan kembali, database dan datanya juga sama.
Mungkin untuk menghindari kesalahan dan masalah ini dalam kerangka arsitektur monolitik-modular seperti itu: membuat pembagian tanggung jawab, memperbaiki kode dan basis data, memisahkan lapisan dengan jelas satu sama lain, memantau kualitas setiap hari. Tetapi solusi arsitektural yang dipilih dan fokus pada perluasan fungsionalitas sistem yang cepat menimbulkan masalah dalam hal stabilitas.
Bagaimana blog Power of the Mind menempatkan mesin kasir di restoran
Jika pertumbuhan jaringan pizza (dan beban) berlanjut dengan kecepatan yang sama, maka setelah beberapa saat penurunannya akan sedemikian rupa sehingga sistem tidak akan naik. Ini menggambarkan dengan baik masalah yang mulai kita hadapi pada tahun 2015, inilah ceritanya.
Di blog"β adalah widget yang menampilkan data pendapatan selama setahun dari seluruh jaringan. Widget mengakses API publik Dodo, yang menyediakan data ini. Statistik ini saat ini tersedia di . Widget ditampilkan di setiap halaman dan membuat permintaan pada penghitung waktu setiap 20 detik. Permintaan pergi ke api.dodopizza.ru dan meminta:
-
jumlah restoran pizza di jaringan;
-
total pendapatan jaringan sejak awal tahun;
-
pendapatan untuk hari ini.
Permintaan statistik pendapatan langsung masuk ke database dan mulai meminta data pesanan, menggabungkan data dengan cepat dan memberikan jumlahnya.
Meja kas di restoran pergi ke meja pesanan yang sama, menurunkan daftar pesanan yang diterima untuk hari ini, dan pesanan baru ditambahkan ke dalamnya. Mesin kasir membuat permintaan mereka setiap 5 detik atau penyegaran halaman.
Diagramnya terlihat seperti ini:
Pada suatu musim gugur, Fyodor Ovchinnikov menulis artikel panjang dan populer di blognya. Banyak orang datang ke blog dan mulai membaca semuanya dengan cermat. Saat setiap orang yang datang membaca artikel tersebut, widget pendapatan berfungsi dengan baik dan meminta API setiap 20 detik.
API memanggil prosedur tersimpan untuk menghitung jumlah semua pesanan sejak awal tahun untuk semua restoran pizza dalam rantai. Agregasi didasarkan pada tabel pesanan, yang sangat populer. Semua meja kas dari semua restoran terbuka pada saat itu pergi ke sana. Meja kas berhenti merespons, pesanan tidak diterima. Mereka juga tidak diterima dari situs, tidak muncul di pelacak, manajer shift tidak dapat melihatnya di antarmuka.
Ini bukan satu-satunya cerita. Pada musim gugur 2015, setiap hari Jumat beban pada sistem menjadi kritis. Beberapa kali kami mematikan API publik, dan sekali, kami bahkan harus mematikan situs, karena tidak ada yang membantu. Bahkan ada daftar layanan dengan perintah shutdown di bawah beban berat.
Mulai sekarang, perjuangan kami dengan beban dan untuk stabilisasi sistem dimulai (dari musim gugur 2015 hingga musim gugur 2018). Saat itulah terjadi"". Selanjutnya, kegagalan juga terkadang terjadi, beberapa sangat sensitif, tetapi periode ketidakstabilan umum sekarang dapat dianggap telah berlalu.
Pertumbuhan bisnis yang pesat
Mengapa itu tidak bisa dilakukan segera? Lihat saja grafik berikut ini.
Juga pada 2014-2015 ada pembukaan di Rumania dan pembukaan di AS sedang dipersiapkan.
Jaringan berkembang sangat cepat, negara baru dibuka, format baru pizza muncul, misalnya, restoran pizza dibuka di food court. Semua ini membutuhkan perhatian yang signifikan khususnya pada perluasan fungsi Dodo IS. Tanpa semua fungsi ini, tanpa melacak di dapur, memperhitungkan produk dan kerugian dalam sistem, menampilkan penerbitan pesanan di aula food court, kita hampir tidak akan berbicara tentang arsitektur yang "benar" dan pendekatan yang "benar" untuk pengembangan sekarang.
Hambatan lain untuk revisi arsitektur yang tepat waktu dan umumnya memperhatikan masalah teknis adalah krisis tahun 2014. Hal-hal seperti ini sangat menghambat peluang bagi tim untuk berkembang, terutama untuk bisnis muda seperti Dodo Pizza.
Solusi Cepat yang Membantu
Masalah membutuhkan solusi. Secara konvensional, solusi dapat dibagi menjadi 2 kelompok:
-
Yang cepat memadamkan api dan memberikan sedikit margin keamanan dan memberi kita waktu untuk berubah.
-
Sistemik dan, karenanya, panjang. Rekayasa ulang sejumlah modul, pembagian arsitektur monolitik menjadi layanan terpisah (kebanyakan dari mereka sama sekali bukan layanan mikro, melainkan layanan makro, dan ada sesuatu tentang itu ).
Daftar kering perubahan cepat adalah sebagai berikut:
Tingkatkan master basis
Tentunya hal pertama yang dilakukan untuk mengatasi beban adalah dengan menambah kapasitas server. Ini dilakukan untuk database master dan untuk server web. Sayangnya, ini hanya mungkin sampai batas tertentu, kemudian menjadi terlalu mahal.
Sejak 2014, kami telah pindah ke Azure, kami juga menulis tentang topik ini saat itu di artikel β". Tetapi setelah serangkaian peningkatan server untuk pangkalan, mereka menghadapi biaya.
Replika dasar untuk membaca
Dua replika dibuat untuk pangkalan:
Baca Replika untuk permintaan referensi. Ini digunakan untuk membaca direktori, jenis, kota, jalan, restoran pizza, produk (domain yang diubah perlahan), dan di antarmuka tersebut di mana penundaan kecil dapat diterima. Ada 2 replika ini, kami memastikan ketersediaannya dengan cara yang sama seperti master.
ReadReplica untuk Permintaan Laporan. Basis data ini memiliki ketersediaan yang lebih rendah, tetapi semua laporan mengarah ke sana. Biarkan mereka memiliki permintaan besar untuk penghitungan ulang data yang sangat besar, tetapi mereka tidak memengaruhi database utama dan antarmuka operasional.
Cache dalam kode
Tidak ada cache di mana pun dalam kode (sama sekali). Hal ini menyebabkan permintaan tambahan, tidak selalu diperlukan, ke database yang dimuat. Cache pertama kali ada di dalam memori dan pada layanan cache eksternal, yaitu Redis. Semuanya dibatalkan oleh waktu, pengaturan ditentukan dalam kode.
Beberapa server backend
Bagian belakang aplikasi juga perlu diskalakan untuk menangani peningkatan beban kerja. Itu perlu untuk membuat cluster dari satu server iis. Kami telah menjadwal ulang dari memori ke RedisCache, yang memungkinkan untuk membuat beberapa server di belakang penyeimbang beban sederhana dengan round robin. Pada awalnya, Redis yang sama digunakan untuk cache, kemudian dipecah menjadi beberapa.
Akibatnya, arsitekturnya menjadi lebih rumit ...
β¦ tetapi beberapa ketegangan telah dihilangkan.
Dan kemudian perlu mengulang komponen yang dimuat, yang kami lakukan. Kita akan membicarakan hal ini di bagian selanjutnya.
Sumber: www.habr.com