Sampeyan wis ngentekake pirang-pirang wulan ngrancang ulang monolith dadi layanan mikro, lan pungkasane kabeh wong wis teka bebarengan kanggo ngalih. Sampeyan pindhah menyang kaca web pisanan ... lan ora ana sing kedadeyan. Sampeyan ngisi maneh - lan maneh ora ana sing apik, situs kasebut alon banget nganti ora nanggapi sawetara menit. Ana apa?
Ing pirembagan kasebut, Jimmy Bogard bakal nganakake "post-mortem" babagan bencana microservice sing nyata. Dheweke bakal nuduhake masalah modeling, pangembangan, lan produksi sing ditemokake, lan kepiye tim kanthi alon-alon ngowahi monolit sing disebarake dadi gambar pungkasan babagan kewarasan. Nalika iku mokal kanggo rampung nyegah kasalahan desain, sampeyan bisa paling ngenali masalah ing awal proses desain kanggo mesthekake produk final dadi sistem mbagekke dipercaya.
Hello everyone, Aku Jimmy lan dina iki sampeyan bakal krungu carane sampeyan bisa supaya mega bilai nalika mbangun microservices. Iki crita babagan perusahaan sing aku kerja suwene setengah taun kanggo nyegah kapale tabrakan karo gunung es. Kanggo nyritakake crita iki kanthi bener, kita kudu bali ing wektu lan ngomong babagan ngendi perusahaan iki diwiwiti lan kepiye infrastruktur IT saya suwe saya suwe. Kanggo nglindhungi jeneng wong sing ora salah ing bilai iki, aku ngganti jeneng perusahaan iki dadi Bell Computers. Slide sabanjure nuduhake kaya apa infrastruktur IT perusahaan kasebut ing pertengahan 90an. Iki arsitektur khas saka gedhe universal fault-toleran HP Tandem Mainframe server kanggo operasi toko hardware komputer.
Padha kudu mbangun sistem kanggo ngatur kabeh pesenan, dodolan, bali, katalog produk, lan basis pelanggan, supaya padha milih solusi mainframe paling umum ing wektu. Sistem raksasa iki ngemot kabeh informasi babagan perusahaan, kabeh sing bisa ditindakake, lan saben transaksi ditindakake liwat kerangka utama iki. Padha nyimpen kabeh endhog ing siji kranjang lan ngira iku normal. Siji-sijine sing ora kalebu ing kene yaiku katalog pesenan surat lan pesenan kanthi telpon.
Sajrone wektu, sistem dadi luwih gedhe lan luwih gedhe, lan akeh sampah sing akumulasi. Uga, COBOL dudu basa sing paling ekspresif ing donya, mula sistem kasebut dadi sampah monolitik sing gedhe. Ing taun 2000, dheweke weruh manawa akeh perusahaan duwe situs web sing ditindakake kabeh bisnis, lan mutusake kanggo mbangun situs web dot-com komersial pisanan.
Desain awal katon apik banget lan kalebu situs tingkat paling dhuwur bell.com lan sawetara subdomain kanggo aplikasi individu: catalog.bell.com, accounts.bell.com, orders.bell.com, panelusuran produk.bell. com. Saben subdomain nggunakake kerangka ASP.Net 1.0 lan database dhewe, lan kabeh padha ngomong karo backend sistem. Nanging, kabeh pesenan terus diproses lan dileksanakake ing siji mainframe ageng, ing ngendi kabeh sampah tetep, nanging ing ngarep ana situs web sing kapisah karo aplikasi individu lan database sing kapisah.
Dadi desain sistem kasebut katon teratur lan logis, nanging sistem nyata kaya sing ditampilake ing slide sabanjure.
Kabeh unsur alamat telpon kanggo saben liyane, diakses API, ditempelake DLL pihak katelu, lan liya-liyane. Asring kedadeyan yen sistem kontrol versi bakal njupuk kode wong liya, nyurung ing proyek kasebut, banjur kabeh bakal rusak. MS SQL Server 2005 nggunakake konsep link server, lan sanajan aku ora nuduhake panah ing geser, saben database uga ngedika kanggo saben liyane, amarga ana apa-apa salah karo mbangun tabel adhedhasar data dijupuk saka sawetara database .
Wiwit saiki wis sawetara misahake antarane wilayah logis beda saka sistem, iki dadi blobs mbagekke saka rereget, karo Piece paling gedhe saka uwuh isih tetep ing backend mainframe.
Sing lucu yaiku mainframe iki dibangun dening pesaing Bell Computers lan isih dikelola dening konsultan teknis. Yakin karo kinerja aplikasi sing ora nyenengake, perusahaan mutusake kanggo nyingkirake lan ngrancang maneh sistem kasebut.
Aplikasi sing wis ana wis diprodhuksi suwene 15 taun, yaiku rekor kanggo aplikasi berbasis ASP.Net. Layanan nampa pesenan saka sak ndonya, lan revenue taunan saka aplikasi siji iki tekan milyar dolar. Sebagean gedhe saka bathi digawe dening situs web bell.com. Ing Black Fridays, jumlah pesenan sing ditindakake liwat situs kasebut nganti pirang-pirang yuta. Nanging, arsitektur sing wis ana ora ngidini pangembangan, amarga interkoneksi kaku saka unsur sistem praktis ora ngidini owah-owahan kanggo layanan.
Masalah sing paling serius yaiku ora bisa nggawe pesenan saka sawijining negara, mbayar ing negara liya lan ngirim menyang pihak katelu, senadyan kasunyatan manawa skema dagang kasebut umum banget ing perusahaan global. Situs web sing ana ora ngidini apa-apa kaya iki, mula dheweke kudu nampa lan ngirim pesenan kasebut liwat telpon. Iki nyebabake perusahaan saya mikir babagan ngganti arsitektur, utamane babagan ngalih menyang layanan mikro.
Dheweke nindakake perkara sing cerdas kanthi ndeleng perusahaan liyane kanggo ndeleng kepiye ngrampungake masalah sing padha. Salah sawijining solusi kasebut yaiku arsitektur layanan Netflix, sing kalebu layanan mikro sing disambungake liwat API lan database eksternal.
Manajemen Bell Computers mutusake kanggo mbangun arsitektur kasebut, kanthi netepi prinsip dhasar tartamtu. Kaping pisanan, padha ngilangi duplikasi data kanthi nggunakake pendekatan basis data sing dienggo bareng. Ora ana data sing dikirim; Kosok baline, saben wong sing mbutuhake kudu pindhah menyang sumber terpusat. Iki diterusake kanthi pamisahan lan otonomi - saben layanan bebas saka liyane. Dheweke mutusake nggunakake API Web kanggo kabeh - yen sampeyan pengin entuk data utawa nggawe owah-owahan menyang sistem liyane, kabeh wis rampung liwat Web API. Ing bab gedhe pungkasan ana mainframe anyar disebut "Bell ing Bell" minangka gantos kanggo "Bell" mainframe adhedhasar hardware pesaing '.
Dadi, sajrone 18 wulan, dheweke nggawe sistem ing babagan prinsip inti kasebut lan nggawa menyang pra-produksi. Bali kerja sawise akhir minggu, para pangembang kumpul lan nguripake kabeh server sing disambungake karo sistem anyar. 18 wulan kerja, atusan pangembang, hardware Bell paling modern - lan ora ana asil sing positif! Iki wis nguciwani akeh wong amarga wis kaping pirang-pirang mbukak sistem iki ing laptop lan kabeh apik.
Padha pinter uncalan kabeh dhuwit ing mecahaken masalah iki. Padha diinstal rak server paling modern karo ngalih, digunakake serat optik gigabit, hardware server paling kuat karo jumlah edan RAM, disambungake kabeh, diatur - lan maneh, boten! Banjur padha wiwit curiga yen alasane bisa dadi wektu entek, mula dheweke mlebu kabeh setelan web, kabeh setelan API lan nganyari kabeh konfigurasi wektu entek nganti maksimal, supaya kabeh sing bisa ditindakake mung njagong lan ngenteni kedadeyan. menyang situs. Dheweke ngenteni lan ngenteni lan ngenteni 9 lan setengah menit nganti situs web pungkasane dimuat.
Sawise iku, dheweke ngerti yen kahanan saiki mbutuhake analisis sing lengkap, lan dheweke ngajak kita. Babagan pisanan sing ditemokake yaiku sajrone pembangunan 18 wulan, ora ana "mikro" sing nyata - kabeh dadi luwih gedhe. Sawise iki, kita wiwit nulis post-mortem, uga dikenal minangka "regretrospective", utawa "retrospektif sedih", uga dikenal minangka "badai nyalahke", padha karo "badai otak", kanggo mangerteni sabab saka bilai.
Kita duwe sawetara pitunjuk, salah sijine yaiku kejenuhan lalu lintas lengkap nalika telpon API. Nalika sampeyan nggunakake arsitektur layanan monolithic, sampeyan bisa langsung ngerti apa persis salah amarga sampeyan duwe tilak tumpukan siji sing laporan kabeh sing bisa nimbulakΓ© Gagal. Ing kasus nalika akeh layanan ngakses API sing padha, ora ana cara kanggo nglacak jejak kasebut kajaba nggunakake alat pemantauan jaringan tambahan kaya WireShark, amarga sampeyan bisa mriksa panjaluk siji lan ngerteni apa sing kedadeyan sajrone implementasine. Dadi, kita njupuk siji kaca web lan ngentekake meh 2 minggu kanggo nggabungake potongan-potongan teka-teki kasebut, nggawe macem-macem telpon lan nganalisa apa sing diarahake saben wong.
Delengen gambar iki. Iki nuduhake manawa panyuwunan eksternal njaluk layanan supaya akeh telpon internal sing bali maneh. Pranyata saben telpon internal nggawe hop tambahan supaya bisa kanthi mandiri nglayani panyuwunan iki, amarga ora bisa pindhah menyang papan liya kanggo entuk informasi sing dibutuhake. Gambar iki katon kaya kaskade telpon sing ora ana gunane, amarga panjaluk eksternal nelpon layanan tambahan, sing nelpon layanan tambahan liyane, lan liya-liyane, meh ad infinitum.
Werna ijo ing diagram iki nuduhake setengah bunderan ing ngendi layanan nelpon saben liyane - layanan A nelpon layanan B, layanan B nelpon layanan C, lan nelpon layanan A maneh. Panyuwunan siji nggawe sewu panggilan API jaringan, lan amarga sistem kasebut ora duwe toleransi kesalahan lan proteksi daur ulang, panjaluk kasebut bakal gagal yen salah sawijining panggilan API kasebut gagal.
Kita nindakake sawetara math. Saben panggilan API duwe SLA ora luwih saka 150 ms lan 99,9% uptime. Siji panjalukan nyebabake 200 telpon beda, lan ing kasus paling apik, kaca bisa ditampilake ing 200 x 150 ms = 30 detik. Alamiah, iki ora apik. Multiplying 99,9% uptime dening 200, kita entuk kasedhiyan 0%. Pranyata arsitektur iki mesthi gagal wiwit wiwitan.
We takon pangembang carane padha gagal kanggo ngenali masalah iki sawise 18 sasi karya? Iku nguripake metu sing padha mung SLA kanggo kode padha mlayu, nanging yen layanan disebut layanan liyane, padha ora count sing wektu ing SLA. Kabeh sing diluncurake sajrone siji proses netepi regane 150 ms, nanging akses menyang proses layanan liyane nambah wektu tundha kaping pirang-pirang. Pawulangan pisanan sing disinaoni yaiku: "Apa sampeyan ngontrol SLA sampeyan, utawa SLA ngontrol sampeyan?" Ing kasus kita, iku sing terakhir.
Babagan sabanjure sing ditemokake yaiku dheweke ngerti babagan konsep misconceptions komputasi sing disebarake, sing diformulasikan dening Peter Deitch lan James Gosling, nanging dheweke ora nggatekake bagean pisanan. Iki nyatakake yen pratelan "jaringan kasebut dipercaya," "nol latensi," lan "throughput tanpa wates" minangka salah paham. Kesalahpahaman liyane kalebu pernyataan "jaringan aman," "topologi ora tau owah-owahan," "mung ana siji administrator," "biaya transfer data nol," lan "jaringan homogen."
Dheweke nggawe kesalahan amarga nyoba layanan ing mesin lokal lan ora nate nyambung karo layanan eksternal. Nalika ngembangake sacara lokal lan nggunakake cache lokal, dheweke ora nate nemoni hop jaringan. Ing kabeh 18 wulan pangembangan, dheweke ora nate mikir apa sing bisa kedadeyan yen layanan eksternal kena pengaruh.
Yen sampeyan ndeleng wates layanan ing gambar sadurunge, sampeyan bisa ndeleng manawa kabeh ora bener. Ana akeh sumber sing menehi saran babagan carane nemtokake wates layanan, lan umume nindakake salah, kaya Microsoft ing slide sabanjure.
Gambar iki saka blog MS ing topik "Cara mbangun microservices". Iki nuduhake aplikasi web sing prasaja, blok logika bisnis, lan basis data. Panjaluk kasebut langsung, bisa uga ana siji server kanggo web, siji server kanggo bisnis lan siji kanggo database. Yen sampeyan nambah lalu lintas, gambar bakal ganti sethithik.
Ing kene ana load balancer kanggo nyebarake lalu lintas ing antarane rong server web, cache sing ana ing antarane layanan web lan logika bisnis, lan cache liyane ing antarane logika bisnis lan database. Iki persis arsitektur Bell sing digunakake kanggo ngimbangi beban lan aplikasi penyebaran biru / ijo ing pertengahan 2000-an. Nganti sawetara wektu, kabeh bisa digunakake kanthi apik, amarga skema iki dimaksudake kanggo struktur monolitik.
Gambar ing ngisor iki nuduhake carane MS nyaranake pindhah saka monolit menyang layanan mikro - mung misahake saben layanan utama dadi layanan mikro sing kapisah. Sajrone implementasine skema iki, Bell nggawe kesalahan.
Padha dibagi kabeh layanan menyang undakan beda, saben kang kapΓ©rang saka akeh layanan individu. Contone, layanan web kalebu layanan mikro kanggo rendering lan otentikasi konten, layanan logika bisnis kalebu layanan mikro kanggo ngolah pesenan lan informasi akun, database dipΓ©rang dadi pirang-pirang layanan mikro kanthi data khusus. Web, logika bisnis, lan basis data minangka layanan tanpa negara.
Nanging, gambar iki pancen salah amarga ora nggambar unit bisnis ing njaba kluster IT perusahaan. Skema iki ora nggatekake hubungane karo jagad njaba, mula ora jelas kepiye, contone, entuk analytics bisnis pihak katelu. Aku nyathet yen dheweke uga duwe sawetara layanan sing diciptakake mung kanggo ngembangake karir karyawan individu sing ngupaya ngatur akeh wong supaya bisa entuk dhuwit luwih akeh.
Dheweke percaya yen pindhah menyang layanan mikro gampang kaya njupuk infrastruktur lapisan fisik N-tier internal lan nempelake Docker. Ayo deleng arsitektur N-tier tradisional.
Iki kalebu 4 level: level antarmuka pangguna UI, level logika bisnis, level akses data lan database. Luwih maju yaiku DDD (Domain-Driven Design), utawa arsitektur berorientasi piranti lunak, ing ngendi rong tingkat tengah yaiku obyek domain lan gudang.
Aku nyoba ndeleng macem-macem wilayah owah-owahan, macem-macem wilayah tanggung jawab ing arsitektur iki. Ing aplikasi N-tier khas, macem-macem wilayah owah-owahan diklasifikasikakΓ© sing permeate struktur vertikal saka ndhuwur kanggo ngisor. Iki minangka Katalog, Setelan konfigurasi sing ditindakake ing komputer individu, lan mriksa Checkout, sing ditangani dening timku.
Keanehan skema iki yaiku wates wilayah owah-owahan kasebut ora mung mengaruhi tingkat logika bisnis, nanging uga ngluwihi database.
Ayo ndeleng apa tegese dadi layanan. Ana 6 sifat karakteristik definisi layanan - yaiku piranti lunak sing:
- digawe lan digunakake dening organisasi tartamtu;
- tanggung jawab kanggo isi, pangolahan lan/utawa panyedhiya jinis informasi tartamtu ing sistem;
- bisa dibangun, disebarake lan mbukak kanthi mandiri kanggo nyukupi kabutuhan operasional tartamtu;
- komunikasi karo konsumen lan layanan liyane, nyedhiyakake informasi adhedhasar perjanjian utawa jaminan kontrak;
- nglindhungi dhewe saka akses ora sah, lan informasi saka mundhut;
- nangani gagal ing kuwi cara sing padha ora mimpin kanggo karusakan informasi.
Kabeh sifat iki bisa ditulis ing siji tembung "otonomi". Layanan makarya kanthi mandiri, marem watesan tartamtu, lan nemtokake kontrak kanthi basis supaya wong bisa nampa informasi sing dibutuhake. Aku ora nyebataken teknologi tartamtu, sing nggunakake iku poto-bukti.
Saiki ayo goleki definisi microservices:
- microservice ukurane cilik lan dirancang kanggo ngatasi masalah tartamtu;
- Microservice iku otonom;
- Nalika nggawe arsitektur layanan mikro, metafora perencanaan kutha digunakake. Iki minangka definisi saka buku Sam Newman, Building Microservices.
DhΓ©finisi Konteks Bounded dijupuk saka buku Eric Evans Domain-Driven Design. Iki minangka pola inti ing DDD, pusat desain arsitektur sing bisa digunakake karo model arsitektur volumetrik, dibagi dadi Konteks Watesan sing beda-beda lan kanthi jelas nemtokake interaksi ing antarane.
Cukup, Konteks Watesan nuduhake ruang lingkup modul tartamtu sing bisa digunakake. Ing konteks iki ana model terpadu logis sing bisa dideleng, contone, ing domain bisnis sampeyan. Yen sampeyan takon "sapa klien" kanggo personel sing melu pesenan, sampeyan bakal entuk definisi siji, yen sampeyan takon sing melu sales, sampeyan bakal entuk liyane, lan pemain bakal menehi definisi katelu.
Dadi, Konteks Bounded ujar manawa yen kita ora bisa menehi definisi sing jelas babagan konsumen layanan kita, ayo nemtokake wates-wates ing ngendi kita bisa ngomong babagan makna istilah iki, banjur nemtokake titik transisi ing antarane definisi sing beda-beda kasebut. Yaiku, yen kita ngomong babagan klien saka sudut pandang nggawe pesenan, iki tegese iki lan iki, lan yen saka sudut pandang sales, iki tegese iki lan iki.
Definisi microservice sabanjure yaiku enkapsulasi saka operasi internal apa wae, nyegah "bocor" komponen proses kerja menyang lingkungan. Sabanjure teka "definisi kontrak eksplisit kanggo interaksi eksternal, utawa komunikasi eksternal," sing diwakili dening gagasan kontrak bali saka SLA. DhΓ©finisi pungkasan yaiku metafora sel, utawa sel, sing tegese enkapsulasi lengkap sakumpulan operasi ing microservice lan ananΓ© reseptor kanggo komunikasi karo donya njaba.
Dadi, kita ngomong karo wong lanang ing Bell Computers, "Kita ora bisa ndandani kekacauan sing wis digawe amarga sampeyan ora duwe dhuwit kanggo nindakake, nanging kita bakal ndandani mung siji layanan kanggo nggawe kabeh. rasane.β Ing wektu iki, aku bakal miwiti kanthi nyritakake kepiye cara ndandani layanan mung supaya bisa nanggapi panjaluk luwih cepet tinimbang 9 menit setengah.
22:30 min
Diterusake kanthi cepet ...
Sawetara iklan
Matur nuwun kanggo tetep karo kita. Apa sampeyan seneng karo artikel kita? Pengin ndeleng konten sing luwih menarik? Ndhukung kita kanthi nggawe pesenan utawa menehi rekomendasi menyang kanca, , analog unik saka server level entri, sing diciptakake kanggo sampeyan: (kasedhiya karo RAID1 lan RAID10, munggah 24 intine lan nganti 40GB DDR4).
Dell R730xd 2 kaping luwih murah ing pusat data Equinix Tier IV ing Amsterdam? Mung kene ing Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - saka $99! Maca babagan
Source: www.habr.com