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

Отдавна исках да напиша статия по темата за архитектурата на микросервизите, но две неща ме спираха - колкото повече навлизах в темата, толкова повече ми се струваше, че това, което знам, е очевидно, а това, което не знам t know трябва да се изучава и изучава. От друга страна, смятам, че вече има какво да се обсъжда сред широка аудитория. Така че алтернативните мнения са добре дошли.

Законът на Конуей и връзката между бизнес, организация и информационна система

За пореден път ще си позволя да цитирам:

„Всяка организация, която проектира система (в широк смисъл), ще получи дизайн, чиято структура възпроизвежда структурата на екипите в тази организация.“
- Мелвин Конуей, 1967 г

Според мен този закон е по-вероятно да се отнася до възможността за организиране на бизнес, отколкото директно до информационната система. Нека обясня с пример. Да кажем, че имаме доста стабилна бизнес възможност с жизнен цикъл с такава дължина, че има смисъл да организираме предприятие (това не е печатна грешка, но наистина харесвам този термин, който откраднах). Естествено, поддържащата система на този бизнес ще съответства организационно и процесно на този бизнес.

Бизнес ориентация на информационните системи

Нека обясня с пример. Да кажем, че има бизнес възможност за организиране на бизнес за продажба на пица. Във версията V1 (да я наречем предварителна информация) компанията беше пицария, каса и услуга за доставка. Тази версия беше дълготрайна в условия на ниска променливост на околната среда. След това версия 2 дойде да го замени - по-усъвършенствана и способна да използва информационна система в основата си за бизнес с монолитна архитектура. И тук, според мен, има просто ужасна несправедливост по отношение на монолитите - твърди се, че монолитната архитектура не съответства на бизнес модела на домейна. Да, ако това беше така, системата изобщо нямаше да работи - в противоречие със същия закон на Конуей и здравия разум. Не, монолитната архитектура е напълно съобразена с бизнес модела на този етап от развитието на бизнеса - разбира се, имам предвид етапа, когато системата вече е създадена и пусната в експлоатация. Абсолютно прекрасен факт е, че независимо от архитектурния подход, както сервизно-ориентираната архитектура версия 3, така и микросервизната архитектура версия N ще работят еднакво добре. Каква е уловката?

Всичко тече, всичко се променя или микроуслугите са средство за борба със сложността?

Преди да продължим, нека разгледаме някои погрешни схващания относно архитектурата на микросервизите.

Поддръжниците на използването на подход на микроуслуги често твърдят, че разбиването на монолит на микроуслуги опростява подхода за разработка чрез намаляване на кодовата база на отделните услуги. Според мен това твърдение е пълна глупост. Сериозно, очевидното взаимодействие в монолитен и хомогенен код изглежда сложно? Ако това наистина беше така, всички проекти първоначално щяха да бъдат изградени като микроуслуги, докато практиката показва, че миграцията от монолит към микроуслуги е много по-често срещана. Сложността не изчезва; тя просто преминава от отделни модули към интерфейси (било то шини за данни, RPC, API или други протоколи) и оркестриращи системи. А това е трудно!

Предимството от използването на разнороден стек също е под въпрос. Няма да твърдя, че това също е възможно, но в действителност се случва рядко (Гледайки напред - това трябва да се случи - но по-скоро като следствие, отколкото като предимство).

Жизнен цикъл на продукта и жизнен цикъл на услугата

Погледнете отново диаграмата по-горе. Неслучайно отбелязах намаляващия жизнен цикъл на отделна версия на бизнес – в съвременните условия именно ускоряването на прехода на бизнеса между версиите е определящо за неговия успех. Успехът на един продукт се определя от скоростта на тестване на бизнес хипотезите в него. И тук, според мен, се крие ключовото предимство на микросервизната архитектура. Но да вървим по ред.

Нека да преминем към следващия етап от еволюцията на информационните системи – към сервизно-ориентираната архитектура на SOA. И така, в определен момент ние подчертахме в нашия продукт дълготрайни услуги - дълготрайни в смисъл, че при преминаване между версии на продукт има шанс жизненият цикъл на услугата да бъде по-дълъг от жизнения цикъл на следващата версия на продукта. Би било логично да не ги променяме изобщо - ние От значение е скоростта на преминаване към следващата версия. Но уви, ние сме принудени да правим постоянни промени в услугите - и тук всичко работи за нас, DevOps практики, контейнеризация и така нататък - всичко, което ни идва на ум. Но това все още не са микроуслуги!

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

И тук най-накрая можем да преминем към определящата роля на микроуслугите – това е подход, който опростява управлението на продуктовата конфигурация. По-подробно функцията на всяка микроуслуга описва точно бизнес функцията вътре в продукта според домейн модела – и това са неща, които живеят не в краткотрайна версия, а в дълготрайна бизнес възможност. И преходът към следващата версия на продукта се случва буквално незабелязано - променяте/добавяте една микроуслуга и може би само схемата на тяхното взаимодействие и изведнъж се оказвате в бъдещето, оставяйки след себе си плачещи конкуренти, които продължават да скачат между версии на техните монолити. Сега си представете, че има доста голям обем микроуслуги с предварително дефинирани интерфейси и бизнес възможности. И вие идвате и изграждате структурата на вашия продукт от готови микроуслуги – просто като нарисувате диаграма, например. Поздравления - имате платформа - и сега можете да привлечете бизнес за себе си. Мечти Мечти.

Данни

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

Източник: www.habr.com