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

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

Часть 1 (Про что статья + проверяем Monolith)

Вводная

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

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

Наконец-то мы узнаем, какие преимущества имеет первый и второй стиль. И это только начало!

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

Начнём!

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

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

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

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

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

Сама Шина технически (т.е. "грубо говоря") тоже является сервисом - то есть там есть своя программная логика и команда программистов, которую её поддерживают. Но никакой Бизнес-логики она не выполнят, а занимается только сервисной работой по приёму/передачи запросов из одного Сервиса в другой. Поэтому не представляйте себе Шину как какой-нибудь протокол передачи типа REST - это уже тогда другая архитектура получится. Ну и все прочие Сервисы обязаны работать по стандартам этой шины: получать от неё запросы, обрабатывать и возвращать результат обратно в шину. И никак иначе.

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

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

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

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

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

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

Во-вторых, пользователи всё так же будут приходить к нам в приложения по ЖД (т.е. по сети). И как и в 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'ом:

Сохранение (Поместить в %USER%\AppData\Roaming\Factorio\saves)

Видео реплея: YouTube и VK Видео

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

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

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

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

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

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

Evolvability

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

В отличие от Monolith'а, в текущем Архитектурном стиле пришлось изучать ещё много чего дополнительно, чтобы справится с Жуками и построить завод на озере. Плюс был немного изменён порядок исследований.

Вот график получился такой:

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

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

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

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

Как только мы в начале игры закончили Monolith-времянку, мы почти сразу же получили не хилый буст по фичам, который и не снился в Monolith'е - на первых порах мы даже обгоняли Monolith по некоторым исследованиям. Но это впечатление оказалось обманчивым и утонули в архитектуре мы достаточно быстро. А за это время конкуренты уже снимают все "сливки" с рынка.

Та самая "лесенка", о которой я предполагал ранее, явно проявилась. Если в Monolith'е у нас скорость исследования и скорость развития приложения шёл более-менее равномерно, то в SOA у нас при организации нового производства колб быстро-быстро проходили исследования и дальше просто начиналась пауза - исследования ждали, когда откроется производство новых цветов колб.

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

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

Ну и напомню, что из всей команды разработки 30-40% будут работать полностью с Шиной - это те самые 30-40% времени на обслуживание Шины, что мы высчитали ранее. Изначально кажется, что эти 30-40% нивелируются в SOA-архитектуру, но "увы и ах".

Agility

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

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

К сожалению, у меня пропала информация по "Новой атаке жуков". Ну и ладно - ценность ещё околомизерная.

Как видно, в SOA произошло больше разнообразных событий: тут и с ульями пришлось повоевать, и электростанции переносить (и не раз), и появилось такое понятие как "Временный монолит" (просто ряд производств, чтобы хотя бы физически можно было начать строить основную архитектуру) и пр. При этом в Monolith'е тоже были свои уникальные события, но сильно меньше.

Собственно из-за того, что у нас некоторые события не случились в том или ином стиле, график будет немного "рваным":

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

А ключевые события относительно Monolith'а случились в следующем соотношением:

• Начало строительства ЖД - в 8.1240 раз позже;

• Запуск АЭС - в 5.2927 раз позже;

• Отказ от сжигания угля - в 4.9593 раз позже;

• Запуск ракеты - в 5.1566 раз позже

Ну в общем мы поняли: SOA это не про скорость.

Perfomance

Ну что у нас по производительности нашего приложения? Может хоть тут SOA покажет преимущество по сравнению с Monolith?

Проверяем:

Повышение производительности действительно есть, а как и понижение:

• Ракетные модули получили прирост в 45.07%

• Спутники - 600%

• Коблы - 726.71%

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

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

А в целом результат явно хороший. Хоть в чём то мы худо-бедно выиграли Monolith :)

Deployability

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

Перенос осуществлялся путём полного копирования завода и размещения его немного ниже. И на эту операцию мой компьютер завис минут на 5:

Надежда была на то, что у нас скорость подобного строительства будет быстрее за счёт большой производительности и больших запасов. Но всё это достоинство просто разбилось от величины самого завода. По итогу получились такие цифры:

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

В общем и целом, большие объёмы дали о себе знать - на то, чтобы развернуть копию завода ушло в 5.215 раз больше времени, чем на Monolith.

Сохранение

Configurability

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

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

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

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

Cost

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

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

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

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

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.

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