Halo, nami abdi Evgeniy. Abdi damel di infrastruktur pilarian Yandex.Market. Abdi hoyong ngawartosan komunitas Habr ngeunaan dapur jero Pasar - sareng kuring gaduh seueur anu dicarioskeun. Anu mimiti, kumaha cara milarian Pasar, prosés sareng arsitéktur. Kumaha urang nungkulan kaayaan darurat: naon anu lumangsung lamun hiji server turun? Kumaha upami aya 100 server sapertos kitu?
Anjeun ogé bakal diajar kumaha urang nerapkeun fungsionalitas anyar dina sababaraha server sakaligus. Sareng kumaha urang nguji jasa kompléks langsung dina produksi, tanpa nyababkeun kasulitan pikeun pangguna. Sacara umum, kumaha pilarian Market jalan ambéh dulur boga waktu nu sae.
A saeutik ngeunaan urang: naon masalah urang ngajawab
Lamun anjeun ngasupkeun téks, neangan hiji produk dumasar parameter, atawa ngabandingkeun harga di toko béda, sadaya requests dikirim ka layanan pilarian. Pilarian mangrupikeun jasa panggedéna di Pasar.
Urang ngolah sagala pamundut pilarian: ti loka market.yandex.ru, beru.ru, ladenan Supercheck, Yandex.Advisor, aplikasi mobile. Kami ogé ngalebetkeun tawaran produk dina hasil pamilarian dina yandex.ru.
Ku layanan pilarian maksudna mah teu ukur pilarian sorangan, tapi ogé database kalawan sagala nawaran on Pasar. Skala ieu: leuwih ti samilyar pamundut pilarian diprosés per poé. Sareng sadayana kedah dianggo gancang, tanpa gangguan sareng salawasna ngahasilkeun hasil anu dipikahoyong.
Naon naon: arsitéktur pasar
Kuring bakal ngajelaskeun sakeudeung arsitéktur Pasar ayeuna. Sacara kasar bisa digambarkeun ku diagram di handap ieu:
Hayu urang nyebutkeun hiji toko mitra datang ka kami. Manéhna nyebutkeun Abdi hoyong ngajual cocooan: ucing jahat ieu kalawan squeaker a. Jeung ucing ambek sejen tanpa squeaker a. Jeung ngan ucing. Lajeng toko perlu nyiapkeun nawaran nu Market pilarian. Toko ngahasilkeun xml khusus sareng nawaran sareng ngahubungkeun jalur ka xml ieu ngalangkungan antarmuka afiliasi. Indéks teras périodik ngaunduh xml ieu, pariksa kasalahan sareng nyimpen sadaya inpormasi kana pangkalan data anu ageung.
Aya seueur xml anu disimpen sapertos kitu. A indéks pilarian dijieun tina database ieu. Indéks disimpen dina format internal. Saatos nyiptakeun indéks, jasa Layout unggah kana pangladén milarian.
Hasilna, ucing ambek kalawan squeaker mucunghul dina database, sarta indéks ucing urang mucunghul dina server.
Kuring gé ngabejaan Anjeun kumaha urang neangan ucing dina bagian ngeunaan arsitéktur pilarian.
Arsitéktur pilarian pasar
Urang hirup di dunya microservices: unggal pamundut asup ngabalukarkeun loba subqueries, sarta puluhan jasa aub dina processing maranéhna. Diagram ngan ukur nunjukkeun sababaraha:
Skéma pamrosésan pamundut saderhana
Masing-masing jasa ngagaduhan hal anu saé - penyeimbang sorangan kalayan nami anu unik:
Balancer masihan kami kalenturan anu langkung ageung pikeun ngatur jasa: anjeun tiasa, contona, mareuman server, anu sering diperyogikeun pikeun apdet. Balancer ningali yén server henteu sayogi sareng otomatis alihan pamundut ka server atanapi pusat data sanés. Nalika nambihan atanapi ngahapus server, beban sacara otomatis disebarkeun deui antara server.
Ngaran unik tina balancer henteu gumantung kana puseur data. Nalika jasa A nyuhunkeun pamundut ka B, sacara standar balancer B alihan pamundut ka pusat data ayeuna. Upami jasana henteu sayogi atanapi henteu aya dina pusat data anu ayeuna, teras pamundutna dialihkeun ka pusat data anu sanés.
A FQDN tunggal pikeun sakabéh puseur data ngamungkinkeun layanan A lengkep abstrak ti lokasi. Pamenta na ka layanan B bakal salawasna diprosés. Pangecualian nyaéta kasus nalika jasa aya di sadaya pusat data.
Tapi teu sagalana jadi rosy kalawan balancer ieu: urang boga komponén tambahan tambahan. balancer bisa jadi teu stabil, sarta masalah ieu direngsekeun ku server kaleuleuwihan. Aya ogé reureuh tambahan antara jasa A jeung B. Tapi dina prakna éta kirang ti 1 mdet sarta pikeun sabagéan ageung jasa ieu teu kritis.
Kaayaan anu teu kaduga: Milarian Balancing sareng Ketahanan Layanan
Bayangkeun yén aya runtuhna: anjeun kedah mendakan ucing kalayan squeaker, tapi server nabrak. Atawa 100 server. Kumaha carana kaluar? Naha urang leres-leres bakal ngantunkeun pangguna tanpa ucing?
Kaayaan pikasieuneun, tapi kami siap pikeun éta. Kuring gé ngabejaan Anjeun dina urutan.
Infrastruktur pilarian ayana di sababaraha puseur data:
Nalika ngarancang, urang kalebet kamungkinan mareuman hiji pusat data. Kahirupan pinuh ku kejutan - contona, hiji excavator bisa motong kabel jero taneuh (enya, éta kajadian). Kapasitas dina sésa-sésa pusat data kedah cekap pikeun nahan beban puncak.
Hayu urang nganggap pusat data tunggal. Unggal puseur data boga skéma operasi balancer sarua:
Hiji balancer sahenteuna tilu server fisik. redundancy ieu dijieun pikeun reliabilitas. Balancers ngajalankeun on HAProx.
Kami milih HAProx kusabab kinerja anu luhur, syarat sumberdaya anu rendah sareng fungsionalitas anu lega. Parangkat lunak milarian kami dijalankeun dina unggal server.
Kamungkinan hiji server gagal rendah. Tapi upami anjeun gaduh seueur server, kamungkinan sahenteuna hiji bakal turun naék.
Ieu naon kajadian kanyataanana: server kacilakaan. Ku alatan éta, perlu terus-terusan ngawas status sadaya server. Lamun server eureun ngarespon, eta otomatis dipegatkeun tina lalulintas. Pikeun tujuan ieu, HAProxy gaduh pamariksaan kaséhatan anu diwangun. Éta mana ka sadaya server sakali sadetik kalayan pamundut HTTP "/ ping".
Fitur HAProxy anu sanés: cek agén ngamungkinkeun anjeun ngamuat sadaya server sacara merata. Jang ngalampahkeun ieu, HAProxy nyambung ka sadaya server, sarta aranjeunna balik beurat maranéhanana gumantung kana beban ayeuna tina 1 ka 100. Beurat diitung dumasar kana jumlah requests dina antrian pikeun ngolah jeung beban dina processor.
Ayeuna ngeunaan manggihan ucing. Hasil pamilarian dina pamundut sapertos: /search?text=ambek+ucing. Pikeun milarian gancang, sadayana indéks ucing kedah pas kana RAM. Malah maca tina SSD teu cukup gancang.
Sakali kana waktos, database tawaran éta leutik, sarta RAM hiji server éta cukup pikeun eta. Nalika dasar tawaran naék, sadayana henteu pas kana RAM ieu, sareng datana dibagi jadi dua bagian: beling 1 sareng beling 2.
Tapi ieu salawasna kajadian: sagala solusi, sanajan alus, ngabalukarkeun masalah séjén.
The balancer masih indit ka server mana wae. Tapi dina mesin dimana pamundut sumping, aya ngan satengah tina indéks dina. Sésana éta dina server séjén. Ku alatan éta, server kapaksa buka sababaraha mesin tatangga. Sanggeus narima data ti duanana server, hasilna digabungkeun jeung reranked.
Kusabab balancer nu distributes requests merata, sadaya server anu kalibet dina re-ranking, sarta teu ngan ngirim data.
Masalahna lumangsung lamun server tatangga teu sadia. Solusina nyaéta nangtukeun sababaraha server kalayan prioritas anu béda-béda salaku server "tatangga". Kahiji, pamundut ieu dikirim ka server dina rak ayeuna. Lamun teu aya respon, pamundut ieu dikirim ka sadaya server di puseur data ieu. Sarta pamungkas, pamundut indit ka puseur data lianna.
Salaku jumlah usulan tumuwuh, data dibagi kana opat bagian. Tapi ieu teu wates.
Ayeuna, konfigurasi dalapan shards dipaké. Sajaba ti éta, pikeun nyimpen malah leuwih memori, indéks ieu dibagi kana bagian pilarian (anu dipaké pikeun néangan) jeung bagian snippet (anu teu kalibet dina pilarian).
Hiji server ngandung émbaran pikeun ngan hiji beling. Ku alatan éta, pikeun milarian indéks pinuh, anjeun kedah milarian dina dalapan server anu ngandung beling anu béda.
Server dikelompokkeun kana klaster. Unggal klaster ngandung dalapan mesin pencari sareng hiji server snippet.
The snippet server ngajalankeun database konci-nilai kalawan data statik. Éta diperlukeun pikeun ngaluarkeun dokumén, contona, déskripsi ucing jeung squeaker a. Data ditransferkeun khusus ka server anu misah supados henteu ngamuat mémori pangladén milarian.
Kusabab ID dokumen unik ngan dina hiji indéks, kaayaan bisa timbul dimana euweuh dokumén dina snippét. Nya, atanapi yén pikeun hiji ID bakal aya eusi anu béda. Ku alatan éta, supados pamilarian tiasa dianggo sareng hasil dipulangkeun, peryogi konsistensi dina sakumna klaster. Kuring gé ngabejaan Anjeun handap kumaha urang ngawas konsistensi.
Pilarian sorangan terstruktur saperti kieu: pamundut pilarian bisa datang ka salah sahiji dalapan server. Hayu urang nyebutkeun anjeunna sumping ka server 1. server Ieu ngolah sagala argumen na understands naon jeung kumaha carana néangan. Gumantung kana pamundut asup, server bisa nyieun requests tambahan ka jasa éksternal pikeun informasi diperlukeun. Hiji pamundut bisa dituturkeun ku nepi ka sapuluh requests ka jasa éksternal.
Saatos ngumpulkeun inpormasi anu diperyogikeun, pamilarian dimimitian dina database tawaran. Jang ngalampahkeun ieu, subqueries dijieun pikeun sakabéh dalapan server dina klaster.
Sakali réspon ditampi, hasilna digabungkeun. Tungtungna, sababaraha subqueries ka server snippet bisa jadi diperlukeun pikeun ngahasilkeun hasil.
Paménta milarian dina kluster sapertos kieu: /shard1?text=ambek+ucing. Salaku tambahan, subqueries bentuk terus dilakukeun antara sadaya server dina kluster sakali sadetik: /status.
Kahoyong /status ngadeteksi kaayaan dimana server teu sadia.
Éta ogé ngatur yén versi mesin pencari sareng versi indéks sami dina sadaya server, upami henteu bakal aya data anu teu konsisten dina kluster.
Najan kanyataan yén hiji server snippet prosés requests ti dalapan mesin pencari, processor na pisan enteng dimuat. Ku alatan éta, urang ayeuna mindahkeun data snippet ka layanan misah.
Pikeun mindahkeun data, kami ngenalkeun konci universal pikeun dokumén. Ayeuna mustahil pikeun kaayaan dimana eusi tina dokumén anu sanés dipulangkeun nganggo hiji konci.
Tapi transisi ka arsitéktur séjén teu acan réngsé. Ayeuna urang hoyong nyingkirkeun server snippet khusus. Lajeng mindahkeun jauh ti struktur klaster sakabehna. Ieu bakal ngidinan urang neruskeun skala gampang. Bonus tambahan nyaéta tabungan beusi anu signifikan.
Tur ayeuna ka carita pikasieuneun jeung endings senang. Hayu urang mertimbangkeun sababaraha kasus unavailability server.
Aya kajadian anu dahsyat: hiji server henteu sayogi
Hayu urang nyebutkeun hiji server teu sadia. Lajeng server sésana dina klaster bisa neruskeun ngabales, tapi hasil teangan bakal lengkep.
Ngaliwatan cek status /status server tatangga ngarti yén hiji teu sadia. Ku alatan éta, pikeun ngajaga completeness, sadaya server dina klaster per pamundut /ping aranjeunna ngawitan ngabales balancer yén maranéhna ogé sadia. Tétéla yén sakabéh server dina klaster maot (nu teu bener). Ieu mangrupikeun kalemahan utama skéma klaster kami - éta sababna urang hoyong ngajauhan éta.
Paménta anu gagal sareng kasalahan anu diambek ku pangimbang dina server anu sanés.
Balancer ogé ngeureunkeun ngirim lalu lintas pangguna ka server anu maot, tapi terus mariksa statusna.
Nalika server janten sadia, dimimitian ngabales /ping. Pas réspon normal pikeun ping ti server maot ngawitan sumping, balancers mimiti ngirim lalulintas pamaké dinya. Operasi klaster dibalikeun deui, hurray.
Malah parah: seueur server anu henteu sayogi
Bagian signifikan tina server di puseur data ditegor. Naon anu kudu dipigawé, dimana ngajalankeun? Balancer datang ka nyalametkeun deui. Unggal balancer terus nyimpen dina mémori jumlah kiwari server live. Éta terus ngitung jumlah maksimum lalu lintas anu tiasa diolah ku pusat data ayeuna.
Nalika seueur server di pusat data turun, pangimbang sadar yén pusat data ieu henteu tiasa ngolah sadaya lalu lintas.
Lajeng kaleuwihan lalulintas mimiti disebarkeun acak ka puseur data lianna. Sagalana jalan, dulur senang.
Kumaha urang ngalakukeun eta: medarkeun Kaluaran
Ayeuna hayu urang ngobrol ngeunaan kumaha urang nyebarkeun parobahan anu dilakukeun kana jasa éta. Di dieu kami geus nyokot jalur nyederhanakeun prosés: rolling kaluar release anyar ampir sagemblengna otomatis.
Nalika sajumlah parobihan akumulasi dina proyék éta, sékrési énggal otomatis didamel sareng ngawangunna dimimitian.
Lajeng jasa digulung kaluar pikeun nguji, dimana stabilitas operasi dipariksa.
Dina waktos anu sami, uji kinerja otomatis diluncurkeun. Ieu diatur ku layanan husus. Kuring moal ngobrol ngeunaan eta ayeuna - pedaran na pantes hiji artikel misah.
Upami publikasi dina tés suksés, publikasi sékrési dina prestable otomatis dimimitian. Prestable mangrupakeun klaster husus dimana lalulintas pamaké normal diarahkeun. Lamun balik kasalahan, balancer ngajadikeun ulang pamundut ka produksi.
Dina prestable, waktu respon diukur sarta dibandingkeun jeung release saméméhna dina produksi. Upami sadayana henteu kunanaon, maka hiji jalma nyambung: pariksa grafik sareng hasil uji beban teras ngamimitian ngaluncurkeun ka produksi.
Sadaya anu pangsaéna pikeun pangguna: Uji A / B
Teu salawasna atra naha parobahan jasa bakal mawa kauntungan nyata. Pikeun ngukur mangpaat parobihan, jalma datang sareng uji A / B. Kuring gé ngabejaan Anjeun saeutik ngeunaan kumaha gawéna dina pilarian Yandex.Market.
Éta sadayana dimimitian ku nambihan parameter CGI énggal anu ngamungkinkeun fungsionalitas énggal. Hayu parameter urang jadi: market_new_functionality=1. Lajeng dina kode urang ngaktipkeun pungsi ieu lamun bandéra hadir:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}fungsionalitas anyar keur digulung kaluar pikeun produksi.
Pikeun ngajadikeun otomatis nguji A/B, aya layanan dedicated nu nyadiakeun inpo wincik . Hiji percobaan dijieun dina layanan. Pangsa lalulintas diatur, contona, 15%. Persentase diatur sanes kanggo patarosan, tapi pikeun pangguna. Durasi percobaan ogé dituduhkeun, contona, saminggu.
Sababaraha percobaan tiasa dijalankeun sakaligus. Dina setélan anjeun tiasa nangtukeun naha simpang sareng ékspérimén sanés tiasa.
Hasilna, jasa sacara otomatis nambihan argumen market_new_functionality=1 ka 15% pamaké. Éta ogé otomatis ngitung métrik anu dipilih. Saatos ékspérimén réngsé, analis ningali hasil sareng ngagambar kacindekan. Dumasar papanggihan, kaputusan dijieun pikeun roll kaluar ka produksi atawa perbaikan.
leungeun deft pasar urang: nguji dina produksi
Ieu sering kajadian nu peryogi pikeun nguji operasi fungsionalitas anyar dina produksi, tapi anjeun teu yakin kana kumaha eta bakal kalakuanana dina kaayaan "ngempur" dina beban beurat.
Aya solusi: umbul dina parameter CGI tiasa dianggo henteu ngan ukur pikeun nguji A / B, tapi ogé pikeun nguji fungsionalitas anyar.
Kami ngadamel alat anu ngamungkinkeun anjeun langsung ngarobih konfigurasi dina rébuan server tanpa ngalaan jasa kana résiko. Disebutna "Stop Tap". Gagasan aslina éta bisa gancang nganonaktipkeun sababaraha pungsi tanpa perenah a. Lajeng alat nu dimekarkeun tur jadi leuwih kompleks.
Diagram alur jasa dibere handap:
Nilai bandéra diatur via API. Ladenan manajemén nyimpen nilai-nilai ieu dina pangkalan data. Sadaya server angkat ka pangkalan data sakali unggal sapuluh detik, ngompa nilai bandéra sareng nerapkeun nilai ieu pikeun unggal pamundut.
Dina ketok Stop anjeun tiasa nyetél dua jinis niléy:
1) Babasan kondisional. Larapkeun nalika salah sahiji nilai leres. Salaku conto:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Nilai "3" bakal diterapkeun nalika pamundut diolah di lokasi DC1. Sareng nilaina "4" nalika pamundut diolah dina klaster kadua pikeun situs beru.ru.
2) Ajén saratna. Larapkeun sacara standar upami teu aya sarat anu kacumponan. Salaku conto:
nilai, nilai!
Lamun nilai hiji ditungtungan make titik exclamation, éta dibéré prioritas luhur.
Parser parameter CGI parses URL. Teras nerapkeun nilai-nilai ti Stop Tap.
Nilai sareng prioritas ieu diterapkeun:
- Kalayan ngaronjatna prioritas ti Stop Tap (tanda seru).
- Nilai tina pamundut.
- Nilai standar tina Stop ketok.
- Nilai standar dina kode.
Aya seueur umbul anu dituduhkeun dina nilai kondisional - aranjeunna cekap pikeun sadaya skénario anu dipikanyaho ku urang:
- Puseur data.
- Lingkungan: produksi, nguji, kalangkang.
- Tempatna: pasar, beru.
- Jumlah klaster.
Kalayan alat ieu, anjeun tiasa ngaktipkeun pungsi anyar dina grup server anu tangtu (contona, ngan ukur dina hiji pusat data) sareng nguji operasi fungsionalitas ieu tanpa aya résiko khusus pikeun sadayana jasa. Malah lamun nyieun kasalahan serius wae, sagalana mimiti ragrag jeung sakabéh puseur data turun, balancers bakal alihan requests ka puseur data lianna. Pamaké tungtung moal aya bewara nanaon.
Upami anjeun perhatikeun masalah, anjeun tiasa langsung ngabalikeun bandéra kana nilaina sateuacana sareng parobihan bakal digulung deui.
Ladenan ieu ogé ngagaduhan karugian: pamekar resep pisan sareng sering nyobian nyorong sadaya parobihan kana Stop Tap. Kami nyobian merangan nyalahgunakeun.
Pendekatan Stop Tap tiasa dianggo nalika anjeun parantos gaduh kode stabil siap digulung ka produksi. Dina waktos anu sami, anjeun masih gaduh mamang, sareng anjeun hoyong pariksa kodeu dina kaayaan "tempur".
Tapi, Stop Tap henteu cocog pikeun uji nalika pangwangunan. Aya klaster misah pikeun pamekar disebut "kluster kalangkang".
Tés rusiah: Kluster kalangkang
Paménta ti salah sahiji klaster diduplikasi ka klaster kalangkang. Tapi balancer nu lengkep malire réspon ti klaster ieu. Diagram operasi na dibere handap.
Kami kéngingkeun kluster tés anu aya dina kaayaan "tempur" nyata. Lalu lintas pamaké normal ka dinya. Hardware dina duanana klaster sarua, jadi kinerja sarta kasalahan bisa dibandingkeun.
Sarta saprak balancer sagemblengna malire réspon, pamaké tungtung moal ningali réspon ti klaster kalangkang. Ku alatan éta, teu pikasieuneun nyieun kasalahan.
papanggihan
Ku kituna, kumaha urang ngawangun pilarian Market?
Pikeun ngajantenkeun sadayana lancar, kami misahkeun fungsionalitas kana jasa anu misah. Ku cara ieu urang ngan ukur tiasa skala komponén anu urang peryogikeun sareng ngajantenkeun komponén langkung saderhana. Gampang napelkeun komponén anu misah ka tim anu sanés sareng ngabagi tanggung jawab pikeun ngerjakeunana. Jeung tabungan signifikan dina beusi jeung pendekatan ieu mangrupa tambah atra.
Kluster kalangkang ogé ngabantosan urang: urang tiasa ngembangkeun jasa, nguji aranjeunna dina prosés sareng henteu ngaganggu pangguna.
Nya, tés dina produksi, tangtosna. Kudu ngarobah konfigurasi dina rébuan server? Gampang, nganggo Stop Tap. Ku cara ieu anjeun tiasa langsung ngagulung solusi kompleks anu siap-siap sareng gulung deui ka versi anu stabil upami aya masalah.
Abdi ngarepkeun kuring tiasa nunjukkeun kumaha urang ngajantenkeun Pasar gancang sareng stabil kalayan dasar nawaran anu terus-terusan. Kumaha urang ngabéréskeun masalah server, nungkulan sajumlah ageung pamundut, ningkatkeun kalenturan jasa sareng ngalakukeun ieu tanpa ngaganggu prosés kerja.
sumber: www.habr.com