Ilang buwan kang muling nagdidisenyo ng iyong monolith sa mga microservice, at sa wakas ay nagsama-sama ang lahat upang i-flip ang switch. Pumunta ka sa unang web page... at walang mangyayari. I-reload mo ito - at muli, walang maganda, napakabagal ng site na hindi ito tumutugon nang ilang minuto. Anong nangyari?
Sa kanyang talumpati, magsasagawa si Jimmy Bogard ng "post-mortem" sa isang real-life microservice disaster. Ipapakita niya ang mga problema sa pagmomodelo, pag-unlad, at produksyon na natuklasan niya, at kung paano dahan-dahang binago ng kanyang koponan ang bagong ibinahagi na monolith sa huling larawan ng katinuan. Bagama't imposibleng ganap na maiwasan ang mga error sa disenyo, maaari mong matukoy ang mga problema nang maaga sa proseso ng disenyo upang matiyak na ang huling produkto ay magiging isang maaasahang ipinamamahaging sistema.
Kumusta sa lahat, ako si Jimmy at ngayon ay maririnig mo kung paano mo maiiwasan ang malalaking sakuna kapag gumagawa ng mga microservice. Ito ang kwento ng isang kumpanyang pinagtrabahuan ko ng halos isang taon at kalahati upang makatulong na maiwasan ang pagbangga ng kanilang barko sa isang malaking bato ng yelo. Para maikwento nang maayos ang kuwentong ito, kailangan nating bumalik sa nakaraan at pag-usapan kung saan nagsimula ang kumpanyang ito at kung paano lumago ang imprastraktura ng IT nito sa paglipas ng panahon. Upang maprotektahan ang mga pangalan ng mga inosente sa kalamidad na ito, pinalitan ko ang pangalan ng kumpanyang ito ng Bell Computers. Ang susunod na slide ay nagpapakita kung ano ang hitsura ng IT infrastructure ng naturang mga kumpanya noong kalagitnaan ng 90s. Ito ay isang tipikal na arkitektura ng isang malaking unibersal na fault-tolerant na HP Tandem Mainframe server para sa pagpapatakbo ng isang computer hardware store.
Kailangan nilang bumuo ng system para pamahalaan ang lahat ng mga order, benta, pagbabalik, mga katalogo ng produkto, at base ng customer, kaya pinili nila ang pinakakaraniwang solusyon sa mainframe noong panahong iyon. Ang napakalaking sistemang ito ay naglalaman ng bawat piraso ng impormasyon tungkol sa kumpanya, lahat ng posible, at bawat transaksyon ay isinasagawa sa pamamagitan ng mainframe na ito. Itinago nila ang lahat ng kanilang mga itlog sa isang basket at inisip na normal lang iyon. Ang tanging bagay na hindi kasama dito ay ang mga mail order catalog at paglalagay ng mga order sa pamamagitan ng telepono.
Sa paglipas ng panahon, ang sistema ay naging mas malaki at mas malaki, at isang malaking halaga ng basura ang naipon dito. Gayundin, ang COBOL ay hindi ang pinaka-nagpapahayag na wika sa mundo, kaya ang sistema ay naging isang malaking, monolitikong piraso ng basura. Noong 2000, nakita nila na maraming kumpanya ang may mga website kung saan ganap nilang isinasagawa ang lahat ng kanilang negosyo, at nagpasyang buuin ang kanilang unang komersyal na dot-com website.
Ang paunang disenyo ay mukhang maganda at binubuo ng isang top-level na site na bell.com at ilang mga subdomain para sa mga indibidwal na application: catalog.bell.com, accounts.bell.com, orders.bell.com, product search search.bell. com. Ginamit ng bawat subdomain ang ASP.Net 1.0 framework at ang sarili nitong mga database, at lahat sila ay nakipag-usap sa backend ng system. Gayunpaman, ang lahat ng mga order ay patuloy na naproseso at naisakatuparan sa loob ng isang malaking mainframe, kung saan nanatili ang lahat ng basura, ngunit ang front end ay hiwalay na mga website na may mga indibidwal na aplikasyon at hiwalay na mga database.
Kaya ang disenyo ng sistema ay mukhang maayos at lohikal, ngunit ang aktwal na sistema ay tulad ng ipinapakita sa susunod na slide.
Ang lahat ng elemento ay nag-address ng mga tawag sa isa't isa, na-access na mga API, naka-embed na mga third-party na dll, at mga katulad nito. Madalas mangyari na ang mga version control system ay kukuha ng code ng ibang tao, itulak ito sa loob ng proyekto, at pagkatapos ay masisira ang lahat. Ginamit ng MS SQL Server 2005 ang konsepto ng mga link server, at kahit na hindi ko ipinakita ang mga arrow sa slide, ang bawat isa sa mga database ay nakipag-usap din sa isa't isa, dahil walang mali sa pagbuo ng mga talahanayan batay sa data na nakuha mula sa ilang mga database .
Dahil nagkaroon na sila ngayon ng ilang paghihiwalay sa pagitan ng iba't ibang lohikal na bahagi ng system, ito ay naging distributed blobs ng dumi, na ang pinakamalaking piraso ng basura ay natitira pa sa mainframe backend.
Ang nakakatawa ay ang mainframe na ito ay binuo ng mga kakumpitensya ng Bell Computers at pinananatili pa rin ng kanilang mga teknikal na consultant. Kumbinsido sa hindi kasiya-siyang pagganap ng mga aplikasyon nito, nagpasya ang kumpanya na alisin ang mga ito at muling idisenyo ang system.
Ang umiiral na aplikasyon ay nasa produksyon sa loob ng 15 taon, na isang talaan para sa ASP.Net-based na mga aplikasyon. Ang serbisyo ay tumanggap ng mga order mula sa buong mundo, at ang taunang kita mula sa nag-iisang application na ito ay umabot sa isang bilyong dolyar. Malaking bahagi ng kita ang nabuo ng bell.com website. Sa Black Fridays, ang bilang ng mga order na inilagay sa pamamagitan ng site ay umabot sa ilang milyon. Gayunpaman, ang umiiral na arkitektura ay hindi pinapayagan ang anumang pag-unlad, dahil ang mahigpit na pagkakaugnay ng mga elemento ng system ay halos hindi pinapayagan ang anumang mga pagbabago na gawin sa serbisyo.
Ang pinaka-seryosong problema ay ang kawalan ng kakayahang maglagay ng isang order mula sa isang bansa, bayaran ito sa isa pa at ipadala ito sa isang pangatlo, sa kabila ng katotohanan na ang gayong pamamaraan ng pangangalakal ay karaniwan sa mga pandaigdigang kumpanya. Ang umiiral na website ay hindi pinapayagan ang anumang bagay na tulad nito, kaya kailangan nilang tanggapin at ilagay ang mga order na ito sa pamamagitan ng telepono. Nagdulot ito ng lalong pag-iisip ng kumpanya tungkol sa pagbabago ng arkitektura, lalo na sa paglipat sa mga microservice.
Ginawa nila ang matalinong bagay sa pamamagitan ng pagtingin sa ibang mga kumpanya upang makita kung paano nila nalutas ang isang katulad na problema. Isa sa mga solusyong ito ay ang arkitektura ng serbisyo ng Netflix, na binubuo ng mga microservice na konektado sa pamamagitan ng isang API at isang panlabas na database.
Nagpasya ang pamamahala ng Bell Computers na bumuo ng ganoong arkitektura, na sumusunod sa ilang mga pangunahing prinsipyo. Una, inalis nila ang pagdoble ng data sa pamamagitan ng paggamit ng shared database approach. Walang data na ipinadala; sa kabaligtaran, lahat ng nangangailangan nito ay kailangang pumunta sa isang sentralisadong mapagkukunan. Sinundan ito ng paghihiwalay at awtonomiya - ang bawat serbisyo ay independiyente sa iba. Nagpasya silang gamitin ang Web API para sa lahat ng bagay - kung gusto mong makakuha ng data o gumawa ng mga pagbabago sa isa pang system, gagawin ang lahat sa pamamagitan ng Web API. Ang huling malaking bagay ay isang bagong mainframe na tinatawag na "Bell on Bell" kumpara sa "Bell" mainframe batay sa hardware ng mga kakumpitensya.
Kaya, sa loob ng 18 buwan, binuo nila ang sistema sa paligid ng mga pangunahing prinsipyong ito at dinala ito sa pre-production. Bumalik sa trabaho pagkatapos ng katapusan ng linggo, nagsama-sama ang mga developer at binuksan ang lahat ng mga server kung saan nakakonekta ang bagong system. 18 buwang trabaho, daan-daang developer, ang pinakamodernong Bell hardware - at walang positibong resulta! Ito ay nabigo sa maraming tao dahil pinatakbo nila ang sistemang ito sa kanilang mga laptop nang maraming beses at maayos ang lahat.
Matalino silang itapon ang lahat ng kanilang pera sa paglutas ng problemang ito. Nag-install sila ng pinakamodernong mga rack ng server na may mga switch, gumamit ng gigabit optical fiber, ang pinakamalakas na hardware ng server na may nakakabaliw na halaga ng RAM, ikinonekta ang lahat, na-configure ito - at muli, wala! Pagkatapos ay nagsimula silang maghinala na ang dahilan ay maaaring mga timeout, kaya pumunta sila sa lahat ng mga setting ng web, lahat ng mga setting ng API at na-update ang buong configuration ng timeout sa maximum na mga halaga, upang ang tanging magagawa nila ay umupo at maghintay para sa isang bagay na mangyari. sa site. Naghintay sila at naghintay at naghintay ng 9 at kalahating minuto hanggang sa tuluyang na-load ang website.
Pagkatapos noon, naisip nila na ang kasalukuyang sitwasyon ay nangangailangan ng masusing pagsusuri, at inanyayahan nila kami. Ang unang bagay na nalaman namin ay sa lahat ng 18 buwan ng pag-unlad, walang isang tunay na "micro" ang nalikha - lahat ay lumaki lamang. Pagkatapos nito, nagsimula kaming magsulat ng post-mortem, na kilala rin bilang "regretrospective", o "sad retrospective", na kilala rin bilang "blame storm", katulad ng isang "brain storm", upang maunawaan ang sanhi ng sakuna.
Nagkaroon kami ng ilang mga pahiwatig, isa na rito ang kumpletong saturation ng trapiko sa oras ng tawag sa API. Kapag gumamit ka ng monolithic na arkitektura ng serbisyo, mauunawaan mo kaagad kung ano ang eksaktong nangyari dahil mayroon kang isang stack trace na nag-uulat ng lahat ng maaaring maging sanhi ng pagkabigo. Sa kaso kung saan ang isang grupo ng mga serbisyo ay sabay-sabay na nag-access sa parehong API, walang paraan upang masubaybayan ang bakas maliban sa paggamit ng mga karagdagang tool sa pagsubaybay sa network tulad ng WireShark, salamat kung saan maaari mong suriin ang isang kahilingan at malaman kung ano ang nangyari sa panahon ng pagpapatupad nito. Kaya kumuha kami ng isang web page at gumugol ng halos 2 linggo sa pagsasama-sama ng mga piraso ng puzzle, paggawa ng iba't ibang mga tawag dito at pagsusuri kung ano ang humantong sa bawat isa sa kanila.
Tingnan ang larawang ito. Ipinapakita nito na ang isang panlabas na kahilingan ay nag-uudyok sa serbisyo na gumawa ng maraming panloob na mga tawag na bumalik. Lumalabas na ang bawat panloob na tawag ay gumagawa ng mga karagdagang hops upang makapag-independiyenteng maserbisyuhan ang kahilingang ito, dahil hindi ito maaaring lumiko kahit saan pa upang makuha ang kinakailangang impormasyon. Ang larawang ito ay mukhang isang walang kabuluhang kaskad ng mga tawag, dahil ang panlabas na kahilingan ay tumatawag ng mga karagdagang serbisyo, na tumatawag sa iba pang mga karagdagang serbisyo, at iba pa, halos ad infinitum.
Ang berdeng kulay sa diagram na ito ay nagpapakita ng kalahating bilog na kung saan ang mga serbisyo ay tumatawag sa isa't isa - ang serbisyo A ay tumatawag sa serbisyo B, ang serbisyo B ay tumatawag sa serbisyo C, at ito ay tumatawag muli sa serbisyo A. Bilang resulta, kami ay nakakakuha ng "naipamahagi na deadlock". Ang isang kahilingan ay lumikha ng isang libong mga tawag sa network API, at dahil ang system ay walang built-in na fault tolerance at loop na proteksyon, ang kahilingan ay mabibigo kung kahit isa sa mga tawag na ito sa API ay nabigo.
May ginawa kaming math. Ang bawat API call ay may SLA na hindi hihigit sa 150 ms at 99,9% uptime. Ang isang kahilingan ay nagdulot ng 200 iba't ibang mga tawag, at sa pinakamagandang kaso, maaaring ipakita ang page sa loob ng 200 x 150 ms = 30 segundo. Naturally, ito ay hindi mabuti. Pag-multiply ng 99,9% uptime sa 200, nakakuha kami ng 0% availability. Lumalabas na ang arkitektura na ito ay tiyak na mapapahamak sa kabiguan mula pa sa simula.
Tinanong namin ang mga developer kung paano nila nabigo na makilala ang problemang ito pagkatapos ng 18 buwang trabaho? Lumalabas na binilang lang nila ang SLA para sa code na kanilang pinatakbo, ngunit kung tumawag ang kanilang serbisyo ng isa pang serbisyo, hindi nila binilang ang oras na iyon sa kanilang SLA. Lahat ng inilunsad sa loob ng isang proseso ay sumunod sa halagang 150 ms, ngunit ang pag-access sa iba pang mga proseso ng serbisyo ay nagpapataas ng kabuuang pagkaantala nang maraming beses. Ang unang aral na natutunan ay: "Ikaw ba ang may kontrol sa iyong SLA, o ang SLA ba ang may kontrol sa iyo?" Sa aming kaso, ito ang huli.
Ang susunod na natuklasan namin ay alam nila ang tungkol sa konsepto ng distributed computing misconceptions, na binuo ni Peter Deitch at James Gosling, ngunit hindi nila pinansin ang unang bahagi nito. Sinasabi nito na ang mga pahayag na "maasahan ang network," "zero latency," at "walang katapusan na throughput" ay mga maling akala. Kasama sa iba pang mga maling akala ang mga pahayag na "ang network ay ligtas," "ang topology ay hindi nagbabago," "mayroong palaging isang administrator," "ang halaga ng paglilipat ng data ay zero," at "ang network ay homogenous."
Nagkamali sila dahil sinubukan nila ang kanilang serbisyo sa mga lokal na makina at hindi kailanman nakakonekta sa mga panlabas na serbisyo. Kapag nag-develop nang lokal at gumagamit ng lokal na cache, hindi sila nakatagpo ng mga network hops. Sa lahat ng 18 buwan ng pag-unlad, ni minsan ay hindi nila naisip kung ano ang maaaring mangyari kung maapektuhan ang mga panlabas na serbisyo.
Kung titingnan mo ang mga hangganan ng serbisyo sa nakaraang larawan, makikita mo na lahat sila ay mali. Mayroong maraming mga mapagkukunan na nagpapayo sa kung paano tukuyin ang mga hangganan ng serbisyo, at karamihan ay ginagawa itong mali, tulad ng Microsoft sa susunod na slide.
Ang larawang ito ay mula sa MS blog sa paksang "Paano bumuo ng mga microservice". Nagpapakita ito ng isang simpleng web application, isang bloke ng lohika ng negosyo, at isang database. Direktang dumarating ang kahilingan, marahil mayroong isang server para sa web, isang server para sa negosyo at isa para sa database. Kung dagdagan mo ang trapiko, mababago ng kaunti ang larawan.
Narito ang isang load balancer upang ipamahagi ang trapiko sa pagitan ng dalawang web server, isang cache na matatagpuan sa pagitan ng web service at ng business logic, at isa pang cache sa pagitan ng business logic at ng database. Ito mismo ang architecture Bell na ginamit para sa load balancing at blue/green deployment application nito noong kalagitnaan ng 2000s. Hanggang sa ilang oras ang lahat ay gumana nang maayos, dahil ang pamamaraan na ito ay inilaan para sa isang monolitikong istraktura.
Ang sumusunod na larawan ay nagpapakita kung paano inirerekomenda ng MS ang paglipat mula sa isang monolith patungo sa mga microservice - hatiin lamang ang bawat isa sa mga pangunahing serbisyo sa magkakahiwalay na mga microservice. Sa panahon ng pagpapatupad ng pamamaraang ito na nagkamali si Bell.
Hinati nila ang lahat ng kanilang mga serbisyo sa iba't ibang mga antas, na ang bawat isa ay binubuo ng maraming indibidwal na mga serbisyo. Halimbawa, kasama sa serbisyo sa web ang mga microservice para sa pag-render ng nilalaman at pagpapatunay, ang serbisyo ng lohika ng negosyo ay binubuo ng mga microservice para sa pagproseso ng mga order at impormasyon ng account, ang database ay nahahati sa isang grupo ng mga microservice na may espesyal na data. Parehong ang web, lohika ng negosyo, at database ay mga serbisyong walang estado.
Gayunpaman, ang larawang ito ay ganap na mali dahil hindi ito nag-mapa ng anumang mga yunit ng negosyo sa labas ng IT cluster ng kumpanya. Ang scheme na ito ay hindi isinasaalang-alang ang anumang koneksyon sa labas ng mundo, kaya hindi malinaw kung paano, halimbawa, upang makakuha ng third-party na analytics ng negosyo. Pansinin ko na mayroon din silang ilang mga serbisyo na naimbento para lamang mapaunlad ang mga karera ng mga indibidwal na empleyado na naghangad na pamahalaan ang pinakamaraming tao hangga't maaari upang makakuha ng mas maraming pera para dito.
Naniniwala sila na ang paglipat sa mga microservice ay kasingdali ng pagkuha ng kanilang panloob na N-tier na physical layer na imprastraktura at pagdikit ng Docker dito. Tingnan natin kung ano ang hitsura ng tradisyonal na N-tier na arkitektura.
Binubuo ito ng 4 na antas: ang antas ng interface ng gumagamit ng UI, ang antas ng lohika ng negosyo, ang antas ng pag-access ng data at ang database. Ang mas progresibo ay DDD (Domain-Driven Design), o software-oriented architecture, kung saan ang dalawang gitnang antas ay mga domain object at isang repository.
Sinubukan kong tingnan ang iba't ibang mga lugar ng pagbabago, iba't ibang mga lugar ng responsibilidad sa arkitektura na ito. Sa isang tipikal na aplikasyon ng N-tier, inuri ang iba't ibang bahagi ng pagbabago na tumatagos sa istraktura nang patayo mula sa itaas hanggang sa ibaba. Ito ang Catalog, mga setting ng Config na isinagawa sa mga indibidwal na computer, at mga pagsusuri sa Checkout, na pinangasiwaan ng aking team.
Ang kakaiba ng pamamaraang ito ay ang mga hangganan ng mga lugar na ito ng pagbabago ay nakakaapekto hindi lamang sa antas ng lohika ng negosyo, ngunit umaabot din sa database.
Tingnan natin kung ano ang ibig sabihin ng pagiging isang serbisyo. Mayroong 6 na katangian ng isang kahulugan ng serbisyo - ito ay software na:
- nilikha at ginagamit ng isang partikular na organisasyon;
- ay responsable para sa nilalaman, pagproseso at/o pagbibigay ng isang tiyak na uri ng impormasyon sa loob ng system;
- maaaring itayo, i-deploy at patakbuhin nang nakapag-iisa upang matugunan ang mga partikular na pangangailangan sa pagpapatakbo;
- nakikipag-ugnayan sa mga mamimili at iba pang mga serbisyo, na nagbibigay ng impormasyon batay sa mga kasunduan o mga garantiyang kontraktwal;
- pinoprotektahan ang sarili mula sa hindi awtorisadong pag-access, at ang impormasyon nito mula sa pagkawala;
- pinangangasiwaan ang mga pagkabigo sa paraang hindi humantong sa pagkasira ng impormasyon.
Ang lahat ng mga katangiang ito ay maaaring ipahayag sa isang salitang "autonomy". Ang mga serbisyo ay gumagana nang hiwalay sa isa't isa, natutugunan ang ilang mga paghihigpit, at tinutukoy ang mga kontrata batay sa kung saan matatanggap ng mga tao ang impormasyong kailangan nila. Hindi ko binanggit ang mga partikular na teknolohiya, ang paggamit nito ay maliwanag.
Ngayon tingnan natin ang kahulugan ng microservices:
- ang isang microservice ay maliit sa laki at idinisenyo upang malutas ang isang partikular na problema;
- Ang microservice ay nagsasarili;
- Kapag lumilikha ng arkitektura ng microservice, ginagamit ang metapora sa pagpaplano ng bayan. Ito ang kahulugan mula sa aklat ni Sam Newman, Building Microservices.
Ang kahulugan ng Bounded Context ay kinuha mula sa aklat ni Eric Evans na Domain-Driven Design. Isa itong pangunahing pattern sa DDD, isang sentro ng disenyo ng arkitektura na gumagana sa mga volumetric na modelo ng arkitektura, na hinahati ang mga ito sa iba't ibang Bounded na Konteksto at tahasang tinutukoy ang mga pakikipag-ugnayan sa pagitan ng mga ito.
Sa madaling salita, ang Bounded Context ay tumutukoy sa saklaw kung saan maaaring gamitin ang isang partikular na module. Sa loob ng kontekstong ito ay isang lohikal na pinag-isang modelo na makikita, halimbawa, sa domain ng iyong negosyo. Kung tatanungin mo ang "sino ang isang kliyente" sa mga tauhan na kasangkot sa mga order, makakakuha ka ng isang kahulugan, kung tatanungin mo ang mga kasangkot sa pagbebenta, makakakuha ka ng isa pa, at ang mga gumaganap ay magbibigay sa iyo ng pangatlong kahulugan.
Kaya, sinasabi ng Bounded Context na kung hindi tayo makapagbibigay ng malinaw na kahulugan kung ano ang consumer ng ating mga serbisyo, tukuyin natin ang mga hangganan kung saan maaari nating pag-usapan ang kahulugan ng terminong ito, at pagkatapos ay tukuyin ang mga transition point sa pagitan ng iba't ibang kahulugang ito. Iyon ay, kung pinag-uusapan natin ang tungkol sa isang kliyente mula sa punto ng view ng paglalagay ng mga order, ito ay nangangahulugan na ito at iyon, at kung mula sa punto ng view ng mga benta, ito ay nangangahulugan na ito at iyon.
Ang susunod na kahulugan ng isang microservice ay ang encapsulation ng anumang uri ng mga panloob na operasyon, na pumipigil sa "leakage" ng mga bahagi ng proseso ng trabaho sa kapaligiran. Susunod ay ang "kahulugan ng mga tahasang kontrata para sa mga panlabas na pakikipag-ugnayan, o panlabas na komunikasyon," na kinakatawan ng ideya ng mga kontratang bumabalik mula sa mga SLA. Ang huling kahulugan ay ang metapora ng isang cell, o cell, na nangangahulugan ng kumpletong encapsulation ng isang hanay ng mga operasyon sa loob ng isang microservice at ang pagkakaroon nito ng mga receptor para sa komunikasyon sa labas ng mundo.
Kaya sinabi namin sa mga lalaki sa Bell Computers, βHindi namin maaayos ang alinman sa mga kaguluhang ginawa ninyo dahil wala lang kayong pera para gawin ito, pero isang serbisyo lang ang aayusin namin para maging maayos ang lahat. pakiramdam.β Sa puntong ito, magsisimula ako sa pagsasabi sa iyo kung paano namin inayos ang aming nag-iisang serbisyo upang tumugon ito sa mga kahilingan nang mas mabilis sa 9 at kalahating minuto.
22:30 min
Itutuloy sa lalong madaling panahon...
Isang maliit na advertising
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com