Halo semuanya! Saya yakin banyak dari Anda pernah membeli T-shirt, bola, sepatu kets, well, atau peralatan olahraga lainnya di toko kami, tetapi hanya sedikit yang tahu apa itu Sportmaster dari sudut pandang teknis.
Sedikit Sportmaster 2003 dari web.archive.orgNama saya Dmitry, saya adalah pengembang java senior di Sportmaster, dan hari ini saya ingin berbicara tentang toko online kami, tentang jalan apa yang dia tempuh untuk menjadi cara Anda mengenalnya sekarang: bagaimana kami memulai, bagaimana kami mengembangkan apa yang terjadi dan apa yang tidak, tentang masalah hari ini, dan tentang rencana untuk masa depan. Menarik? Selamat datang di kucing!
Sejarah kehadiran perusahaan kami di web sudah dimulai sejak tahun 1999 dengan situs pertama Sportmaster, yang hanya kartu nama dan katalog barang untuk pembeli grosir. Sebenarnya toko online perusahaan memiliki sejarahnya sejak tahun 2001. Pada masa itu, perusahaan tidak memiliki tim sendiri untuk mengembangkan proyek online, dan toko online berhasil mengubah beberapa platform buatan sendiri (sekarang kami bahkan tidak ingat berapa banyak). Solusi yang relatif stabil pertama bagi kami dibuat oleh integrator berikutnya pada tahun 2011 di PHP, berdasarkan CMS 1C Bitrix. Situs itu ternyata sederhana, pada kenyataannya, fungsi kotak Bitrix digunakan, dengan penyesuaian kecil untuk melakukan pemesanan. Untuk perangkat keras, konfigurasi awal termasuk 2 server aplikasi dan satu server database.
Sementara itu, perusahaan mulai secara aktif membangun kompetensinya sendiri di bidang penjualan online, terutama di sisi bisnis, yang, harus saya katakan, berjalan cukup cepat, dan tim pengembangan dipaksa untuk tumbuh dengan cepat dalam segala hal untuk memenuhi kebutuhannya. Dalam waktu kurang dari satu tahun, tiga tim segera mulai menjawab untuk pengembangan dan dukungan situs - integrator sendiri, tim internal Sportmaster, yang pada saat itu hanya terdiri dari beberapa orang, dan kontraktor lain - penampilannya, sebenarnya, disebabkan oleh fakta bahwa integrator tersebut pada saat itu saya tidak dapat menyediakan kapasitas yang kami butuhkan untuk orang-orang.
Masalah apa yang kita miliki saat itu? Ada banyak masalah, tetapi yang paling penting adalah operasi toko online kami yang tidak stabil.
Kita dapat jatuh bahkan dari kenyataan bahwa bisnis itu melakukan semacam buletin, setelah itu ~ 2000-2500 orang datang ke situs tersebut, atau, seperti yang saya ingat sekarang, spanduk iklan di Yandex mengirim kami ke dalam knockdown yang dalam. Tentu saja, hal-hal seperti itu tidak dapat diterima, karena ini bukan hanya kehilangan keuntungan, tetapi juga citra perusahaan - secara umum, kami memahami bahwa sesuatu perlu diubah. Pertama-tama, disadari bahwa solusi standar dengan beban kerja kami (pada saat itu tidak super besar, tetapi masih tidak kecil) tidak akan berfungsi. Kemudian kami memiliki ~ 1000 pengunjung online secara normal, ~ 2500 di puncak, ditambah rencana pengembangan x2 setiap tahun.
Segera diintensifkan dalam hal perangkat keras: kami menambahkan 2 server aplikasi lebih banyak dan membuat sekelompok 2 server basis data. Tumpukan kami pada waktu itu adalah nginx, MySQL, PHP. Secara paralel, kami mencoba mengoptimalkan solusi saat ini - kami mencari kemacetan, mencoba menulis ulang semua yang mungkin. Karena kemacetan kami adalah pangkalan, itu selalu yang pertama untuk "mati", kami memutuskan untuk menurunkannya secara maksimal. Diimplementasikan sphinx untuk pencarian teks lengkap dan output ubin komoditas dengan aspek oleh filter yang dipilih dan cache yang terhubung. Dan voila - muatan yang ternyata berakibat fatal bagi kami kemarin, kami mulai bertahan dengan mudah.
Seiring dengan ini, seorang pilot diluncurkan secara paralel, dalam kerangka yang mereka ingin melakukan pembaruan teknologi situs - transfer ke platform yang berbeda secara mendasar. Ada banyak ide dan ide - pada waktu itu personalisasi segalanya dan segalanya, rekomendasi pribadi, surat, diskon, dan hal-hal bermanfaat lainnya mulai populer, dan kami, tentu saja, juga ingin menggunakan semua ini. Kami melihat apa yang tersedia di pasaran dari ini, yah, dan membeli platform paling mahal dengan prinsip "Sekali lagi mahal, lalu dinginkan." Implementasinya direncanakan dengan bantuan integrator, dan kami masih memiliki dukungan dan pengembangan lebih lanjut dari IM lama bersyarat sampai yang baru dioperasikan pada platform baru.
Tetapi karena kecepatan pengembangan fungsional dari situs saat ini sangat tinggi, kami memutuskan bahwa kami akan memulai implementasi platform e-commerce baru dari yang lebih kecil dan lebih sederhana pada saat itu toko online rantai ritel Austin, yang juga dilayani oleh tim IT Sportmaster. Dalam prosesnya, kami menyadari bahwa benda itu lumayan dan fungsional canggih, tetapi secara teknologi sudah usang, dan menemukan orang untuk sepenuhnya menerapkannya ternyata menjadi masalah besar. Selain itu, ukuran yang dibuat sebelum dimulainya proyek memberikan persyaratan yang sangat berkurang untuk perangkat keras dan jumlah lisensi - kehidupan ternyata jauh lebih kejam. Secara umum, kami memahami satu hal: kami tidak akan melakukan Sportmaster. Dan karena tim untuk bermigrasi ke platform sudah dalam proses merekrut, orang-orang memutuskan untuk mulai membuat prototip solusi mereka sendiri, berdasarkan persyaratan yang ditetapkan oleh bisnis untuk platform baru.
Tumpukan teknologi dipilih sebagai berikut: Java, Spring, Tomcat, ElasticSearch, Hazelcast.
Sebagai hasilnya, pada akhir 2014, kami memiliki versi baru IM siap, sepenuhnya ditulis sendiri, yang kami berhasil beralih. Dia adalah versi pertama dari situs yang Anda lihat hari ini. Secara alami, versi saat ini jauh lebih fungsional dan teknologi, tetapi platform dasarnya sama.
Tugas utama
Tentu saja, ketika kita berbicara tentang toko online besar, kita berbicara tentang kesediaan untuk mengatasi tidak hanya dengan harian, tetapi juga dengan beban puncak - agar stabil untuk bisnis dan pengguna akhir.
Pendekatan utama di sini adalah kemampuan untuk skala secara horizontal dan penerapan pendekatan caching data pada tingkat yang berbeda. Dan sekarang, seperti beberapa waktu lalu, kami memutuskan untuk mengoptimalkan akses ke data kami. Tetapi kita tidak bisa menggunakan caching halaman biasa. Umumnya. Ini adalah persyaratan bisnis, dan persyaratannya cukup masuk akal - jika Anda menunjukkan harga yang salah atau ketersediaan barang yang salah pada saat tertentu kepada pengguna situs, ini kemungkinan besar akan menyebabkan penolakan pembelian dan penurunan loyalitas pelanggan.
Dan tidak apa-apa jika klien memesan 15 pasang kaus kaki untuk 299 rubel, dan di toko ia menemukan bahwa sebenarnya hanya ada 14 pasang dan 300 rubel masing-masing - Anda entah bagaimana dapat hidup dengannya. Terima, beli apa adanya, dan hiduplah dengan bekas luka ini di jiwa Anda. Tetapi jika perbedaan dalam jumlah adalah serius, atau Anda sedang mencari ukuran tertentu - dan itu dibeli saat Anda membaca ulasan dari pemilik celana pendek kotak-kotak yang bahagia, di sini semuanya sudah lebih sedih. Yaitu, segera kehilangan klien yang puas (sampai saat ini), dan hilangnya waktu dan uang untuk pekerjaan call center, di mana klien ini akan menelepon untuk mencari tahu apa yang terjadi dan mengapa.
Oleh karena itu, pengguna harus selalu melihat harga terbaru dan data terkini tentang saldo komoditas, dan oleh karena itu cache kami cerdas dan tahu kapan data dalam database berubah. Untuk caching kami menggunakan Hazelcast.
By the way, tentang sisa makanan
Penting untuk dicatat di sini bahwa kedalaman residu komoditas sangat kecil. Dan sejumlah besar pesanan diambil (sangat). Oleh karena itu, klien biasanya harus memesan barang di toko yang tepat dan melacak saldo. Pada suatu waktu, pada Bitrix, masalah residu diambil oleh fakta bahwa mereka hanya menganggap residu lebih dari 10 unit sebagai tak terhingga. Artinya, segala sesuatu yang lebih dari 10 selalu sama dengan 10, tetapi nilai yang lebih rendah sudah menarik untuk kita hitung dan kita memperhitungkannya, mengunggahnya ke situs.
Sekarang tidak mungkin lagi melakukan ini, jadi kami mengunduh sisa makanan dari semua toko setiap 15 menit. Dan kami memiliki sekitar 500 toko, ditambah sejumlah gudang regional, ditambah beberapa rantai ritel. Dan semua ini harus segera diperbarui. Ceri di sini adalah fakta bahwa kondisi kerja perusahaan kurir sangat sering berubah pada skala Federasi Rusia, oleh karena itu, parameter pengiriman juga harus dimuat. Selain itu, aliran barang terus menerus dikirim ke gudang perusahaan, itulah sebabnya jumlah barang di gudang diharapkan berubah. Jadi, itu juga perlu ditarik lagi.
Dan di sini adalah bagaimana pengidentifikasi barang komoditas (SKU) dibentuk. Kami memiliki sekitar 40.000, yang disebut model warna barang. Jika kita melangkah lebih jauh ke ukuran barang, kita mendapatkan sekitar 200.000 SKU. Dan untuk semua ini, 200.000 perlu diperbarui pada skala 500 toko.
Kami juga memiliki puluhan ribu kota dan desa tempat kami mengirimkan barang dari toko atau dari gudang. Oleh karena itu, ternyata variabilitas cache hanya untuk satu halaman produk (kota * SKU) bernilai sepersejuta nilai. Pendekatan kami adalah ini: perhitungan ketersediaan unit komoditas tertentu dilakukan saat pengguna memasuki kartu produk. Kami melihat pekerjaan kurir di wilayah pengguna, kami melihat jadwal kerja mereka, kami menghitung rantai pengiriman dan mempertimbangkan durasinya. Seiring dengan ini, sisa-sisa di toko terdekat dianalisis secara paralel, dari mana transportasi dapat diatur.
Untuk mempermudah mengelola semua ini, kami memiliki sejumlah cache yang sangat cepat dalam aplikasi - berkat ini kami dapat dengan cepat mendapatkan semua data yang diperlukan dengan ID, dan mengatasinya dengan cepat. Hal yang sama dengan kurir - kami mengelompokkannya menjadi kelompok, dan kemudian kelompok sudah disimpan ke database. Setiap 15 menit, semua ini diperbarui, untuk setiap permintaan yang masuk, kami menghitung sekelompok kurir tertentu dengan parameter yang diperlukan, mengumpulkannya dan dengan cepat memberikannya kepada pembeli - semuanya baik-baik saja, kami pasti memiliki celana pendek hijau ukuran 50, Anda dapat ambil dengan pena di tiga toko terdekat sekarang, atau pesan di toko di seberang jalan (atau bahkan rumah) selama 3 hari, pilih.
Untuk Moskow, situasi ini mungkin tampak tidak perlu, tetapi untuk daerah ini adalah masalah yang sama sekali berbeda, mereka sering memesan barang ke beberapa toko (yang, mungkin, Anda juga perlu secara khusus melakukannya).
Tokoh
Sekarang situs menerima ribuan permintaan per detik, dengan mempertimbangkan statika dan 500-1000 permintaan per detik ke server aplikasi. Jumlah server aplikasi tidak berubah, tetapi konfigurasinya telah tumbuh secara signifikan. Rata-rata sekitar 3.000.000 tampilan per hari diperoleh.
DDoS terkadang ditemukan di situs. Pada saat yang sama, mereka mengetuk botnet, apalagi, kerabat kami dari Federasi Rusia. Dahulu kala ada kasus upaya untuk mengetuk botnet dari Meksiko dan Taiwan, tetapi sekarang ini tidak lagi menjadi masalah.
Ada sejumlah solusi untuk perlindungan cloud terhadap DDoS di pasaran, ya, dan yang cukup bagus. Tetapi untuk kebijakan keamanan tertentu, kami tidak dapat menggunakan solusi cloud semacam ini.
Apa sekarang?
Kami mulai membuat solusi platform, memisahkan tim tidak secara vertikal (beberapa dari mereka melihat satu situs, dan yang kedua melihat yang lain), tetapi secara horizontal, menyoroti lapisan platform umum, membaginya menjadi beberapa bagian, membentuk sebuah tim di sekitarnya. Dan pada mereka kami sudah menutup situs dan tidak hanya, termasuk pelanggan perusahaan, baik eksternal maupun internal. Karena itu, kami memiliki banyak pekerjaan yang kompleks dan menarik.
Tumpukan di bagian depan, untuk alasan yang jelas, belum benar-benar berubah selama ini - Java, Spring, Tomcat, ElasticSearch, Hazelcast masih bagus untuk kebutuhan kita. Hal lain adalah bahwa sekarang banyak sistem back-office pada berbagai teknologi tersembunyi di balik situs. Dan, tentu saja, rekayasa ulang sedang berlangsung (karena permintaan untuk sistem internal dan bekerja bersama mereka secara keseluruhan perlu dioptimalkan, ditambah kita tidak melupakan persyaratan bisnis dan fungsi bisnis baru).
Dan Anda dapat dengan aman memasukkan saya dalam saran pribadi (atau dalam komentar) tentang peningkatan situs - baik dalam hal fitur baru, dan komponen visual dan pengalaman pengguna secara keseluruhan. Kami akan mencoba untuk merespon dengan cepat dan memperhitungkan semuanya. Dan jika Anda ingin menjadi bagian dari tim dan melihat semuanya dari dalam -
selamat datang .