Архітектура микросервисов



На жаль, у мене немає досвіду роботи з микросервисами, але близько року тому я дуже активно цікавився цією темою і вивчив всі джерела інформації, які зміг знайти. Я переглянув кілька виступів на конференціях, прочитав кілька статей дуже авторитетних і досвідчених фахівців на зразок Мартіна Фаулера, Фреда і Джорджа, Едріана Кокрофта та Кріса Річардсона, щоб якомога більше дізнатися про микросервисах. Ця стаття — результат моїх вишукувань.

Зміст
Микросервисная архітектура — це підхід до створення програми, що передбачає відмову від єдиної, монолітної структури. Тобто замість того щоб виконувати всі обмежені контексти програми на сервері за допомогою внутрипроцессных взаємодій, ми використовуємо кілька невеликих додатків, кожне з яких відповідає якомусь обмеженому контексту. Причому ці програми працюють на різних серверах і взаємодіють один з одним по мережі, наприклад, за допомогою HTTP.

Іншими словами, ми инкапсулируем певні контексти програми в микросервисы, по одному на кожен, а самі микросервисы крутимо на різних серверах.

SOA і микросервисы
Згідно Мартіну Фаулера, терміном SOA зловживають всі, кому не лінь, сьогодні під ним розуміють безліч речей. З точки зору Мартіна, микросервисы — це різновид SOA.

Коли слід використовувати микросервисы?
Як архітектор-теоретик, бажаючий стати практиком, я вважаю наступне. Вирішуючи, чи використовувати микросервисы, ні в якому разі не можна керуватися міфами, або бажанням «наступного разу спробувати це», або прагненням бути на передньому краї технологій. До цього, згідно з висновками Рейчел Майерс, потрібно підходити виключно з прагматичної точки зору. Рейчел зазначає, що архітектура повинна:

  • робити продукт гнучкіше і стійкіше до збоїв;
  • полегшувати розуміння, налагодження і зміна коду;
  • допомагати в командній роботі.
Я згоден з Рейчел, але я також вважаю, що цим критеріям задовольняють і монолітні архітектурні схеми.

Мартін Фаулер виділяє кілька переваг монолітною і микросервисной архітектур, що допоможе вам вирішити, який підхід вибрати:
Переваги
Монолітна архітектура Микросервисы
Простота

Монолітна архітектура набагато простіше в реалізації, управління та розгортанні.

Микросервисы вимагають ретельного управління, оскільки вони розгортаються на різних серверах і використовують API.
Часткове розгортання

Микросервисы дозволяють по мірі необхідності оновлювати програму по частинах.

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

При монолітній архітектурі простіше підтримувати узгодженість коду, обробляти помилки і т. д. Зате микросервисы можуть повністю управлятися різними командами з дотриманням різних стандартів.
Доступність

У микросервисов доступність вище: навіть якщо один з них збоїть, це не призводить до збою всього програми.
Межмодульный рефакторинг

Єдина архітектура полегшує роботу в ситуаціях, коли кілька модулів повинні взаємодіяти між собою або коли ми хочемо перемістити класи з одного модуля до іншого. У випадку з микросервисами ми повинні дуже чітко визначати межі модулів!
Збереження модульності

Зберігати модульність і інкапсуляцію може бути непросто, незважаючи на правила SOLID. Однак микросервисы дозволяють гарантувати відсутність загальних станів (shared state) між модулями.
Мультиплатформеність/гетерогенність

Микросервисы дозволяють використовувати різні технології та мови, у відповідності з вашими завданнями.
Особисто мені подобається прагматичний підхід Еріка Еванса. Микросервисы з точки зору апаратних ресурсів мають переваги, яких позбавлені єдині архітектури, а також полегшують вирішення низки завдань з програмної точки зору:
Микросервисы
Апаратні переваги Програмні переваги
Незалежна масштабованість

За розміщення модулів на окремих серверних вузлах ми можемо масштабувати їх незалежно від інших модулів.
Збереження модульності

І єдина, і микросервисная архітектури дозволяють зберігати модульність та інкапсуляцію. Однак це може бути досить важким завданням, на вирішення якої підуть десятиліття, незважаючи на правила SOLID. Зате микросервисы дозволяють забезпечувати логічне розділення програми на модулі за рахунок явного фізичного поділу по серверам. Фізична ізольованість захищає від порушення меж обмежених контекстах.
Незалежний технічний стек

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

Микросервис може розвиватися і ламати зворотну сумісність, не обтяжуючи себе підтримкою старих версій, так як завжди можна залишити стару версію микросервиса працює необхідний час.
Я вважаю, що основні причини для використання микросервисов — апаратні переваги, недосяжні за допомогою єдиної архітектури. Так що якщо вам важливі вищеописані моменти, то микросервисы безальтернативні. Якщо ж апаратні переваги для вас некритичні, то складність микросервисной архітектури може переважити її гідності. Також мені здається, що з допомогою єдиної архітектури неможливо досягти часткового розгортання і часткової доступності, характерних для микросервисов. Це не ключові переваги (хоча це в жодному разі переваги).

Незалежно від наших смаків і побажань не МОЖНА починати новий проект відразу з використанням микросервисной архітектури. Спочатку потрібно зосередитися на розумінні задачі і способі її досягнення, не витрачаючи ресурси на подолання величезної складності створення екосистеми микросервисов (Ребекка Парсонс, Саймон Браун).

Передумови
Безперервне розгортання
Можливість і націленість на постійне прискорення роботи

Одна з причин використання микросервисов полягає в тому, що ми хочемо мати можливість швидко щось міняти, щоб реагувати на зміни бізнес-вимог, випереджати конкурентів. Або, висловлюючись словами Еріка Еванса, нам потрібно усвідомлювати хаос в компаніях:

Реальність розробки ПЗ така, що спочатку ми ніколи не маємо повного розуміння завдання. Наше розуміння поглиблюється в міру робіт, і нам постійно доводиться рефакторіть. Так що рефакторинг — це потреба, але в той же час і небезпекою, тому що код стає заплутанішими, особливо при недотриманні обмеженості контекстів. Микросервисы змушують дотримуватися межі обмежених контекстах, що дозволяє зберігати працездатність, ясність, ізольованість і инкапсулированность коду в окремих зв'язкових модулях. Якщо модуль/микросервис стає заплутаним, то ця заплутаність тільки в ньому і залишається, не поширюється за його межі.
Нам треба діяти швидше на всіх стадіях розробки! Це вірно для будь-якої архітектури, але микросервисы в цьому відношенні зручніше. Мартін Фаулер говорить, що необхідно мати можливість:

  • Швидко вводити в експлуатацію: швидко розгортати нові машини для розробки, тестування, приймання та роботи.
  • Швидко розгортати додатки: автоматично і швидко розгортати наші сервіси.



Фред, Джордж стверджує те ж саме: є величезна потреба прискорити роботу, щоб витримати конкуренцію! Він наводить ретроспективний аналіз часу, необхідного на введення в експлуатацію сервера, і зазначає, що в 1990-х було потрібно 6 місяців, у 2010-му завдяки хмарним сервісам — 30 хвилин, а в 2015-му Docker дозволяв підняти і запустити новий сервер менш ніж за хвилину.

Едріан Кокрофт, один з ключових фахівців в Netflix Cloud і піонер в освоєнні микросервисов, відзначає, як важливо знаходитися в перших рядах при освоєнні нових технологій, а також дуже швидко вводити нові сервери і розгортати нові версії своїх додатків. Едріан — великий шанувальник Docker, оскільки цей сервіс дозволяє за секунди створювати сервер і розгортати середовища для розробки, тестування та роботи.

image

Ускладнився моніторинг
Моніторинг вкрай важливийРебекка Парсонс), нам необхідно відразу дізнаватися про те, що сервер впав, що якийсь компонент перестав відповідати, що відбуваються збої викликів, причому по кожному з микросервисов (Фред, Джордж). Також нам потрібні інструменти для швидкого налагодження (Мартін Фаулер).

Сильна devops-культура
Нам потрібні devops'и для моніторингу та управління, при цьому між ними і розробниками повинні бути тісні відносини і хороша взаємодія (Мартін Фаулер). При роботі з микросервисами нам доводиться більше розгортати, ускладнюється система моніторингу, сильно розростається кількість можливих збоїв. Тому в компанії дуже важлива сильна devops-культура (Ребекка Парсонс).

Характеристики
Мартін Фаулер і Джеймс Льюїс у своїй широко відомій статті і виступах (Фаулер, Льюїс) призводять набір характеристик для визначення микросервиса.

Що таке микросервис?
Особисто я повністю згоден з визначенням Едріана Кокрофта:

Архітектура на основі вільно пов'язаних сервісів з обмеженими контекстами. (Loosely coupled service oriented architecture with bounded contexts.)
image

Обмежений контекст — це поняття явних кордонів навколо якогось бізнес-контексту. Наприклад, в рамках електронної комерції ми оперуємо поняттями «теми» (themes), «постачальники платіжних послуг» (payment providers), «замовлення», «відвантаження», «магазин додатків». Все це обмежені контексти, а значить — кандидати в микросервисы.

Корисна загальна інформація про микросервисах наводиться в книзі Сема Ньюмена «Building Microservices». На думку Джеймса Льюїса, микросервисы повинні:

  • дешево замінюватися;
  • швидко масштабуватися;
  • бути стійкими до збоїв;
  • жодним чином не сповільнювати нашу роботу.
Наскільки великий микросервис?
Джеймс Льюїс стверджує, що сервіс має бути «настільки великим, щоб уміщатися в руці», тобто щоб одна людина могла повністю розібратися в його пристрої і роботі.

Є різні думки про розміри микросервисов. Мартін Фаулер описує випадки, коли співвідношення кількості співробітників і сервісів коливався від 60 до 20 до 4 до 200. Приміром, у Amazon використовується підхід з «командами на дві піци» (two pizzas team): в команді микросервиса повинно бути стільки людей, щоб їх можна було нагодувати двома піцами.

Фред, Джордж вважає, що микросервис повинен бути «дуже-дуже маленьким», щоб його створював і супроводжував тільки один розробник. Те ж саме говорить і Джеймс Льюїс.

Я згоден з Джеймсом Льюїсом, Фредом Джорджем і Едріаном Кокрофтом. Мені здається, микросервис повинен відповідати обмеженого контексту, який здатний повністю зрозуміти один чоловік. Тобто чим ширше функціональність програми, тим більше повинно бути микросервисов. Наприклад, Netflix їх близько 800! Фред, Джордж

Тим не менше, як на самому початку життєвого циклу микросервиса, так і пізніше обмежений контекст може виявитися занадто великий для розуміння однією людиною. Потрібно виявляти такі ситуації і дробити подібні сервіси на більш дрібні. Це відповідає концепціям архітектури з еволюційним розвитком і DDD, передбачають, що архітектура постійно змінюється/рефакторится у міру поглиблення завдання та/або змін бізнес-вимог. Як говорить Ребекка Парсонс, «дроблення вкрай важливо»: при розробці микросервисов найважче визначати їх межі. І при просуванні роботи ми однозначно будемо об'єднувати чи дрібнити сервіси.

Компонентне подання через сервіси
  1. Компонент — це елемент системи, який можна незалежно замінити, удосконалити Мартін Фаулер і масштабувати Ребекка Парсонс).
  2. При розробці, ми використовуємо два типи компонентів:
    А. Бібліотеки: шматки коду, що застосовуються в програмах, які можуть доповнюватися або замінюватися іншими бібліотеками, бажано без впливу на іншу частину програми. Взаємодія відбувається через мовні конструкти. Однак якщо цікавить нас бібліотека написана іншою мовою, ми не можемо використовувати цей компонент.
    Б. Сервіси: частини додатків, за фактом представляють собою маленькі програми, які працюють у власних процесах. Взаємодія виконується за рахунок межпроцессной зв'язку, викликів веб-сервісів, черги повідомлень і т. д. Ми можемо використовувати сервіс, написаний іншою мовою, оскільки він виконується у власному процесі (цей підхід воліє Чод Фаулер).
  3. Незалежна масштабованість — кожен сервіс може бути масштабований незалежно від решти програми.
Гетерогенність
Гетерогенність — це можливість побудувати систему з використанням різних мов програмування. В підходу є ряд переваг (Мартін Фаулер, Чод Фаулер вважає, що системи повинні бути гетерогенны за замовчуванням, тобто розробники повинні намагатися застосовувати нові технології.

Переваги гетерогенної системи:

  • Запобігає виникненню тісних зв'язків завдяки використанню різних мов.
  • Розробники можуть експериментувати з технологіями, що підвищує їх власну цінність і дозволяє не йти в інші компанії, щоб спробувати новинки.
    Правило. При експериментах з новими технологіями:
    — потрібно використовувати маленькі елементи коду (code unit), модулі/микросервисы, щоб знизити ризик;
    — елементи коду повинні бути одноразовими (disposable).
Організація людських ресурсів у відповідності з можливостями бізнесу
Коли всередині команд розробників самоорганізовувалися групи на основі використовуваних технологій. В результаті проект створювали команда з DBA, команда розробки серверної частини і команда розробки інтерфейсу, що діяли незалежно один від одного. Така схема позначається на якості продукту, тому що знання в конкретних областях і зусилля по розробці розсіюються по підгрупах.

При микросервисном підході команди повинні організовуватися на основі бізнес-можливостей: наприклад команда замовлень, відвантаження, каталогу і т. д. В кожній команді повинні бути фахівці з усім необхідним технологій (інтерфейс, серверна частина, DBA, QA...). Це дасть кожній команді достатній обсяг знань, щоб зосередитися на створенні конкретних частин програми — микросервисов (Мартін Фаулер, Ерік Еванс).

Підхід поєднується з законом Конвея, який свідчить, що якщо нам потрібні высокосвязные роздільні микросервисы, то структура організації повинна відображати бажану компонентну структуру.

Організації, що розробляють системи… створюють архітектури, які копіюють структури взаємодій всередині цих організацій.

Мелвін Конвей, 1967
Продукти, а не проекти
Раніше був такий підхід: команда створює якусь функціональність, а потім передає її на супровід іншій команді.

У випадку з микросервисами команда повинна відповідати за свій продукт протягом усього його життєвого циклу, включаючи розробку, супроводження та виведення з експлуатації. Це формує «продуктове мислення», що означає сильну зв'язок між технічним продуктом і його бізнес-можливостями. Тобто створюється прямий взаємозв'язок: як додаток допомагає своїм користувачам розширити їх бізнес-можливості.

Розумні эндпойнты і дурні канали (Smart endpoints and dumb pipes)
Знову ж таки, в старі добрі часи використовували архітектуру Enterprise Service Bus (сервісна шина), при якій формується канал комунікацій між эндпойнтами і бізнес-логікою. Потім цей підхід змінився у spaghetti box.

Микросервисная архітектура переносить бізнес-логіку в кінцеві точки і використовує прості способи взаємодії на зразок HTTP.

Децентралізоване управління
Ключові рішення щодо микросервисам повинні приймати люди, які дійсно розробляють микросервисы. Тут під ключовими рішеннями мається на увазі вибір мов програмування, методології розгортання, контрактів публічних інтерфейсів і т. д.

Децентралізоване управління даними
При традиційному підході у додатку лише одна база даних, і багато різних компонентів бізнес-логіки програми «взаємодіють» в рамках цієї БД: безпосередньо читають з неї дані, що належать іншим компонентам. Це також означає, що для всіх компонентів характерна одна і та ж ступінь збереження даних, навіть якщо для них це не найкраща ситуація (Мартін Фаулер).

При микросервисной архітектурі, коли кожен бізнес-компонент являє собою микросервис, всі компоненти володіють власними базами даних, які недоступні іншим микросервисам. Дані компоненти доступні для читання і запису) тільки через відповідний інтерфейс компонентів. Завдяки цьому ступінь стійкості даних варіюється в залежності від компонента (Мартін Фаулер, Чод Фаулер).

З точки зору Фреда і Джорджа, це перший виклик на шляху до микросервисной архітектурі.

image

Автоматизація інфраструктури
Безперервне розгортання Мартін Фаулер, Ребекка Парсонс, Чод Фаулер, Ерік Еванс):

  1. «Блакитне» і «зелене» розгортання: нульовий час простою.
  2. Автоматизація: натисненням однієї кнопки можна розгорнути кілька серверів.
  3. Сервери Phoenix: швидкий запуск і зупинка.
  4. Моніторинг: можна помітити, коли щось пішло не так, і налагодження.
Страховка від збоїв (Design for failure)
Сервери, за якими розподілено додаток, рано чи пізно падають, особливо різні вузли. Тому архітектура додатків повинна бути стійка до таких збоїв (Мартін Фаулер).

Chaos monkey — це інструмент, створений в Netflix. Він дозволяє вимикати сервери для перевірки стійкості системи до такого типу відмов (Мартін Фаулер).

Ребекка Парсонс вважає дуже важливим, що ми більше не використовуємо навіть внутрипроцессное взаємодія між сервісами, замість цього для зв'язку ми вдаємося до HTTP, який і близько не буває настільки ж надійний. В результаті будуть виникати збої при спілкуванні сервісів один з одним, і система повинна бути до цього готова.

Архітектура з еволюційним розвитком
Архітектура всього програми не повинна бути статичною, необхідна можливість її простого розвитку у відповідності з потребами бізнесу. Наприклад, можна:

  • Перетворити (рефакторіть) єдине додаток в додаток микросервисное, ізолювавши і перенісши набори бізнес-логіки (обмежені контексти) в окремі микросервисы.
  • Об'єднати існуючі микросервисы, наприклад, коли часто доводиться одночасно змінювати різні микросервисы.
  • Розділити існуючі микросервисы, коли потрібно і є можливість розвивати їх окремо або коли ми розуміємо, що поділ серйозно вплине на бізнес-логіку.
  • Тимчасово додати в додаток якусь можливість, створивши микросервис, який буде працювати певний час.
Фронтенд/бекенд
Є два підходи до структурування фронтенда і бекенду при микросервисной архітектурі:

  1. Розкидати всі частини користувальницького інтерфейсу по микросервисам і зберігати взаємозв'язку між відповідними микросервисами. Це дозволяє налагодити внутрипроцессное взаємодія між фронтендом і бекендом. Але тоді буде дуже складно, якщо взагалі можливо, підтримувати зв'язність UI. У разі перехресних змін кордонів у UI нам доведеться одночасно оновлювати кілька микросервисов, створюючи взаємозв'язку і порушуючи ізольованість і незалежність микросервисов, забезпечуються самою архітектурою. Виходить практично антипаттерн!
  2. Розкидати кодові бази фронтенда і бекенду, залишивши UI програми одним цілим, щоб вони потім працювали по HTTP. Микросервисы будуть відокремлені одне від одного, що додатково розділить фронтенд і бекенд. Зате UI можна підтримувати цілком, легко зберігаючи його зв'язність. Таку структуру рекомендує використовувати Рейчел Майерс, і, наскільки я розумію, це єдиний спосіб. В такому разі у нас є два варіанти взаємодії між фронтендом і бекендом:
    1. Багато маленьких асинхронних HTTP-запитів замість одного великого, що виключить можливість блокування (цей підхід воліє Чод Фаулер).
    2. Один великий запит до спеціалізованих сервісів (шлюзу/агрегатору/кешу), які збирають дані з усієї микросервисной екосистеми. Це зменшує складність UI.
Небезпеки
Потрібно управляти гнучкістю технології
Одна з переваг микросервисов полягає в тому, що ми можемо застосовувати різні технології для вирішення однієї і тієї ж задачі. Наприклад, в кожному микросервисе використовувати різні бібліотеки для XML-парсинга або різні інструменти збереження даних. Але сама можливість не означає, що ми повинні це робити. Не виключено, що велика кількість технологій і бібліотек вийде з-під контролю. Так що виберіть базовий набір інструментів і звертайтесь до інших тільки тоді, коли це дійсно потрібноРебекка Парсонс).

Потрібно управляти нестабільністю інтерфейсу
На початку розробки микросервиса його API особливо нестабільний. Але навіть на більш пізніх стадіях, коли микросервис досить відпрацьований, нам доводиться міняти API, його введення і виведення. Обережно вносите зміни, тому що інші програми будуть покладатися на стабільність API (Ребекка Парсонс).

Необхідно бути впевненими в узгодженості даних
Микросервисы мають власні сховища даних. І в багатьох випадках дані, що належать одному микросервису, будуть частково або повністю скопійовано іншим, клієнтським микросервисом. Коли дані у постачальника змінюються, він ініціює подія для запуску оновлення даних, скопійованих клієнтським микросервисом. Подія потрапляє в чергу повідомлень і чекає, коли його отримає клієнтський микросервис.

Ця схема означає, що клієнтський микросервис буде володіти застарілими даними, поки не знайде потрібну подію. Дані не узгоджені.

Звичайно, в результаті зміни будуть застосовані до всіх копій, а дані знову стануть узгодженими. Це називається eventual consistency — узгодженість в кінцевому рахунку. Тобто ми знаємо, що протягом короткого періоду часу дані залишаються неузгодженими. Цей ефект має важливе значення в ході розробки додатків, від серверної частини до UX-рівнів (Ребекка Парсонс).

Як декомпозировать єдине додаток
Приступаючи до створення програми, потрібно спочатку дотримуватися єдиної архітектури — через її простоти. У той же час потрібно намагатися створювати його як можна більш модульним, щоб кожен компонент легко переносився в окремий микросервис (Ребекка Парсонс). Це поєднується з ідеєю Саймона Брауна про розробку програми у вигляді набору окремих компонентів в єдиному развертываемом модулі.

При декомпозиції єдиної архітектури в микросервисную, або в набір окремих компонентів, необхідно думати про кількох вимірах в підтримку нашого рішення:

  • Думайте про обмежених контекстах, як це визначено в DDD (Ребекка Парсонс, Рейчел Майерс
    • Кожен микросервис повинен являти собою обмежений контекст, з точки зору концепції бізнесу і з технічної точки зору. Зазвичай в рамках микросервиса повинні бути з'єднання між елементами коду (між даними та/або бізнес-логікою), а також кілька з'єднань з зовнішніми елементами коду.
  • Думайте про бізнес-можливості (Ребекка Парсонс: 1, 2
    • Які потоки створення цінностей (value streams) існують в організації? Бізнес-продукти? Які доставляються бізнес-сервіси?
  • Думайте про потребах споживачів (Ребекка Парсонс: 1, 2, 3
    • Ми можемо подивитися на продукт не лише як творці, але і як споживачі: що вони хочуть від нашого сервісу? Як вони будуть його використовувати? Чого вони чекають?
  • Думайте про шаблонах взаємодії
    • Які частини системи можуть використовувати одні і ті ж дані? Які бізнес-логіки будуть взаємодіяти інтенсивніше? (Ребекка Парсонс: 1, 2, 3
    • Є в архітектурі єдина точка відмови завдяки жорсткій залежності одного микросервиса від багатьох інших? Рейчел Майерс
  • Думайте про архітектурі даних (Ребекка Парсонс: 1, 2, 3, Рейчел Майерс
    • Сервіси володіють власними даними, у них свої бази даних, і нам потрібно виходити з принципу узгодженості в кінцевому рахунку. Якщо дві структури даних дуже сильно залежать один від одного, то може бути доцільніше тримати їх в одному микросервисе, щоб не довелося створювати механізм для роботи з узгодженістю в кінцевому рахунку.
  • Думайте про шаблони взаємопов'язаних змін (Ребекка Парсонс: 1, 2, 3, Рейчел Майерс
    • Якщо можна передбачити одночасне зміна двох елементів коду, то краще зберігати їх в одному микросервисе, щоб виключити зайві зусилля по зміні API.
  • Будьте готові до злиття і поділу сервісів Ребекка Парсонс
    • Ймовірно, ви не зможете завжди робити це вчасно. Але у міру отримання досвіду і заглиблення в завдання ми починаємо краще розуміти розташування обмежених контекстів. Бізнес теж буде змінюватися, і нам доведеться до цього швидко пристосовуватися! Так що наша система повинна дозволяти швидко розділяти і об'єднувати микросервисы.
  • Шаблон Tolerant reader Ребекка Парсонс
    • Завжди може виникнути необхідність внести критичне зміна в зворотну сумісність (backwards compatibility breaking change). Але ми можемо спробувати робити це лише в крайньому випадку. Щоб не змінювати свій сервіс постійно створіть його так, щоб сервіс доводилося міняти тільки при зміні дійсно важливих даних.
  • Без збереження стану і вузли Phoenix Рейчел Майерс, Чод Фаулер, Ерік Еванс
    • Не дублюйте статичні файли (HTML, CSS, JS, зображення) в додатках і сервісах.
    • Програми з інтерфейсом повинні бути повністю відокремлені від микросервисной екосистеми.
    • Використовуйте одноразові вузли.
    • Використовуйте незмінне розгортання (immutable deployments): ніколи не оновлюйте на існуючих вузлах.
  • Пріоритет угоди над конфігурацією (Convention over configuration) Чод Фаулер
    • Прийняті у вашій архітектурі структура і система найменувань повинні бути однаковими для всієї екосистеми микросервисов.
    • Створіть генератор микросервисной пісочниці, щоб у вас була початкова точка з уже заданим звичної структурою.
  • Оптимізація взаємодії між микросервисами Чод Фаулер
    • Створіть базову клієнтську бібліотеку HTTP REST, оптимізовану для REST-дзвінків, на основі якої можна будувати конкретний микросервисный клієнт, їм будуть користуватися інші микросервисы. Цей оптимізований клієнт повинен бути портований на всі мови, застосовувані у вашій екосистемі.
  • Виявлення сервісів (Service discovery) Чод Фаулер
    • Кожен микросервис повинен знати, як контактувати з іншими. Можна використовувати локалізований (для кожного сервісу) конфіг, оновлюваний відразу у всіх місцях при зміні розташування микросервиса.
  • Моніторинг Чод Фаулер
    • Вимірюйте все: мережа, машини, додаток.
    • При створенні нового микросервиса необхідно оснащувати його всією необхідною функціональністю з моніторингу.
  • Міграція від єдиної архітектури до микросервисам Чод Фаулер
    • Краще використовувати багато маленьких запитів замість кількох великих (приберіть з'єднання — joins).
    • Розділяйте бази даних.
    • Створюйте нові фічі у вигляді микросервисов, прототипів.
    • Замініть код в старій системі на API-виклики нових микросервисов.
    • Протестуйте в божевільних умовах і під божевільною навантаженням.
  • Довгострокові цілі Чод Фаулер
    • Це повинно працювати.
    • Це повинно працювати швидко.
    • Це повинно бути дешевим => спотові примірники (spot instances) AWS економлять від 85 до 95 % серверних вузлів.
  • Продуктивність Чод Фаулер
    • Підвищити швидкість розробки і розгортання Docker.
Висновок
У більшості проектів не потрібно микросервисная архітектура, їм потрібна гарна архітектура. Під цим я маю на увазі не тільки хорошу структуру, але також (може, це навіть важливіше) чіткого визначення цієї структури, чітке й акуратне відображення структури в самому коді, щоб це було очевидно для розробників і допомогло їм виділити обмежені контексти і зрозуміти, коли варто перетинати кордони, а коли ні.

А далі вже розробникам вирішувати, підтримувати або розвивати архітектурну структуру. Це передбачає суворе дотримання плану, структурі, архітектурі, що не завжди легко. Адже ми всього лише люди.

Корисні посилання
Статті
Werner Vogels • грудень 2008 • Eventually Consistent – Revisited
Oracle • червень 2012 • De-mystifying «eventual consistency» in distributed systems
Мартін Фаулер і Джеймс Льюїс • березень 2014 • Microservices

Конференції
Едріан Кокрофт • січень 2015 • The State of the Art in Microservices
Чед Фаулер • липень 2015 • From Homogeneous Monolith to Radically Heterogeneous Microservices Architecture
Ерік Еванс • грудень 2015 • DDD & Microservices: At Last, Some Boundaries!
Фред, Джордж • серпень 2015 • Challenges in implementing Microservices
Джеймс Льюїс • жовтень 2015 • Microservices and the Inverse Conway Manoeuvre
Джет Уеслі-Сміт • жовтень 2014 • Real World Microservices
Мартін Фаулер • січень 2015 • Microservices
Рейчел Майерс • грудень 2015 • Stop Building Services, Episode 1: The Phantom Menace
Ребекка Парсонс • липень 2015 • Evolutionary Architecture & Micro-Services
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.