Wiel vun engem architektonesche Stil (Deel 2)

Moien, Habr. Haut ginn ech eng Serie vu Publikatiounen weider, déi ech speziell fir de Start vun engem neie Stream vum Cours geschriwwen hunn. "Software Architekt".

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.

В d'lescht Kéier mir hunn de Monolith beschäftegt an sinn zur Conclusioun komm datt de Monolith eng Rei Probleemer huet: Gréisst, Konnektivitéit, Deployment, Skalierbarkeet, Zouverlässegkeet a Steifheet.

Dës Kéier proposéieren ech iwwer d'Méiglechkeeten ze schwätzen fir e System als Set vu Moduler / Bibliothéiken (komponentorientéiert Architektur) oder Servicer (serviceorientéiert Architektur) ze organiséieren.

Komponent-orientéiert Architektur

Komponentorientéiert Architektur involvéiert d'Ausféierung vun engem System als Set vu Komponenten déi a béid aktuellen an zukünfteg Projete kënne benotzt ginn. Wann Dir e System an Komponenten ofbriechen, ginn déi folgend berücksichtegt: hir Wiederverwendbarkeet, hir Ersatzbarkeet, Kontextonofhängegkeet, Extensibilitéit, Encapsulation an Onofhängegkeet.

Mat der korrekter Notzung vu Komponenten gëtt de Problem vum "grousse Kugel vum Dreck" (grouss Gréisst + Héichkupplung) geléist, an d'Komponente selwer kënne souwuel Montage-Eenheeten (Moduler, Bibliothéiken) an Deployment-Eenheeten (Servicer) sinn. Deployment Unitéiten sinn net ëmmer op de lafende Prozess mapéiert: Zum Beispill, eng Webapplikatioun an eng Datebank ginn zesummen ofgesat.

Déi meescht Oft sinn Monolithen als Set vu Moduler entwéckelt. Dës Approche féiert zu enger onofhängeger Entwécklung, awer d'Problemer vun der onofhängeger Skaléieren an Deployment, Feeler Toleranz an Onofhängegkeet vum Gesamttechnologie Stack bleiwen. Dofir ass de Modul en deelweis onofhängege Bestanddeel.

De gréisste Problem mat esou engem Monolith ass, datt d'Divisioun an Moduler reng logesch ass a kann einfach vun Entwéckler verletzt ginn. E Kärmodul kann optrieden, dee sech no an no an en Dreckstipp verwandelt, d'Grafik vun Ofhängegkeeten tëscht Moduler ka wuessen, asw. Fir esou Probleemer ze vermeiden, soll d'Entwécklung entweder vun engem ganz reife Team duerchgefouert ginn, oder ënner der Leedung vun engem "Architekt", deen an der Vollzäitcode-Iwwerpréiwung engagéiert ass an d'Hänn vun Entwéckler schloen, déi d'logesch Struktur verletzen.

Den "ideale" Monolith ass eng Rei vu logesch getrennte Moduler, déi jidderee an seng eege Datebank kuckt.

Service-orientéiert Architektur

Wann de System soll a Form vun enger Rei vu Servicer organiséiert ginn, da schwätze mer vun enger serviceorientéierter Architektur. Seng Prinzipien sinn user-centric Applikatioun Interoperabilitéit, Business Service Wiederverbrauch, Technologie Stack Onofhängegkeet, an Autonomie (onofhängeg Evolutioun, Skalierbarkeet, an Deployment).

Service-orientéiert Architektur (SOA = Service orientéiert Architektur) léist all identifizéiert Problemer vun engem Monolith: wann eng Ännerung geschitt, nëmmen ee Service betraff, an eng gutt definéiert API ënnerstëtzt gutt Encapsulation vun Komponente.

Awer net alles ass sou glat: SOA schaaft nei Probleemer. Remote Calls si méi deier wéi lokal, an d'Verdeelung vu Verantwortung tëscht Komponenten ass wesentlech méi deier ginn.

Iwwregens, ass d'Méiglechkeet vun onofhängeg Détachement eng ganz wichteg Fonktioun vum Service. Wann Servicer mussen zesummen agesat ginn, oder ausserdeem, an enger bestëmmter Reihenfolge, da kann de System net als serviceorientéiert ugesi ginn. An dësem Fall schwätze se iwwer e verdeelt Monolith (als Anti-Muster ugesi net nëmmen aus der SOA Siicht, awer och aus der Siicht vun der Microservice Architektur).

Service-orientéiert Architektur gëtt gutt ënnerstëtzt vun der architektonescher Gemeinschaft a Verkeefer. Dëst implizéiert d'Präsenz vu ville Coursen an Zertifizéierungen, gutt entwéckelt Musteren. Déi lescht beinhalt zum Beispill de bekannte Enterprise Service Bus (ESB = Enterprise Service Bus). Zur selwechter Zäit ass ESB e Gepäck vu Verkeefer, et muss net onbedéngt an SOA benotzt ginn.

D'Popularitéit vun der serviceorientéierter Architektur huet sech ëm 2008 als Héichpunkt erreecht, duerno huet se ugefaang ze falen, wat däitlech méi dramatesch gouf nom Advent vu Mikroservicer (~ 2015).

Konklusioun

Nodeems mir d'Méiglechkeeten diskutéiert hunn fir Informatiounssystemer a Form vu Servicer a Moduler z'organiséieren, proposéieren ech endlech op d'Prinzipien vun der Mikroservicearchitektur ze goen a besonnesch op den Ënnerscheed tëscht Mikroservicearchitektur a Serviceorientéierter Architektur am nächsten Deel opmierksam ze maachen.

Wiel vun engem architektonesche Stil (Deel 2)

Source: will.com

Setzt e Commentaire