Для понимания того, чем мы тут занимаемся обязательно прочтите предыдущую статью: Часть 1  Добрый день снова, дорогие читатели!   В продолжение первой части мы сегодня будем снова пробовать разные Архитектурные стили и сегодня мы переместимся с Монолита на Сервисо-ориентированную архитектуру (Service-Oriented Architecture или SOA) на движке Factorio. Наконец-то мы не просто соберём данные, но ещё сравним их с нашим предыдущим замером различных параметров - с Monolith. Наконец-то мы узнаем, какие преимущества имеет первый и второй стиль. А то ли ещё будет позже! С этого момента я начну писать название Архитектурных стиле на английском языке, чтобы их можно было легко глазами выискивать в тексте и ещё избавиться от двузначности терминов. Начнём! Немного вспомним, чем интересен данный архитектурный стиль. Именно в нём начались первые попытки разбивать запутанные, монолитные приложения по программной логике: что-то занимается фронтом, что-то считает деньги, что-то хранит файлы, что-то взаимодействует с БД и так далее. Чтобы всё это работало относительно независимо друг другу, придумали всё соединять некой шиной - 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% времени в зависимости от этапа. При этом можно заметить, что график достаточно равномерный и по мере развития приложения баланс количества работы над Шиной к работе над самим Приложением более-менее сохраняется. Теперь переходим к замеру параметров данного Архитектурного стиля. Тут мы сравниваем, как быстро мы провели открытия различных исследований. В отличие от Monolith'а, в текущем Архитектурном стиле пришлось изучать ещё много чего дополнительно, чтобы справится с Жуками и построить завод на озере. Плюс был немного изменён порядок исследований - то есть у нас появился такой фактор как "Сервисные фичи". Это означает, что есть не представляющие особой ценности Бизнесу, но необходимы для того, чтобы Архитектура работала как таковая. Ну и ещё тут наблюдается такая тенденция, что изучение новых технологий при налаженном производстве никак не тормозит движение в финишу - так было изучено много фич, которые оказались невостребованными (например, "Огнемёт" или "Танк"). Но количество (но не разнообразия) колб и времени часто хватает с лихвой, так что проблем с этим нет. Исследование Время для Monolith Время для SOA Автоматизация 00:54:35 00:31:31 Логистический исследовательский пакет 01:01:53 00:43:24 Производство стали 01:04:37 00:37:34 Логистика 01:07:14 00:30:36 Пулемётная турель 01:08:41 00:44:20 Электроника 01:12:27 00:35:22 Логистика 2 01:29:01 10:58:13 Двигатель 01:38:41 10:55:09 Железные дороги 01:46:36 10:59:24 Автоматизация железных дорог 01:54:05 11:00:32 Железнодорожные сигналы 02:04:03 11:02:00 Военная промышленность 02:04:26 01:04:27 Каменная стена 02:04:45 00:49:07 Военная промышленность 2 02:05:47 11:11:00 Военный исследовательский пакет 02:08:42 11:11:19 Продвинутая металлургия 02:16:33 11:09:18 Огнестрельный урон 02:22:54 01:54:49 Скорострельность оружия 02:27:14 01:29:43 Огнестрельный урон 2 02:35:39 11:04:50 Скорострельность оружия 2 02:44:53 11:07:44 Огнестрельный урон 3 03:21:40 19:36:24 Быстрый манипулятор 03:22:17 00:48:12 Автоматизация 2 03:22:53 11:08:08 Транспортировка и хранение жидкостей 03:23:41 11:11:51 Вагон-цистерна 03:30:01 11:14:46 Переработка нефти 03:33:41 11:19:48 Скорость лабораторий 03:38:00 11:16:14 Скорость лабораторий 2 03:48:23 11:18:45 Электроснабжение 1 03:55:13 11:40:48 Обработка серы 04:08:43 11:21:28 Взрывчатые вещества 04:11:04 11:31:50 Аккумулятор 04:18:41 11:28:04 Пластмассы 04:31:33 11:23:49 Продвинутая электроника 04:52:07 11:25:44 Химические исследовательская пакет 04:57:29 11:26:22 Пояс для инструментов 05:04:18 11:10:48 Пакетный манипулятор 05:18:05 11:34:05 Бонус вместимости манипулятора 1 05:29:31 11:44:52 Бонус вместимости манипулятора 2 05:51:40 11:47:31 Модули 06:05:41 11:29:09 Модуль скорости 06:13:55 11:29:46 Модуль продуктивности 06:21:32 11:30:23 Стационарный аккумуляторы 06:43:18 11:42:43 Продуктивность добычи 1 07:26:42 11:39:28 Огнестрельный урон 4 07:43:50 20:38:24 Ворота 07:45:57 11:53:37 Оптика 07:46:10 01:03:08 Солнечная энергия 07:53:07 11:50:58 Скорострельность оружия 2 08:07:46 11:36:23 Горючие жидкости 09:11:45 11:34:40 Дрон-защитник 09:24:49 21:53:30 Количество следующих за персонажем дронов 1 09:58:13 22:07:49 Количество следующих за персонажем дронов 2 10:48:08 22:15:10 Бетон 10:52:31 12:01:41 Продвинутая переработка нефти 10:53:51 73:35:46 Смазочная жидкость 10:54:50 74:23:11 Продуктивность добычи 2 11:21:01 74:47:59 Переработка урана 11:33:58 74:31:40 Продвинутая металлургия 2 11:50:32 74:36:51 Ядерная энергия 12:37:14 74:39:04 Производственный исследовательский пакет 12:42:13 74:37:48 Конструкция малой плотности 13:02:14 74:41:09 Ракетное топливо 13:22:09 74:52:16 Процесс обогащения им. Коварекса 15:29:05 85:48:59 Переработка ядерного топлива 15:33:37 86:21:06 Электродвигатель 15:34:31 74:23:42 Робототехника 15:35:50 74:24:22 Скорость рабочего дрона 1 15:36:51 74:27:12 Сила торможения 2 15:37:14 74:14:54 Скорость рабочего дрона 2 15:38:35 74:28:08 Сила торможения 1 15:40:28 74:12:34 Продвинутая электроника 2 16:06:20 74:34:20 Вспомогательный исследовательский пакет 16:13:01 74:48:57 Скорость лабораторий 3 16:29:44 74:17:51 Скорострельность оружия 5 17:03:17 74:17:52 Сила торможения 3 17:19:43 85:55:42 Сила торможения 4 17:43:03 86:15:55 Сила торможения 5 18:13:07 86:20:34 Блок управления ракетой 19:15:06 115:23:24 Модуль скорости 2 19:16:09 74:59:50 Модуль продуктивности 2 19:17:12 75:00:35 Модуль продуктивности 3 19:25:36 86:47:16 Модуль скорости 3 19:34:08 86:43:26 Ракетная шахта 20:34:18 115:30:55 Космический исследовательский пакет 23:24:52 115:30:01 Автотранспорт  11:54:54 Скорость лабораторий 4  74:22:41 Скорость лабораторий 5  86:01:48 Взрывчатка скал  11:52:28 Портативная солнечная панель  11:57:55 Автоматизация 3  86:04:33 Атомная бомба  116:08:47 Бонус вместимости манипулятора 3  75:02:50 Бонус вместимости манипулятора 4  86:11:14 Бонус вместимости манипулятора 5  86:28:21 Бонус вместимости манипулятора 6  86:32:29 Бонус вместимости манипулятора 7  116:11:33 Лазерные технологии  75:29:25 Личный аккумулятор  11:59:00 Логистическая робототехника  74:26:38 Логистическая сеть  11:48:15 Модуль эффективности  11:30:57 Модуль эффективности 2  75:01:20 Модульная броня  11:57:14 Мины  21:48:32 Прибор ночного видения  11:58:17 Портативный генератор электрического щита  21:57:51 Огнемет  20:46:38 Ракетостроение  21:55:27 Оборудование для игнорирования конвейеров  11:58:39 Отсыпка территории  11:32:27 Скорострельность оружия 3  21:27:26 Скорострельность оружия 4  21:45:26 Переработанное горючие 1  21:50:59 Переработанное горючие 2  22:02:52 Стальной инструмент  01:01:45 Танк  03:32:07 Тяжелая броня  02:02:24 Усиленная взрывчатка  11:56:02 Усиленная взрывчатка 2  19:08:11 Военная промышленность 2  73:32:50 Взрывные боеголовки  73:34:28 Усиленная взрывчатка 3  73:46:13 Огнестрельный урон 5  73:59:08 Скорострельность оружия 5  74:11:14 Грузоподъёмность рабочего дрона 1  74:29:56 Военная промышленность 3  115:24:17 Огнестрельный урон 6  116:15:29 Скорострельность оружия 6  116:19:24 Усиленная взрывчатка 4  116:22:02 Скорость рабочего дрона 2  116:23:00 Усиленная взрывчатка 5  116:26:28 Усиленная взрывчатка 6  116:30:22 Скорость лабораторий 6  116:32:32 Сила торможения 6  116:35:06 Сила торможения 7  116:38:54 Продуктивность добычи 3  116:44:30 Скорость рабочего дрона 4  116:45:53 Скорость рабочего дрона 5  116:48:50 Диаграмму придётся обезличить т.к. порядок исследований был нарушен. Вот график "по возрастанию" количества исследований: Шкала оси 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 штук), а так же решению ИБ- и Бизнес-вопросов. Такие дела. Тут мы оцениваем, насколько раньше/позже у нас произошли важные события в нашем Продукте. Таблица по производству и прочим событиям: Событие Время для Monolith Время для SOA Первая лаборатория (временная) не применимо 00:27:48 Временный Монолит закончен не применимо 00:53:56 Начало создания основной архитектуры не применимо 01:01:45 Первая лаборатория 00:52:56 04:23:26 Заканчивается стартовая железная жила  - прошлось вести новую жилу неизв 06:41:36 Первый конфликт с ульем (мешают строить) не применимо 07:46:42 Второй конфликт с ульем (мешают строить) не применимо 08:03:27 Закончилась стартовая железная жила неизв 10:14:53 Производство зелёных колб 01:12:27 10:45:49 Заканчивается стартовый уголь - прошлось вести новую жилу неизв 13:24:36 Производство черных колб 02:24:34 17:26:03 Заканчивается стартовая медная жила  - прошлось вести новую жилу неизв 18:04:07 Первая атака жуков 08:10:37 25:26:04 Организовано ЖД производство 02:22:17 25:53:13 Начато строительство ЖД 03:38:32 29:35:23 Запущена ЖД (железо) 06:35:07 31:54:15 Убрано старое производство (железо) 06:48:43 34:34:15 Запущена ЖД (медь) неизв 35:00:44 Запущена ЖД (камень) 19:32:27 41:01:31 Производство красных конвейеров 01:44:19 43:50:51 Запущено выкачка нефти 09:08:44 54:00:33 Производство пластмассы 10:04:01 61:52:19 Производство серы неизв 62:21:09 Производство красных микросхем неизв 64:27:02 Производство синих колб 10:43:45 67:33:56 Перенесена электростанция #1 не применимо 72:00:40 Перенесена электростанция #2 не применимо 73:28:38 Производство мазута, дизеля и смазки 11:04:12 73:35:46 Производство соляной кислоты 11:20:06 79:43:12 Добыча урана 12:03:17 79:59:50 Производство фиолетовых колб 12:59:12 85:22:43 Кончилось электричество (уголь) не применимо 90:19:01 Восстановлено электричество не применимо 91:15:00 Поезда переведены на ракетное топливо 16:11:20 92:26:58 Переработка урана 12:20:23 93:40:32 Процесс обогащения урана запущена 15:33:37 94:00:02 Запущена АЭС 18:52:05 99:51:49 Запущено производство синих микросхем 16:35:14 103:13:26 Запущено производство конструкций малой плотности неизв 107:37:10 Отказ от сжигания угля 22:20:34 110:48:18 Запущено производство жёлтых колб 18:02:56 115:00:36 Запущено производство блоков управления ракетой 19:15:50 115:48:54 Запущено производство ракетных шахт 20:56:03 118:35:23 Запущено производство частей ракет 21:01:03 119:40:38 Запущено производство спутников 23:19:52 119:58:51 Ракета собрана 23:18:24 122:41:01 Запущена ракета 23:47:36 122:41:41 Переключено переплавка железных и стальных плит на ЖД 07:27:15 не применимо Новая атака жуков (от загрязнения) 14:11:00 не применимо Опять же, некоторые события случались только в Monolith'е или только в SOA, поэтому график будет немного "рваным": Читать это график следует следующим образом: выбираем нужно событие и смотрим, когда оно было в Monolith, а когда в SOA и, отдельно, в SOA/5 (с увеличенной в 5 раз командой). Например, тут можно заметить, что первую атаку жуков мы спровоцировали значительно раньше Monolith'а, а так же значительно позднее запустили ЖД. Зато запустили ракеты и АЭС мы почти  одновременно при в случае "SOA/5". Ну и с чистым SOA сравнивать смысла нет т.к. в этом случае позднее будет абсолютно всё. В общем: Запуск АЭС - одновременно, при увеличении количества команды в 5 раз; Отказ от сжигания угля - одновременно, при увеличении количества команды в 5 раз; Запуск ракеты - одновременно, при увеличении количества команды в 5 раз. Можно ли считать тогда считать, что в плане финальных целей SOA идентичен Monolith'у, но просто требует больше "рук"? Вопрос спорный и поэтому придётся посмотреть ещё на другие особенности Архитектурного стиля SOA. Тут мы сравниваем, какие производства нам пришлось улучшать по ходу игры и какой прирост производительности при этом достигли. Если в Monolith'е мы могли наращивать производство чего-либо в ущерб другому, то теперь на это тратится только площадь и электроэнергия, а само перенаправление не запутывает конвейера на заводе - мы просто подключаем его к Шине по аналогии с остальным. Иными словами - процесс больше похож на масштабирование внутри приложения, чем на переписку кода. Цифры прироста, правда, не особо впечатляющие: Конфигурирование Прирост производства для Monolith Прирост производства для SOA Красные микросхемы на синие колбы 222,22%  Зелёные микросхемы на модули управления ракетой 900,00%  Железные плиты на стальные плиты 150,00%  Добавление завода шестерёнок  325,53% Добавление завода зелёных микросхем  240,96% Добавление завода красных микросхем  185,34% Добавление завода кабелей  175,00% Добавление завода пластмассы  220,00% Добавление переплавки железа  185,19% Добавление переплавки меди  203,45% То есть в SOA любое реконфигурирование даёт прирост, стремящийся к удвоению, но при этом работает не в ущерб другим производствам. В Monolith же, в виду более простой Архитектуры, можно сделать прямо впечатляющий прирост, но только путём отключения или значительного уменьшения другого(их) производств(а). Тут мы определяем, какую площадь завода и потребление его электроэнергии - это прямое отражение стоимости одного запущенного приложения. Собственно, большие проблемы с Жуками связаны исключительно с занимаемой площадью приложения. Сравните его с Monolith'ом: Параметр для Monolith для SOA Площадь общая (любые постройки) 3402 m2 (100%) 4466850 m2  (131300%) Площадь полезная (производственные здания) 2425 m2 (100%) 1831119 m2 (75510%) Энергопотребление 125 МВт (100%) 283 МВт (226%) Это ужасает - площадь приложения на SOA больше примерно в тысячу раз Monolith'а и всё это вина Шины. Хотя при этом потребление электроэнергии сравнительно маленькая - связано это с тем, что не все производства в нём работают одновременно (см. карту загрязнений). Собственно, подобные площади очень сильно сказались на следующем эксперименты - Deployability. Тут мы оцениваем, насколько долго мы будем строить второй экземпляр завода по времени - то есть сколько времени понадобится на разворачивания второго экземпляра нашего приложения. Я то думал, что за счёт того, что моё производство всяких строительных расходников многократно превышает то, что было в Monolith'е и я смогу значительно быстрее развернуть второй экземпляр Завода. Но, к сожалению, сам Завод разросся до таких объёмов, что получилось ещё хуже, чем в Monolith по времени: Событие для Monolith для SOA Нехватка конвейеров 200 минут - Запущено второе производство конвейеров 248 минут (100%) 1700 минут (685%) Полный запуск второго завода 473 минут (100%) 2467 минут (521%) В общем и целом, большие объёмы дали о себе знать - на то, чтобы развернуть копию завода ушло в 5 раз больше времени, чем на Monolith. Эта цифра связана не со сложность приложения, а исключительно с большим объёмом - большую часть времени я просто либо что-то строил по плану, либо ждал расходников. Сохранение Тут мы будем оценивать максимальное производство ключевого продукта с и без учёта Масштабирования, а так же в целом скорость реализации проведения подобного замера. При тестировании производительности мы, как всегда, даём бесконечный буст сырья (железо, медь, нефть и прочее) и смотрим, какую производительность покажет производство Частей ракет и Спутников. Тут есть интересность: если в Monolith'е мы получали буст производства в течении нескольких минут, то в SOA на это уходит чуть меньше часа - сырьё долго идёт производственный путь с начала Шины до целевых производств. На скриншоте видно, что мы подключили бесконечное сырьё ~54 минут назад, а производство начало уверено расти только ~4 минуты назад Более того, если подождать ещё, то можно заметить, что оно ещё и медленно разгоняется и ждать стабилизации производства приходится достаточно долго - около 12-ти часов. Тем не менее рано или поздно оно стабилизируется и можно снять параметры и сравнить с Monolith: Производство Производство базовое (контрольное) При вертикальном масштабировании При горизонтальном масштабировании Части ракеты (SOA) 148 ед/час (100%) 200 ед/час (135%) 390 ед/час (263%) Части ракеты (M-th) 99 ед/час (66%) 110 ед/час (74%) 192 ед/час (129%) Спутник (SOA) 27 ед/час (100%) 32 ед/час (118%) 67 ед/час (248%) Спутник (M-th) 2 ед/час (7%) 2 ед/час (7%) 3 ед/час (11%) В качестве 100% мы берём контрольные измерения производства Частей ракет и Спутников от SOA и сравниваем его с масштабированием и цифрами от Monolith. Как видно, прирост производительности получился большой. Более того, здесь значительно лучше показывает себя вертикальное масштабирование, а вот горизонтальное не сильно лучше Monolith'а. Ещё радует значительный прирост производства спутников: не смотря на то, что в Monolith и в SOA у нас на них был только один единственный завод - за счёт обилия расходников его производство возрастает многократно. Что по тестированию: Производство Производство базовое (контрольное) Тестирование на бесконечный спавн Конструкций малой плотности, Блоков управления ракетами, Ракетного топлива и Спутников Тестирование на бесконечный спавн Плат всех цветов, Медных, Стальных и Железных плит, Ракетного топлива, Статичных аккумуляторов, Солнечных панелей и Радаров Тестирование на бесконечный спавн Медных, Стальных, Железных и Пластмассовых плит, Серы и Дизельного топлива Части ракеты (SOA) 148 ед/час (100%) 1000 ед/час (676%) 335 ед/час (226%) 148 ед/час (100%) Части ракеты (M-th) 99 ед/час (100%) 757 ед/час (764%) 100 ед/час (101%) 99 ед/час (100%) Спутник (SOA) 27 ед/час (100%) Вне учёта 81 ед/час (300%) 27 ед/час (100%) Спутник (M-th) 2 ед/час (100%) Вне учёта 47 ед/час (2350%) 2 ед/час (100%) Время, затраченное на организацию тестирования (SOA)  04:52 17:10 20:38 Время, затраченное на организацию тестирования (M-th)  04:23 14:23 09:10 Выглядит подключение для тестирования примерно вот так: В плане времени видно, что SOA более предсказуема чем Monolith т.к. чем более сырьевое производство мы делаем, чем больше мы на это время тратим. Но не из-за попыток придумать КАК подключить тестирование, а больше из-за выбора места КУДА подключить. Зато за счёт ширины Шины получается дать больше сырья и, соответственно, получить больше производительности. Тут мы просто высчитываем некое число эффективности скорости разворачивания к фактическому приросту производительности для сравнения. На основании Deployability и Perfomance, можно сказать, что за 2467 минут мы получаем прирост на 163% частей ракет и на 148% спутников. Итого, умножаем это: Части ракет: 1.63х2467=4021.21 Спутники: 1.48х2467=3651.16 Для сравнения, в Monolith'е у нас были числа 444.6 и 236.5 соответственно - то есть в нём за меньшее время мы получили большее число производительности при Горизонтальном масштабировании, а значит Monolith эффективней SOA в этом плане. Тут мы смотрим, насколько легко логически разделить завод на зоны производства и на сколько они плотно друг к другу располагаются - это напрямую влияет на сложность расширения продукта в будущем. Основные зоны производства стоят параллельно Шине и, хотя они плотно находятся друг к другу по бокам, но вниз у каждого из них есть место для роста - собственно это помогло ранее сделать Вертикальное масштабирование. Так что как таковых плотно стоящих зон у нас не наблюдается, но и возможность расширения только в одну стороны сложно назвать "Хорошо разграниченной зоной". Думаю, что с этого момент введём новое состояние зоны "С ограничениями" - то есть расширяться можно, но не в любую сторону. Итого: Хорошо разграниченных зон: 16 Плотно стоящих зон: 0 С ограничениями: 98 Думаю, такое количество зон "С ограничениями" мы будем наблюдать только в SOA, но это не точно. Что бесспорно, это у нас стало лучше, чем было в Monolith'е: Тут мы высокоуровнево обозначаем части продукта по назначению и смотрим, как сильно оно перемешано: Если проанализировать уровень абстракции, то тут в основном всё замечательно: Ресурсы добываются где-то в стороне, от ЖД начинается Шина и по всей её длине идёт Основной завод, изредка переключаясь на "Переработку ресурсов" и ещё реже на "Хранилище". На этом уровне всё выглядит достаточно комфортно для понимания принципа работы приложения, что нельзя было сказать про Monolith. Сравните, ради интереса, с тем, что у нас было в Monolith'е: Тут мы пробуем сломать наш завод путём DDoS- и хакерской атак. С жуками просто: они прорвали оборону через 125 минут. При этом под раздачу попал не сам завод, а точки добычи ресурсов и пути к ним. А без добычи ресурсов сырьё просто кончилось и всё встало. С вторым вариантом (имитация DDoS) вышло интересней - на то, чтобы полностью застопорить работу завода путём посылания "паразитных" поездов (трафика), ушло 7:40:19 (почти 8 часов) времени. По количеству поездов ситуация следующая: Событие для Monolith для SOA Базовое количество поездов 19 (100%) 40 (100%) Проблема стала видимой 33 (173%) 109 (272%) Началось снижение производительности производства 68 (357%) 219 (547%) Полная остановка производства 110 (578%) 221 (552%) Поскольку в данном Архитектурном стиле ЖД играет более значимую роль из-за своих объёмов, то и она оказалась более стойкой к большому количеству поездов. По сути, если не считать мелкие улучшения и проблему с кольцевой дорогой - производство упало только под конец, когда станции просто не могли обменяться друг с другом поездами из-за занятости обоих. Хотя в процентном соотношении разницы не очень много, конечно, но мы тут больше смотрим на количество поездов. Deadlock на кольцевой дороге: По финалу ЖД застопорилось примерно вот в таком виде - поезда просто упёрлись в установленный лимит составов на станциях и не могли двигаться т.к. им просто некуда ехать: Если отключить лимит на станции, то станет только хуже - поезда начнут двигаться более хаотично и просто заблочат проезды другим поездам: Сохранение Если сравнивать с Monolith'ом, то можно выделить следующие достоинства SOA: Значительно больший запас производительности - продукт реально сможет как принять больше нагрузки изначально, так и иметь значительно больший прирост производительности при масштабировании. Плюс при запуске новой фичи она сразу же имеет возможность принять большую нагрузку "по умолчанию"; На описании продукта на уровне абстракций получается вполне логичная и понятная схема взаимодействия вида [Сырьё]->[ЖД]->[Шина]->[Обработка сырья]->[Шина]->[Производство]->[Шина]->[Ракета]. Так же это очень хорошо сказывается на возможности добавления новых производств в Продукт - всегда просто сообразить, куда добавить новое производство (спойлер: тупо в конец); Удобство тестирования - подключить к какой-либо части Шины бесконечные ресурсы для проверки производительности значительно проще осуществить, чем в Monolith'е; Получается более развитая система точки входа для пользователей в плане нагрузки, включая DDoS - при этом она получается такой сама собой просто эволюционно по мере создания Продукта; Значительно проще выполнять Вертикальное масштабирование т.к. достаточно скопировать текущую схему заводов и либо дополнить его текущим подключением к существующему заводу, либо отдельно подключить его к Шине. Не идеально, конечно, но точно лучше того, что было ранее. Но недостатков у неё имеются: Значительно более поздний запуск первых пользователей из-за технологических аспектов Архитектуры, что вызывает множество вопросов со стороны Бизнеса относительно сроков; Необходимость тратить много человеко-часов и ресурсов на поддержание работы Шины - это сказывается на увеличенный Бюджет, чему Бизнес рад не будет. Сама работа оказалась не сколько сложной и запутанной, сколько большой и монотонной; Получается очень большое приложение, что негативно сказывается как на Горизонтальном масштабировании, так и на необходимость тратить Бюджет на дополнительные серверные ресурсы. При этом прирост производительности при масштабировании не идёт ни в какое сравнение с получаемым увеличением производительности. Как говориться, "Долго, дорого, качественно". Получается, что все недостатки SOA связаны именно с Бизнесом и его неудовлетворённым желанием выпустить продукт быстро и дёшево - именно поэтому SOA имеет столь негативную славу. Если Бизнес захочет новую фичу - он будет привлекать как минимум двух программистов (Шины и Сервисов) и ещё достаточно долго ждать, когда они договорятся и сработаются между собой. Да, у нас получается достаточно структурированное и производительное приложение и любой программист бы им гордился, но если со стороны Бизнеса эти расходы не окупятся - приложение уйдёт в раздел "Провальные". Так что применять SOA стоит только при отсутствии конкуренции, спешки и необходимостью большого запаса производительности. В следующей статье мы продолжим идти по хронологическому порядку развития Архитектурных стилей и перейдём на Основанную на сервисах архитектуру (Service-Based Architecture или SeBA). Исторически команды, познав горький опыт использования SOA начали думать, что делать дальше и решили (наконец-то) заменить громоздкую шину на REST API. Что из этого у них получилось - узнаем в следующей статье! А пока я временно прощаюсь с вами, душевно благодарю за прочтение моей работы и ухожу опять на полгода запускать новую игру с нуля - пожелайте удачи, ибо я вам этого тоже желаю ;)  SRE