Hello, Habr. Ngayon ay nagpapatuloy ako ng isang serye ng mga publikasyon na partikular kong isinulat para sa pagsisimula ng isang bagong stream ng kurso. .
Pagpapakilala
Ang pagpili ng istilo ng arkitektura ay isa sa mga pangunahing teknikal na desisyon kapag nagtatayo ng isang sistema ng impormasyon. Sa seryeng ito ng mga artikulo, iminumungkahi kong pag-aralan ang pinakasikat na istilo ng arkitektura para sa pagbuo ng mga aplikasyon at sagutin ang tanong kung kailan kung aling istilo ng arkitektura ang pinakagusto. Sa proseso ng pagtatanghal, susubukan kong gumuhit ng isang lohikal na kadena na nagpapaliwanag sa pagbuo ng mga istilo ng arkitektura mula sa mga monolith hanggang sa mga microservice.
Noong nakaraang pagkakataon, napag-usapan natin ang tungkol sa iba't ibang uri ng mga monolith at ang paggamit ng mga bahagi upang buuin ang mga ito, parehong mga bahagi ng pagbuo at mga bahagi ng pag-deploy. Naiintindihan namin ang arkitektura na nakatuon sa serbisyo.
Ngayon ay tutukuyin natin sa wakas ang mga pangunahing katangian ng isang arkitektura ng microservice.
Relasyon ng mga arkitektura
Kinakailangang maunawaan na batay sa mga kahulugang ibinigay sa mga nakaraang artikulo, ang anumang serbisyo ay isang bahagi, ngunit hindi lahat ng serbisyo ay isang microservice.
Mga Katangian ng Microservice Architecture
Ang mga pangunahing katangian ng arkitektura ng microservice ay:
- Inayos ayon sa Mga Kakayahang Pangnegosyo
- Mga Produkto hindi Mga Proyekto
- Mga matalinong endpoint at piping tubo
- Desentralisadong Pamamahala
- Desentralisadong Pamamahala ng Data
- Infrastructure Automation
- Disenyo para sa kabiguan
- Arkitekturang may evolutionary development (Evolutionary Design)
Ang unang punto ay mula sa arkitektura na nakatuon sa serbisyo dahil ang mga microservice ay isang espesyal na kaso ng mga serbisyo. Ang iba pang mga punto ay nararapat na hiwalay na pagsasaalang-alang.
Inayos ayon sa Mga Kakayahang Pangnegosyo
Ngayon ay kailangang tandaan ang batas ng Conway: ang mga organisasyong lumikha ng mga sistema ay nag-aayos ng arkitektura nito, na kinokopya ang istruktura ng pakikipag-ugnayan sa loob ng mga organisasyong ito. Bilang halimbawa, maaalala natin ang kaso ng paglikha ng isang compiler: isang pangkat ng pitong tao ang bumuo ng isang seven-pass compiler, at isang team na may limang taong bumuo ng isang five-pass compiler.
Kung pinag-uusapan natin ang tungkol sa mga monolith at microservice, kung gayon kung ang pag-unlad ay isinaayos ng mga functional na departamento (backend, frontend, database administrator), makakakuha tayo ng isang klasikong monolith.
Upang makakuha ng mga microservice, ang mga koponan ay dapat na ayusin ayon sa kakayahan ng negosyo (mga order, pagpapadala, pangkat ng katalogo). Ang organisasyong ito ay magbibigay-daan sa mga team na tumuon sa pagbuo ng mga partikular na bahagi ng application.
Mga Produkto hindi Mga Proyekto
Ang isang diskarte sa proyekto kung saan inililipat ng isang team ang nabuong functionality sa ibang mga team ay ganap na hindi angkop sa kaso ng isang microservice architecture. Dapat suportahan ng team ang system sa buong ikot ng buhay nito. Ang Amazon, isa sa mga nangunguna sa pagpapatupad ng mga microservice, ay nagsabi: "nagtatayo ka, pinapatakbo mo ito." Ang diskarte sa produkto ay nagbibigay-daan sa koponan na madama ang mga pangangailangan ng negosyo.
Mga matalinong endpoint at piping tubo
Ang arkitektura ng SOA ay nagbigay ng malaking pansin sa mga channel ng komunikasyon, lalo na sa Enterprise Service Bus. Na kadalasang humahantong sa Maling Spaghetti Box, iyon ay, ang pagiging kumplikado ng monolith ay nagiging kumplikado ng mga koneksyon sa pagitan ng mga serbisyo. Ang arkitektura ng microservice ay gumagamit lamang ng mga simpleng paraan ng komunikasyon.
Desentralisadong Pamamahala
Ang mga pangunahing desisyon tungkol sa mga microservice ay dapat gawin ng mga taong aktwal na bumuo ng mga microservice. Dito, ang mga pangunahing desisyon ay nangangahulugan ng mga pagpipilian
programming language, deployment methodology, public interface contracts, atbp.
Desentralisadong Pamamahala ng Data
Ang karaniwang diskarte, kung saan ang application ay umaasa sa isang solong database, ay hindi maaaring isaalang-alang ang mga detalye ng bawat partikular na serbisyo. Kasama sa MSA ang desentralisadong pamamahala ng data, kabilang ang paggamit ng iba't ibang teknolohiya.
Infrastructure Automation
Sinusuportahan ng MSA ang tuluy-tuloy na pag-deploy at mga proseso ng paghahatid. Ito ay makakamit lamang sa pamamagitan ng pag-automate ng mga proseso. Kasabay nito, ang pag-deploy ng malaking bilang ng mga serbisyo ay hindi na mukhang nakakatakot. Ang proseso ng pag-deploy ay dapat maging boring. Ang pangalawang aspeto ay nauugnay sa pamamahala ng serbisyo sa isang kapaligiran ng produkto. Kung walang automation, nagiging imposible ang pamamahala sa mga prosesong tumatakbo sa iba't ibang operating environment.
Disenyo para sa kabiguan
Maraming mga serbisyo ng MSA ang madaling mabigo. Kasabay nito, ang paghawak ng error sa isang distributed system ay hindi isang maliit na gawain. Ang arkitektura ng application ay dapat na nababanat sa mga naturang pagkabigo. Iniisip ni Rebecca Parsons na napakahalaga na hindi na kami gumamit ng in-process na komunikasyon sa pagitan ng mga serbisyo; sa halip, gumagamit kami ng HTTP para sa komunikasyon, na halos hindi gaanong maaasahan.
Arkitekturang may evolutionary development (Evolutionary Design)
Ang arkitektura ng sistema ng MSA ay dapat na umunlad sa ebolusyon. Maipapayo na limitahan ang mga kinakailangang pagbabago sa mga hangganan ng isang solong serbisyo. Dapat ding isaalang-alang ang epekto sa ibang mga serbisyo. Ang tradisyunal na diskarte ay subukang lutasin ang problemang ito sa pag-bersyon, ngunit iminumungkahi ng MSA ang paggamit ng bersyon sa
bilang huling paraan.
Konklusyon
Matapos ang lahat ng nasa itaas, maaari nating bumalangkas kung ano ang mga microservice. Ang arkitektura ng microservice ay isang diskarte sa pagbuo ng isang application bilang isang koleksyon ng mga maliliit na serbisyo, bawat isa ay tumatakbo sa sarili nitong proseso at nakikipag-ugnayan sa pamamagitan ng magaan na mekanismo, kadalasan ay isang HTTP resource API. Ang mga serbisyong ito ay binuo sa mga kakayahan sa negosyo at maaaring i-deploy nang hiwalay gamit ang ganap
awtomatikong mekanismo ng pag-deploy. Mayroong isang minimum na antas ng sentralisadong pamamahala ng mga serbisyong ito, na maaaring isulat sa iba't ibang mga wika ng programming at gumamit ng iba't ibang mga teknolohiya sa pag-iimbak ng data.
Pinagmulan: www.habr.com