Проектування і микросервисы для самих маленьких



Проектування системи — дуже відповідальний захід. Помилки на цьому етапі найдорожчі.

Важлива частина навчання будь-якої людини, що бажає стати професіоналом — обмін досвідом, адже це дозволяє уникнути багатьох проблем. Мені вдалося поговорити на тему проектування микросервисов зі спікером майбутньої конференції DotNext 2016 Moscow Микитою Цукановим і отримати відповіді на свої запитання. Якщо ви жодного разу не застосовували підхід, заснований на микросервисах, рекомендую ознайомитися з цією концепцією побудови архітектури. Під катом інформація до роздумів для майбутніх і справжніх архітекторів.

Микита Цуканов:

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


Про микросервисах в цілому та їх переваги
– Микита, розкажіть трохи про микросервисах в цілому та особливості микросервисной архітектури .NET

– Дати поняття того, що є микросервис, найпростіше в порівнянні з класичною «монолітної» структурою програми, до якої всі звикли. В монолітному додатку у нас є єдина кодова база, компилирующаяся в один великий виконуваний файл і його залежності (іноді їх декілька, коли, наприклад, необхідно винести фонові завдання з IIS працює окремо Windows-сервіс). Головним критерієм монолітності є те, що для поновлення програми нам треба взяти його вихідні коди, зібрати і провести деплой на всі сервери, на яких воно повинно працювати. До таких повним пересборке і деплою призводять навіть найменші зміни, неважливо, де саме вони зроблені. У ряді випадків виникає бажання розділити життєвий цикл розробки окремих частин програми, розділити зони відповідальності команд. Для виконання цих завдань додаток по суті поділяють на декілька, кожне з яких виконує свою відокремлену від решти завдання, має свій цикл розробки, тестування і розгортання. Треба розуміти, що спілкування програми зі своїми власними примірниками по мережі ще не робить його заснованим на микросервисах, воно залишається монолітним.

– В чому переваги застосування микросервисов в проектуванні? Як сильно розрізняються між собою підхід до проектування програмних систем на микросервисах і стандартний підхід, заснований на монолітній архітектурі програми?

– Головною перевагою микросервисов є більш чітке розділення програми на компоненти, неможливість зробити в коді локшину тепер не гарантується конвенціями і корпоративним стандартом проектування, а фізичним поділом кодових баз. Якщо у вас вже все правильно спроектоване, то підхід в цілому відрізнятися буде мало, у вас будуть всі ті ж відповідають за свою задачу компоненти легко замінними реалізаціями, між якими будуть визначені контракти викликів. Швидше за все, із змін ви побачите тільки поява прошарку у вигляді мережевої взаємодії. Якщо спроектовано все неправильно, то микросервисы не зроблять магічним чином з поганої архітектури хорошу.

– Уявімо, що перед нами стоїть завдання спроектувати систему. Які є індикатори того, що слід застосовувати архітектуру, засновану на микросервисах?

– Головне — не намагатися розділити нероздільна, не використовувати микросервисы заради використання микросервисов. Подумайте над тим, наскільки у вас незалежні компоненти програми. У вас напевно є кочує з проекту в проект код, слабо пов'язаний з рештою кодової базою. Хорошим прикладом є модуль інтеграції з платіжними системами. На вхід він повинен отримати суму і номер замовлення, у відповідь видати URL перенаправлення на той користувача, а в подальшому надіслати повідомлення про проходження платежу. У нього є чітко визначений інтерфейс взаємодії, який прекрасно лягає на REST API, його спокійно може робити що сидить в іншому місті команда, яка про ваш основний проект взагалі нічого не знає. Можна виділити в микросервис локалізацію текстів помилок, модуль збору курсів валют (курси валют взагалі побитий приклад для всього підряд, що, втім, не робить його поганим).

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

– такий підхід до проектування впливає на відмовостійкість і надійність кінцевої системи?

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

Головна проблема — розмивання відповідальності
Які є підводні камені при застосуванні архітектури на микросервисах?

— У нас вузька спеціалізація. Один пришиває кишеню, один — проймочку, я особисто пришиваються ґудзики. До ґудзиків претензії є?
— Ні! Пришиті на смерть, не відірвеш! Хто пошив костюм? Хто замість штанів мені рукави пришив? Хто замість рукавів мені штани пришпандорил? Хто це зробив?
— Скажіть спасибі, що ми до гульфику рукав не пришили.
А. В. Райкін про микросервисы

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

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

– Які технології ви пропонуєте використовувати для реалізації микросервисов? Як і за якими протоколами відбувається обмін даними між окремими микросервисами?

– Оскільки сама ідея микросервисов припускає, що вони можуть розроблятися на різних фреймворках і мовами програмування, свій вибір слід зупинити на максимально простих і переносите протоколах, інструменти для роботи з якими є скрізь. Тобто, звичайне REST API поверх HTTP для синхронного взаємодії та обміну повідомленнями на кшталт RabbitMQ для асинхронного. Відповідно, для реалізації .NET рекомендую використовувати WebAPI, RestSharp, EasyNetQ. Для документування REST API себе добре зарекомендував RAML, але це вже справа смаку і конкретної команди.

Не застосовуйте микросервисы заради застосування микросервисов
–Означає така архітектура, що всі сервіси повинні працювати асинхронно?

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

– чи Буває таке, що дроблення системи на микросервисы стає шкідливим?

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

– Як тестувати і відлагоджувати таку систему?

– Якщо ви застосовуєте микросервисы там, де це виправдано, то ніяких проблем з тестуванням і налагодженням у вас не може бути в принципі, оскільки кожен сервіс має строго певний набір ізольованих завдань та вимог і може бути без проблем протестований як будь-яке інше відокремлений додаток.

– Як і за допомогою яких інструментів можна швидко зрозуміти, де сталася відмова, помилка або падіння, якщо робота всієї системи раптом зупинилася? Чи такого не буває через незалежності сервісів один від одного?

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

– Архітектура на микросервисах — це новий і сучасний підхід до проектування або просто добре забуте старе?

– Микросервисы — це такий Unix-way, коли є набір програм, кожна з яких робить щось одне, а потім їх пов'язують разом. Тільки замість текстових потоків stdin/stdout у нас тепер REST API і системи обміну повідомленнями. Також можна згадати давню запеклу дискусію про монолітних і микроядрах ОС (на ринку перемогли у результаті монолітні).

Що ще цікавого буде в вашій доповіді на конференції DotNext 2016 Moscow?

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




Послухати доповідь Микити можна буде 9 грудня в рамках конференції DotNext (реєстрація).

Також у програмі:

.NET Core: State of the art
Squeezing the Hardware to Make Performance Juice
Інтелектуальні чатботы і когнітивні сервіси
Stack Overflow — it's all about performance!
Advanced Xamarin.Forms
C++ через C#
Продовжуємо говорити про арифметику
ASP.NET SignalR: Why it's Getting Really Crucial for Web Development
Exceptional Exceptions in .NET
Модифікація коду .NET у рантайме
ETW — Monitor Anything, Anytime, Anywhere
End-to-end JIT
Performance tuning Stack Overflow tags
C# Scripting — why and how you can use your C# in places you never thought of before!
Multithreading Deep Dive
Зібрати все, або Знайомимося з Cake (C# Make)
WinDbg Superpowers for .NET Developers
Overview of the new .NET Core and .NET Platform Standard
Які знаходять уразливості в .NET платформі і як не повторити їх в своїх додатках
what's new in C# 7?

І невелике опитування по темі.

Джерело: Хабрахабр

0 коментарів

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