Seueur startups parantos ngalangkungan ieu: seueur pangguna énggal ngadaptar unggal dinten, sareng tim pamekaran berjuang pikeun ngajaga jasa éta.
Ieu mangrupikeun masalah anu saé, tapi aya sakedik inpormasi anu jelas dina wéb ngeunaan kumaha sacara saksama skala aplikasi wéb tina euweuh ka ratusan rébu pangguna. Biasana aya solusi seuneu atanapi solusi bottleneck (sareng sering duanana). Ku alatan éta, jalma ngagunakeun téhnik rada cliched mun skala proyék amatir maranéhanana kana hal bener serius.
Hayu urang cobian nyaring inpormasi sareng nyerat rumus dasarna. Urang bade skala situs babagi poto anyar kami Graminsta step by step ti 1 nepi ka 100 pamaké.
Hayu urang nyerat tindakan khusus anu kedah dilakukeun nalika panongton naék kana 10, 100, 1000, 10 sareng 000 urang.
1 pamaké: 1 mesin
Ampir unggal aplikasi, boh situs wéb atanapi aplikasi sélulér, ngagaduhan tilu komponén konci:
- API
- pangkalan data
- klien (aplikasi mobile sorangan atawa ramatloka)
Database nyimpen data pengkuh. API ngalayanan requests ka jeung sabudeureun data ieu. Klién ngirimkeun data ka pangguna.
Kuring sumping ka kacindekan yén éta loba gampang ngobrol ngeunaan skala hiji aplikasi lamun, ti sudut pandang arsitéktur, klien tur éntitas API sagemblengna dipisahkeun.
Nalika urang mimiti ngawangun aplikasi, sadaya tilu komponén tiasa dijalankeun dina server anu sami. Dina sababaraha cara, ieu sami sareng lingkungan pangembangan urang: hiji insinyur ngajalankeun pangkalan data, API, sareng klien dina mesin anu sami.
Dina tiori, urang tiasa nyebarkeun éta dina méga dina hiji conto DigitalOcean Droplet atanapi AWS EC2, sapertos anu dipidangkeun di handap ieu:
Kalayan ngomong yén, lamun bakal aya leuwih ti hiji pamaké dina loka, éta ampir sok ngajadikeun rasa bakti hiji lapisan database.
10 pamaké: mindahkeun database ka tingkat misah
Ngabagi pangkalan data kana jasa anu diurus sapertos Amazon RDS atanapi Digital Ocean Managed Database bakal ngalayanan kami pikeun waktos anu lami. Éta sakedik langkung mahal tibatan hosting diri dina mesin tunggal atanapi conto EC2, tapi kalayan jasa ieu anjeun nampi seueur ekstensi anu mangpaat tina kotak anu bakal mangpaat di hareup: cadangan multi-wilayah, baca réplika, otomatis. cadangan, sareng nu sanesna.
Ieu kumaha sistemna ayeuna:
100 pamaké: mindahkeun klien ka tingkat misah
Untungna, pangguna munggaran urang resep pisan kana aplikasi urang. Lalu lintas janten langkung stabil, janten waktosna pikeun mindahkeun klien ka tingkat anu kapisah. Ieu kudu dicatet yén pipisahan éntitas mangrupa aspék konci ngawangun aplikasi scalable. Salaku salah sahiji bagian tina sistem nampi langkung seueur lalu lintas, urang tiasa ngabagi éta pikeun ngontrol kumaha skala jasa dumasar kana pola lalu lintas khusus.
Ieu naha kuring resep mikir klien salaku misah ti API. Hal ieu ngajadikeun eta pisan gampang mikir ngeunaan ngembangkeun pikeun sababaraha platform: web, web mobile, ios, Android, aplikasi desktop, jasa pihak-katilu, jsb Éta kabéh ngan klien ngagunakeun API sarua.
Salaku conto, ayeuna pangguna urang sering naroskeun ngaleupaskeun aplikasi sélulér. Upami anjeun misahkeun éntitas klien sareng API, ieu janten langkung gampang.
Ieu mangrupikeun sistem sapertos kieu:
1000 pamaké: nambahkeun beban balancer
Barang keur néangan. Pamaké Graminsta beuki loba unggah poto. Jumlah pendaptaran ogé tumuwuh. Pangladén API tunggal kami sesah ngajaga sadaya lalu lintas. Peryogi langkung beusi!
Load balancer mangrupikeun konsép anu pohara kuat. Gagasan konci éta urang nempatkeun hiji balancer beban di hareup API, sarta eta distributes lalulintas keur instansi jasa individu. Ieu kumaha urang skala horisontal, hartina urang nambahkeun leuwih server jeung kode sarua, ngaronjatkeun jumlah requests urang bisa ngolah.
Urang bade nempatkeun balancers beban misah di hareup klien web na di hareup API. Ieu hartosna anjeun tiasa ngajalankeun sababaraha instansi anu ngajalankeun kode API sareng kode klien wéb. The load balancer bakal langsung requests ka server anu kirang dimuat.
Di dieu urang meunang kaunggulan penting séjén - redundancy. Nalika hiji conto gagal (panginten kabeuratan atanapi nabrak), urang tinggaleun ku batur anu teras-terasan ngaréspon kana pamundut anu datang. Upami ngan ukur aya hiji conto anu tiasa dianggo, maka upami gagal, sadaya sistem bakal ngadat.
The load balancer ogé nyadiakeun skala otomatis. Urang tiasa ngonpigurasikeunana pikeun ningkatkeun jumlah instansi sateuacan beban puncak, sareng ngirangan nalika sadaya pangguna saré.
Kalayan penyeimbang beban, tingkat API tiasa diskalakeun ampir salamina, kantun nambihan instansi énggal nalika jumlah pamundut naék.
Catetan. Ayeuna sistem kami sami pisan sareng perusahaan PaaS sapertos Heroku atanapi Elastic Beanstalk on AWS nawiskeun out of the box (nu janten sababna populer pisan). Heroku nempatkeun database dina host misah, ngatur hiji otomatis-skala beban balancer, sarta ngidinan Anjeun pikeun host web klien misah ti API. Ieu mangrupikeun alesan anu saé pikeun ngagunakeun Heroku pikeun proyék-proyék tahap awal atanapi ngamimitian - anjeun nampi sadaya jasa dasar tina kotak.
10 pamaké: CDN
Panginten urang kedah ngalakukeun ieu ti mimiti. Ngolah pamundut sareng nampi poto énggal parantos nyababkeun seueur teuing beban dina server kami.
Dina tahap ieu, anjeun kedah nganggo jasa awan pikeun nyimpen eusi statik - gambar, video sareng seueur deui (AWS S3 atanapi Digital Ocean Spaces). Sacara umum, API urang kedah nyingkahan nanganan hal sapertos ngalayanan gambar sareng unggah gambar ka server.
Kauntungan sejen tina cloud hosting nyaéta CDN (AWS nyauran ieu tambihan Cloudfront, tapi seueur panyadia panyimpen awan nawiskeun éta kaluar tina kotak). CDN otomatis nyimpen gambar urang dina sagala rupa puseur data di sakuliah dunya.
Sanaos pusat data utama urang tiasa aya di Ohio, upami aya anu nyuhunkeun gambar ti Jepang, panyadia awan bakal ngadamel salinan sareng nyimpenna di pusat data Jepangna. Jalma salajengna anu menta gambar ieu di Jepang bakal nampa eta leuwih gancang. Ieu penting nalika urang damel sareng file ageung, sapertos poto atanapi pidéo, anu peryogi waktos anu lami pikeun diunduh sareng dikirimkeun ka sakuliah pangeusina.
100 pamaké: skala lapisan data
CDN geus mantuan pisan: lalulintas keur tumuwuh di speed pinuh. The video blogger kawentar Mavid Mobrick ngan didaptarkeun ku kami sarta dipasang na "carita", sabab nyebutkeun. Hatur nuhun kana load balancer, CPU jeung pamakéan memori dina server API diteundeun low (sapuluh instansi API ngajalankeun), tapi urang dimimitian meunang loba timeouts on requests ... ti mana datangna telat ieu?
Digging saeutik kana metrics, urang tingali yén CPU dina server database 80-90% dimuat. Kami dina wates.
Skala lapisan data meureun bagian paling hese tina persamaan. server API ngalayanan requests stateless, jadi urang ngan nambahan deui instansi API. Irung mayoritas database teu bisa ngalakukeun ieu. Urang bakal ngobrol ngeunaan sistem manajemén database relational populér (PostgreSQL, MySQL, jsb).
Caching
Salah sahiji cara panggampangna pikeun ningkatkeun kinerja database urang nyaéta pikeun ngawanohkeun komponén anyar: lapisan cache. Metodeu caching anu paling umum nyaéta toko catetan nilai konci dina mémori, sapertos Redis atanapi Memcached. Seuseueurna awan gaduh vérsi anu diurus tina jasa ieu: Elasticache on AWS and Memorystore on Google Cloud.
A cache mangpaat lamun jasa nyieun loba sauran terus-terusan ka database pikeun meunangkeun inpo nu sarua. Intina, urang ngakses database ngan sakali, nyimpen informasi dina cache, sarta ulah noél deui.
Salaku conto, dina layanan Graminsta kami, unggal waktos aya anu angkat ka halaman profil béntang Mobrik, server API naroskeun databés pikeun inpormasi tina profilna. Ieu kajadian deui jeung deui. Kusabab inpormasi profil Mobrik henteu robih sareng unggal pamundut, éta saé pikeun cache.
Urang bakal cache hasil tina database di Redis ku konci user:id kalawan periode validitas 30 detik. Ayeuna, nalika aya anu angkat ka profil Mobrik, urang pariksa heula Redis, sareng upami datana aya, urang ngan saukur mindahkeun langsung ti Redis. Ayeuna requests ka profil nu pang populerna di loka praktis teu muka database urang.
Kauntungan sejen tina sabagéan ageung jasa cache nyaéta aranjeunna langkung gampang skala tibatan server database. Redis ngagaduhan mode Kluster Redis anu diwangun. Sarupa jeung hiji load balancer, eta ngidinan Anjeun pikeun ngadistribusikaeun cache Redis Anjeun sakuliah sababaraha mesin (di sakuliah rébuan server lamun diperlukeun).
Ampir sadaya aplikasi skala ageung nganggo cache; éta mangrupikeun bagian integral tina API gancang. Pamrosésan pamundut anu langkung gancang sareng kode anu langkung produktif sadayana penting, tapi tanpa cache ampir teu mungkin pikeun skala jasa ka jutaan pangguna.
Baca Réplika
Nalika jumlah pamundut ka pangkalan data parantos ningkat pisan, hiji deui anu tiasa urang laksanakeun nyaéta nambihan réplika baca dina sistem manajemen database. Kalayan jasa anu diurus anu dijelaskeun di luhur, ieu tiasa dilakukeun dina hiji klik. Réplika anu dibaca bakal tetep aya dina pangkalan data utama sareng sayogi pikeun pernyataan PILIH.
Ieu sistem kami ayeuna:
Laku lampah langkung
Nalika aplikasi terus skala, kami bakal terus misahkeun jasa pikeun skala aranjeunna sacara mandiri. Salaku conto, upami urang mimitian nganggo Websockets, maka masuk akal pikeun narik kode pangolahan Websockets kana jasa anu misah. Urang bisa nempatkeun eta dina instansi anyar balik balancer beban urang sorangan, nu bisa skala luhur jeung ka handap dumasar kana sambungan Websockets kabuka sarta paduli jumlah requests HTTP.
Urang ogé bakal terus ngalawan larangan dina tingkat database. Dina tahap ieu nya éta waktuna pikeun diajar partisi database sareng sharding. Duanana pendekatan merlukeun overhead tambahan, tapi ngidinan Anjeun pikeun skala database ampir salamina.
Kami ogé hoyong masang jasa ngawaskeun sareng analitik sapertos New Relic atanapi Datadog. Ieu bakal ngabantosan anjeun ngaidentipikasi patarosan anu lambat sareng ngartos dimana perbaikan diperyogikeun. Nalika urang skala, urang hoyong difokuskeun milarian bottlenecks sareng ngaleungitkeun aranjeunna-sering nganggo sababaraha ide tina bagian sateuacana.
sumber
Tulisan ieu diideuan ku salah sahiji . Abdi hoyong ngadamel tulisan langkung spésifik pikeun tahap awal proyék sareng ngabongkar éta tina hiji padagang. Pastikeun maca upami anjeun resep kana topik ieu.
Catetan handap
- Sanaos sami dina hal distribusi beban dina sababaraha instansi, palaksanaan dasar tina klaster Redis béda pisan sareng kasaimbangan beban.
sumber: www.habr.com