😳 🧔🏿 ➿ Teknologi Radar: Daftar Bahasa, Alat, dan Platform yang Melewati Tangan Lamoda 👏🏾 🙏 🈳

Dalam komentar di artikel terakhir kami , ada banyak pertanyaan tentang teknologi yang kami gunakan. Dalam artikel ini, saya - Igor Mosyagin, pengembang R&D Lamoda - akan saya ceritakan tentang mereka. Di bawah potongan Anda akan menemukan daftar lengkap bahasa, alat, platform dan teknologi yang telah melewati tangan kami. Frontend, backend, database, pialang pesan, cache dan pemantauan, pengembangan, dan penyeimbangan adalah kisah terperinci tentang apa yang kita gunakan hari ini dan apa yang telah kita tinggalkan.

Rekan-rekan saya dan saya siap untuk berdiskusi di komentar atau di stand perusahaan di HighLoad ++ 2018.

Lihat radar secara luas dan terperinci di sini.

Seperti yang telah kami katakan, sejumlah besar teknologi dan alat yang berbeda terlibat dalam Lamoda. Dan ini bukan kebetulan. Kalau tidak, kita tidak bisa mengatasi beban! Kami memiliki gudang otomatis yang besar. Call-center kami dilayani oleh 500 karyawan, dan proses yang kami bangun memungkinkan kami untuk menelepon kembali pelanggan dalam waktu 5 menit setelah melakukan pemesanan. Layanan pengiriman kami beroperasi dengan interval 15 menit. Namun selain sistem kami sendiri, kami memiliki integrasi B2B dengan toko online lainnya. Dengan beragam tugas dan persyaratan bisnis dinamis seperti e-commerce, pertumbuhan tumpukan teknis tidak bisa dihindari, karena kami ingin menyelesaikan setiap masalah dengan teknologi yang paling sesuai. Keragaman tidak bisa dihindari. Kami akan berbicara tentang perwakilan utama tumpukan kami di bawah ini. Tetapi mari kita mulai dengan mekanisme yang memungkinkan kita untuk tidak tersesat dalam varietas ini.

Esensi Arsitektur

Kami secara aktif bergerak menuju arsitektur layanan mikro. Sebagian besar sistem telah dibangun sesuai dengan ideologi ini - dua tahun yang lalu kami melewati tahap transisi dengan masalah dan solusi mereka. Tetapi kami tidak akan membahas perincian proses ini - sebuah laporan oleh Andrey Evsyukov " Fitur-fitur layanan-mikro pada contoh platform e-Com " akan memberi tahu lebih banyak tentang ini.

Agar tidak memperburuk keragaman teknologi, kami telah memperkenalkan "kediktatoran praktik yang terbukti", yang menurutnya pencipta chip baru direkomendasikan untuk menggunakan teknologi dan alat yang sudah digunakan di suatu tempat di perusahaan. Sebagian besar layanan berkomunikasi satu sama lain melalui API (kami menggunakan modifikasi kami dari versi kedua standar JSONRPC), tetapi jika logika bisnis memungkinkannya, kami juga menggunakan bus data untuk berinteraksi.

Penggunaan teknologi lain tidak dilarang. Namun, setiap ide baru harus diuji dalam komite arsitektur yang dibuat khusus, yang mencakup para pemimpin bidang utama.

Mempertimbangkan proposal berikutnya, panitia memberikan lampu hijau untuk percobaan, atau menawarkan semacam pengganti dari tumpukan yang ada. Omong-omong, keputusan ini sangat tergantung pada keadaan saat ini dalam bisnis. Sebagai contoh, jika sebuah tim datang menjelang penjualan Black Friday dan mengumumkan bahwa mereka akan memperkenalkan teknologi ke dalam produksi yang belum pernah didengar komite, kemungkinan besar akan ditolak. Di sisi lain, percobaan yang sama dapat diberikan lampu hijau jika teknologi atau alat baru diperkenalkan dalam keadaan bisnis yang kurang kritis, dan implementasi akan dimulai dengan pengujian di luar produksi.

Komite Arsitektur juga bertanggung jawab untuk memelihara radar Teknologi, membuat perubahan yang diperlukan setiap 2-3 bulan. Salah satu tujuan dari sumber daya ini adalah untuk memberi tim gagasan tentang keahlian apa yang sudah dimiliki perusahaan.

Tapi mari kita beralih ke yang paling menarik - untuk analisis sektor-sektor radar kita.

Perlu dicatat bahwa kami menggunakan interpretasi yang sedikit tidak standar dari kategori adopsi teknologi:

ADOPT - teknologi dan alat yang diimplementasikan dan digunakan secara aktif;
TRIAL - teknologi dan peralatan yang telah melewati tahap pengujian dan sedang bersiap untuk bekerja dengan produksi (atau bahkan sudah bekerja di sana);
ASSESS - alat percobaan yang saat ini sedang dievaluasi dan belum mempengaruhi produksi. Dengan partisipasinya, hanya proyek uji yang dilaksanakan;
TAHAN - dalam kategori ini kami memiliki keahlian, tetapi alat yang disebutkan hanya digunakan dengan dukungan sistem yang ada - proyek baru tidak diluncurkan pada mereka.

Pengembangan

PHP - Python - Go

Bahasa pertama yang ingin kita bahas adalah PHP. Hari ini hanya menyelesaikan sebagian dari tugas backend toko, dan awalnya seluruh backend bekerja pada PHP. Ketika bisnis ditingkatkan di front-end, kurangnya kecepatan dan produktivitas menjadi nyata - saat itu kami menggunakan PHP 5, jadi Python menggantinya (pertama 2.x, dan kemudian 3.x). Namun, PHP memungkinkan Anda untuk menulis model bisnis yang kaya, sehingga bahasa ini tetap berada di kantor belakang untuk mengotomatisasi berbagai proses operasional, khususnya, integrasi dengan toko online pihak ketiga atau layanan pengiriman, serta otomatisasi studio konten yang menyusun kartu produk. Sekarang kami sudah menggunakan PHP 7. Dalam PHP kami telah menulis banyak perpustakaan untuk penggunaan internal: integrasi dan pembungkus infrastruktur kami, lapisan integrasi antara layanan, berbagai pembantu yang digunakan kembali. Kumpulan perpustakaan pertama telah diambil untuk sumber terbuka di github.com kami , dan sisanya, yang paling "matang", akan segera tiba. Salah satu yang pertama adalah mesin negara, yang hadir di hampir semua aplikasi, memastikan bahwa dengan pesanan sebelum mengirim semua tindakan yang diperlukan.

Seiring waktu, Python juga menjadi tidak cukup untuk backend toko. Sekarang kami lebih suka Go yang lebih produktif dan ringan.

Mungkin transisi ke Go adalah perubahan penting, karena menghemat banyak perangkat keras dan sumber daya manusia - efisiensinya meningkat secara signifikan. Yang pertama membuat proyek pertama di Go adalah RnD, mereka tidak mau berurusan dengan keterbatasan teknis Python. Kemudian di tim pengembangan ponsel ada orang-orang yang akrab dengannya dan mempromosikannya ke produksi. Dari pengajuan mereka, kami melakukan tes dan lebih dari puas dengan hasilnya. Dalam kasus terpisah, setelah bagian dari proyek ditulis ulang dari Python ke Go, memuat node cluster turun secara signifikan. Misalnya, menulis ulang mesin penghitungan diskon untuk keranjang dari Python ke Go memungkinkan kami memproses 8 kali lebih banyak permintaan pada kapasitas perangkat keras yang sama, dan waktu respons API rata-rata berkurang 25 kali. Yaitu Go ternyata lebih efisien daripada Python (jika Anda menulisnya dengan benar), bahkan jika itu tidak begitu nyaman bagi pengembang.

Karena pengembangan seluler harus berinteraksi dengan lusinan API internal, pembuat kode dibuat, sesuai dengan deskripsi layanan API (sesuai dengan spesifikasi Swagger), klien dapat menghasilkan di Go. Jadi On Go secara bertahap mulai berkorespondensi dengan layanan dan alat yang ada, terutama yang menciptakan "bottleneck" untuk muatan. Selain membuat hidup lebih mudah bagi pengembang backend seluler, kami telah menyederhanakan mengikuti konvensi internal tentang cara mengembangkan API, cara memberi nama metode, cara menyampaikan parameter, dan sejenisnya. Standarisasi ini telah membuat pengembangan dan implementasi layanan baru lebih mudah untuk semua tim.

Hari ini, Go sudah digunakan hampir di mana-mana - dalam semua interaksi waktu nyata dengan pengguna - di backend situs dan aplikasi seluler, serta layanan yang terkait dengannya. Dan di mana tidak perlu pemrosesan cepat dan respons, misalnya, dalam tugas berinteraksi dengan gudang data, Python tetap, karena tidak ada yang sama untuk tugas pemrosesan data (meskipun ada penetrasi Go di sini).

Seperti yang dapat Anda lihat di radar, kami memiliki Java di aset. Ini digunakan dalam Sistem Manajemen Gudang (WMS), membantu dengan cepat mengumpulkan pesanan. Sejauh ini, kami memiliki tumpukan yang cukup lama di sana dan model arsitektur lama - pemintalan monolit pada Wildfly 10 dan 8 Java Hotspot, dan ada juga klien yang kaya dan terpencil di Platform Aplikasi Netbeans (sekarang fungsi ini ditransfer ke web). Di sini, di gudang kami, kami memiliki penyimpanan standar untuk perusahaan dan bahkan pemantauan kami sendiri. Sayangnya, kami tidak menemukan alat yang dapat dengan baik memvisualisasikan operasi gudang dan proses penting di atasnya (ketika bagian kelebihan beban, misalnya), dan membuat alat seperti itu sendiri.

Kami menggunakan Python sebagai bahasa utama untuk pembelajaran mesin: kami membangun sistem rekomendasi dan memberi peringkat pada katalog, mengoreksi kesalahan ketik dalam permintaan pencarian, dan juga memecahkan masalah lain sehubungan dengan Spark pada cluster Hadoop (PySpark). Python membantu kami mengotomatiskan perhitungan metrik internal dan pengujian AB.

Pengembangan frontend dan mobile

Bagian depan toko online desktop, serta situs seluler, ditulis dalam JavaScript. Sekarang frontend secara bertahap pindah ke spesifikasi ES6, menciptakan proyek baru yang sesuai dengannya. Kami menggunakan vue.js sebagai kerangka kerja utama, tetapi kami akan membahasnya lebih detail di bagian alat.

Pengembangan aplikasi untuk platform seluler adalah unit terpisah di perusahaan, yang meliputi kelompok backend, serta aplikasi Android dan iOS dengan tumpukan teknologi dan alat mereka sendiri, yang, karena perbedaan platform, jauh dari selalu bersatu di seluruh unit.

Selama dua tahun sekarang, semua pengembangan Android baru telah berlangsung di Kotlin, yang memungkinkan kita untuk menulis kode yang lebih ringkas dan mudah dipahami. Di antara fitur yang paling sering digunakan, pengembang kami memanggil: smartcast, kelas tertutup, fungsi ekstensi, pembangun typesafe (DSL), fungsionalitas stdlib.

Pengembangan iOS sedang berlangsung di Swift, yang menggantikan Objective-C.

Bahasa khusus

Rentang tugas Lamoda tidak terbatas pada pengembangan "showcase" untuk platform yang berbeda, karena itu, kami memiliki sejumlah bahasa yang hanya digunakan dalam kerangka sistem kami, berfungsi dengan baik di sana, tetapi tidak akan diimplementasikan di bagian lain dari infrastruktur:

R - digunakan untuk pemrosesan data dan skrip pelaporan dalam kerangka intelijen bisnis (BI). Itu tidak dalam produksi dan tidak lagi digunakan untuk tugas-tugas baru, tetapi kami masih memiliki sejumlah skrip seperti itu. Memecahkan masalah dengan R, kami menyadari bahwa bahasa ini bukan untuk aplikasi yang sangat dimuat. Dalam tugas baru, kami menggunakan Python dan teknologi lain yang tidak kompatibel dengan R.
Scala - digunakan oleh kantor pengembangan di Vilnius untuk mengembangkan sistem otomasi pusat panggilan. Awalnya, sistem ini ditulis dalam PHP, tetapi selama transisi ke arsitektur microservice, sejumlah komponen ditulis ulang dalam Scala. Juga di atasnya, tim Rekayasa Data menulis pekerjaan Spark.
TypeScript yang kita lihat. Pengiriman sudah dilaksanakan dengan bantuannya, dan di masa depan kita akan menggunakan TypeScript + vue.js di frontend.
Lua digunakan untuk mengkonfigurasi nginx (melalui API nginx), dalam proyek lain tidak dan tidak akan pernah.
Kami adalah perusahaan mode dan mengikuti mode untuk pemrograman fungsional. Misalnya, emulator perangkat sortir di salah satu gudang kami ditulis dalam Haskell.

Manajemen data

DBMS, pencarian dan analisis data

Seperti banyak, basis data paling beragam yang telah kami terapkan pada PostgreSQL - digunakan di mana pun basis data relasional diperlukan, misalnya, untuk menyimpan direktori. Sangat mudah untuk menemukan spesialis dalam teknologi ini, di samping itu, banyak layanan yang berbeda tersedia.

Tentu saja, PostgreSQL bukan satu-satunya DBMS yang dapat ditemukan di infrastruktur TI kami. Pada beberapa sistem yang lebih lama, misalnya, MySQL digunakan, sedangkan WMS memiliki sedikit MongoDB. Namun, untuk beban tinggi dan penskalaan (dengan mempertimbangkan sisa tumpukan teknologi kami), kami tidak menggunakannya untuk proyek baru. Secara umum, PostgreSQL adalah segalanya bagi kami.

Aerospike juga terlihat di radar. Kami menggunakannya dengan cukup aktif, tetapi kemudian perjanjian lisensi berubah untuk produk tersebut, sehingga versi "kami" ternyata agak terpotong. Namun, sekarang kami menatapnya lagi. Mungkin kita akan mempertimbangkan kembali sikap kita terhadap instrumen dan akan menggunakannya lebih aktif. Sekarang Aerospike digunakan dalam layanan agregasi acara melihat halaman dan pekerjaan pengguna dengan keranjang, serta dalam layanan sosial-bukti ("5 orang menambahkan produk ini ke favorit minggu ini"). Sekarang kami bahkan membuat rekomendasi yang lebih curam.

Apache Solr digunakan untuk mencari data produksi. Secara paralel, kami juga menggunakan ElasticSearch. Kedua solusi adalah open source, tetapi jika sebelumnya, ketika kami baru saja mengimplementasikan pencarian, Apache Solr sudah memiliki versi ketiga atau keempat dan secara aktif berkembang, dan ElasticSearch bahkan tidak memiliki rilis stabil pertama - masih terlalu dini untuk menggunakannya pada produksi. Sekarang peran telah berubah - jauh lebih mudah untuk menemukan solusi untuk ElasticSearch, dan orang-orang baru telah datang kepada kami yang pandai mempersiapkannya. Namun, di prod kami memiliki Solr, dan kami tidak akan pindah ke solusi lain setidaknya sampai Black Friday 2018.

Perbandingan dinamika permintaan pencarian Apache Solr (biru) dan ElasticSearch (merah), menurut Google Trends

Analisis data terjadi di beberapa sistem, khususnya, kami secara aktif menggunakan Apache Hadoop. Pada saat yang sama, kolom Vertica DBMS digunakan untuk menyimpan data mart (dengan volume total sekitar 4 TB). Selama Showcases ini, pelaporan keuangan, operasional dan komersial dibangun. Untuk banyak tugas ETL kami, kami sebelumnya menggunakan Luigi, tapi sekarang kami pindah ke Apache Airflow. Kami juga menggunakan Pentaho untuk penyimpanan relasional, di mana ada sekitar seribu tugas ETL biasa.

Bagian dari analisis dan persiapan data untuk sistem lain dilakukan di Spark. Di beberapa tempat, ini bukan hanya alat analisis, tetapi juga bagian dari arsitektur lambda kami.

Peran penting dalam infrastruktur TI dimainkan oleh sistem ERP: Microsoft Dynamics AX dan 1C. Sebagai DBMS, Microsoft SQL Server digunakan. Dan untuk pelaporan, komponennya, seperti layanan Analisis dan layanan Pelaporan.

Caching

Untuk caching kami menggunakan Redis. Sebelumnya, tugas ini dilakukan oleh MemCached, itu tidak dapat digunakan sebagai penyimpanan nilai kunci dengan dump berkala ke disk, jadi kami mengabaikannya.

Antrian pesan

Sebagai broker acara, kami menggunakan dua alat sekaligus - Apache Kafka dan RabbitMQ.
Apache Kafka adalah alat yang memungkinkan kita memproses puluhan ribu pesan di berbagai sistem di mana pengiriman pesan diperlukan. Cluster Kafka yang terpisah digunakan untuk beberapa bagian sistem yang sarat muatan - misalnya, untuk acara pengguna atau pencatatan (kami memiliki laporan bagus tentang pencatatan di Highload ++ 2017 ). Kafka memungkinkan Anda untuk mengatasi 6000 ribu pesan massal per detik dengan penggunaan besi yang minimal.

Dalam sistem internal, kami menggunakan RabbitMQ untuk tindakan yang ditangguhkan.

Platform dan Infrastruktur

Pengiriman terus menerus

Untuk penyebaran, Kubernetes digunakan, yang menggantikan bundel Nomad + Konsul dari Hashicorp. Tumpukan sebelumnya bekerja sangat buruk dengan peningkatan perangkat keras. Ketika tim Ops kami mengubah server fisik tempat node berputar dan wadah disimpan, secara berkala rusak dan jatuh, tidak ingin naik. Tidak ada versi stabil saat itu. Selain itu, kami tidak menggunakan yang terbaru pada saat itu - 0,5.6, yang masih perlu diperbarui. Untuk meningkatkan ke versi beta terakhir diperlukan beberapa pekerjaan. Karena itu, diputuskan untuk meninggalkannya dan beralih ke Kubernet yang lebih populer.

Sekarang Nomad dan Konsul masih digunakan di QA, tetapi di masa depan ia juga harus pindah ke Kubernetes.

Untuk menerapkan pengiriman berkelanjutan, kontainer Docker digunakan, yang telah kami migrasi dua tahun lalu. Untuk layanan kami yang penuh muatan (keranjang, katalog, situs web, sistem manajemen pesanan), kemampuan untuk dengan cepat mengambil beberapa kontainer tambahan dari suatu layanan adalah penting, jadi kami memiliki kontainer di mana-mana. Dan Docker adalah salah satu metode kemasukan yang paling populer, sehingga kehadirannya di radar cukup logis.

Sebagai server build dan integrasi berkesinambungan, Bamboo dikerahkan, digunakan bersama dengan Jira dan Bitbucket (tumpukan standar).

Jenkins juga disebutkan dalam radar. Kami bereksperimen dengannya, tetapi kami tidak akan menyeretnya ke proyek baru. Ini adalah alat yang hebat, tetapi tidak pas di tumpukan kami karena kami sudah memiliki Bambu.

Dikumpulkan menggunakan buruh pelabuhan Bambu-wadah disimpan di repositori di bawah kendali Artifactory.

Manajemen proses dan penyeimbangan

Kami menggunakan NGINX Plus, tetapi tidak dalam hal menyeimbangkan, karena metriknya tidak cukup untuk tugas kami. Dia tidak bisa mengatakan, misalnya, permintaan mana yang paling sering dialihkan atau dibekukan. Oleh karena itu, HAProxy digunakan untuk menyeimbangkan beban. Ia dapat bekerja dengan cepat dan efisien bersamaan dengan nginx, tanpa memuat prosesor dan memori. Selain itu, metrik yang kami butuhkan ada di sini di luar kotak - HAproxy dapat menampilkan statistik dengan node, dengan jumlah koneksi saat ini, dengan seberapa sibuk bandwidth dan banyak lagi.

UWSGI digunakan untuk menjalankan aplikasi Python sinkron. Php-fpm digunakan sebagai manajer proses pada semua layanan PHP.

Pemantauan

Kami menggunakan Prometheus untuk mengumpulkan metrik dari aplikasi kami dan mesin host (mesin virtual), serta basis data time series untuk aplikasi tersebut . Kami mengumpulkan log, untuk ini kami menggunakan tumpukan ELK, sebagai sistem peringatan kami menggunakan Icinga, yang dikonfigurasi untuk ELK dan Prometheus. Dia mengirimkan peringatan ke surat dan SMS. Layanan dukungan 6911 menerima peringatan yang sama dan memutuskan untuk menarik insinyur tugas.

Prometheus terlibat hampir di mana-mana, dan untuk ini kami memiliki perpustakaan untuk semua bahasa, yang memungkinkan penggunaan hanya beberapa baris kode untuk menghubungkan metriknya ke proyek. Misalnya, perpustakaan untuk PHP tersedia di Open Source ).

Untuk menampilkan secara visual hasil pemantauan dalam bentuk dasbor yang indah, Grafana digunakan. Pada dasarnya, kami mengumpulkan semua dasbor dari Prometheus, meskipun terkadang sistem lain juga dapat berfungsi sebagai sumber.

Untuk menangkap dan mengumpulkan kesalahan secara otomatis, kami menggunakan Sentry, yang terintegrasi dengan Jira dan membuatnya mudah untuk memulai pelacak tugas untuk setiap masalah produksi. Dia tahu cara menangkap kesalahan dengan beberapa backtrack dan informasi tambahan, jadi itu mudah untuk debut.

Statistik pada kode permintaan tarikan yang dibuat dikumpulkan menggunakan SonarQube.

Kerangka dan alat

Selama pengembangan infrastruktur TI Lamoda, kami bereksperimen dengan hampir tiga lusin alat yang berbeda, sehingga kategori ini adalah yang paling “berskala besar” pada radar kami. Sampai saat ini, digunakan secara aktif:

Symfony 3.x, dan yang terbaru - Symfony 4.x - untuk pengembangan di PHP;
Django dan mesin template Jinja untuk pengembangan Python. Omong-omong, Jinja digunakan, termasuk, untuk konfigurasi di Ansible;
Labu - untuk layanan internal (bersama dengan Django), tetapi dalam produksi kami tidak menyeretnya;
Musim semi - dalam pembangunan Jawa;
Bootstrap - untuk berbagai alat internal dalam pengembangan web (panel admin, dasbor buatan sendiri, dll.);
jQuery - untuk pengembangan js;
OpenAPI (Swagger) - untuk dokumentasi semua layanan API, termasuk yang digunakan untuk pembuatan kode di atas on Go;
Webpack - untuk mengemas JS dan meminimalkan CSS;
Selenium - untuk menguji frontend;
WireMock, JMeter, Allure dan lainnya juga digunakan dalam pengujian;
Ansible - untuk manajemen konfigurasi;
Kibana - untuk memvisualisasikan hasil pencarian di ElasticSearch.

Saya ingin berbicara tentang pengembangan JavaScript secara terpisah. Kami, seperti banyak orang, memiliki seluruh bidang percobaan.Situs untuk JavaScript menggunakan kerangka kerja yang ditulis sendiri. Di ujung depan, dalam kerangka tugas yang tidak penting untuk bisnis, percobaan dilakukan dengan kerangka kerja yang berbeda - Angular, ReactJS, vue.js. Dalam "perlombaan senjata" ini, tampaknya vue.js, yang awalnya digunakan dalam sistem otomasi studio konten, tampaknya menjadi yang terdepan, dan sekarang secara bertahap datang ke mana-mana.

Dalam residu kering

Jika kami mencoba menggambarkan semua keragaman ini secara singkat, maka kami menulis dalam GO, PHP, Java, JavaScript, kami memegang basis data di PostgreSQL, dan kami menggunakan Docker dan Kubernetes.

Tentu saja, keadaan yang dijelaskan dari tumpukan teknologi tidak dapat disebut final. Kami terus berkembang, dan dengan meningkatnya beban, kelas solusi yang sesuai harus diubah, yang dengan sendirinya merupakan tugas yang menarik. Pada saat yang sama, logika bisnis semakin rumit, jadi kami harus terus mencari alat baru. Jika Anda ingin berdebat tentang topik mengapa Anda memilih alat ini dan bukan yang lain, selamat datang untuk berkomentar.

Teknologi Radar: Daftar Bahasa, Alat, dan Platform yang Melewati Tangan Lamoda