Проверяем Архитектурные стили на движке Factorio (часть 2, SOA)

Для понимания того, чем мы тут занимаемся обязательно прочтите предыдущую статью:

Часть 1

Вводная

Добрый день снова, дорогие читатели!

В продолжение первой части мы сегодня будем снова пробовать разные Архитектурные стили и сегодня мы переместимся с Монолита на Сервисо-ориентированную архитектуру (Service-Oriented Architecture или SOA) на движке Factorio. Наконец-то мы не просто соберём данные, но ещё сравним их с нашим предыдущим замером различных параметров — с Monolith.

Наконец-то мы узнаем, какие преимущества имеет первый и второй стиль. А то ли ещё будет позже!

С этого момента я начну писать название Архитектурных стиле на английском языке, чтобы их можно было легко глазами выискивать в тексте и ещё избавиться от двузначности терминов.

Начнём!

Сервисо-ориентированная архитектура (Service-Oriented Architecture или SOA)

Немного вспомним, чем интересен данный архитектурный стиль.

Именно в нём начались первые попытки разбивать запутанные, монолитные приложения по программной логике: что-то занимается фронтом, что-то считает деньги, что-то хранит файлы, что-то взаимодействует с БД и так далее. Чтобы всё это работало относительно независимо друг другу, придумали всё соединять некой шиной — Enterprise Service Bus (далее просто «Шина»). Именно эта шина содержала в себе логику «что, куда и при каких условиях отправлять», а при этом остальные сервисы просто принимают от шины запросы, обрабатывают их и возвращают обратно в шину.

На бумаге это выглядит так, что каждый сервис можно назначить определённую команду программистов и они будут писать код под стандарты Шины не отвлекаясь на то, то твориться в соседних командах/сервисах.

Однако, если углубится в Интернет за поиском дополнительной информации по этой архитектуре, то можно увидеть по ней есть прямо множество статей, но при этом все этот стиль не рекомендуют к применению. А причина проста — она содержала кучу критически важных минусов для Продукта. При этом популярность её обусловлено тем, что именно она дала толчок для развития в сторону других Архитектурных стилей (Service-Based, Space-Based, Event-Driven и Microservices), которые мы ещё рассмотрим в будущем.

У SOA выделяют один существенный недостаток — запутанная логика в Шине. То есть когда приложение будет расширяться, всё больше и больше логики «что-куда-когда» будет заноситься в Шину, а поскольку она является критическим, связующим звеном для всех сервисов — ошибка в ней чревата сбоями в работе приложении. Плюс к командам разработки отдельных сервисов ещё появляется необходимость выделения и команды разработки Шины, работа где будет сложна: поддержка критичной для приложения компонента; постепенно растущая и запутывающаяся логика работы Шины; множество взаимодействий с командами Сервисов со своими уникальными хотелками. В общем, именно на этом аспекте и не удалось получить от Архитектурног остиля ни ускорения разработки, ни надёжности.

Когда мы будем пробовать смастерить эту архитектуру в Facrorio, мы должны будем наткнуться на ту же проблему — поддержка Шины должна будет потреблять достаточно большую долю человекочасов разработки продукта. Если это будет так и у нас — значит мы реализуем нечто похоже на то, что было в реальных приложениях на SOA-архитектуре. Конечно, реальная разработка не является игрой и поэтому тут будут ряд условностей, но без них никуда.

Предварительный план

Давайте сразу же определим основные аспекты Стиля и попробуем перевести это в игру до её начала.

Во-первых, REST API к этому моменту ещё не так был популярен для использования, а значит различные производства будут связываться через всё те же конвейера. Разница только в том, что теперь нам нужно подводить сырьё к заводу по Шине и в неё же вливать результат производства.

Во-вторых, пользователи всё так же будут приходить к нам в приложения по ЖД. И как и в Monolith’е, в SOA это должно быть единственное использование ЖД во всём продукте.

В-третьих, ни в коем случае нельзя смешивать производства, как это было в Monolith’е — если уж ответвились для создания, например, Зелёных Микросхем, то только для Зелёных Микросхем эта ветка и предназначена.

В-четвёртых, электростанция тоже будет частью одной из веток Шины. Но она будет только потреблять ресурсы с Шины, а но не отдавать (электричество особо на конвейер не положишь).

В-пятых, трубы с жидкостями так же придётся вести по Шине.

В-шестых, конвейера в Шине должны будут двигаться в обе стороны т.к. ряд сырья будет требоваться не только впереди по заводу, но и сзади (например, то же ядерное топливо из середины Шины придётся вести к электростанции, располагаемой в самом начале).

В целом всё. На данный момент я вижу тут две сложности и одну легкость:

• Первая сложность — я не представляю, как будет работать Шина и насколько сложно/возможно будет её обслуживать;

• Вторая сложность — из-за всё той же Шины весь завод будет занимать кучу места, на что достаточно скоро сагрятся жуки;

• Легкость — вертикально расти при такой схеме будет значительно проще. Главное оставлять пространство между ответвлениями от Шины.

Пока же я набросал следующую схему Шины:

В теории всё выглядит хорошо: заводы будут расширятся условно бесконечно вниз, а Шина расширяется условно бесконечно вправо и, чуть медленней, вверх. Даже есть место чтобы развернуть некоторые конвейера в случае необходимости (наверное).

Но опять же — это всё прототип, а игра не так проста и в ней явно возникнут сложности ближе ко второй половине игры. По сути тут нужно будет всегда соблюдать правило «не тулить» и оставлять место как между ветками, так и в самой Шине. Ну и нужно будет ОЧЕНЬ много конвейеров и труб…

В общем, думаю, что можно пробовать начинать…

Старт игры. Пилот

Для того, чтобы обеспечить постройку самой Шины, подключить всё к ней и при этом не испытывать проблем со стройматериалами — я в первую очередь наладил производство базовых предметов (конвейеров, заводов, манипуляторов, печей и т.д.). Для этого я по-быстрому создал небольшой заводик прямо возле ископаемых ресурсов и сделал там по примеру прошлого захода — Monolith’а. Как выяснилось, это было удачным решением т.к. предметы на Шину расходуются крайне быстро и стартового набора не хватило бы даже на то, чтобы создать самые первые производства.

Ну и для науки: видимо отныне все Архитектурные стили всегда придётся начинать с мини-Monolith’а. Это даже чем-то напоминает на MVP.

В целом мой план работает хорошо: сначала я подключил переплавку ресурсов, потом перенёс электростанцию в начало, ну и продолжил создавать различные зоны производства (шестерёнки, колбы и т.д.). Пока всё это хорошо расширяется — заводы можно расширять вниз, а Шину — вправо. А если будет достигнут лимит по расширению завода — никаких проблем не будет сделать ещё одну зону с аналогичным производством далее по Шине.

Пока я делал это всё, меня не покидало желание экономить — то расположить завод теснее, чтобы позже добраться до жуков; то сделать поменьше ширину канала в Шине. Оно и верно — по ощущениям на создание Шины и подключения к ней уходит неприятно много времени, а предметов на конвейере пока не много. В общем, это именно то, с чем приходится морально бороться с собой и не допускать подобные мысли.

Чуть позже у меня нарисовались две проблемы:

Во-первых, у меня меня достаточно быстро истощились стартовые рудник железа, меди и камня, а до ЖД было ещё далеко (я даже не успел наладить производство Зелёных микросхем для Зелёных колб). В итоге пришлось временно тащить пару путей из конвейеров от ближайшей жилы. Когда у меня будет ЖД — я переведу этот костыль на поезда, но пока только так. Относительно Продукта это означает что мы начали не укладываться в Сроки — вместо того, чтобы полноценно впустить пользователей мы всё ещё работаем с ограниченным числом пользователей. То есть у нас происходит что-то вроде закрытого Альфа-тестирования, но при этом приложение готово взять и бóльшую нагрузку — странная ситуация.

Во-вторых, я территориально разросся так, что уже начал подходить к месту дислокации Жуков. То есть мы ещё в добавок начали выходить за Бюджет. Поскольку скоро начнутся нападения (ака нападки Бизнеса на неукладывание в бюджет), я прервал наладку производства Зеленых колб и сконцентрировался на производстве оборонительных сооружений (стены, турели и патроны к ним) и Чёрных колб. На текущем этапе игры убивать их ульи крайне сложно — у меня открыто не так много исследований на военное дело, а воюю уже со Средними червями. В общем, когда «Бизнес» начинает давить на проект в плане затрат — начинается крайне нервная работа в пустую по обоснованию Сроков и Бюджета. Позже, с увеличенным уроном и гранатами, уничтожать ульи стало легче, но всё это всё равно на это потратился достаточно ощутимый процент общего времени, которое можно было бы потратить на движение по пути полноценного старта работы пользователей.

В общем, всё плохо.

Зато я, как ни странно, я не испытываю проблем с Конвейерами: как только я наладил производство Желтых Конвейеров оказалось, что их производственных мощностей хватает для поддержки как Шины, так и Завода в целом (если помните, в Monolith’е с этим были большие проблемы). В общем, как ни крути, Архитектура медленно и верно начинает себя окупать.

Сама Шина уже начинает разрастаться так, что её становится проблемно обслуживать — даже её план уже в экран не помещается. Пришлось снова чуть-чуть отвлечься от ЖД и сделать производство радаров — расставив их у меня открылась вся карта и работать с разросшейся Шиной стало проще.

Ещё очень много тратится времени на расположение, строительство и подключение Шины. При этом полностью воспользоваться вместимостью этой Шины так и не смог — по её широким каналам перемещаются тонкие ручьи предметов и только в где-то в конце оно накапливается в ожидании потребления…

Ну а спустя некоторое время я вообще упёрся в большое озеро по пути хода Шины и пришлось ещё раз отвлекаться на производство земли для отсыпки территории.

В общем, одни проблемы и я не представляю, как это всё можно было бы предугадать на первоначальном этапе планирования работы с SOA. Уже прошли игровые сутки, а я даже не успел поставить производство предметов для запуска ЖД (напомню, что в Monolith’е к суткам игры мы уже завершили игру).

Из хорошего могу отметить следующее:

• Расширять Шину и подключать к ней заводы оказалось достаточно просто, хоть и долго — по сути работает принцип копировать-вставить и дальше начинают работать дроны. Короче, достаточно монотонная работа;

• Затыков на Шине нет — все ресурсы поступают вполне себе равномерно и есть ещё много места для роста;

• Шину не обязательно прямо всегда строить, тратя конвейеры — редко используемые потоки ресурсов можно не вести вперёд до востребования, однако нужно не забывать всегда оставлять под них места в Шине.

И ещё отмечу один минус: всё это очень трудозатратно по предметам, по территории и по времени — бюджет на разработку явно раздуется на всё это безобразие, а начало получения прибыли всё откладывается и откладывается…

Обрастание фичами

ЖД наконец-то подключено — железо, медь и уголь полились рекой.

Уже сейчас можно заметить, что всё развитие продукта движется крайне медленно: если в Monolith’е основной проблемой было придумать как втулить то или иное запутанное производство, то здесь таких вопросов не возникает, но от этого времени и ресурсов уходит далеко не меньше.

Плюс возникает много смежных проблем: то начали кончатся конвейера для постройки Шины, то земля (пока строил на воде), то жуки вечно норовят прорвать оборону.

Ещё я заметил, что ресурсов как таковых у меня много, но вот они все застряли в неактуальных местах: то в самой Шине, то на не приоритетном производстве — в Monolith’е подобного у нас такого не наблюдалось в подобных масштабах. Зато если построить завод в текущем конце Шины, то все эти зависшие ресурсы из Шины идут именно на новое производство и мы на первое время получаем заметный прирост данный предметов. Из-за этого на графиках всегда можно заметить пик производства в самом начале, а потом оно нормализуется.

Ещё странным выглядит подключение к Шине тех производств, которые не могут быть продолжены (например, Электрические столбы, Длинные манипуляторы, Ящики). У меня возникало куча вопросов вида «зачем они здесь, ведь оно не будет давать результата обратно в Шину»? Но правило есть правило.

Жуки прямо покоя не дают: вдалеке от центра их много и они хорошо защищены. И неизвестно, что с этим можно сделать: в Monolith’е удавалось с ними мало контактировать из-за малого размера завода; в будущих Microservices’ах я предполагаю, что можно будет делать производства равномерно от центра. Но в SOA мы просто ведёт Шину в одну сторону навстречу ульям на весь экран и Чудовищным червям.

Забавный случай произошёл с Шиной: когда я реализовал производство Синих колб я понял, что мне нужно будет везти их обратно в начало шины, где у меня располагаются Лаборатории. Но это оказалось не так просто т.к., во-первых, придётся вести достаточно дорогостоящие Синие колбы через весь завод, что крайне накладно; во-вторых, места для «обратного» хода конвейера внезапно не нашлось и пришлось вести их по достаточно запутанному пути, чтобы обойти все уже существующие дорожки Шины. В итоге нашлось неожиданное решение перенести Лаборатории в центр Шины, что решило эти две вышеуказанных проблемы, но добавило кучу работы по переделке Шины

Такие же проблемы были и с патронами, и ракетным топливом для поездов, и с ядерным топливом для электростанций. В общем, Шина начинает усложняться и явно не этого хотели от SOA архитекторы в своё время.

В целом по карте загрязнений можно увидеть, что активно работает только заводы в начале и конце Шины:

Объясняется это просто: в начале производства находится электростанция и переплавка руд, поэтому они «фанят» всегда и сильно. В конце находятся недавно запущенные заводы, которые ещё не успели заполнить Шину своей продукцией. Ну а в центре (преимущественно) находятся уже те заводы, которые успели отработать и остановится из-за того, что «Выход заполнен».

Есть и хорошие новости:

Во-первых, если организовывается производство чего бы то ни было, то можно быть уверенным, что уже через полчаса у нас будет много выходного продукта от него;

Во-вторых, сделать дублирующее производство, если чего-то не хватает, проще простого — скопировал и подключил к Шине. Например, я так делал с шестерёнками и зелеными/красными микросхемами и получил заметный прирост их производства. Главное — это вовремя сообразить, что у тебя есть нехватка чего-бы то ни было.

Касательно расширения самой Шины: ближе ко второй половине игры строить её стало морально легче — то ли из-за обилия комплектующих для неё, то ли получилось просто привыкнуть к этой работе. Но это чисто ощущение — времени на неё тратиться всё так же заметно, как и в начале.

Интересности были с электричеством:

Сначала оно кончилось просто потому-что стало поступать мало воды — пришлось переносить его со старого места ближе к озеру (по сути подключать воду в обход Шины). Позже истощилась шахта с углём начались нарушения поставки угля к бойлерам — пришлось отвлекаться и аварийно создавать ещё пару удалённых шахт угля. Ну и аккурат к переходу на АЭС я понял, что достиг максимума в использовании паровых двигателей. Конечно, можно было бы ещё попробовать как-то оптимизировать подачу пара, но благо этого не потребовалось.

Атомка без проблем запустилась не смотря на достаточный долгий процесс обогащения урана — Шина позволила принять много урана и достаточно быстро обеспечить подачу урановых стержней на Шину. Если помните, на Monolith’е я АЭС сделал чуть ли не в конце игры т.к. процесс обогащения урана еле-еле «разгонялся».

Ну и последнее — по исследованиям:

Колб как таковых всегда хватает — делаешь производство и их всегда поступает тысячами в Шину. Но сделать производство новых видов колб реально занимает много времени. В итоге получается такая картина: быстро открываются все исследования, которые требуют тех колб, производство которых у меня уже налажена, но потом возникает долгая пауза в исследованиях т.к. для них нужны новые виды колб; потом производство новых видов колб всё же запускается и вся очередь исследования достаточно шустро открывается; потом опять начинается потребность в новых видах колб и начинается долгая пауза… Чую, что итоговый график будет похож на лесенку — посмотрим по завершению текущей игры. Напомню, что в Monolith’е была ситуация более сбалансированной: пока изучаешь текущее исследование — активно строишь заводы на новые виды колб (хотя и под конец игры этот принцип стал сбоить).

В общем, если вы используйте SOA, готовьтесь к тому, что вы будете долго-долго оставлять Бизнес без актуальных фич просто потому-что морочетесь с Архитектурой как таковой, но потом сможете выкатить всё пачкой и с достаточно большим запасом по производительности.

Рывок до конечной цели

Пришла пара начинать создание ракеты. Тут можно выделить три интересности:

Во-первых, хоть я и расширял создание Зеленых микросхем — их всё равно катастрофически мало. А всё потому-что их производство находится очень далеко актуального производства и большая часть продукции «сжирается» по пути. И тут не помогает ни переход на Красные конвейера, ни переход на улучшенные виды заводов, ни масштабирование. В общем, индивидуальный контроль внутри Шины требует дополнительных трудовложений и ещё больше увеличивает сложность Продукта.

Во-вторых, под конец я столкнулся с похожей мыслью, что была и в начале — «Зачем мне выводить в Шину дорогостоящее производство, если можно подключить её в рядом стоящую ракетную шахту». Посмотрите сами на то, как близко располагается производство Спутников от Ракетной шахты и думаю, что у вас тоже возникнет желание не тянуть их в Шину, а подключить напрямую. Но правило есть правило.

И на этот раз это реально не окупилось — ну зачем мне полная линия дорогостоящих спутников, если достаточно одного раз в несколько часов?

В третьих, из-за перепроизводства стали кончаться уже существующие шахты/жилы нефти, меди и железа. Это странно т.к. я их достаточно много наделал когда подключал ЖД. Но, видимо, это такая особенность Архитектуры — так сказать «Цена за самоподдержание».

Итого по финалу:

• Затрачено реального времени в 23 дня;

• Убито жуков: 2’411’763

• Убито червей: 3848

• Убито ульев: 3626

Вот ещё я сделал гифку сравнения размера завода с Monolith’ом:

Сохранение

Видео

Во всей этой картине меня особенно пугает ни затраченное время, ни количество убитых кусак, а на почти 2.4к убитых Чудовищных червей. Не думаю, что другие архитектуры покажут такие же цифры.

В целом приложение получилось достаточно производительным и в меру удобным в плане расширения. Но уж очень громоздкое — ты идёшь на километры в одну сторону и никак ты с этой дороги не свернёшь.

Мне этом приложение напоминает старые, исполняемые файлы на Java: один большой, исполняемый файл, который просто, но долго переносить, а так же запускается он крайне медленно.

Сразу же после окончания у меня встал вопрос: «А сколько же я времени убил на развитие Шины по сравнению с остальными работами?». По ощущениям это было около 40%. Чтобы проверить это я поделил реплей на 11 частей и замерил, сколько времени я тратил на работу с Шиной. Вот результат:

В целом ощущения не подвели — 30-40% времени в зависимости от этапа. При этом можно заметить, что график достаточно равномерный и по мере развития приложения баланс количества работы над Шиной к работе над самим Приложением более-менее сохраняется.

Теперь переходим к замеру параметров данного Архитектурного стиля.

Evolvability

Тут мы сравниваем, как быстро мы провели открытия различных исследований.

В отличие от Monolith’а, в текущем Архитектурном стиле пришлось изучать ещё много чего дополнительно, чтобы справится с Жуками и построить завод на озере. Плюс был немного изменён порядок исследований — то есть у нас появился такой фактор как «Сервисные фичи». Это означает, что есть не представляющие особой ценности Бизнесу, но необходимы для того, чтобы Архитектура работала как таковая.

Ну и ещё тут наблюдается такая тенденция, что изучение новых технологий при налаженном производстве никак не тормозит движение в финишу — так было изучено много фич, которые оказались невостребованными (например, «Огнемёт» или «Танк»). Но количество (но не разнообразия) колб и времени часто хватает с лихвой, так что проблем с этим нет.

Диаграмму придётся обезличить т.к. порядок исследований был нарушен. Вот график «по возрастанию» количества исследований:

Шкала оси Y — сутки; шкала оси X — исследование по порядку.

Что можно сказать по этому графику:

Самое главное и очевидное с первых часов игры — на достижении всех основных целей потребовалось в 5 раз больше времени, чем в Monolith’е. То есть, чтобы примерно сравняться по времени разработки с Monolith’ом нужно увеличивать команду разработки в 5 раз.

Я знаю правило по поводу увеличения количество сотрудников в проекте вида «две женщины не могут родить в 2 раза быстрее», но тут я это намеренно опустил из расчётов т.к. другой коэффициент продуктивности по увеличению количества программистов я удачно применить не могу. В разных компаниях эта формула разная: можно нанять наивысших специалистов с ЗП по 1 кв.метру квартиры в Сингапуре в месяц, но которые будут работать 24/7 и выдавать ту самую удвоенную (а то и больше) скорость разработки; а можно нанять толпу лентяев за пачку Анакома и удивляться, что ничего не ускорилось. В общем, берите пока наиболее простой расчёт от меня и накладывайте его на свой реалии.

Если разделить значения в графике SOA на 5, то получится тоже очень интересный график:

Во-первых, сразу видно, что за то же самое время мы смогли сделать значительно больше фич. Да, часть из них не требуются в Monolith’е (та же «Отсыпка территории» или военные исследования), но всё же факт есть факт. Если бы не это не приходилось бы делать, то можно было увеличивать число сотрудников команды не на 5, а на 3, но это уже утопическая лирика.

Во-вторых, как только мы в начале игры закончили Monolith-времянку, мы почти сразу же получили не хилый буст по фичам, который и не снился в Monolith’е — по сути мы его догнали по скорости. Но потом начался этап, когда нужно было поднимать производство новых видов Колб и появилась необходимость активно расширять Шину, создавая новые производства. И так до следующего буста по кругу.

В общем, это та самая «лесенка», о которой я предполагал ранее — на шаге 17 мы получили буст от Зелёных Колб и быстро изучили всё нужное, но потом появился простой до шага 65, где пришлось ждать наладку производства Чёрных колбы. Подобное было потом на шаге 79 — от Синих колб; на шаге 111 — от Фиолетовых; на 123 — от Желтых. Как то так.

Ещё можно заметить, что у нас в SOA начались первые исследования немного раньше, чем в Monolith’е — связано это с тем, что в SOA я строил временный монолит как попало (лишь бы обеспечить себя ресурсами на первое время), а потом просто всё снёс. В то же время в попытках построить Monolith я изначально пытался все строить более-менее правильно, держа в голове, что всё это будет расширяться.

В общем ситуация странная: относительно производства простоев нет и всё идёт в сторону Прекрасного Продукта, но относительно Бизнеса мы прямо очень сильно контрастируют на фоне Monolith’а по срокам и бюджету.

Ну и напомню, что из этих 5-и человек двое будут работать полностью с Шиной — это те самые 30-40% времени на обслуживание Шины, что мы высчитали ранее. Остальные 3 человека поделят между собой обслуживание производств (их 98 штук), поставку сырья (их 16 штук), а так же решению ИБ- и Бизнес-вопросов. Такие дела.

Agility

Тут мы оцениваем, насколько раньше/позже у нас произошли важные события в нашем Продукте.

Таблица по производству и прочим событиям:

Опять же, некоторые события случались только в Monolith’е или только в SOA, поэтому график будет немного «рваным»:

Читать это график следует следующим образом: выбираем нужно событие и смотрим, когда оно было в Monolith, а когда в SOA и, отдельно, в SOA/5 (с увеличенной в 5 раз командой). Например, тут можно заметить, что первую атаку жуков мы спровоцировали значительно раньше Monolith’а, а так же значительно позднее запустили ЖД. Зато запустили ракеты и АЭС мы почти одновременно при в случае «SOA/5». Ну и с чистым SOA сравнивать смысла нет т.к. в этом случае позднее будет абсолютно всё.

В общем:

• Запуск АЭС — одновременно, при увеличении количества команды в 5 раз;

• Отказ от сжигания угля — одновременно, при увеличении количества команды в 5 раз;

• Запуск ракеты — одновременно, при увеличении количества команды в 5 раз.

Можно ли считать тогда считать, что в плане финальных целей SOA идентичен Monolith’у, но просто требует больше «рук»? Вопрос спорный и поэтому придётся посмотреть ещё на другие особенности Архитектурного стиля SOA.

Configurability

Тут мы сравниваем, какие производства нам пришлось улучшать по ходу игры и какой прирост производительности при этом достигли.

Если в Monolith’е мы могли наращивать производство чего-либо в ущерб другому, то теперь на это тратится только площадь и электроэнергия, а само перенаправление не запутывает конвейера на заводе — мы просто подключаем его к Шине по аналогии с остальным. Иными словами — процесс больше похож на масштабирование внутри приложения, чем на переписку кода.

Цифры прироста, правда, не особо впечатляющие:

То есть в SOA любое реконфигурирование даёт прирост, стремящийся к удвоению, но при этом работает не в ущерб другим производствам. В Monolith же, в виду более простой Архитектуры, можно сделать прямо впечатляющий прирост, но только путём отключения или значительного уменьшения другого(их) производств(а).

Cost

Тут мы определяем, какую площадь завода и потребление его электроэнергии — это прямое отражение стоимости одного запущенного приложения.

Собственно, большие проблемы с Жуками связаны исключительно с занимаемой площадью приложения. Сравните его с Monolith’ом:

Это ужасает — площадь приложения на SOA больше примерно в тысячу раз Monolith’а и всё это вина Шины. Хотя при этом потребление электроэнергии сравнительно маленькая — связано это с тем, что не все производства в нём работают одновременно (см. карту загрязнений).

Собственно, подобные площади очень сильно сказались на следующем эксперименты — Deployability.

Deployability

Тут мы оцениваем, насколько долго мы будем строить второй экземпляр завода по времени — то есть сколько времени понадобиться на разворачивания второго экземпляра нашего приложения.

Я то думал, что за счёт того, что моё производство всяких строительных расходников многократно превышает то, что было в Monolith’е и я смогу значительно быстрее развернуть второй экземпляр Завода. Но, к сожалению, сам Завод разросся до таких объёмов, что получилось ещё хуже, чем в Monolith по времени:

В общем и целом, большие объёмы дали о себе знать — на то, чтобы развернуть копию завода ушло в 5 раз больше времени, чем на Monolith. Эта цифра связана не со сложность приложения, а исключительно с большим объёмом — большую часть времени я просто либо что-то строил по плану, либо ждал расходников.

Сохранение

Scalability/Perfomance/Testability

Тут мы будем оценивать максимальное производство ключевого продукта с и без учёта Масштабирования, а так же в целом скорость реализации проведения подобного замера.

При тестировании производительности мы, как всегда, даём бесконечный буст сырья (железо, медь, нефть и прочее) и смотрим, какую производительность покажет производство Частей ракет и Спутников. Тут есть интересность: если в Monolith’е мы получали буст производства в течении нескольких минут, то в SOA на это уходит чуть меньше часа — сырьё долго идёт производственный путь с начала Шины до целевых производств.

На скриншоте видно, что мы подключили бесконечное сырьё ~54 минут назад, а производство начало уверено расти только ~4 минуты назад

Более того, если подождать ещё, то можно заметить, что оно ещё и медленно разгоняется и ждать стабилизации производства приходится достаточно долго — около 12-ти часов.

Тем не менее рано или поздно оно стабилизируется и можно снять параметры и сравнить с Monolith:

В качестве 100% мы берём контрольные измерения производства Частей ракет и Спутников от SOA и сравниваем его с масштабированием и цифрами от Monolith. Как видно, прирост производительности получился большой. Более того, здесь значительно лучше показывает себя вертикальное масштабирование, а вот горизонтальное не сильно лучше Monolith’а. Ещё радует значительный прирост производства спутников: не смотря на то, что в Monolith и в SOA у нас на них был только один единственный завод — за счёт обилия расходников его производство возрастает многократно.

Что по тестированию:

Выглядит подключение для тестирования примерно вот так:

В плане времени видно, что SOA более предсказуема чем Monolith т.к. чем более сырьевое производство мы делаем, чем больше мы на это время тратим. Но не из-за попыток придумать КАК подключить тестирование, а больше из-за выбора места КУДА подключить. Зато за счёт ширины Шины получается дать больше сырья и, соответственно, получить больше производительности.

Elacticity

Тут мы просто высчитываем некое число эффективности скорости разворачивания к фактическому приросту производительности для сравнения.

На основании Deployability и Perfomance, можно сказать, что за 2467 минут мы получаем прирост на 163% частей ракет и на 148% спутников. Итого, умножаем это:

• Части ракет: 1.63х2467=4021.21

• Спутники: 1.48х2467=3651.16

Для сравнения, в Monolith’е у нас были числа 444.6 и 236.5 соответственно — то есть в нём за меньшее время мы получили большее число производительности при Горизонтальном масштабировании, а значит Monolith эффективней SOA в этом плане.

Domain Partitioning

Тут мы смотрим, насколько легко логически разделить завод на зоны производства и на сколько они плотно друг к другу располагаются — это напрямую влияет на сложность расширения продукта в будущем.

Основные зоны производства стоят параллельно Шине и, хотя они плотно находятся друг к другу по бокам, но вниз у каждого из них есть место для роста — собственно это помогло ранее сделать Вертикальное масштабирование. Так что как таковых плотно стоящих зон у нас не наблюдается, но и возможность расширения только в одну стороны сложно назвать «Хорошо разграниченной зоной». Думаю, что с этого момент введём новое состояние зоны «С ограничениями» — то есть расширяться можно, но не в любую сторону.

Итого:

• Хорошо разграниченных зон: 16

• Плотно стоящих зон: 0

• С ограничениями: 98

Думаю, такое количество зон «С ограничениями» мы будем наблюдать только в SOA, но это не точно.

Что бесспорно, это у нас стало лучше, чем было в Monolith’е:

Abstraction Level

Тут мы высокоуровнево обозначаем части продукта по назначению и смотрим, как сильно оно перемешано:

Если проанализировать уровень абстракции, то тут в основном всё замечательно: Ресурсы добываются где-то в стороне, от ЖД начинается Шина и по всей её длине идёт Основной завод, изредка переключаясь на «Переработку ресурсов» и ещё реже на «Хранилище». На этом уровне всё выглядит достаточно комфортно для понимания принципа работы приложения, что нельзя было сказать про Monolith.

Сравните, ради интереса, с тем, что у нас было в Monolith’е:

Fault Tolerance

Тут мы пробуем сломать наш завод путём DDoS- и хакерской атак.

С жуками просто: они прорвали оборону через 125 минут. При этом под раздачу попал не сам завод, а точки добычи ресурсов и пути к ним. А без добычи ресурсов сырьё просто кончилось и всё встало.

С вторым вариантом (имитация DDoS) вышло интересней — на то, чтобы полностью застопорить работу завода путём посылания «паразитных» поездов (трафика), ушло 7:40:19 (почти 8 часов) времени.

По количеству поездов ситуация следующая:

Поскольку в данном Архитектурном стиле ЖД играет более значимую роль из-за своих объёмов, то и она оказалась более стойкой к большому количеству поездов. По сути, если не считать мелкие улучшения и проблему с кольцевой дорогой — производство упало только под конец, когда станции просто не могли обменяться друг с другом поездами из-за занятости обоих. Хотя в процентном соотношении разницы не очень много, конечно, но мы тут больше смотрим на количество поездов.

Deadlock на кольцевой дороге:

По финалу ЖД застопорилось примерно вот в таком виде — поезда просто упёрлись в установленный лимит составов на станциях и не могли двигаться т.к. им просто некуда ехать:

Если отключить лимит на станции, то станет только хуже — поезда начнут двигаться более хаотично и просто заблочат проезды другим поездам:

Сохранение

Общий вывод по SOA

Если сравнивать с Monolith’ом, то можно выделить следующие достоинства SOA:

• Значительно больший запас производительности — продукт реально сможет как принять больше нагрузки изначально, так и иметь значительно больший прирост производительности при масштабировании. Плюс при запуске новой фичи она сразу же имеет возможность принять большую нагрузку «по умолчанию»;

• На описании продукта на уровне абстракций получается вполне логичная и понятная схема взаимодействия вида [Сырьё]->[ЖД]->[Шина]->[Обработка сырья]->[Шина]->[Производство]->[Шина]->[Ракета]. Так же это очень хорошо сказывается на возможности добавления новых производств в Продукт — всегда просто сообразить, куда добавить новое производство (спойлер: тупо в конец);

• Удобство тестирования — подключить к какой-либо части Шины бесконечные ресурсы для проверки производительности значительно проще осуществить, чем в Monolith’е;

• Получается более развитая система точки входа для пользователей в плане нагрузки, включая DDoS — при этом она получается такой сама собой просто эволюционно по мере создания Продукта;

• Значительно проще выполнять Вертикальное масштабирование т.к. достаточно скопировать текущую схему заводов и либо дополнить его текущим подключением к существующему заводу, либо отдельно подключить его к Шине. Не идеально, конечно, но точно лучше того, что было ранее.

Но недостатков у неё имеются:

• Значительно более поздний запуск первых пользователей из-за технологических аспектов Архитектуры, что вызывает множество вопросов со стороны Бизнеса относительно сроков;

• Необходимость тратить много человеко-часов и ресурсов на поддержание работы Шины — это сказывается на увеличенный Бюджет, чему Бизнес рад не будет. Сама работа оказалась не сколько сложной и запутанной, сколько большой и монотонной;

• Получается очень большое приложение, что негативно сказывается как на Горизонтальном масштабировании, так и на необходимость тратить Бюджет на дополнительные серверные ресурсы. При этом прирост производительности при масштабировании не идёт ни в какое сравнение с получаемым увеличением производительности.

Как говориться, «Долго, дорого, качественно». Получается, что все недостатки SOA связаны именно с Бизнесом и его неудовлетворённым желанием выпустить продукт быстро и дёшево — именно поэтому SOA имеет столь негативную славу. Если Бизнес захочет новую фичу — он будет привлекать как минимум двух программистов (Шины и Сервисов) и ещё достаточно долго ждать, когда они договорятся и сработаются между собой.

Да, у нас получается достаточно структурированное и производительное приложение и любой программист бы им гордился, но если со стороны Бизнеса эти расходы не окупятся — приложение уйдёт в раздел «Провальные». Так что применять SOA стоит только при отсутствии конкуренции, спешки и необходимостью большого запаса производительности.

В следующей передаче — Service-Based Architecture или SeBA

В следующей статье мы продолжим идти по хронологическому порядку развития Архитектурных стилей и перейдём на Основанную на сервисах архитектуру (Service-Based Architecture или SeBA). Исторически команды, познав горький опыт использования SOA начали думать, что делать дальше и решили (наконец-то) заменить громоздкую шину на REST API.

Что из этого у них получилось — узнаем в следующей статье! А пока я временно прощаюсь с вами, душевно благодарю за прочтение моей работы и ухожу опять на полгода запускать новую игру с нуля — пожелайте удачи, ибо я вам этого тоже желаю 😉