Hindi tumitigil ang mundo. Ang pag-unlad ay lumilikha ng mga bagong teknolohikal na hamon. Alinsunod sa pagbabago ng mga kinakailangan, ang arkitektura ng mga sistema ng impormasyon ay dapat umunlad. Ngayon ay pag-uusapan natin ang tungkol sa arkitektura na hinimok ng kaganapan, concurrency, concurrency, asynchrony, at kung paano ka mabubuhay nang payapa sa lahat ng ito sa Erlang.
Pagpapakilala
Depende sa laki ng idinisenyong sistema at sa mga kinakailangan para dito, kami, ang mga developer, ang pipili ng paraan ng pagpapalitan ng impormasyon sa system. Sa karamihan ng mga kaso, upang ayusin ang pakikipag-ugnayan ng mga serbisyo, ang isang gumaganang opsyon ay maaaring isang pamamaraan sa isang broker, halimbawa, batay sa RabbitMQ o kafka. Ngunit kung minsan ang daloy ng mga kaganapan, SLA at antas ng kontrol sa system ay tulad na ang handa na pagmemensahe ay hindi angkop para sa amin. Siyempre, maaari mong gawing kumplikado ang system nang kaunti sa pamamagitan ng pagkuha ng responsibilidad para sa layer ng transportasyon at pagbuo ng kumpol, halimbawa gamit ang ZeroMQ o nanomsg. Ngunit kung ang system ay may sapat na throughput at mga kakayahan ng isang karaniwang Erlang cluster, kung gayon ang isyu ng pagpapakilala ng karagdagang entity ay nangangailangan ng detalyadong pag-aaral at pang-ekonomiyang pagbibigay-katwiran.
Ang paksa ng mga reaktibong ipinamamahaging aplikasyon ay medyo malawak. Upang mapanatili sa loob ng format ng artikulo, ang paksa ng talakayan ngayon ay magiging homogenous na kapaligiran lamang na binuo sa Erlang/Elixir. Binibigyang-daan ka ng Erlang/OTP ecosystem na magpatupad ng reaktibong arkitektura na may pinakamababang pagsisikap. Ngunit sa anumang kaso, kakailanganin namin ng isang layer ng pagmemensahe.
Batayang teoretikal
Nagsisimula ang disenyo sa pagtukoy ng mga layunin at mga hadlang. Ang pangunahing layunin ay wala sa lugar ng pag-unlad para sa kapakanan ng pag-unlad. Kailangan nating kumuha ng secure at scalable na tool batay sa kung saan tayo makakagawa at, higit sa lahat, bumuo ng mga modernong application ng iba't ibang antas: simula sa mga single-server na application na nagsisilbi sa isang maliit na audience, na sa kalaunan ay maaaring maging mga cluster na hanggang 50 -60 node, na nagtatapos sa mga cluster federations. Kaya, ang pangunahing layunin ay upang i-maximize ang mga kita sa pamamagitan ng pagbawas sa gastos ng pag-unlad at pagmamay-ari ng panghuling sistema.
I-highlight natin ang 4 na pangunahing kinakailangan para sa panghuling sistema:
- Π‘nakatuon sa kaganapan.
Ang sistema ay laging handa na dumaan sa daloy ng mga kaganapan at isagawa ang mga kinakailangang aksyon; - Πscalability.
Ang mga indibidwal na bloke ay maaaring i-scale parehong patayo at pahalang. Ang buong sistema ay dapat na may kakayahang walang katapusang pahalang na paglaki; - Πpagpaparaya sa kasalanan.
Ang lahat ng antas at lahat ng mga serbisyo ay dapat na awtomatikong makabawi mula sa mga pagkabigo; - Πgarantisadong oras ng pagtugon.
Ang oras ay mahalaga at ang mga gumagamit ay hindi dapat maghintay ng masyadong mahaba.
Tandaan ang lumang fairy tale tungkol sa "The little engine that could"? Upang ang dinisenyong sistema ay matagumpay na lumabas sa prototype stage at maging progresibo, ang pundasyon nito ay dapat matugunan ang mga minimum na kinakailangan SMOG.
Ang isa pang punto ay idinagdag sa pagmemensahe bilang isang tool sa imprastraktura at ang batayan para sa lahat ng mga serbisyo: kadalian ng paggamit para sa mga programmer.
Nakatuon sa kaganapan
Para lumago ang isang application mula sa isang server patungo sa isang cluster, dapat na sinusuportahan ng arkitektura nito ang maluwag na pagkabit. Natutugunan ng asynchronous na modelo ang kinakailangang ito. Sa loob nito, ang nagpadala at tatanggap ay nagmamalasakit sa pag-load ng impormasyon ng mensahe at huwag mag-alala tungkol sa paghahatid at pagruruta sa loob ng system.
Scalability
Ang scalability at kahusayan ng system ay magkatabi. Dapat na magamit ng mga bahagi ng application ang lahat ng magagamit na mapagkukunan. Kung mas mahusay nating magagamit ang kapasidad at mas mahusay ang ating mga pamamaraan sa pagproseso, mas kaunting pera ang ating ginagastos sa kagamitan.
Sa loob ng iisang makina, lumilikha si Erlang ng lubos na mapagkumpitensyang kapaligiran. Ang balanse sa pagitan ng concurrency at parallelism ay maaaring itakda sa pamamagitan ng pagpili sa bilang ng mga thread ng operating system na magagamit sa Erlang VM at ang bilang ng mga scheduler na gumagamit ng mga thread na ito.
Ang mga proseso ng Erlang ay hindi nagbabahagi ng estado at gumagana sa non-blocking mode. Nagbibigay ito ng medyo mababang latency at mas mataas na throughput kaysa sa tradisyonal na mga application na nakabatay sa pagharang. Tinitiyak ng scheduler ni Erlang ang patas na paglalaan ng CPU at IO, at ang kawalan ng pagharang ay nagbibigay-daan sa application na tumugon kahit na sa mga peak load o pagkabigo.
Sa antas ng kumpol, umiiral din ang problema sa pagtatapon. Mahalaga na ang lahat ng mga makina sa cluster ay pantay na na-load at ang network ay hindi na-overload. Isipin natin ang isang sitwasyon: dumarating ang trapiko ng gumagamit sa mga papasok na balanse (haproxy, nginx, atbp), namamahagi sila ng mga kahilingan para sa pagproseso nang pantay-pantay hangga't maaari sa pagitan ng hanay ng mga available na backend. Sa loob ng imprastraktura ng application, ang serbisyong nagpapatupad ng kinakailangang interface ay nasa huling milya lamang at kakailanganing humiling ng ilang iba pang serbisyo upang tumugon sa paunang kahilingan. Ang mga panloob na kahilingan ay nangangailangan din ng pagruruta at pagbabalanse.
Upang epektibong pamahalaan ang mga daloy ng data, ang pagmemensahe ay dapat magbigay sa mga developer ng isang interface upang pamahalaan ang pagruruta at pagbalanse ng load. Dahil dito, magagawa ng mga developer, gamit ang mga pattern ng microservice (aggregator, proxy, chain, branch, atbp), upang malutas ang parehong mga karaniwang problema at ang mga bihirang lumitaw.
Mula sa pananaw ng negosyo, ang scalability ay isa sa mga tool sa pamamahala ng panganib. Ang pangunahing bagay ay upang matugunan ang mga kahilingan ng customer sa pamamagitan ng mahusay na paggamit ng kagamitan:
- Kapag ang lakas ng kagamitan ay tumaas bilang resulta ng pag-unlad. Hindi ito magiging idle dahil sa hindi perpektong software. Ang Erlang ay sumusukat nang patayo at palaging magagamit ang lahat ng mga core ng CPU at magagamit na memorya;
- Sa cloud environment, maaari naming pamahalaan ang dami ng kagamitan depende sa kasalukuyan o hinulaang pagkarga at ginagarantiyahan ang SLA.
pagpaparaya sa kasalanan
Isaalang-alang natin ang dalawang axiom: "Ang mga pagkabigo ay hindi katanggap-tanggap" at "Palaging may mga kabiguan." Para sa isang negosyo, ang pagkabigo ng software ay nangangahulugan ng pagkawala ng pera, at ang mas masahol pa, pagkawala ng reputasyon. Ang pagbabalanse sa pagitan ng mga posibleng pagkalugi at ang gastos ng pagbuo ng fault-tolerant na software, madalas na mahahanap ang isang kompromiso.
Sa maikling panahon, ang isang arkitektura na nagsasama ng fault tolerance ay nakakatipid ng pera sa pagbili ng mga off-the-shelf clustering solution. Ang mga ito ay mahal at mayroon din silang mga surot.
Sa mahabang panahon, ang isang fault-tolerant na arkitektura ay nagbabayad para sa sarili nito nang maraming beses sa lahat ng mga yugto ng pag-unlad.
Ang pagmemensahe sa loob ng code base ay nagbibigay-daan sa iyo upang maisagawa nang detalyado ang pakikipag-ugnayan ng mga bahagi sa loob ng system kahit na sa yugto ng pag-unlad. Pinapasimple nito ang gawain ng pagtugon at pamamahala ng mga pagkabigo, dahil ang lahat ng mga kritikal na bahagi ay humahawak ng mga pagkabigo, at ang resultang sistema ay alam kung paano awtomatikong bumalik sa normal pagkatapos ng pagkabigo sa pamamagitan ng disenyo.
Pagkatugon
Anuman ang mga pagkabigo, ang application ay dapat tumugon sa mga kahilingan at matugunan ang SLA. Ang katotohanan ay ang mga tao ay hindi gustong maghintay, kaya ang mga negosyo ay dapat umangkop nang naaayon. Parami nang parami ang mga application ay inaasahan na lubos na tumutugon.
Ang mga tumutugon na application ay gumagana nang malapit sa real time. Gumagana ang Erlang VM sa soft real-time mode. Para sa ilang lugar, gaya ng stock trading, gamot, at pang-industriyang kagamitan na kontrol, ang hard real-time na mode ay mahalaga.
Pinapabuti ng mga tumutugong system ang UX at nakikinabang sa negosyo.
Paunang buod
Kapag pinaplano ang artikulong ito, nais kong ibahagi ang aking karanasan sa paglikha ng isang broker ng pagmemensahe at pagbuo ng mga kumplikadong sistema batay dito. Ngunit ang teoretikal at motivational na bahagi ay naging medyo malawak.
Sa ikalawang bahagi ng artikulo, magsasalita ako tungkol sa mga nuances ng pagpapatupad ng mga exchange point, mga pattern ng pagmemensahe at ang kanilang aplikasyon.
Sa ikatlong bahagi isasaalang-alang namin ang mga pangkalahatang isyu ng pag-aayos ng mga serbisyo, pagruruta at pagbabalanse. Pag-usapan natin ang praktikal na bahagi ng scalability at fault tolerance ng mga system.
Katapusan ng unang bahagi.
Larawan .
Pinagmulan: www.habr.com