Moien, habr. Aschreiwung fir en neie Cours Stream ass elo op OTUS op . Um Virowend vum Start vum Cours wëll ech mäin originelle Artikel mat Iech deelen.
Aféierung
D'Wiel vum architektonesche Stil ass eng vun de fundamentalen techneschen Entscheedungen beim Bau vun engem Informatiounssystem. An dëser Serie vun Artikelen proposéieren ech déi populär architektonesch Stiler fir Bauapplikatiounen ze analyséieren an d'Fro ze beäntweren wéini wéi en architektonescht Stil am léifsten ass. Am Prozess vun der Presentatioun wäert ech probéieren eng logesch Kette ze zéien, déi d'Entwécklung vun architektonesche Stile vu Monolithen bis Mikroservicer erkläert.
E bësse vun der Geschicht
Wann Dir probéiert d'Entwéckler ze froen: "Firwat brauche mir Mikroservicer?", kritt Dir eng Vielfalt vun Äntwerten. Dir héiert datt Mikroservicer d'Skalierbarkeet verbesseren, de Code méi einfach ze verstoen maachen, d'Feeltoleranz verbesseren, an heiansdo héiert Dir datt se Iech erlaben "Äre Code ze botzen." Loosst eis d'Geschicht kucken fir den Zweck hannert der Entstoe vu Mikroservicer ze verstoen.
Kuerz gesot, Mikroservicer an eisem aktuellen Verständnis entstanen wéi follegt: 2011 huet den James Lewis, d'Aarbecht vu verschiddene Firmen analyséiert, op d'Entstoe vun engem neie "Micro-App" Muster opmierksam gemaach, wat d'SOA optimiséiert wat d'Beschleunegung vun der Deployment vun Servicer. E bësse méi spéit, am Joer 2012, op engem Architektur-Sommet, gouf d'Muster Microservice ëmbenannt. Also war den initialen Zil fir Mikroservicer aféieren ze verbesseren déi notoresch Zäit um Maart.
Mikroservicer waren op der Hype Welle am Joer 2015. Laut e puer Studien war keng eenzeg Konferenz komplett ouni Bericht iwwer d'Thema Mikroservicer. Ausserdeem waren e puer Konferenzen exklusiv fir Mikroservicer gewidmet. Hautdesdaags fänken vill Projeten un dësen architektonesche Stil ze benotzen, a wann de Projet Tonne Legacy Code enthält, da gëtt d'Migratioun op Mikroservicer méiglecherweis aktiv duerchgefouert.
Trotz all vun den uewe kann eng zimlech kleng Zuel vun Entwéckler nach d'Konzept vun "Mikroservice" definéieren. Mee mir schwätzen iwwer dëst e bësse méi spéit ...
Monolith
Den architektonesche Stil deen Mikroservicer kontrastéiert ass de Monolith (oder All-in-One). Et ass wahrscheinlech kee Sënn fir ze soen wat e Monolith ass, also wäert ech direkt d'Nodeeler vun dësem architektonesche Stil opzielen, deen d'Weiderentwécklung vun architektonesche Stiler initiéiert huet: Gréisst, Konnektivitéit, Détachement, Skalierbarkeet, Zouverlässegkeet a Steifheet. Drënner proposéieren ech all eenzel vun de Mängel separat ze kucken.
Gréisst
De Monolith ass ganz grouss. An et kommunizéiert normalerweis mat enger ganz grousser Datebank. D'Applikatioun gëtt ze grouss fir een Entwéckler iwwerhaapt ze verstoen. Nëmmen déi, déi vill Zäit op dësem Code geschafft hunn, kënne gutt mam Monolith schaffen, während Ufänger vill Zäit verbréngen fir de Monolith erauszefannen an et gëtt keng Garantie datt se et erausfannen. Normalerweis, wann Dir mat engem Monolith schafft, gëtt et ëmmer e "bedingte" Senior, deen de Monolith méi oder manner gutt kennt an d'Hänn vun aneren neien Entwéckler bannent engem Joer an en halleft schloe. Natierlech ass sou e bedingte Senior en eenzege Punkt vum Versoen, a säin Depart kann zum Doud vum Monolith féieren.
Verbindung
De Monolith ass e "grousse Ball vu Bulli", Ännerungen an deenen zu onberechenbaren Konsequenze féieren kann. Andeems Dir Ännerungen op enger Plaz maacht, kënnt Dir de Monolith an enger anerer beschiedegen (déi selwecht "Dir hutt Äert Ouer gekräizt, *@ gefall"). Dëst ass wéinst der Tatsaach, datt d'Komponente am Monolith ganz komplex an, am wichtegsten, net offensichtlech Bezéiungen hunn.
Deployment
Den Ofbau vun engem Monolith, wéinst de komplexe Bezéiungen tëscht senge Komponenten, ass e laange Prozess mat engem eegene Ritual. Esou e Ritual ass normalerweis net komplett standardiséiert a gëtt "mëndlech" weiderginn.
Skalierbarkeet
Monolith Moduler kënnen konfliktend Ressourcebedürfnisser hunn, a verlaangen datt e Kompromëss a Saache Hardware gemaach gëtt. Stellt Iech vir, datt Dir e Monolith besteet aus Servicer A a B. Service A exigent op der Gréisst vun der Festplack, an Service B exigent op RAM. An dësem Fall muss entweder d'Maschinn op där de Monolith installéiert ass d'Ufuerderunge vu béide Servicer ënnerstëtzen, oder Dir musst ee vun de Servicer manuell kënschtlech deaktivéieren.
En anert Beispill (méi klassesch): Service A ass vill méi populär wéi Service B, sou datt Dir wëllt datt et 100 Servicer A sinn, an 10 Servicer B. Nach eng Kéier zwou Méiglechkeeten: entweder mir setzen 100 vollwäerteg Monolithen aus, oder op e puer dann Servicer B musse manuell ausgeschalt ginn.
Zuverlässegkeet
Well all Servicer zesumme sinn, wann de Monolith fällt, da falen all Servicer op eemol. Tatsächlech ass dëst vläicht net sou schlecht, op d'mannst gëtt et keng deelweis Feeler an engem verdeelte System, awer op der anerer Säit, wéinst engem Feeler an der Funktionalitéit, déi vun 0.001% vun de Benotzer benotzt gëtt, kënnt Dir all d'Benotzer verléieren vun Ärem System.
Inertie
Wéinst der Gréisst vum Monolith ass et schwéier op nei Technologien ze wiesselen. Als Resultat schéngt dee ganz bedingte Senior ze behalen eng separat Aufgab ze sinn. Den Technologiestack, deen am Ufank vun engem Projet gewielt gëtt, kann e Block ginn, deen d'Entwécklung vum Produkt behënnert.
Konklusioun
D'nächst Kéier schwätze mer iwwer wéi d'Leit probéiert hunn dës Probleemer ze léisen andeems se op Komponenten an SOA plënneren.
Liest méi:
Source: will.com