Мікросервіси: Що таке мікросервіси?

Використання мікросервісів

Це перша частина серії блог-постів про мікросервіси. Видається, що в суспільстві існує багато різнотлумачень стосовно того, чим є мікросервіси; коли їх потрібно використовувати та який підхід до них застосувати. 

Серія цих блог-постів, по суті, - наслідок 5-річного досвіду вибудови та вивчення природи мікросервісів. Я допускаю, що не всі погодяться з тим, про що я тут писатиму, але, я надіюся, що не знайдеться настільки контроверсійних положень, які могли б зумовити серйозні суперечності.

Частина 1. Що таке мікросервіси?
Частина 2. Коли варто використовувати мікросервіси?
Частина 3. Чому вам не варто використовувати мікросервіси?

Найважливіше, що треба запам'ятати, коли мова йде про мікросервіси, - це переконатися у тому, що коли говоримо про мікросервіси, ми відштовхуємося від одного і того ж вихідного положення. Протягом своєї кар’єри я намагався дотримуватися простої філософії: коли не доходять згоди двоє розумних людей, один з них не враховує одного з наявних контекстів. Я хотів би зараз згадати, хто вклав цю думку мені в голову; і хоча це положення не завжди стверджувалося, воно, безумовно, привнесло велике благо у мої професійні стосунки.

Ціллю написання цього блог-посту є ще раз переконатися у тому, що коли ми спілкуємося, то виходимо з одного і того ж контексту. Що ми б (або конкретніше я б) хотів зробити у цій сфері, то це уникнути різнотлумачень лексичних значень. Навіть серед моїх колег спостерігається доволі значна плутанина у стосунку до того, чим, насправді, є мікросервіси. Наскільки вони макро? Наскільки вони сервіси.

Загалом, не існує єдиного визначення, яке б пояснювало, чим насправді є мікросервіс. Проте, я вірю, що вироблення уніфікованого погляду на те, чим є мікросервіси, та як вони працюють, є дуже важливим, і саме для цього я пишу цей блог-пост.

Найперше, що потрібно чітко усвідомити - це те, чим мікросервіс не є. Мікросервіси - це не мільйон сервісів, що творять один, єдиний сервіс (подумайте самі мікро = 1 000 000? Це вже смішно))). Говорячи серйозно, якщо хтось може написати архітектуру мікросервіса кожним з ПРС ресурсів, який є єдиним сервісом, то це може призвести до дуже неоднозначної архітектури. Я говоритиму про це детальніше в наступному блог-пості. Мікросервіси - не є також декількома великими сервісами, кожен з яких покриває делька з функцій і які взаємопов’язуються через базу даних або через КШД у великих корпоративних системах. Навпаки, правда, я думаю, міститься десь посередині.

Іншою важливою річчю, яку варто усвідомити, - це те, що мікросервіси необов’язково мають розгортатися осібно. Замість того, щоб фокусуватися на сервісах, що розгортаються осібно достатньо вибрати групи сервісів, які можна розгорнути осібно. Джеймс Левіс описує це у вигляді плану міста та стверджує, що сервіси, які функціонують спільно, щоб виробити один або цілий набір функціоналів, мають розгортатися осібно від інших груп сервісів, які надають частину або цілий набір функціоналів. 

У випадку використання такої метафори ці групи виглядають подбіно до кварталів у місті. Сервіси у певному кварталі необов’язково повинні розгортатися осібно. Адже, несуться витрати на розгортання сервісів осібно, а прагматичні люди уникають сервісів, що розгортаються осіб, якщо тільки це не приносить справжньої користі. Нагoлошую ще раз, що ми заглибимося у цю тему в наступному блог-пості .

Коли я розмовляв з Джеймсом Левісом, я запитав його: “Яке визначення можна дати мікросервісам?” Його відповідь була: “...високоякісна, добірна COA, вироблена на манеру ‘Юнікс’.” Звучить доволі однозначно. Важливо пам’ятати, що ми говоримо про чітко визначену частину функціоналу, яка комунікує з іншими чітко визначеними частинами функціоналу через добре визначений інтерфейс. Філософія ‘Юнікс’ передбачає побудову багатьох речей, що виконують одне завдання; виконують його добре і працюють дистанційно через трубки та фільтри. Беручи до уваги цю філософію та застосовуючи її до СОА, передбачається також вибудову сервісів, що фокусуються на одній частині функціоналу та комунікують з іншими сервісами, що виробити конкретну бізнес-вартість.

Фактично, це продовження принципу Боба Мартіна - ‘Принципу єдиного обов’язку’ до рівня сервісу. На практиці цього важко досягнути, але в ідеальному світі - це означає, що потрібно тільки змінити сервіс (тобто він розгорнеться), якщо функціонал, за який він відповідає зміниться. Це дуже благородно, але й дуже важко, адже розбиття системи на частини може стати нічним кошмаром.

Комунікація між цими сервісами має бути здійснена через чітко визначений інтерфейс, таки, який надає HTTP. На щастя, існує переконлива СOA архітектура, що надає нам можливість накласти чітко визначений інтерфейс на HTTP. Про передачу репрезентативного стану (ПРС) вже давно відомо, і вона добре задовольняє цілі. В той час, коли неможливо досягти доволі високого ступеня відмежування, який можна досягти використовуючи ‘Юнікс’, хорошому ПРС з гіпер-медіа доведеться довго досягати відмежування.

Є інші протоколи, які можуть функціонувати у цьому просторі, і я не хочу сказати, що ПРС єдиний, який відповідає моделі. У багатьох випадках інші протоколи трансферу більш доцільні ніж HTTP. В рамках серії цих блог постів, і в цілому, я вважаю, що ПРС - це дуже переконлива інтеграційна техніка, яка, якщо виконана правильно, додає вартості та перетворює мікросервіси з неосягненої мрії в осягненну реальність.  

Отже, в даному контексті давайте визначимо мікросервіси або архітектуру мікросервісів наступним чином:

Система, яка будується на мікросервісах - це система, вибудувана з малих “легких” сервісів, в якій кожен сервіс відіграє свою функцію. Сервіси впорядковані у групи, що осібно розгортаються та комунікують між собою через чітко визначений інтерфейс, а також співпрацюють, щоб згенерувати бізнес-вартість .

Copying of this content is allowed only with reference to the source and indication of the author of TQM systems' material.

Written by David

• 
• Editor of TQM systems Olga Nikanorova
• 12/22/2020 9:43:38 PM
• ua-articles