{"id":31761,"date":"2019-10-31T21:42:55","date_gmt":"2019-10-31T18:42:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes\/"},"modified":"2019-10-31T21:42:55","modified_gmt":"2019-10-31T18:42:55","slug":"mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes","title":{"rendered":"Mikrotjenester: St\u00f8rrelse betyder noget, selvom du har Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

19. september i Moskva tog sted<\/a><\/noindex> den f\u00f8rste temam\u00f8de HUG (Highload++ User Group), der var dedikeret til mikrotjenester. Der blev pr\u00e6senteret et foredrag med titlen \u00abDrift af mikrotjenester: st\u00f8rrelse betyder noget, selvom du har Kubernetes\u00bb, hvor vi delte omfattende erfaringer fra virksomheden \u00abFlant\u00bb inden for drift af projekter med en mikrotjeneste-arkitektur. Det vil prim\u00e6rt v\u00e6re nyttigt for alle udviklere, der overvejer at anvende denne tilgang i deres nuv\u00e6rende eller fremtidige projekt.<\/p>\n

\"Mikrotjenester:
\n
\nVi pr\u00e6senterer videoen med foredraget<\/b><\/a><\/noindex> (50 minutter, v\u00e6sentligt mere informativt end artiklen), samt en hovedopsummering i tekstform.<\/p>\n

NB: Video og pr\u00e6sentation er ogs\u00e5 tilg\u00e6ngelige i slutningen af denne publikation.<\/i><\/a><\/noindex><\/p>\n

Introduktion<\/h2>\n

\nSom regel har en god historie en opbygning, hovedplot og opl\u00f8sning. Dette foredrag minder mere om en tragisk opbygning. Det er ogs\u00e5 vigtigt at bem\u00e6rke, at det pr\u00e6senterer et syn p\u00e5 mikrotjenester fra siden af udnyttelse<\/i>.<\/p>\n

Lad mig begynde med en s\u00e5dan graf, hvis forfatter (i 2015) er blev<\/a><\/noindex> Martin Fowler:<\/p>\n

\"Mikrotjenester:
\n
\nGrafen viser, hvordan produktiviteten for en monolitisk applikation, der n\u00e5r en vis st\u00f8rrelse, begynder at falde. Mikrotjenester adskiller sig ved, at den oprindelige produktivitet med dem er lavere, men efterh\u00e5nden som kompleksiteten vokser, er degradationen af effektivitet ikke s\u00e5 m\u00e6rkbar.<\/p>\n

Jeg vil supplere denne graf for brug af Kubernetes:<\/p>\n

\"Mikrotjenester:
\n
\nHvorfor har applikationen med mikrotjenester f\u00e5et det bedre? Fordi en s\u00e5dan arkitektur stiller alvorlige krav til arkitekturen, som i mellemtiden bliver fremragende opfyldt af Kubernetes' muligheder. P\u00e5 den anden side vil noget af denne funktionalitet ogs\u00e5 v\u00e6re nyttig for monolitten, is\u00e6r fordi en typisk monolit i dag ikke rigtig er en ren monolit (detaljer f\u00f8lger i foredraget).<\/p>\n

Som det ses, adskiller den endelige graf (n\u00e5r b\u00e5de monolitiske og mikrotjenesteapplikationer k\u00f8res i en Kubernetes-infrastruktur) sig ikke meget fra den oprindelige. Herefter vil der blive talt om applikationer, der drives ved hj\u00e6lp af Kubernetes.<\/p>\n

Nyttig og skadelig mikrotjenestearkitektur<\/h2>\n

\nHer er den vigtigste tanke:<\/p>\n

\"Mikrotjenester:
\n
\nHvad er normal<\/b> mikrotjenestearkitektur? Den skal give dig reelle fordele ved at \u00f8ge arbejdseffektiviteten. Hvis vi vender tilbage til grafen, ser vi den her:<\/p>\n

\"Mikrotjenester:
\n
\nHvis vi kalder den nyttig<\/b>, vil der p\u00e5 den anden side af grafen v\u00e6re skadelig<\/b> mikrotjenestearkitektur (h\u00e6mmer arbejdet):<\/p>\n

\"Mikrotjenester:
\n
\nN\u00e5r vi vender tilbage til \"den centrale tanke\": Skal jeg overhovedet stole p\u00e5 min erfaring? Siden starten af dette \u00e5r har jeg set 85 projekter<\/b>. Ikke alle har v\u00e6ret mikrotjenester (omkring en tredjedel til halvdelen havde s\u00e5dan en arkitektur), men det er stadig et stort antal. Vi (firmaet \"Flant\") som outsourcere har mulighed for at se et bredt udvalg af applikationer, der udvikles b\u00e5de i sm\u00e5 virksomheder (med 5 udviklere) og i store (~500 udviklere). En ekstra fordel er, at vi ser, hvordan disse applikationer lever og udvikler sig over mange \u00e5r.<\/p>\n

Hvorfor mikrotjenester?<\/h2>\n

\nDer er et ret konkret svar<\/a><\/noindex> fra den n\u00e6vnte Martin Fowler:<\/p>\n

    \n
  1. klare gr\u00e6nser for modul\u00e6re deler;<\/li>\n
  2. uafh\u00e6ngig deployment;<\/li>\n
  3. frihed til at v\u00e6lge teknologier.<\/li>\n<\/ol>\n

    \nJeg har talt meget med arkitekter og softwareudviklere og spurgt, hvorfor de har brug for mikrotjenester. Og jeg har lavet min liste over deres forventninger. Her er, hvad jeg kom frem til:<\/p>\n

    \"Mikrotjenester:
    \n
    \nHvis jeg skal beskrive \"f\u00f8lelserne\" omkring nogle af punkterne, s\u00e5:<\/p>\n