Ech wollt fir eng laang Zäit en Artikel iwwer d'Thema vun der Mikroservicearchitektur schreiwen, awer zwou Saachen hunn mech ëmmer gestoppt - wat ech méi wäit an d'Thema gefall sinn, wat et mir méi schénge wéi wann dat wat ech weess evident ass, a wat ech maachen' t wëssen muss studéiert a studéiert ginn. Op der anerer Säit, mengen ech, gëtt et schonn eppes ënner engem breede Publikum ze diskutéieren. Also alternativ Meenungen si wëllkomm.
Conway's Law an d'Relatioun tëscht Geschäft, Organisatioun an Informatiounssystem
Ech erlaben mech nach eng Kéier ze zitéieren:
"All Organisatioun déi e System designt (am breede Sënn) kritt en Design deem seng Struktur d'Struktur vun den Teams an där Organisatioun replizéiert."
- Melvyn Conway, 1967
Menger Meenung no ass dëst Gesetz méi wahrscheinlech mat der Machbarkeet vun der Organisatioun vun engem Geschäft ze bezéien, anstatt direkt mam Informatiounssystem. Loosst mech mat engem Beispill erklären. Loosst eis soen datt mir eng zimlech stabil Geschäftsméiglechkeet hunn mat engem Liewenszyklus vu sou enger Längt datt et Sënn mécht eng Entreprise ze organiséieren (dëst ass keen Tippfeeler, awer ech hunn dëse Begrëff wierklech gär, deen ech geklaut hunn). Natierlech ass de Supportsystem vun dësem Geschäft. wäert organisatoresch a processuell zu dësem Geschäft entspriechen.
Geschäftsorientéierung vun Informatiounssystemer
Loosst mech mat engem Beispill erklären. Loosst eis soen datt et eng Geschäftsméiglechkeet ass fir e Geschäft ze organiséieren deen Pizza verkeeft. An der V1 Versioun (loosst eis et Pre-Informatioun nennen), war d'Firma eng Pizzeria, e Keesseberäich an e Liwwerservice. Dës Versioun war laang gelieft a Konditioune vu gerénger Ëmweltverännerlechkeet. Dunn ass d'Versioun 2 komm fir se ze ersetzen - méi fortgeschratt a fäeg en Informatiounssystem am Kär fir Geschäfter mat enger monolithescher Architektur ze benotzen. An hei gëtt et menger Meenung no einfach eng schrecklech Ongerechtegkeet par rapport zu de Monolithen - angeblech monolithesch Architektur entsprécht net dem Domaingeschäftsmodell. Jo, wann dat esou wier, géif de System iwwerhaapt net funktionnéieren - am Widdersproch mam selwechte Conway sengem Gesetz an dem gesonde Mënscheverstand. Neen, monolithesch Architektur ass voll konsequent mam Geschäftsmodell an dëser Etapp vun der Geschäftsentwécklung - ech mengen natierlech d'Bühn wou de System scho geschaf an a Betrib geholl gouf. Et ass eng absolut wonnerbar Tatsaach datt onofhängeg vun der architektonescher Approche souwuel déi serviceorientéiert Architektur Versioun 3 an d'Mikroservicer Architektur Versioun N gläich gutt funktionnéieren. Wat ass de Fang?
Alles fléisst, alles ännert sech, oder sinn Mikroservicer e Mëttel fir d'Komplexitéit ze bekämpfen?
Ier mer weidergoen, loosst eis e puer Mëssverständnisser iwwer Mikroservicearchitektur kucken.
Proponenten fir eng Mikroservice Approche ze benotzen argumentéieren dacks datt e Monolith a Mikroservicer briechen d'Entwécklungs Approche vereinfacht andeems d'Codebasis vun eenzelne Servicer reduzéiert gëtt. Menger Meenung no ass dës Ausso komplett Nonsens. Eescht, déi offensichtlech Interaktioun bannent engem Monolith an homogene Code schéngt komplizéiert? Wann dat wierklech de Fall wier, géifen all Projeten am Ufank als Mikroservicer gebaut ginn, während d'Praxis weist datt d'Migratioun vun engem Monolith op Mikroservicer vill méi heefeg ass. Komplexitéit verschwënnt net; et bewegt sech einfach vun eenzelne Moduler op Interfaces (sief et Datebussen, RPC, APIen an aner Protokoller) an Orchestratiounssystemer. An dëst ass schwéier!
De Virdeel fir en heterogene Stack ze benotzen ass och a Fro. Ech wäert net streiden datt dëst och méiglech ass, awer a Wierklechkeet geschitt et seelen (virauskucken - dat soll geschéien - awer éischter als Konsequenz wéi e Virdeel).
Produkt Liewenszyklus a Service Liewenszyklus
Huelt en anere Bléck op d'Diagramm uewen. Et ass keen Zoufall datt ech den erofgaangende Liewenszyklus vun enger separater Versioun vun engem Geschäft bemierkt hunn - a modernen Konditiounen ass et d'Beschleunigung vum Transitioun vun engem Geschäft tëscht Versiounen entscheedend fir säin Erfolleg. Den Erfolleg vun engem Produkt gëtt bestëmmt duerch d'Geschwindegkeet fir d'Geschäftshypothesen ze testen. An hei, menger Meenung no, läit de Schlësselvirdeel vun der Mikroservicearchitektur. Awer loosst eis an Uerdnung goen.
Loosst eis op déi nächst Etapp an der Evolutioun vun Informatiounssystemer goen - op d'Serviceorientéiert Architektur vu SOA. Also, zu engem gewësse Punkt hu mir an eisem Produkt beliicht laang-gelieft Servicer - laang gelieft am Sënn datt wann Dir tëscht Versioune vun engem Produkt bewegt, et eng Chance ass datt de Liewenszyklus vum Service méi laang ass wéi de Liewenszyklus vun der nächster Versioun vum Produkt. Et wier logesch, se guer net ze änneren - mir Wat wichteg ass, ass d'Vitesse vum Iwwergang op déi nächst Versioun. Awer leider, mir si gezwongen konstant Ännerunge fir Servicer ze maachen - an hei funktionnéiert alles fir eis, DevOps Praktiken, Containeriséierung, an sou weider - alles wat an de Kapp kënnt. Awer dëst sinn nach ëmmer keng Mikroservicer!
Mikroservicer als Mëttel fir Komplexitéit ze bekämpfen ... Konfiguratiounsmanagement
An hei kënne mir endlech op d'definéierend Roll vu Mikroservicer weidergoen - dëst ass eng Approche déi d'Produktkonfiguratiounsmanagement vereinfacht. Méi detailléiert beschreift d'Funktioun vun all Mikroservice genee d'Geschäftsfunktioun am Produkt no dem Domainmodell - an dat sinn Saachen déi net an enger kuerzlieweger Versioun liewen, mee an enger laanglieweger Geschäftsméiglechkeet. An den Iwwergank op déi nächst Versioun vum Produkt geschitt wuertwiertlech onnotéiert - Dir ännert / füügt ee Mikrodéngscht un, a vläicht just de Schema vun hirer Interaktioun, an op eemol fannt Dir Iech an Zukunft, hannerloosst kräizend Konkurrenten, déi weider tëscht Versioune sprangen hir Monolithen. Stellt Iech elo vir datt et e relativ grousse Volume vu Mikroservicer mat virdefinéierten Interfaces a Geschäftsfäegkeeten ass. An Dir kommt a baut d'Struktur vun Ärem Produkt aus fäerdege Mikroservicer - einfach andeems Dir en Diagramm zeechnen, zum Beispill. Gratulatioun - Dir hutt eng Plattform - an elo kënnt Dir Geschäfter fir Iech selwer unzezéien. Dreem Dreem.
Conclusiounen
- D'Architektur vum System soll vum Liewenszyklus vu senge Komponenten bestëmmt ginn. Wann e Komponent an enger Produktversioun lieft, ass et kee Sënn fir d'Komplexitéit vum System ze erhéijen andeems Dir eng Mikroservice Approche benotzt.
- D'Mikroservicearchitektur soll um Domainmodell baséieren - well d'Geschäftsméiglechkeet déi längst gelieft Domain ass
- Liwwerpraktiken (DevOps Praktiken) an Orchestratioun sinn eng vun de wichtegsten fir Mikroservicearchitektur - aus dem Grond datt d'Erhéijung vun der Taux vun der Ännerung vun de Komponenten erhéicht Fuerderungen un d'Geschwindegkeet an d'Qualitéit vun der Liwwerung stellt
Source: will.com