Ang mga microservice ay isang paraan ng paghiwa-hiwalay ng isang malaking application sa maluwag na pinagsamang mga module na nakikipag-ugnayan sa isa't isa sa pamamagitan ng isang simpleng API.
Kamakailan lamang, ang mga mute lang ang hindi nagsasalita tungkol sa mga microservice. Ito ay nagiging mas at mas sikat. Ang modular na istilo ng arkitektura ay tila partikular na angkop sa mga cloud-based na kapaligiran at lumalaki sa katanyagan. Bago natin talakayin ang mga detalye, tingnan natin ang lahat ng bagay . Samakatuwid: Ang mga microservice ay isang paraan ng paghiwa-hiwalay ng isang malaking proyekto sa maliit, independyente at maluwag na pinagsamang mga module. Ang mga independyenteng module ay may pananagutan para sa malinaw na tinukoy at hiwalay na mga gawain at nakikipag-usap sa isa't isa sa pamamagitan ng simple at naa-access na API. Sa madaling salita, ang mga microservice ay simpleng ibang istilo ng arkitektura para sa pagdidisenyo ng kumplikado, karamihan sa mga web application. Ngunit ano ang masama sa umiiral na mga solusyon sa arkitektura tulad ng SOA (Service oriented architecture)? Karamihan sa mga modernong solusyon sa negosyo na isinulat gamit ang SOA ay tila gumagana nang maayos. Maaaring ito ang magandang panahon para pag-usapan ang ilan sa mga hamon na kinakaharap ng industriya ngayon... Magsimula tayo sa isang simpleng halimbawa. Sabihin nating kailangan kong magpatakbo ng isang klasikong application na nakasulat sa Java. Una kong bubuoin ang User Interface, pagkatapos ay ang business logic layer, na may ilang bahagi na makikipag-ugnayan sa UI, at sa wakas ang database layer, na magiging accessible sa persistent database. Ngayon ayon sa katotohanan na gusto kong patakbuhin ang application, gagawa ako ng WAR/EAR/JAR at i-mount ito sa isang server (tulad ng JBoss, Tomcat o WebLogic). Dahil ito ay tapos na lahat sa isa, nakakakuha ako ng monolitikong aplikasyon, na nangangahulugan na ang lahat ng mga bahagi ay nasa isang lugar... Halimbawa sa larawan:
Malamang, pamilyar ka na sa diskarteng ito at nagamit mo na ito, ngunit ang ideya ay gamitin ang halimbawang ito upang ipakita kung anong mga hamon ang kailangang harapin ng mga developer gamit ang solusyong arkitektura na ito. Monolithic application: humahamon sa mga hamon
Habang lumalaki ang application, lumalaki din ang dami ng nakasulat na code, na maaaring mag-overload sa development environment sa tuwing kailangan mong buksan ito. Tiyak na binabawasan nito ang kahusayan ng developer.
Dahil ang lahat ay kailangang i-mount sa isang lugar, ito ay humahantong sa katotohanan na ang paglipat sa ibang programming language o paglipat sa iba pang mga teknolohiya ay isang malaking problema. Halimbawa, nagsulat ka ng isang application sa Java, at pagkaraan ng ilang sandali ay lumabas si Kotlin at sabik kang muling isulat dito, dahil na- promote ito bilang mas cool, mas mahusay, mas mabilis. Sa isang monolitikong aplikasyon, kahit na ang pag-iisip tungkol sa refactoring ay magdudulot ng tunay na sakit, hindi sa banggitin ang proseso mismo. Sa kasalukuyan ay maraming mga application na ginawa sa ganitong paraan at ang bilang ng mga linya ng code ay hindi kapani-paniwala.
Kung ang alinman sa mga bahagi ay hihinto sa paggana para sa anumang kadahilanan , ang buong application ay mag-crash din. Isipin mo na lang na may web application na may mga module tulad ng authorization, payment, history, etc. At sa ilang kadahilanan nasira ang isa sa kanila. Ito ay simpleng pagkabigla para sa negosyo at, bilang resulta, para sa mga developer.
Ang pag-scale ng isang monolitikong aplikasyon ay maaari lamang makamit sa pamamagitan ng pagtataas ng isa pang aplikasyon ng parehong uri. Ngunit paano kung kailangan mo lamang sukatin ang isang bahagi, at hindi ang buong aplikasyon. Ilang resources ang masasayang?...
Maaari itong magkaroon ng malaking epekto sa proseso ng pag-develop at proseso ng pag-install ng application. Kung mas malaki ang application, mas mahalaga na maaaring hatiin ng mga developer ang application sa mas maliliit na bahaging gumagana. Dahil ang lahat ng mga module sa isang monolitikong aplikasyon ay konektado sa isa't isa, ang mga developer ay hindi maaaring gumana/i-mount ang mga module na ito nang hiwalay sa isa't isa. Dahil umaasa ang mga developer sa isa't isa, tumataas ang oras ng pag-develop.
Kasabay nito, handa kaming isaalang-alang at unawain ang kahulugan ng mga microservice, lalo na kung paano magagamit ang mga ito upang maibalik ang flexibility na nawala sa istilong SOA. God Microservices to the rescue Isa sa pinakamahalagang katangian sa anumang solusyon sa arkitektura ay ang scalability. Habang nag-aaral ako ng mga microservice sa unang pagkakataon, nakita ko na ang lahat ay katulad ng mga panipi mula sa aklat na "The Art of Scalability". Ito ay isang magandang simula at lugar para sa talakayan. Tinutukoy ng aklat na ito ang tinatawag na "Scalability Cube" na modelo, na naglalarawan sa isang three-dimensional na scalability system:
Gaya ng nakikita mo, inilalarawan ng X axis ang "horizontal scaling" (na nakita namin ay available din para sa mga monolitikong arkitektura), ang Y axis ay kumakatawan sa scaling sa kahulugan ng paghihiwalay ng iba't ibang bahagi ng serbisyo . Ang ideya ng Z axis ay nauunawaan kapag ang data ay hinati at ang application ay nagpapadala ng mga kahilingan sa eksaktong kung saan matatagpuan ang data. Ibig sabihin, hindi sila lahat sa isang lugar. Ang ideya ng Y axis ay ang tututukan natin nang mas detalyado. Ang axis na ito ay kumakatawan sa isang functional decomposition . Sa diskarteng ito, maaaring ituring ang iba't ibang mga function bilang mga independiyenteng serbisyo. Samakatuwid, sa pamamagitan lamang ng pag-mount sa buong application kapag tapos na ang lahat, maaaring i-mount ng mga developer ang mga indibidwal na serbisyo nang hiwalay sa isa't isa at hindi maghintay para matapos ang iba sa paggawa sa kanilang mga module. Hindi lamang nito mapapabuti ang oras ng pag-unlad, ngunit nag-aalok din ng kakayahang umangkop upang magbago at mag-rewire nang hindi na kailangang mag-alala tungkol sa iba pang bahagi ng application. Ihambing natin ang diagram na ito sa nakaraang monolitikong isa:
Mga Microservice: Mga Benepisyo Ang mga benepisyo ng mga microservice ay tila sapat na upang kumbinsihin ang mga developer ng enterprise tulad ng Amazon, Netflix, Ebay na simulan ang paggamit ng diskarteng ito. Hindi tulad ng mga monolitikong aplikasyon sa arkitektura, ang mga microservice ay:
Pinapabuti ang pag-iisa ng component failure: Ang malalaking application ay maaaring patuloy na gumana nang mahusay kahit na nabigo ang isang module.
Tinatanggal ang pangako ng application sa isang stack ng teknolohiya: kung gusto mong sumubok ng bagong stack ng teknolohiya sa ilang serbisyo, magpatuloy. Magiging mas magaan ang mga dependency kaysa sa isang monolitik, at mas madali ring ibalik ang lahat. Ang mas kaunting code sa isang application, mas madali itong gumana.
Ginagawang mas madali para sa mga bagong empleyado na maunawaan ang functionality ng serbisyo.
Mga Microservice: mga tampok ng pag-mount at virtualization Ngayon naiintindihan na namin kung ano ang mga microservice. At ang pinakamalaking kalamangan ay na ito ay naka-mount sa pamamagitan ng higit sa isang WAR/EAR/JAR archive. Ngunit paano ito naka-install? Ang pinakamahusay na paraan upang i-mount ang mga microservice sa loob ng mga container. Ang container ay isang ganap na naka-configure na virtual operating system na may kinakailangang environment na naka-configure, na tumutulong na ihiwalay ang access sa mga mapagkukunan ng hardware system kung saan naka-install ang container. Ang pinakatanyag na solusyon sa merkado ay siyempre Docker . Ang mga virtual machine mula sa IaaS (imprastraktura bilang isang serbisyo) tulad ng AWS ay maaari ding gumana nang maayos para sa pag-mount ng mga microservice, ngunit ang medyo magaan na microservice ay maaaring hindi gumamit ng lahat ng mga mapagkukunan na nasa virtual machine, na maaaring mabawasan ang kakayahang kumita ng paggamit. Maaari mo ring i-mount ang iyong mga microservice gamit ang OSGI (Open Service Gateway Initiative) package. Sa kasong ito, ang lahat ng mga microservice ay tatakbo sa isang JVM, ngunit ito ay nagsasangkot ng mga isyu sa trade-off sa pagitan ng kontrol at paghihiwalay. Mga Microservice: Mga Disadvantage Dahil lang sa "ang lahat ng ito ay cool" at "hindi pa namin nakita ito dati" ay hindi nangangahulugan na walang mga disadvantages. Nasa ibaba ang isang listahan ng mga posibleng lugar ng sakit na dala ng arkitektura ng microservice:
Maaaring maging mahirap ang pagbuo ng mga distributed system. Ang ibig kong sabihin ay ang lahat ng mga bahagi ay mga independiyenteng serbisyo na ngayon - kailangan mong maingat na pangasiwaan ang mga kahilingang dumadaan sa pagitan ng mga module. Maaaring mayroong isang sitwasyon kung saan ang isang module ay hindi tumutugon, na pumipilit sa iyong magsulat ng karagdagang code upang maiwasan ang pag-crash ng system. Maaari itong maging mas mahirap kung ang mga malayuang tawag ay sensitibo sa latency .
Ang maramihang mga database at pamamahala ng transaksyon ay maaaring maging isang tunay na sakit.
Ang pagsubok sa mga aplikasyon ng microservice ay maaaring maging mahirap. Gamit ang isang monolithic application, kailangan lang nating patakbuhin ang WAR/EAR/JAR archive sa server at tiyaking nakakonekta ito sa database. At sa mga microservice, dapat magsimula ang bawat indibidwal na serbisyo bago magsimula ang pagsubok.
Ang pag-mount ng mga application ay maaaring nakakalito. Maaaring mangailangan sila ng koordinasyon sa maraming serbisyo na maaaring hindi kasing daling i-mount gaya ng lalagyan ng WAR.
.... Siyempre, sa tamang mga tool at diskarte ay maiiwasan ang mga kawalan na ito. Ngunit sila mismo ay nangangailangan ng suporta at hindi ganap na malulutas ang lahat ng mga problema. Ang artikulo ay isinalin mula sa website ng CloudAcademy . Libreng pagsasalin. Malaya ang lahat na ipahayag ang lahat ng kanilang mga saloobin sa mga komento. Siguradong babasahin sila. Orihinal na artikulo Aking Github account
GO TO FULL VERSION