Артыкул на тэму мікрасэрвіснай архітэктуры я хацеў напісаць даўно, аднак увесь час спынялі два моманты - чым далей я апускаўся ў тэму, тым больш мне здавалася, што тое, што я ведаю - відавочна, а што не ведаю - яшчэ вывучаць і вывучаць. З іншага боку лічу, што ўжо ёсць пра што паразважаць і ў шырокай аўдыторыі. Так што альтэрнатыўныя думкі вітаюцца.
Закон Канвею і сувязь паміж бізнесам, арганізацыяй і інфармацыйнай сістэмай
Я ў чарговы раз дазволю сабе працытаваць:
"Любая арганізацыя, якая праектуе нейкую сістэму (у шырокім сэнсе) атрымае дызайн, чыя структура капіюе структуру каманд у гэтай арганізацыі".
- Melvyn Conway, 1967
На мой погляд гэты закон хутчэй суадносіцца да мэтазгоднасці арганізацыі бізнэсу, чым наўпрост да інфармацыйнай сістэмы. Растлумачу на прыкладзе. Дапушчальны, у нас ёсць досыць стабільная бізнэс магчымасць з жыццёвым цыклам такой працягласці, каб мела сэнс арганізаваць прадпрыемства (гэта не памылка друку, але мне вельмі падабаецца гэты тэрмін, які я зацягнуў) Натуральна, што забяспечвальная сістэма гэтага бізнэсу будзе арганізацыйна і працэсна адпавядаць гэтаму бізнэсу .
Бізнес-арыентаванасць інфармацыйных сістэм
Растлумачу на прыкладзе. Дапусцім наяўнасць бізнес-магчымасці па арганізацыі бізнесу па продажы піцы. У V1 версіі (назавём яе даінфармацыйнай) кампанія ўяўляла сабой піцэрыю, касу, службу дастаўкі. Гэтая версія была даўгавечнай ва ўмовах нізкай зменлівасці навакольнага свету. Затым на змену прыйшла версія 2 – больш прасунутая і ўмелая выкарыстоўваць інфармацыйную сістэму ў сваёй аснове для бізнэсу з маналітнай архітэктурай. І тут, на мой погляд узнікае вось проста жудасная несправядлівасць у адносінах да маналітаў - нібы маналітная архітэктура не адпавядае даменнай мадэлі бізнэсу. Ды будзь гэта так, сістэма б не змагла працаваць наогул -у супярэчнасці з тым жа законам Канвея і разумным сэнсам. Не, маналітная архітэктура цалкам адпавядае бізнэс-мадэлі на дадзеным этапе развіцця бізнесу - я вядома маю на ўвазе этап, калі сістэма ўжо створана і ўведзена ў эксплуатацыю. Зусім выдатны факт, што па-за залежнасцю ад архітэктурнага падыходу і сэрвісна-арыентаваная архітэктура версіі 3 і мікрасэрвісная архітэктура версіі N будзе працаваць аднолькава добра. У чым падвох?
Усё цячэ, усё змяняецца або мікрасэрвісы - сродак барацьбы са складанасцю?
Перш чым працягнуць, разгледзім некаторыя памылкі датычна мікрасэрвіснай архітэктуры.
Прыхільнікі выкарыстання мікрасэрвіснага падыходу часта гавораць аб тым, што разбіццё маналіта на мікрасэрвісы спрашчае падыход да распрацоўкі за кошт памяншэння кодавай базы асобных сэрвісаў. На мой погляд гэтае сцвярджэнне з'яўляецца найпоўным трызненнем. Сур'ёзна, відавочнае ўзаемадзеянне ў рамках маналіта і гамагеннага кода здаецца складаным? Калі б гэта сапраўды было так, усе праекты б першапачаткова будаваліся як мікрасэрвісы, у той час як практыка паказвае, што міграцыя з маналіта ў мікрасэрвісы з'яўляецца куды больш распаўсюджанай. Складанасць нікуды не знікае, яна проста пераходзіць з асобных модуляў у інтэрфейсы (няхай гэта будзе шыны дадзеных, RPC, API і іншыя пратаколы) і аркеструючыя сістэмы. І гэта - складана!
Перавага выкарыстання гетэрагеннага стэка таксама з'яўляецца сумніўным. Я не буду спрачацца, што такое таксама магчыма, але ў рэальнасці рэдка сустракаецца (Забягаючы наперад - гэта павінна мець месца быць - але хутчэй як следства, чым перавага).
Жыццёвы цыкл прадукта і жыццёвы цыкл сэрвісу
Зірніце яшчэ раз на дыяграму вышэй. Я не выпадкова адзначыў памяншаецца жыццёвы цыкл асобнай версіі бізнесу - у сучасных умовах менавіта паскарэнне пераходу бізнесу паміж версіямі з'яўляецца вызначальным для яго поспеху. Паспяховасць прадукта вызначаецца хуткасцю праверкі бізнес-гіпотэз у ім. І вось тут на мой погляд і закапана ключавая перавага мікрасэрвіснай архітэктуры. Але пойдзем па парадку.
Пяройдзем на наступную прыступку эвалюцыі інфармацыйных сістэм – на сэрвіс-арыентаваную архітэктуру SOA. Такім чынам, у нейкі пэўны момант мы вылучылі ў сваім прадукце доўгажывучыя сэрвісы - доўгажывучыя ў тым сэнсе, што пры пераходзе паміж версіямі прадукта ёсць шанцы што жыццёвы цыкл сэрвісу будзе даўжэй, чым жыццёвы цыкл чарговай версіі прадукта. Лагічна было б не змяняць іх наогул - нам важная менавіта хуткасць пераходу да наступнай версіі. Але нажаль, мы змушаныя ўносіць сталыя змены ў сэрвісы - і тут у нас усё падыходзіць, і практыкі DevOps, і кантэйнерызацыя, і іншае - усё што ў галаву прыйдзе. Але гэта ўсё яшчэ не мікрасэрвісы!
Мікрасэрвісы як сродак барацьбы са складанасцю… кіравання канфігурацыяй
І вось тут мы можам перайсці да вызначальнай ролі мікрасэрвісаў – гэта падыход, які спрашчае кіраванне канфігурацыяй прадукта. Дэталёва кажучы, функцыя кожнага мікрасэрвісу апісвае менавіта бізнэс-функцыю ўнутры прадукта паводле даменнай мадэлі – а гэта ўжо рэчы, якія жывуць не ў кароткажывучых версіі, а ў доўгажывучых бізнес-магчымасці. І пераход да наступнай версіі прадукта адбываецца літаральнай выявай неўзаметку — вы змяняеце/дадаеце адзін мікрасэрвіс, а магчыма і проста схему іх узаемадзеяння і раптам апыняецеся ўжо ў будучыні, пакідаючы за бортам якія плачуць канкурэнтаў, якія працягваюць скакаць паміж версіямі сваіх маналітаў. Цяпер уявіце сабе, што маецца дастаткова вялікі аб'ём мікрасэрвісаў з загадзя вызначанымі інтэрфейсамі і бізнэс-магчымасцямі. І вы прыходзіце і будуеце структуру вашага прадукта з гатовых мікрасэрвісаў - проста малюючы дыяграму напрыклад. Віншую - у вас з'явілася платформа - і зараз вы можаце сабе бізнэс наклікаць. Мары, мары.
Высновы
- Архітэктура сістэмы павінна вызначацца жыццёвым цыклам якія ўваходзяць у яе кампанентаў. Калі кампанента жыве ў рамках версіі прадукта – няма сэнсу павялічваць складанасць сістэмы, ужываючы мікрасэрвісны падыход.
- Мікрасэрвісная архітэктура павінна грунтавацца на даменнай мадэлі – па тым чынніку што бізнэс-магчымасць найболей доўгажывучая вобласць
- Практыкі дастаўкі (практыкі DevOps) і аркестрацыі маюць для мікрасэрвіснай архітэктуры адно з найважнейшых значэнняў – па той прычыне, што павелічэнне хуткасці змены кампанентаў прад'яўляе падвышаныя патрабаванні да хуткасці і якасці дастаўкі.
Крыніца: habr.com