Візуалізація інтеграційних додатків

image

З тих пір, як я почав виконувати обов'язки системного архітектора, мені частіше доводиться малювати прямокутники і стрілки, ніж писати програмний код. З цим можна було б боротися, наприклад, безсонними ночами брати участь у проектах з відкритим вихідним кодом, створювати підтвердження обґрунтованості концепції і демонстраційний код, але і там теж потрібно малювати прямокутники, щоб продемонструвати архітектуру. Ця стаття присвячена візуалізації обміну повідомленнями в розподілених системах, сервіс-орієнтованої архітектури (SOA) і микросервисным додатками при використанні методології розробки agile (цей термін втратив своє значення, але більш підходящого в даному випадку немає).

Що мені подобається у сфері програмного забезпечення в останні роки, так це те, що в більшості організацій, в яких я працював, цінуються принципи ощадливої і гнучкої методології розробки ПЗ. Всі прагнуть створювати готове програмне забезпечення (а не документацію), швидко видавати результат (а не займатися довгим плануванням), виключити втрати і реагувати на зміни. Для реалізації цих принципів використовуються такі методи управління, як Scrum, «канбан» та технічні методи, запозичені з методології екстремального програмування (наприклад, модульне тестування і парне програмування), а також методи CI/CD і DevOps. Загалом, я вирішив зібрати в одному місці схеми та інструменти проектування, які я використовую у своїй повсякденній роботі з розподіленими системами.

Проблеми моделі уявлень «4+1» і «смерть від UML»

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

Більшість схем, які я зустрічав, були засновані на моделі уявлень «4+1» Філіпа Крачтена, яка має уявлення розробки, процесу, а також логічне та фізичне представлення.

image
Модель уявлень «4+1». Зображення взято з книги Практичне керівництво по архітектурі підприємства (A Practical Guide to Enterprise Architecture), автори: Джеймс МакГаверн, Скотт Ст. Амблер, Майкл Е. Стівенс, Джеймс Лінн, Вікас Шаран, Элияс К. Джо, 2003 рік.

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

Застосовність діаграм

Як правило, ці уявлення описуються за допомогою уніфікованої мови моделювання (unified modeling language, UML), і для кожного подання потрібно створювати одну або кілька UML-діаграм. Якщо мені потрібно створити 15 типів UML-діаграм, щоб описати і доступно пояснити архітектуру системи, то це суперечить призначенню UML.

image
Death by UML (Смерть від UML). Фрагменти діаграми Пауло Мерсона Вікіпедії.

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

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

Застосовність уявлень

Уявлення, що відображають різні аспекти системи, — відмінна форма опису її концепції, однак існуючі уявлення моделі «4+1» не відповідають практиці розробки та впровадження сучасного програмного забезпечення. Ідея спрямованого потоку — коли спочатку створюється логічне уявлення, потім випливають з нього подання розробки і процесів, а в кінці і відповідне фізичне уявлення не завжди узгоджується з дійсністю. Життєвий цикл розробки систем відрізняється від традиційної (водоспадної) послідовності збору вимог, проектування, реалізації та супроводу.

image
Життєвий цикл розробки програмного забезпечення. Фрагмент малюнка Web Serv.

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

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

Засоби візуалізації інтеграційних додатків

Найкорисніша, з моєї точки зору, модель описана Саймоном Брауном і носить назву модель C4 (я раджу завантажити безкоштовну копію відмінною книги Саймона «Мистецтво візуалізації архітектури програмного забезпечення» (The Art of Visualising Software Architecture)). Описуючи свою модель, Саймон відзначає важливість наявності єдиного набору абстракцій, а не загальної нотації (наприклад, UML), та використання невеликого набору діаграм для створення абстракцій різного рівня: контексту системи, контейнерів, компонентів і класів. Цей підхід подобається мені тим, що передбачає рух від загального до часткового, починаючи з загального уявлення з його подальшою деталізацією на кожному новому рівні.

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

Виникає питання: які ж діаграми використовувати? Я використовую три типи діаграм, які позначаються абревіатурою SSD (хоча вона звучить не так здорово, як C4): контексту системи (system context), структури служби (service design) і розгортання (deployment).

Діаграма контексту системи

На цій моделі відображаються всі служби (як SOA, так і микрослужбы) з входами і виходами. Як правило, зовнішні системи розташовуються у верхній частині моделі служби — в середині, а внутрішні служби — у нижній частині. Іноді внутрішні і зовнішні служби розташовуються частково над проміжним рівнем, а частково і під ним, як показано на малюнку нижче. Поруч зі стрілками також корисно (хоча і необов'язково) вказувати протоколи (наприклад, HTTP, JMS, файловий) і формати даних (XML, JSON, CSV). Якщо кількість служб велике, то протоколи і формати даних, можна вказувати на діаграмах рівня служб. З допомогою стрілок я показую служби, ініційовані запити, а не напряму потоків даних.

image
Діаграма контексту системи

Ця діаграма дає хороше загальне уявлення про структуру розподіленої системи: її служби, внутрішніх і зовнішніх зв'язках, типах взаємодій (з протоколами і форматами даних) і їх ініціаторів.

Діаграма структури служби

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

image
Діаграма структури служби

Діаграма розгортання

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

image
image
Діаграма розгортання

Діаграма розгортання показує, як окремі служби і система загалом відносяться до вузлів (фізичним і віртуальним).

Поради щодо вибору інструментів

Діаграми контексту системи і розгортання складаються тільки з прямокутників та стрілок; для їх створення не потрібні спеціальні інструменти. Для створення діаграми структури служби вам знадобиться інструмент з функцією інтеграції EIP-піктограм. На поточний момент мені відомі такі інструменти з підтримкою EIP-значків:

  • Mac OS: OmniGraffle зі значками graffletopia. За допомогою цього інструменту я створив всі діаграми для книги Шаблони проектування Camel (Camel Design Patterns;
  • Windows: Enterprise Architect компанії Sparx Systems з EIP-значками Гаральда Вестфала. Крім того, тут знаходяться шаблони MS Visio;
  • • Інтернет: LucidCharts, до складу якого за замовчуванням включені EIP-значки. Цей інструмент найбільш простий у використанні і доступний в будь-якому місці.


Крім того, є ряд інших засобів розробки, за допомогою яких можна створювати EIP-діаграми:


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

ІТ-фахівці вміють знаходити собі завдання, які займають весь їх робочий час. Я впевнений, що якщо б у нас було більше часу, то ми б придумали ще десяток корисних уявлень, однак без цих трьох ми не змогли б описати додаток для інтеграції. Як колись сказав Антуан де Сент-Екзюпері: «Досконалість досягається не тоді, коли нема чого додати, а тоді, коли нічого прибрати».
Джерело: Хабрахабр

0 коментарів

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