Англійська мова для декомпозиції мікросервісів: Як обговорити розбиття монолита

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

Ключовий словник

Монолит Моноліт — це програмне забезпечення, в якому всі компоненти щільно з’ єднані і розгорнуті як єдиний блок. Термін часто використовується неформально для опису будь-якої великої, важкої для зміни кодової бази. “Наш моноліт виріс до 800 000 рядків коду за вісім років - розгортання займає 45 хвилин і кожна зміна ризикує повним відновленням.”

Разложение Розкладання — це процес розбиття монолита на менші, незалежно розгорнуті служби. Це стратегія, а не одиночний випадок. “Ми працювали над розкладанням домену управління замовленнями протягом останніх двох кварталів.”

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

• “Ми використовуємо шаблон « удушення фіг » — нова служба сповіщень тепер обробляє всі вихідні листи, і ми вилучили цей код з монолита.” *

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

** Обмежений контекст ** Обмежений контекст, з Domain-Driven Design, є чітко визначеною областю моделі домену з власною внутрішньою мовою і логікою. Це концептуальна основа для межі мікросервісу. “Домен платежів має чітко обмежений контекст — він має власні сутності, власну мову і мінімальне з’ єднання з доменом запасів.”

** Шлях захисту від пошкодження (ACL) ** Антикорупційний шар — це шар перекладу, який знаходиться між старим монолитом і новим мікросервісом, запобігаючи витоку старої моделі даних в дизайн нової служби.

• “Ми ввели антикорупційний шар, щоб нова служба користувача не успадковувала стару модель облікового запису від монолиту.” *

** Фаза міграції ** Фаза міграції є визначеною стадією в плані розкладання, зазвичай пов’ язаною з певною службою або доменом, який витягується. Фази дозволяють командам надавати цінність поступово, а не намагатися міграції великого вибуху.

• « Ми перебуваємо на другому етапі перенесення — служба каталогів вилучена, і ми починаємо вилучення домену пошуку. » *

** Маршрутизація трафіку / шар маршрутизації ** У міграції « душілки », шар маршрутизації розташовується перед монолитом і новими службами, направляючи запити до відповідного місця призначення за допомогою правил маршрутизації.

• “Шар маршрутизації вирішує, чи буде запит направлено до старого монолита чи до нової служби замовлення, на основі прапора можливості.” *

Корисні фрази

• “Ми пропонуємо поетапний розклад протягом 12 місяців, починаючи з меж найвищого значення домена.”
• • “Патерн « удушувальна фіга » дозволяє нам мігрувати поступово без дня прапора — нам ніколи не доведеться перемикати все відразу.” *
• “Перед тим, як ми розпочнемо видобування, нам потрібно домовитися про межі обмежених контекстів — де закінчується домен замовлень і починається домен виконання?”
• “Головним ризиком розкладання є розподілені транзакції — нам потрібно погодитися на моделі послідовності, перш ніж ми витягнемо платіжну службу.”
• “Це міграція, а не переписування — ми зберігаємо поведінку і змінюємо власника, а не винайдуємо логіку знову.”

Поширені помилки

Сказав “розбити моноліт” замість “розкладати” або “витягувати з” “Ми збираємося розбити монолит” звучить тривожно і неточно. Використовуйте « розкладати », « витягувати », « мігрувати » або « розділятися ». Ці терміни позначають намір і контроль, а не знищення.

** Плутанина обмежений контекст з мікросервісом ** Обмежений контекст є концептуальним інструментом проектування; мікросервіс є одиницю розгортання. Один обмежений контекст може стати однією мікросервісом, але концепції не є взаємозамінними. Скажіть “ми використовуємо обмежені контексти, щоб керувати межами наших сервісів”, а не “ми розробляємо обмежені контексти як наші мікросервіси”

** Розгляд розкладання як технічної проблеми ** Розкладання завжди включає в себе організаційні зміни — власність, відповідальність за виклик і зміну топологій команди. При обговоренні плану англійською мовою, включіть цю вимірність: * “Витягування платіжної служби також означає, що платіжна команда бере на себе власність SLO і постійну ротацію.” *

Розкладання мікросервісів є таким же комунікаційним викликом, як і технічним. Вміння вільно користуватися словником понять, пов’ язаних з швами, обмеженим контекстом і поетапною міграцією допоможе вам вести і робити внесок у ці обговорення з впевненістю.

Науковий ступінь: доктор філософії, англійська мова

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

Одна з найчастіших перешкод виникає при обговоренні моделі «душувальної фігури». Хоча метафора сама по собі корисна, просто сказати «ми душимо моноліт» може звучати надто агресивно або відверто. Більш конструктивний підхід буде таким: «Ми використовуємо стратегію «душілки» — поступове замінення функціональності в рамках існуючої системи новими мікросервісами. Це дозволяє нам мінімізувати перешкоди і управляти ризиками під час переходу.” Зауважте, що ця фраза зосереджена на стратегії і менеджменті, а не на насильницькій дії. Аналогічно, при описі « обмеженого контексту », уникайте слів « ця служба має свій власний маленький світ ». Замість цього спробуйте: « Цей обмежений контекст містить всі дані і логіку, пов’ язані з введенням клієнта, забезпечуючи послідовність і зменшуючи залежності у системі ». Ключовим є те, щоб описати ці концепції як навмисні вибори дизайну з ясними перевагами.

Іншою областю, де нюанс має значне значення, є описи PR. Типове повідомлення про затвердження, наприклад, « Виправлена помилка », не достатньо, коли обговорюється розкладання мікросервісів. Замість цього, розгляньте: « Перероблена логіка автентифікації користувача у нову службу, вирівняну з обмеженим контекстом « Керування користувачами ». Це зменшує зв’ язок з основною платформою і дозволяє незалежне масштабування служб автентифікації.» Додаткові подробиці надають контекст для переглядачів і підкреслюють * чому * зміна була внесена — для вирішення залежностей і поліпшення масштабованості. Ви також часто почуєте розмови про « фази міграції ». Замість того, щоб сказати « ми мігруємо це », більш професійним твердженням буде: « Ми починаємо Фазу 2 міграції, зосереджуючись на переході функціональності обробки платежів з монолита на спеціальну платіжну службу ». Використання слів « ініціювання » і « зосередження » сигналізує про запланований і контролюваний процес.

Нарешті, зверніть увагу на те, як ви висловлюєте свої розбіжності або занепокоєння під час перегляду коду. Замість того, щоб сказати «це не підходить до нашої архітектури», спробуйте: «Я переживаю, що ця тісно пов’язана інтеграція може створити проблеми для майбутнього масштабування. Можливо, ми могли б дослідити альтернативні підходи, які б відповідали обмеженому контексту [Назва служби]?» Це демонструє активну зацікавленість і запрошує до обговорення, а не просто вказує на проблему. Сфокусування на потенційних викликах і запропоновані рішення є ключем до конструктивного спілкування в складних технічних середовищах.