Habr ngarobah dunya. Kami parantos blogging langkung ti sataun. Sakitar genep bulan kapengker kami nampi tanggapan anu cukup logis ti warga Khabrovsk: "Dodo, anjeun nyarios dimana-mana yén anjeun gaduh sistem sorangan. Naon jenis sistem ieu? Sareng naha ranté pizzeria peryogi éta? ”
Kami calik sareng mikir sareng sadar yén anjeun leres. Kami nyobian ngajelaskeun sadayana nganggo ramo urang, tapi éta kaluar dina potongan torn sareng teu aya pedaran lengkep ngeunaan sistem di mana waé. Ku kituna dimimitian lalampahan panjang ngumpulkeun informasi, néangan pangarang jeung nulis runtuyan artikel ngeunaan Dodo IS. Hayu angkat!
Pangakuan: Hatur nuhun pikeun ngabagi tanggapan anjeun ka kami. Hatur nuhun ka anjeunna, kami tungtungna ngajelaskeun sistem, disusun technoradar a, sarta baris geura-giru gulung kaluar pedaran badag prosés urang. Tanpa anjeun, kami bakal calik sapertos kieu salami 5 taun deui.
Runtuyan artikel "Naon Dodo IS?" nyaritakeun ngeunaan:
- Monolith mimiti di Dodo IS (2011-2015). (Nuju prosés...)
- jalur Backoffice: basa misah jeung beus. (Anjeun aya didieu)
- Jalur sisi klien: adul leuwih dasar (2016-2017). (Nuju prosés...)
- Sajarah microservices nyata. (2018-2019). (Nuju prosés...)
- Réngsé sawing tina monolith sareng stabilisasi arsitéktur. (Nuju prosés...)
Upami anjeun resep diajar anu sanés, tulis dina koméntar.
Pamadegan ngeunaan pedaran kronologis ti pangarang
Kuring rutin ngayakeun rapat pikeun pagawé anyar dina topik "System Arsitéktur". Kami nyebatna "Intro to Dodo IS Arsitéktur" sareng éta mangrupikeun bagian tina prosés onboarding pikeun pamekar anyar. Ngawangkong dina hiji formulir atawa sejen ngeunaan arsitéktur urang, ngeunaan fitur na, kuring ngembangkeun hiji pendekatan sajarah nu tangtu kana pedaran.
Sacara tradisional, urang ningali sistem salaku sakumpulan komponén (tingkat teknis atanapi langkung luhur), modul bisnis anu saling berinteraksi pikeun ngahontal sababaraha tujuan. Sareng nalika pandangan sapertos kitu diyakinkeun pikeun desain, éta henteu cocog pikeun pedaran sareng pamahaman. Aya sababaraha alesan:
- Kanyataanana béda ti anu aya dina kertas. Teu sagalana jalan kaluar sakumaha rencanana. Sarta kami museurkeun kumaha sagalana sabenerna tétéla tur jalan.
- presentasi konsisten inpormasi. Nyatana, anjeun tiasa kronologis ti mimiti dugi ka kaayaan ayeuna.
- Ti basajan nepi ka kompléks. Henteu universal, tapi dina kasus urang kitu. Arsitéktur dipindahkeun tina pendekatan anu saderhana ka anu langkung kompleks. Mindeng, ngaliwatan komplikasi, masalah speed palaksanaan jeung stabilitas, kitu ogé puluhan sipat séjén tina daptar sarat non-fungsi ( ogé ngobrol ngeunaan kontras pajeulitna sareng sarat anu sanés).
Dina 2011, arsitéktur Dodo IS katingali sapertos kieu:
Ku 2020, éta janten sakedik langkung rumit sareng janten sapertos kieu:
Kumaha évolusi ieu lumangsung? Naha bagian béda tina sistem diperlukeun? Kaputusan arsitéktur naon anu dilakukeun sareng kunaon? Hayu urang manggihan dina runtuyan artikel ieu.
Masalah mimiti 2016: naha jasa kudu ninggalkeun monolith nu?
Artikel munggaran dina séri bakal ngeunaan jasa anu mimiti misahkeun tina monolith. Pikeun nempatkeun anjeun kana kontéks, kuring bakal nyarioskeun ka anjeun naon masalah anu aya dina sistem dina awal 2016, yén urang kedah nganyahokeun pamisahan jasa.
Basis data MySql tunggal dimana sadaya aplikasi anu aya dina waktos éta di Dodo IS nyerat rékamanna. Balukarna nyaéta:
- Beban beurat (kalayan 85% tina pamundut dibaca).
- Dasarna ngembang. Kusabab ieu, biaya sareng dukungan janten masalah.
- Hiji titik gagal. Upami hiji aplikasi nyerat kana pangkalan data ujug-ujug mimiti ngalakukeunana langkung aktip, teras aplikasi anu sanés karasa dampakna.
- Inefficiency dina neundeun jeung queries. Seringna data disimpen dina sababaraha struktur anu cocog pikeun sababaraha skenario tapi henteu pikeun anu sanés. Indexes nyepetkeun sababaraha operasi, tapi bisa ngalambatkeun turun batur.
- Sababaraha masalah anu direngsekeun ku hastily dijieun caches jeung maca-réplika kana database (ieu bakal dibahas dina artikel misah), tapi aranjeunna ngan diwenangkeun urang mangtaun waktu jeung teu fundamentally ngajawab masalah.
Masalahna éta ayana monolith sorangan. Balukarna nyaéta:
- Kaluaran unik sareng jarang.
- Kasusahna aya dina pangwangunan kolaboratif sajumlah ageung jalma.
- Henteu mampuh ngenalkeun téknologi anyar, kerangka anyar sareng perpustakaan.
Masalah sareng dasar sareng monolith parantos dijelaskeun sababaraha kali, contona, dina konteks kacilakaan di awal 2018 (, и ), jadi kuring moal cicing teuing. Hayu urang nyarios yén urang hoyong masihan langkung kalenturan nalika ngembangkeun jasa. Anu mimiti, ieu merhatikeun jalma anu paling dimuat sareng akar dina sakabéh sistem - Auth sareng Tracker.
The Back Office Path: Bases misah jeung Beus
Bab Napigasi
Skéma tina monolith 2016
Di handap ieu mangrupakeun blok utama 2016 Dodo IS monolith, sarta ngan handap mangrupa ngarecahna tugas utama maranéhanana.
Meja kas pangiriman. Akuntansi pikeun kurir, ngaluarkeun pesenan ka kurir.
Puseur kontak. Narima pesenan ngaliwatan operator.
loka. Situs wéb kami (dodopizza.ru, dodopizza.co.uk, dodopizza.by, jsb.).
Nulis. Otorisasi sareng jasa auténtikasi pikeun backoffice.
tracker. Pelacak pesenan dapur. Ladenan pikeun nyirian status kesiapan nalika nyiapkeun pesenan.
meja kas réstoran. Nyandak pesenan di réstoran, interfaces kasir.
ekspor. Ngunggah laporan dina 1C pikeun akuntansi.
Tanda jeung invoice. Paréntah sora di dapur (contona, "pizza anyar geus anjog") + percetakan invoices pikeun kurir.
Manajer Shift. Interfaces pikeun karya manajer shift: daptar pesenan, grafik produktivitas, bringing karyawan ka shifts.
Manajer Kantor. Interfaces pikeun karya franchisees sarta manajer: panarimaan karyawan, laporan ngeunaan karya pizzeria nu.
dewan réstoran. Mintonkeun ménu dina TV di pizzerias.
Admin. Setélan pikeun pizzeria husus: menu, harga, akuntansi, kode promosi, promosi, spanduk pikeun situs, jsb.
Akun Pribadi Pagawe. Jadwal kerja karyawan, inpormasi ngeunaan karyawan.
Dapur Motivasi Board. Layar anu misah anu ngagantung di dapur sareng ningalikeun laju tukang pizza.
komunikasi. Ngirim sms sareng email.
Panyimpen File. Ladenan sorangan pikeun nampi sareng ngaluarkeun file statik.
Usaha munggaran pikeun ngabéréskeun masalah ngabantosan kami, tapi éta ngan ukur samentawis. Aranjeunna henteu janten solusi sistem, janten écés yén aya anu kedah dilakukeun sareng dasarna. Contona, ngabagi database umum kana sababaraha leuwih husus.
Urang ngawitan ngabongkar momotanana monolith: separation of Auth na Tracker
Ladenan utama anu teras nyerat sareng maca tina pangkalan data langkung seueur tibatan anu sanés:
- Auth. Otorisasi sareng jasa auténtikasi pikeun backoffice.
- Tracker. Pelacak pesenan dapur. Ladenan pikeun nyirian status kesiapan nalika nyiapkeun pesenan.
Naon anu dilakukeun ku Auth?
Auth mangrupikeun jasa dimana pangguna asup ka kantor tukang (aya login mandiri anu misah di sisi klien). Éta ogé dirujuk dina pamundut pikeun mastikeun yén hak aksés anu leres aya sareng yén hak-hak ieu henteu robih ti saprak login terakhir. Alat ngasupkeun pizzerias ngaliwatan eta.
Salaku conto, urang hoyong muka tampilan kalayan status pesenan réngsé dina TV nongkrong di aula. Teras we muka auth.dodopizza.ru, pilih "Login salaku alat", muncul kode anu tiasa diasupkeun dina halaman khusus dina komputer manajer shift, nunjukkeun jinis alat (alat). TV sorangan bakal angkat ka antarbeungeut pizzeria anu dipikahoyong sareng ngawitan nampilkeun nami palanggan anu pesenan parantos siap.
Ti mana asalna beban?
Unggal log-in backoffice pamaké mana anu ka database pikeun tiap pamundut, kana tabel pamaké, narik kaluar pamaké ti dinya ngaliwatan query sql jeung mariksa naha anjeunna boga aksés diperlukeun tur hak kana kaca ieu.
Masing-masing alat ngalakukeun hal anu sami ngan ukur sareng tabel alat, mariksa peranna sareng aksésna. A angka nu gede ngarupakeun requests ka master database ngabalukarkeun loading sarta runtah sumberdaya database umum dina operasi ieu.
Unloading Auth
Auth ngagaduhan domain anu terasing, nyaéta, data ngeunaan pangguna, login atanapi alat asup kana jasa (ayeuna ka hareup) sareng tetep aya. Upami aya anu peryogi aranjeunna, anjeunna bakal angkat ka layanan ieu pikeun data.
NYAETA. Alur kerja mimitina sapertos kieu:
Abdi hoyong ngajelaskeun sakedik kumaha éta damel:
- Hiji pamundut éksternal datang ka backend nu (Asp.Net MVC aya), bringing kalawan cookie sési, nu dipaké pikeun ménta data sési ti Redis (1). Ieu boh ngandung émbaran ngeunaan aksés, lajeng aksés ka controller dibuka (3,4), atanapi henteu.
- Upami teu aya aksés, anjeun kedah ngalangkungan prosedur otorisasi. Di dieu, pikeun kesederhanaan, eta ditémbongkeun salaku bagian tina jalur dina atribut sarua, sanajan ieu téh transisi ka kaca login. Dina kasus skenario anu positif, urang bakal nampi sési anu dieusi leres sareng angkat ka Backoffice Controller.
- Upami aya data, maka anjeun kedah parios éta relevansi dina pangkalan data pangguna. Naha peranna parantos robih, naha anjeunna henteu diidinan dina halaman ayeuna? Dina hal ieu, saatos nampi sési (1), anjeun kedah langsung angkat ka pangkalan data sareng pariksa aksés pangguna nganggo lapisan logika auténtikasi (2). Teras, angkat ka halaman login atanapi angkat ka controller. Ieu sistem basajan, tapi teu sagemblengna baku.
- Upami sadaya prosedur parantos réngsé, teras urang skip salajengna dina logika dina pangendali sareng metode.
Data pangguna dipisahkeun tina sadaya data anu sanés, disimpen dina méja kaanggotaan anu misah, fungsi tina lapisan logika AuthService tiasa janten metode API. Watesan domain ditetepkeun sacara jelas: pangguna, kalungguhanana, data aksés, penerbitan sareng panyabutan aksés. Sagalana sigana bisa dipindahkeun ka layanan misah.
JADI. Éta naon anu aranjeunna lakukeun:
Pendekatan ieu ngagaduhan sababaraha masalah. Contona, nelepon metoda di jero prosés teu sarua jeung nelepon hiji layanan éksternal via http. Latency, reliabiliti, supportability, sarta transparansi operasi sagemblengna béda. Andrey Morevsky nyarios langkung rinci ngeunaan masalah ieu dina laporan na .
Ladenan auténtikasi sareng nganggo éta jasa alat dianggo pikeun kantor tukang, nyaéta, pikeun jasa sareng antarmuka anu dianggo dina produksi. Auténtikasi pikeun layanan klien (sapertos situs wéb atanapi aplikasi seluler) lumangsung nyalira tanpa nganggo Auth. Separation nyandak ngeunaan sataun, sarta ayeuna urang deui dipake dina topik ieu, mindahkeun sistem ka layanan auténtikasi anyar (kalawan protokol baku).
Naha pisahna lila pisan?
Aya seueur masalah sapanjang jalan anu ngalambatkeun kami:
- Kami hoyong nransper data ngeunaan pangguna, alat sareng auténtikasi tina pangkalan data nagara kana hiji. Jang ngalampahkeun ieu, urang kedah nransper sadaya tabel sareng pamakean tina identifier int ka identifier UUId global (urang nembe ngerjakeun kode ieu. sareng proyék open source ). Nyimpen data pangguna (sabab ieu inpormasi pribadi) aya watesanana sareng pikeun sababaraha nagara kedah disimpen nyalira. Tapi kedah aya ID pangguna global.
- Seueur tabel dina pangkalan data gaduh inpormasi Inok ngeunaan pangguna anu ngalaksanakeun operasi. Ieu diperlukeun hiji mékanisme tambahan pikeun mastikeun konsistensi.
- Saatos nyiptakeun jasa API, aya waktos anu panjang sareng bertahap pikeun mindahkeun kana sistem anu sanés. Saklar kedah lumangsung sacara lancar pikeun pangguna sareng peryogi padamelan manual.
Skéma pikeun ngadaptar alat dina pizzeria a:
Arsitéktur umum saatos misahkeun jasa Auth sareng Alat:
nyarios. Pikeun 2020, kami nuju ngerjakeun vérsi anyar Auth, anu didasarkeun kana standar otorisasi OAuth 2.0. Standar ieu rada rumit, tapi mangpaat pikeun ngembangkeun jasa auténtikasi tungtung-ka-tungtung. Dina artikel "» Kami Alexey Chernyaev nyoba ngobrol ngeunaan standar sakumaha basajan tur jelas-gancang ku kituna anjeun ngahemat waktos diajar.
Naon anu dilakukeun ku Tracker?
Ayeuna ngeunaan kadua tina jasa dimuat. Tracker ngalaksanakeun peran ganda:
- Di hiji sisi, tugasna nyaéta pikeun nunjukkeun ka karyawan di dapur naon pesenan anu ayeuna lumangsung, produk naon anu kedah disiapkeun ayeuna.
- Di sisi anu sanésna, digitalisasi sadaya prosés di dapur.
Lamun produk anyar (Contona, pizza) némbongan dina urutan, mana kana stasiun Tracker "Rolling". Di stasion ieu aya panyipta pizza anu nyandak roti ukuran anu diperyogikeun sareng ngagulungna, saatos éta anjeunna nandaan dina tablet tracker yén anjeunna parantos réngsé tugasna sareng ngalihkeun dasar adonan anu digulung ka stasiun salajengna - "Ngeusian" .
Di dinya, panyipta pizza salajengna ngaluhuran pizza, teras nandaan dina tablet yén anjeunna parantos réngsé tugasna sareng nempatkeun pizza dina oven (ieu ogé stasiun anu misah anu kedah ditandaan dina tablet). Sistem sapertos kitu aya ti mimiti di Dodo sareng ti mimiti Dodo IS. Éta ngamungkinkeun anjeun ngalacak sareng ngadigitalkeun sadaya operasi. Salaku tambahan, tracker nunjukkeun kumaha nyiapkeun produk khusus, ngalaksanakeun unggal jinis produk dumasar kana skéma manufaktur sorangan, nyimpen waktos masak anu optimal pikeun produk, sareng ngalacak sadaya operasi dina produk.
Ieu naon layar tablet kasampak kawas di stasiun tracker Raskatka.
Ti mana asalna beban?
Unggal pizzeria gaduh sakitar lima tablet kalayan tracker. Taun 2016 urang ngagaduhan langkung ti 100 pizzeria (sareng ayeuna langkung ti 600). Unggal tablet ngadamel pamundut ka backend unggal 10 detik sareng ngumpulkeun data tina tabel pesenan (link sareng klien sareng alamat), komposisi pesenan (link sareng produk sareng indikasi kuantitas), sareng tabel motivasi (éta ngalacak. waktos pencét). Lamun maker pizza klik dina produk on Tracker nu, rékaman dina sakabéh tabel ieu diropéa. Méja pesenan umumna; éta sakaligus ngandung sisipan nalika nampi pesenan, apdet tina bagian-bagian sanés sistem, sareng seueur bacaan, contona, dina TV anu ngagantung dina pizzeria sareng nunjukkeun pesenan anu siap-siap ka konsumén.
Salila période perjuangan kalayan beban, nalika sagalana jeung dulur ieu sindangan sarta dibikeun ka replica Asynchronous tina database, operasi ieu kalawan tracker terus buka database master. Henteu kedah aya lag di dieu, data kedah mutakhir, teu sinkron teu tiasa ditampi.
Ogé, kurangna tabel urang sorangan sarta indéks dina éta teu ngidinan urang nulis queries leuwih husus tailored pikeun pamakéan urang. Contona, eta bisa jadi éféktif pikeun tracker a boga indéks pikeun pizzeria dina tabel pesenan na. Simkuring salawasna kerok pesenan pizzeria ti database tracker. Dina waktos anu sami, pikeun nampi pesenan, henteu penting pisan kana pizzeria mana, anu langkung penting nyaéta klien anu ngadamel pesenan ieu. Ieu ngandung harti kudu aya hiji indéks dina klien nu. Éta ogé teu dipikabutuh pikeun Tracker pikeun nyimpen id tina resi dicitak atawa promosi bonus pakait jeung urutan dina tabel urutan. Ladenan tracker kami henteu resep kana inpormasi ieu. Dina database monolithic umum, tabel ngan bisa jadi kompromi antara sakabéh pamaké. Ieu salah sahiji masalah aslina.
NYAETA. Awalna arsitéktur sapertos kieu:
Malah sanggeus dipisahkeun kana prosés misah, lolobana dasar kode tetep umum pikeun layanan béda. Sagalana di handap controller ieu ngahiji jeung cicing dina hiji gudang. Métode umum jasa, repositori, sareng pangkalan data umum anu ngandung tabel umum dianggo.
Ngabongkar momotanana Tracker
Masalah utama sareng tracker nyaéta yén data kedah disingkronkeun antara database anu béda. Ieu ogé bédana utami tina divisi jasa Auth; urutan sareng statusna tiasa robih sareng kedah ditampilkeun dina sababaraha jasa.
Kami nampi pesenan di Restoran Checkout (ieu mangrupikeun jasa), disimpen dina pangkalan data dina status "Ditampa". Saatos éta, éta kedah angkat ka tracker, dimana éta bakal ngarobih statusna sababaraha kali deui: tina "Dapur" ka "Dipak". Dina hal ieu, sababaraha pangaruh éksternal ti Kasir atawa panganteur Shift Manajer bisa lumangsung kalawan pesenan. Kuring bakal masihan status pesenan sareng pedaranana dina tabél:
Skéma parobahan status pesenan sapertos kieu:
Statuses robah antara sistem béda. Sareng di dieu tracker sanes sistem ahir dimana datana dikonci. Kami parantos ningali sababaraha pendekatan anu mungkin pikeun pamisahan dina kasus sapertos kieu:
- Urang konsentrasi sagala lampah urutan dina hiji layanan. Dina kasus urang, pilihan ieu merlukeun teuing jasa pikeun ngolah pesenan. Lamun urang geus dieureunkeun aya, urang bakal geus réngsé nepi ka monolith kadua. Kami moal bakal ngarengsekeun masalah.
- Hiji sistem nelepon ka nu sejen. Pilihan kadua leuwih metot. Tapi kalayan éta, ranté telepon tiasa (), konektipitas komponénna langkung luhur, sareng langkung hese pikeun ngatur.
- Urang ngatur acara, sarta unggal bursa jasa jeung lianna ngaliwatan acara ieu. Hasilna, pilihan katilu dipilih, numutkeun nu sagala jasa ngawitan tukeur acara saling.
Kanyataan yén urang milih pilihan katilu dimaksudkan yén tracker bakal boga database sorangan, sarta unggal robah dina urutan bakal ngirim hiji acara ngeunaan ieu, nu jasa lianna bakal ngalanggan jeung nu ogé bakal kaasup kana database master. Jang ngalampahkeun ieu, urang diperlukeun sababaraha layanan nu bakal mastikeun pangiriman pesen antara jasa.
Dina waktos éta, urang parantos ngagaduhan RabbitMQ dina tumpukan, ku kituna kaputusan ahir pikeun ngagunakeunana salaku calo pesen. Diagram nunjukkeun transisi pesenan ti Kasir Rumah Makan ngalangkungan Tracker, dimana éta ngarobih statusna sareng tampilan na dina antarmuka Pesenan Manajer. JADI:
Mesen jalur step by step
Jalur pesenan dimimitian dina salah sahiji jasa sumber pesenan. Ieu mangrupikeun Kasir Réstoran:
- Urutan tos rengse siap di Checkout, sarta éta waktu pikeun ngirim ka tracker nu. Acara anu ngalanggan tracker dialungkeun.
- Tracker, narima pesenan, nyimpen eta dina database sorangan, nyieun acara "Pesanan Ditampa ku Tracker" jeung ngirim ka RMQ.
- Sababaraha pawang anu parantos ngalanggan beus acara adat. Pikeun urang, anu nyingkronkeun sareng database monolithic penting.
- Pawang nampi acara, milih data anu penting pikeun éta: dina kasus urang, ieu mangrupikeun status pesenan "Ditampi ku Tracker" sareng ngapdet éntitas pesenan na dina pangkalan data utama.
Upami aya anu peryogi pesenan khusus tina méja pesenan monolithic, teras aranjeunna tiasa maca ti dinya ogé. Salaku conto, ieu mangrupikeun antarmuka Orders dina Shift Manager peryogi:
Sadaya jasa anu sanés ogé tiasa ngalanggan pesenan acara ti tracker supados tiasa dianggo pikeun nyalira.
Upami saatos sababaraha waktos pesenan dicandak kana produksi, statusna mimiti robih dina database na (database Tracker), teras acara "OrderInWork" langsung dibangkitkeun. Éta ogé asup kana RMQ, ti mana éta disingkronkeun dina database monolithic sareng dikirimkeun ka jasa anu sanés. Bisa jadi aya rupa-rupa masalah sapanjang jalur ieu; leuwih rinci ngeunaan éta bisa kapanggih dina laporan Zhenya Peshkov .
Arsitéktur final sanggeus parobahan dina Auth na Tracker
Pikeun nyimpulkeun: Mimitina, kuring boga ide pikeun ngarangkep sajarah salapan taun sistem Dodo IS kana hiji artikel. Kuring hayang gancang jeung saukur ngobrol ngeunaan tahapan évolusi. Nanging, saatos calik pikeun diajar bahan, kuring sadar yén sadayana langkung rumit sareng pikaresepeun tibatan sigana.
Reflecting on kauntungan (atawa kakuranganana) bahan misalna, abdi sumping ka kacindekan yen ngembangkeun kontinyu teu mungkin tanpa babad pinuh-fledged kajadian, retrospectives lengkep jeung analisis kaputusan kaliwat hiji.
Abdi ngarepkeun anjeun mendakan éta mangpaat sareng pikaresepeun pikeun diajar ngeunaan perjalanan urang. Ayeuna kuring Nyanghareupan pilihan mana bagian tina sistem Dodo IS ngajelaskeun dina artikel salajengna: nulis dina komentar atawa sora.
Ngan pamaké nu kadaptar bisa ilubiung dina survey. , Punten.
Bagian naon tina Dodo IS anu anjeun hoyong diajar dina tulisan salajengna?
-
24,1%Monolith mimiti di Dodo IS (2011-2015)14
-
24,1%Masalah kahiji jeung solusina (2015-2016)14
-
20,7%Jalur bagian klien: adul luhureun dasar (2016-2017)12
-
36,2%Sajarah microservices nyata (2018-2019)21
-
44,8%Réngsé motong tina monolith jeung stabilisasi arsitektur26
-
29,3%Ngeunaan rencana salajengna pikeun ngembangkeun sistem17
-
19,0%Kuring teu hayang nyaho nanaon tentang Dodo IS11
58 pamaké milih. 6 pamaké abstained.
sumber: www.habr.com