Микроуслуги: што се тие, зошто се и кога да се имплементираат

Долго време сакав да напишам статија на тема микросервис архитектура, но две работи постојано ме спречуваа - колку повеќе се впуштав во темата, толку повеќе ми се чинеше дека она што го знам е очигледно, а што не. да знаеш треба да се изучува и изучува. Од друга страна, мислам дека веќе има за што да се разговара меѓу широката публика. Така што алтернативните мислења се добредојдени.

Законот на Конвеј и односот помеѓу бизнисот, организацијата и информацискиот систем

Уште еднаш ќе си дозволам да цитирам:

„Секоја организација што дизајнира систем (во широка смисла) ќе добие дизајн чија структура ја повторува структурата на тимовите во таа организација.
- Мелвин Конвеј, 1967 година

Според мене, овој закон е поверојатно да се однесува на изводливоста на организирање бизнис, наместо директно на информацискиот систем. Да објаснам со пример. Да речеме дека имаме прилично стабилна деловна можност со толкав животен циклус што има смисла да се организира претпријатие (ова не е печатна грешка, но навистина ми се допаѓа овој термин што го украдов). Нормално, системот за поддршка на овој бизнис организациски и процесно ќе одговараат на овој бизнис .

Деловна ориентација на информациски системи

Да објаснам со пример. Да речеме дека постои деловна можност да се организира бизнис со продажба на пица. Во верзијата V1 (да ја наречеме прединформација), компанијата беше пицерија, каса и услуга за достава. Оваа верзија беше долготрајна во услови на мала варијабилност на животната средина. Потоа дојде да го замени верзијата 2 - понапредна и способна да користи информациски систем во неговото јадро за бизнис со монолитна архитектура. И тука, според мене, едноставно има страшна неправда во однос на монолитните - наводно монолитна архитектура не одговара на бизнис моделот на доменот. Да, да беше така, системот воопшто немаше да може да работи - во спротивност со истиот закон на Конвеј и здравиот разум. Не. Апсолутно е прекрасен факт дека без оглед на архитектонскиот пристап, и сервисно-ориентираната архитектура верзија 3 и микросервисната архитектура верзија N ќе работат подеднакво добро. Што е финтата?

Сè тече, сè се менува или дали микросервисите се средство за борба против сложеноста?

Пред да продолжиме, ајде да погледнеме неколку заблуди за микросервисната архитектура.

Поддржувачите на користење на микросервис пристап често тврдат дека разбивањето на монолит во микросервис го поедноставува развојниот пристап со намалување на базата на кодови на поединечни услуги. Според мене, оваа изјава е целосна глупост. Сериозно, очигледната интеракција во рамките на монолитен и хомоген код се чини комплицирана? Да беше навистина така, сите проекти првично ќе се градеа како микросервис, додека практиката покажува дека миграцијата од монолит кон микросервис е многу почеста. Комплексноста не исчезнува; таа едноставно се движи од поединечни модули до интерфејси (било да се тоа магистрали за податоци, RPC, API и други протоколи) и системи за оркестрирање. И ова е тешко!

Предноста на користење на хетероген оџак е исто така сомнителна. Нема да тврдам дека тоа е исто така можно, но во реалноста тоа ретко се случува (Гледајќи напред - ова треба да се случи - туку повеќе како последица отколку како предност).

Животниот циклус на производот и работниот век

Погледнете уште еднаш на дијаграмот погоре. Не случајно го забележав намалениот животен циклус на посебна верзија на бизнис - во современи услови, забрзувањето на транзицијата на бизнисот помеѓу верзии е одлучувачко за неговиот успех. Успехот на производот се одредува со брзината на тестирање на деловните хипотези во него. И тука, според мене, лежи клучната предност на микросервисната архитектура. Но, да одиме по ред.

Ајде да преминеме на следната фаза во еволуцијата на информациските системи - до сервисно ориентирана архитектура на SOA. Така, во одреден момент истакнавме во нашиот производ долговечни услуги - долговечен во смисла дека при движење помеѓу верзии на производ, постои шанса животниот циклус на услугата да биде подолг од животниот циклус на следната верзија на производот. Би било логично да не ги менуваме воопшто - ние Она што е важно е брзината на транзиција кон следната верзија. Но, за жал, ние сме принудени да правиме постојани промени во услугите - и тука сè работи за нас, практиките на DevOps, контејнеризацијата и така натаму - сè што ќе ви падне на ум. Но, ова сè уште не се микроуслуги!

Микросервисите како средство за борба против сложеноста... управување со конфигурации

И тука конечно можеме да преминеме на дефинирачката улога на микросервисите - ова е пристап кој го поедноставува управувањето со конфигурацијата на производите. Подетално, функцијата на секој микросервис точно ја опишува деловната функција внатре во производот според моделот на доменот - а тоа се работи кои живеат не во краткотрајна верзија, туку во долготрајна деловна можност. И преминот кон следната верзија на производот се случува буквално незабележано - менувате/додавате еден микросервис, а можеби и само шемата на нивната интеракција, и одеднаш ќе се најдете во иднината, оставајќи ги зад себе расплаканите конкуренти кои продолжуваат да скокаат помеѓу верзиите на нивните монолити. Сега замислете дека има прилично голем обем на микросервиси со претходно дефинирани интерфејси и деловни способности. А вие доаѓате и ја градите структурата на вашиот производ од готови микросервиси - едноставно со цртање дијаграм, на пример. Честитки - имате платформа - и сега можете да привлечете бизнис за себе. Соништа Соништа.

Наоди

• Архитектурата на системот треба да се определи според животниот циклус на неговите компоненти. Ако некоја компонента живее во верзија на производ, нема смисла да се зголеми сложеноста на системот со користење на микросервис пристап.
• Архитектурата на микросервис треба да се заснова на моделот на доменот - затоа што бизнис-можноста е најдолготрајниот домен
• Практиките за испорака (практики на DevOps) и оркестрацијата се едни од најважните за микросервисната архитектура - од причина што зголемувањето на стапката на промена на компонентите поставува зголемени барања за брзината и квалитетот на испораката

Извор: www.habr.com