Anjeun parantos nyéépkeun sababaraha bulan ngadesain ulang monolit anjeun kana jasa mikro, sareng tungtungna sadayana parantos ngahiji pikeun ngagentos saklar. Anjeun buka kaca web munggaran ... jeung euweuh kajadian. Anjeun ngamuat deui - sareng deui teu aya anu saé, situsna laun pisan sareng henteu ngabales sababaraha menit. Aya naon?
Dina ceramahna, Jimmy Bogard bakal ngalaksanakeun "post-mortem" dina musibah microservice real-life. Anjeunna bakal nunjukkeun masalah pemodelan, pamekaran, sareng produksi anu anjeunna mendakan, sareng kumaha timna lalaunan ngarobih monolit anu disebarkeun anyar kana gambar ahir sanity. Sanaos teu mungkin pikeun nyegah kasalahan desain, anjeun sahenteuna tiasa ngaidentipikasi masalah dina awal prosés desain pikeun mastikeun produk ahir janten sistem distribusi anu dipercaya.
Halo sadayana, Abdi Jimmy sareng dinten ayeuna anjeun badé nguping kumaha anjeun tiasa nyingkahan bencana mega nalika ngawangun jasa mikro. Ieu carita hiji parusahaan kuring digawé pikeun ngeunaan hiji satengah taun pikeun mantuan nyegah kapal maranéhanana tabrakan jeung gunung es. Pikeun nyarioskeun carita ieu kalayan leres, urang kedah uih deui dina waktosna sareng ngobrol ngeunaan dimana perusahaan ieu ngamimitian sareng kumaha infrastruktur IT na parantos ningkat kana waktosna. Pikeun nangtayungan ngaran jalma polos dina musibah ieu, Kuring geus ngaganti ngaran pausahaan ieu Bell Komputer. Slide salajengna nunjukkeun kumaha infrastruktur IT perusahaan sapertos kitu dina pertengahan 90an. Ieu mangrupikeun arsitéktur khas tina server HP Tandem Mainframe anu toleran universal pikeun operasi toko hardware komputer.
Aranjeunna kedah ngawangun sistem pikeun ngatur sadaya pesenan, penjualan, pamulangan, katalog produk, sareng basa palanggan, janten aranjeunna milih solusi mainframe anu paling umum dina waktos éta. Sistim gigantic ieu ngandung unggal bit informasi ngeunaan parusahaan, sagalana mungkin, sarta unggal transaksi dilaksanakeun ngaliwatan mainframe ieu. Aranjeunna nyimpen sadayana endogna dina hiji karanjang sareng panginten éta normal. Hiji-hijina hal anu henteu kalebet di dieu nyaéta katalog pesenan surat sareng nempatkeun pesenan ku telepon.
Kana waktosna, sistem janten langkung ageung sareng langkung ageung, sareng sajumlah ageung sampah akumulasi di jerona. Ogé, COBOL sanes basa anu paling ekspresif di dunya, ku kituna sistem éta janten sapotong sampah monolitik anu ageung. Taun 2000, aranjeunna ningali yén seueur perusahaan ngagaduhan situs wéb dimana aranjeunna ngalaksanakeun sadayana bisnisna, sareng mutuskeun pikeun ngawangun situs wéb dot-com komérsial munggaran.
Desain awal katingali saé saé sareng diwangun ku situs tingkat luhur bell.com sareng sajumlah subdomain pikeun aplikasi individu: catalog.bell.com, accounts.bell.com, orders.bell.com, search.bell produk. com. Unggal subdomain dipaké kerangka ASP.Net 1.0 jeung database sorangan, sarta aranjeunna sadayana dikaitkeun kana backend sistem. Sanajan kitu, sagala pesenan terus diolah jeung dieksekusi dina mainframe badag tunggal, nu sagala sampah tetep, tapi tungtung hareup éta ramatloka misah kalawan aplikasi individu jeung database misah.
Janten desain sistem katingalina teratur sareng logis, tapi sistem saleresna sapertos anu dipidangkeun dina slide salajengna.
Sadaya elemen ngahubungkeun telepon ka unggal anu sanés, API anu diaksés, dll pihak katilu anu dipasang, sareng anu sanésna. Sering kajadian yén sistem kontrol versi bakal nyandak kodeu batur, nyorong éta ka jero proyék, teras sadayana bakal rusak. MS SQL Server 2005 dipaké konsép link server, sarta sanajan kuring teu némbongkeun panah dina slide, unggal database ogé dikaitkeun ka silih, sabab aya nu lepat ngawangun tabel dumasar kana data dicandak ti sababaraha database .
Kusabab aranjeunna kiwari miboga sababaraha separation antara wewengkon logis béda tina sistem, ieu jadi blobs disebarkeun kokotor, jeung sapotong pangbadagna sampah masih sésana dina backend mainframe.
Hal lucu éta mainframe ieu diwangun ku pesaing Bell Komputer sarta masih dijaga ku konsultan teknis maranéhna. Yakin kana kinerja anu henteu nyugemakeun tina aplikasina, perusahaan mutuskeun pikeun ngaleungitkeunana sareng ngadesain ulang sistem.
Aplikasi anu tos aya parantos di produksi salami 15 taun, anu mangrupikeun catetan pikeun aplikasi berbasis ASP.Net. Palayanan nampi pesenan ti sakumna dunya, sareng pendapatan taunan tina aplikasi tunggal ieu ngahontal samilyar dolar. Bagian signifikan tina kauntungan dihasilkeun ku ramatloka bell.com. Dina Jumaah Hideung, jumlah pesenan ditempatkeun ngaliwatan loka ngahontal sababaraha juta. Sanajan kitu, arsitéktur aya teu ngidinan ngembangkeun nanaon, sabab interkonéksi kaku tina elemen sistem praktis teu ngidinan parobahan nanaon nu bisa dilakukeun dina layanan.
Masalah anu paling serius nyaéta henteu mampuh nempatkeun pesenan ti hiji nagara, mayar di tempat anu sanés sareng ngirim ka katilu, sanaos kanyataan yén skéma dagang sapertos kitu umum pisan di perusahaan global. Situs wéb anu tos aya henteu ngijinkeun nanaon sapertos kieu, janten aranjeunna kedah nampi sareng nempatkeun pesenan ieu dina telepon. Ieu nyababkeun perusahaan beuki mikir ngeunaan ngarobih arsitéktur, khususna ngeunaan ngalih ka microservices.
Aranjeunna ngalakukeun hal anu pinter ku ningali perusahaan-perusahaan sanés pikeun ningali kumaha aranjeunna ngarengsekeun masalah anu sami. Salah sahiji solusi ieu nyaéta arsitéktur jasa Netflix, anu diwangun ku microservices disambungkeun via API jeung database éksternal.
Manajemén Bell Computers mutuskeun pikeun ngawangun arsitéktur sapertos kitu, nganut prinsip dasar anu tangtu. Kahiji, aranjeunna ngaleungitkeun duplikasi data ku ngagunakeun pendekatan database dibagikeun. Henteu aya data anu dikirim; sabalikna, saha waé anu peryogi éta kedah angkat ka sumber terpusat. Ieu dituturkeun ku isolasi jeung otonomi - unggal jasa éta bebas tina batur. Aranjeunna mutuskeun pikeun ngagunakeun Web API pikeun pancen sagalana - lamun hayang meunang data atawa jieun perobahan kana sistem sejen, eta sadayana dipigawé ngaliwatan Web API. Hal badag panungtungan éta mainframe anyar disebut "Bell on Bell" sabalikna mainframe "Bell" anu dumasar kana hardware pesaing '.
Janten, salami 18 bulan, aranjeunna ngawangun sistem sakitar prinsip-prinsip inti ieu sareng dibawa ka pra-produksi. Balik deui ka damel saatos sabtu minggu, pamekar ngumpul sareng ngaktipkeun sadaya server anu nyambungkeun sistem énggal. 18 bulan damel, ratusan pamekar, hardware Bell paling modéren - sareng henteu aya hasil anu positif! Ieu kuciwa seueur jalma sabab parantos ngajalankeun sistem ieu dina laptopna sababaraha kali sareng sadayana saé.
Aranjeunna pinter ngalungkeun sadayana artos pikeun ngarengsekeun masalah ieu. Aranjeunna dipasang rak server paling modern jeung saklar, dipaké serat optik gigabit, hardware server pangkuatna kalawan jumlah gélo RAM, disambungkeun kabeh, ngonpigurasi - jeung deui, nanaon! Teras aranjeunna mimiti curiga yén alesanana tiasa waktosna, janten aranjeunna asup kana sadaya setélan wéb, sadaya setélan API sareng ngapdet sadaya konfigurasi waktos waktos ka nilai maksimal, ku kituna sadayana anu tiasa dilakukeun nyaéta calik sareng ngantosan hiji kajadian. ka loka. Aranjeunna ngadagoan sareng ngantosan sareng ngantosan 9 satengah menit dugi ka halaman wéb parantos dimuat.
Saatos éta, aranjeunna terang yén kaayaan ayeuna peryogi analisa anu lengkep, sareng aranjeunna ngajak kami. Hal kahiji anu urang terangkeun nyaéta yén salami 18 bulan pangwangunan, teu aya hiji "mikro" nyata anu diciptakeun - sadayana langkung ageung. Saatos ieu, urang mimiti nulis post-mortem, ogé katelah "regretrospective", atawa "retrospective sedih", ogé katelah "badai nyalahkeun", sarupa jeung "badai otak", ngartos ngabalukarkeun musibah.
Urang tadi sababaraha clues, salah sahiji nu lengkep jenuh lalulintas dina waktu panggero API. Lamun anjeun ngagunakeun arsitéktur jasa monolithic, anjeun bisa langsung ngarti naon kahayang nu salah sabab boga renik tumpukan tunggal nu ngalaporkeun sagalana nu bisa ngabalukarkeun gagalna. Dina kasus dimana sakumpulan jasa sakaligus ngaksés API anu sami, teu aya deui jalan pikeun ngalacak jejak iwal ngagunakeun alat ngawaskeun jaringan tambahan sapertos WireShark, hatur nuhun anjeun tiasa mariksa hiji pamundut sareng milari naon anu kajantenan nalika palaksanaanna. Janten urang nyandak hiji halaman wéb sareng nyéépkeun ampir 2 minggu pikeun ngahijikeun potongan teka-teki éta, ngadamel sababaraha telepon ka dinya sareng nganalisa naon anu ditujukeun masing-masing.
Tingali gambar ieu. Ieu nunjukeun yen hiji pamundut éksternal nyarankeun jasa sangkan loba telepon internal nu balik deui. Tétéla yén unggal panggero internal ngajadikeun hops tambahan pikeun bisa bebas ngalayanan pamundut ieu, sabab teu bisa ngahurungkeun mana sejenna pikeun ménta inpo nu diperlukeun. gambar ieu Sigana mah a cascade euweuh hartina nelepon, sakumaha pamundut éksternal nelepon jasa tambahan, nu nelepon jasa tambahan lianna, jeung saterusna, ampir ad infinitum.
Warna héjo dina diagram ieu nembongkeun satengah buleudan nu jasa nelepon silih - jasa A nelepon jasa B, jasa B nelepon jasa C, sarta eta nelepon jasa A deui. Hasilna, urang meunang "disebaran deadlock". Paménta tunggal nyiptakeun sarébu sauran API jaringan, sareng kusabab sistem éta henteu ngagaduhan kasabaran sesar sareng panyalindungan loop, pamundut éta bakal gagal upami salah sahiji telepon API ieu gagal.
Urang ngalakukeun sababaraha math. Unggal sauran API ngagaduhan SLA henteu langkung ti 150 mdet sareng 99,9% uptime. Hiji pamundut ngabalukarkeun 200 telepon béda, sarta dina kasus pangalusna, kaca bisa ditémbongkeun dina 200 x 150 mdet = 30 detik. Alami, ieu teu alus. Ngalikeun 99,9% uptime ku 200, urang ngagaduhan 0% kasadiaan. Tétéla yén arsitéktur ieu ditakdirkeun gagal ti mimiti.
Urang naroskeun ka pamekar kumaha aranjeunna gagal ngakuan masalah ieu saatos 18 bulan damel? Tétéla yén maranéhna ukur diitung SLA pikeun kode aranjeunna ngajalankeun, tapi lamun jasa maranéhanana disebut layanan sejen, aranjeunna henteu cacah waktu éta di SLA maranéhna. Sadayana anu diluncurkeun dina hiji prosés patuh kana nilai 150 mdet, tapi aksés ka prosés jasa anu sanés ningkatkeun total reureuh sababaraha kali. Pangajaran anu munggaran diajar nyaéta: "Naha anjeun ngadalikeun SLA anjeun, atanapi SLA ngawasa anjeun?" Dina kasus urang, ieu dimungkinkeun.
Hal salajengna urang manggihan éta yén maranéhna terang ngeunaan konsép misconceptions komputasi disebarkeun, ngarumuskeun ku Peter Deitch sarta James Gosling, tapi maranéhna teu dipalire bagian mimiti eta. Éta nyatakeun yén pernyataan "jaringan tiasa dipercaya," "enol latency," sareng "throughput tanpa wates" mangrupikeun salah paham. Kasalahan anu sanés kalebet pernyataan "jaringan aman," "topologi henteu kantos robih," "salawasna ngan ukur hiji administrator," "biaya transfer data nol," sareng "jaringan homogen."
Aranjeunna nyieun kasalahan sabab nguji jasa maranéhanana dina mesin lokal sarta pernah hooked up kalawan jasa éksternal. Nalika ngembangkeun lokal sareng nganggo cache lokal, aranjeunna henteu kantos mendakan jaringan hops. Dina sadaya 18 bulan pangwangunan, aranjeunna henteu kantos kantos heran naon anu bakal kajantenan upami jasa éksternal kapangaruhan.
Upami anjeun ningali wates jasa dina gambar sateuacana, anjeun tiasa ningali yén aranjeunna sadayana lepat. Aya seueur sumber anu mamatahan ngeunaan cara nangtukeun wates jasa, sareng kalolobaanana ngalakukeunana salah, sapertos Microsoft dina slide salajengna.
Gambar ieu ti blog MS dina topik "Kumaha carana ngawangun microservices". Ieu nunjukkeun aplikasi wéb anu sederhana, blok logika bisnis, sareng pangkalan data. Paménta asalna langsung, meureun aya hiji server pikeun web, hiji server pikeun bisnis jeung hiji keur database. Lamun ningkatkeun lalulintas, gambar bakal robah saeutik.
Di dieu asalna hiji load balancer pikeun ngadistribusikaeun lalulintas antara dua web server, a cache lokasina antara layanan wéb jeung logika bisnis, sarta cache sejen antara logika bisnis jeung database. Ieu persis arsitektur Bell dipaké pikeun beban balancing sarta aplikasi deployment biru / héjo dina pertengahan 2000s. Dugi sababaraha waktos sadayana damel saé, sabab skéma ieu dimaksudkeun pikeun struktur monolithic.
Gambar di handap ieu nunjukkeun kumaha MS nyarankeun pindah tina monolith ka microservices - ngan saukur ngabagi unggal jasa utama kana microservices anu misah. Ieu salila palaksanaan skéma ieu Bell nyieun kasalahan.
Aranjeunna dibagi sagala jasa maranéhanana kana tiers béda, nu masing-masing diwangun ku loba jasa individu. Salaku conto, jasa wéb kalebet microservices pikeun rendering sareng auténtikasi kontén, jasa logika bisnis diwangun ku microservices pikeun ngolah pesenan sareng inpormasi akun, pangkalan data dibagi kana sakumpulan microservices sareng data khusus. Duanana wéb, logika bisnis, sareng pangkalan data mangrupikeun jasa anu teu aya kaayaan.
Sanajan kitu, gambar ieu sagemblengna salah sabab teu peta sagala unit bisnis di luar klaster IT parusahaan. Skéma ieu teu tumut kana akun sagala sambungan jeung dunya luar, jadi teu jelas kumaha, contona, pikeun ménta analytics bisnis pihak-katilu. Kuring perhatikeun yén aranjeunna ogé ngagaduhan sababaraha jasa anu diciptakeun ngan ukur pikeun ngembangkeun karir karyawan individu anu narékahan pikeun ngatur saloba-lobana jalma pikeun kéngingkeun artos langkung seueur.
Aranjeunna yakin yén pindah ka microservices sagampil nyandak infrastruktur lapisan fisik N-tier internal maranéhanana sarta nempel Docker di dinya. Hayu urang tingali kumaha arsitéktur N-tier tradisional.
Éta diwangun ku 4 tingkat: tingkat antarmuka pangguna UI, tingkat logika bisnis, tingkat aksés data sareng pangkalan data. Anu langkung progresif nyaéta DDD (Domain-Driven Design), atanapi arsitéktur berorientasi parangkat lunak, dimana dua tingkat tengah nyaéta objék domain sareng gudang.
Kuring diusahakeun kasampak di wewengkon béda parobahan, wewengkon béda tanggung jawab dina arsitektur ieu. Dina aplikasi N-tier has, wewengkon béda parobahan digolongkeun nu permeate struktur vertikal ti luhur ka handap. Ieu mangrupikeun Katalog, Setélan Konfigurasi anu dilakukeun dina komputer individu, sareng pamariksaan Checkout, anu diurus ku tim kuring.
The peculiarity of skéma ieu yén wates wewengkon ieu parobahan mangaruhan teu ukur tingkat logika bisnis, tapi ogé ngalegaan ka database.
Hayu urang tingali naon hartosna janten jasa. Aya 6 sipat karakteristik definisi jasa - nyaéta parangkat lunak anu:
- dijieun jeung dipaké ku organisasi husus;
- tanggung jawab eusi, pamrosésan sareng / atanapi panyadiaan jinis inpormasi anu tangtu dina sistem;
- bisa diwangun, deployed tur ngajalankeun mandiri pikeun minuhan kabutuhan operasional husus;
- komunikasi sareng konsumén sareng jasa anu sanés, nyayogikeun inpormasi dumasar kana perjanjian atanapi jaminan kontrak;
- ngajaga diri tina aksés anu henteu sah, sareng inpormasina tina karugian;
- handles gagal dina cara nu teu ngakibatkeun karuksakan informasi.
Sadaya sipat ieu tiasa dikedalkeun dina hiji kecap "otonomi". Ladenan beroperasi sacara mandiri, nyugemakeun larangan anu tangtu, sareng netepkeun kontrak dumasar kana jalma anu tiasa nampi inpormasi anu diperyogikeun. Kuring henteu nyarios téknologi khusus, anu dianggo ku nyalira.
Ayeuna hayu urang tingali definisi microservices:
- microservice ukuranana leutik tur dirancang pikeun ngajawab hiji masalah husus;
- microservice nyaeta otonom;
- Nalika nyiptakeun arsitéktur microservice, métafora tata kota dianggo. Ieu mangrupikeun definisi tina buku Sam Newman, Building Microservices.
Definisi Bounded Context dicokot tina buku Eric Evans' Domain-Driven Design. Ieu mangrupikeun pola inti dina DDD, pusat desain arsitéktur anu dianggo sareng modél arsitéktur volumetrik, ngabagi kana Kontéks Bounded anu béda sareng sacara eksplisit nangtukeun interaksi antara aranjeunna.
Kantun nempatkeun, a Konteks wates ngalambangkeun wengkuan nu modul husus bisa dipaké. Dina kontéks ieu mangrupikeun modél ngahiji sacara logis anu tiasa ditingali, contona, dina domain bisnis anjeun. Lamun nanya "saha klien" ka tanaga aub dina pesenan, anjeun bakal meunang hiji harti, lamun nanya ka jalma aub dina jualan, anjeun bakal meunang sejen, sarta performers bakal masihan anjeun harti katilu.
Janten, Bounded Context nyarios yén upami urang teu tiasa masihan definisi anu jelas ngeunaan naon konsumen jasa urang, hayu urang ngartikeun wates-wates anu urang tiasa nyarioskeun ngeunaan harti istilah ieu, teras ngartikeun titik transisi antara definisi anu béda-béda ieu. Nyaéta, upami urang ngobrol ngeunaan klien tina sudut pandang nempatkeun pesenan, ieu hartosna ieu sareng éta, sareng upami tina sudut pandang penjualan, ieu hartosna ieu sareng éta.
Definisi salajengna ngeunaan microservice nyaéta enkapsulasi tina sagala jinis operasi internal, nyegah "bocor" komponén prosés kerja kana lingkungan. Salajengna asalna "definisi kontrak eksplisit pikeun interaksi éksternal, atawa komunikasi éksternal," nu digambarkeun ku gagasan kontrak balik ti SLAs. Definisi anu terakhir nyaéta métafora sél, atanapi sél, anu hartosna enkapsulasi lengkep sakumpulan operasi dina microservice sareng ayana reséptor pikeun komunikasi sareng dunya luar.
Ku kituna kami ngomong ka guys di Bell Computers, "Kami teu bisa ngalereskeun salah sahiji rusuh anjeun geus dijieun sabab ngan teu boga duit pikeun ngalakukeun hal eta, tapi urang bakal ngalereskeun ngan hiji layanan sangkan eta kabeh nyieun. rasa.” Dina titik ieu, kuring bakal ngamimitian ku nyarioskeun ka anjeun kumaha urang ngalereskeun hiji-hijina jasa kami supados ngaréspon kana pamundut langkung gancang ti 9 satengah menit.
22:30 mnt
Diteruskeun geura...
Iklan saeutik
Hatur nuhun pikeun tetep sareng kami. Naha anjeun resep artikel kami? Hoyong ningali eusi anu langkung narik? Dukung kami ku cara nempatkeun pesenan atanapi nyarankeun ka babaturan, , analog unik tina server tingkat éntri, anu diciptakeun ku kami pikeun anjeun: (sadia kalawan RAID1 na RAID10, nepi ka 24 cores sarta nepi ka 40GB DDR4).
Dell R730xd 2 kali langkung mirah dina puseur data Equinix nagara golongan IV di Amsterdam? Ngan di dieu di Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ti $99! Baca ngeunaan
sumber: www.habr.com