Комментарии 50
Краткий вывод? Если и реализовать, то только для крупной компании в качестве внутреннего инструмента. В этом случае количество подключений и высокое качество важнее скорости. Тем более что первоначальный запуск можно откладывать достаточно долго, если результат достаточно важен. Все таки чаще всего у компании уже есть изначальный программный продукт, на котором она работает (Начальный монолит). Но и затягивать не стоит, изначальный продукт обычно либо крайне кривое временное поделие, созданное во времена основания компании, либо внешний инструмент (И крайне дорогой в лицензировании, других не бывает).
P.S. Радары как телеметрия процессов. Без жизнь возможна, но очень уж неприятна. Особенно когда происходит ошибка, а ее замечают только через несколько часов или дней.
Мне кажется, шину можно реализовать разными способами. Например, можно вместо конвейеров использовать ЖД или логистическую сеть.
Кроме того, в факторио есть логические элементы, позволяющие считать количество и тип вещей на конвейере и ещё закрывать/открывать подачу по конвейеру. Этим практически никто не пользуется, но так можно собирать всякие прикольные штуки.
Например, в моде diggy смешанные руды, можно подключить все буры на один конвейер и сделать, чтобы в зависимости от количества железа/меди/угля на базе включались те или иные буры.
Я не пытался делать такое в масштабах базы, но для медленных производств делал один закольцованный конвейер, на который по необходимости докладывались/убирались ресурсы. Например, производство какой-нибудь науки - ресурсов требуется несколько видов, но в небольшом количестве и тянуть много конвейеров лень.
Можно попробовать обобщить это на всю базу - сделать закольцованную шину из десятка конвейеров и просто сыпать туда все ресурсы подряд. Единственная сложность - отслеживать количество ресурсов на шине и останавливаться, если их слишком много. Я использовал схемы типа подсчёта количества ресурсов на отрезке в 5-10 клеток, они вполне работают.
Условно, потребитель передаёт в сеть сигнал -3 железа, производитель складывает количество железа на участке в 10 клеток с сигналом, сравнивает с нулём, и если меньше - досыпает нового железа на шину.
Если потребителей станет больше, из сигналы просуммируются и для подачи на шину "запросился" бОльший поток нужного ресурса
Вот это, по-моему, самый эффективный способ если максимизировать отдачу при минимальных ресурсах. Только геморрой с настройкой.
Спасибо!
В статье у меня Архитектурный вопрос поднимается и его суть в том, как сделать идеальное приложение по производительности, а более общее: как это приложение будет тестироваться, масштабироваться, описываться, быстро писаться и прочее.
Именно в этом аспекте я пытаюсь сделать статью: мне нужно сделать не идеальное приложение, а именно оценить плюсы и минусы каждого Архитектурного стиля.
Но работы много ещё)
@Nifaninты конечно молодец! Я давно подсознательно сравнивал Факторио с разработкой, но так как ты считать и заворачивать производство, это конечно бомба.
Склоняюсь перед твоим терпением в строительстве фабрике, по правилам разработки. Очень круто, у самого периодически опускаются руки, когда разрастается фабрика до размеров слишком больших
Пробовал как и ты реализовывать оба варианта и полностью подтверждаю все твои выводы. SOA конечно крута по производительности, но строить это все, особенно тащить ресурсы из конца в начало это жесть)) Играю не на ванильнке, а на Бобе, и это прибавляет 100500 проблем к тому, что ты описываешь)
Можешь предположить, добавление модов это получается использование более сложного языка или это просто усложнение бизнес функций продукта?
Спасибо)
Можешь предположить, добавление модов это получается использование более сложного языка или это просто усложнение бизнес функций продукта?
Хороший вопрос, но я не думаю, что я тут эксперт т.к. мне моды не зашли особо. А с учётом того, что я специально ограничил себе игру (не использовать логические сети, отключил эволюцию жуков, запретил использовать статических дрон-станций), я думаю, что моды бы особо мне не помогли - бы их тоже ограничил :). Разве что моды на передвижение персонажа были бы кстати (типа мода на телепорты), но это уже дисбаланс. Так что я не знаю, сорри)
Программистское порно с 16:15.
Да, спасибо за отзыв!
В SOA же используется Шина, а это уже внутрипрограммная логика, поэтому я тут использовал конвейеры: во-первых, потому-что я установил такие ассоциации в первой части; во-вторых, чтобы потом не повторяться, когда буду делать EDA.
Касательно логических сетей - я их не использую т.к. я не смог придумать ассоциацию для них в реальной разработке. То есть ЖД - это сеть; конвейера - функции; логическая сеть - хз. Ну и для более точных измерений мне нужна как можно менее нагруженная игра и логическая сеть вносит сюда фактор оптимизации, на которую придётся потратить время и которая собьёт графики в положительную сторону. В общем, я пока не готов к этому.
Кстати, по этой же причине я и не использую статичные Дрон-станции - я просто не могу придумать ассоциацию их с реальной разработкой.
Ну и моды у меня тоже запрещены, чтобы не сбивать баланс и ещё иметь возможность публиковать свои сохранения для широких масс.
Я думал использовать ЖД, но проблема в том, что у меня тут на схеме ЖД является сетью, а в это уже ближе к API и/или очередям. Я буду ещё использовать подобную схему с ЖД, но уже в Архитектурном стиле "Событийно-управляемая архитектура (Event-Driven Architecrute или EDA". Вот схема и, как видите, она чем-то похожа на SOA:
Там по идее так и задумано, но можно схитрить, если отьехать буквально на 30 минут от изначального респауна то количество ресурсов станет бесконечнным с точки зрения игры. Для этого надо сначала выходить в ЖД, уезжать а потом уже строится.
Монолит в мультиплеере сложнее распределяется на несколько ролей.
На шине можно сразу обозначить линии под еще несуществующие ресурсы, и назначить человека строить завод по переработке этих ресурсов где-то впереди по шине, недожидаясь самих ресурсов. И когда ресурс появится, сразу заработает.
Ох боже... Наткнулся на эту игру когда работал как HDL программист. В итоге я построил внутри игры FPGA модуль с трассировкой, памятью, специальными функциональными блоками(прим. печи) и IO. Вышло грамостко но позволяло мне малой кровью переоборудовать любую цепочку производства. А на поздних этапах, собрав несколько таких "схем" можно было спокойно занятся только разработкой новых месторождений и прокладки дорог к ним.
Ох тыж, красота! Вдохновляюще прозвучало. Надо в очередной раз запустить Factorio и что-нибудь такое нестандартное придумать.
Есть еще вариант создания полнофункциональной базы с выпуском всего и вся в миниатюре, а далее просто с помощью чертежей масштабировать, на входе идут базовые ресурсы на выходе даже готовые дроны, соотвественно копирование можно проводить бесконечно. Тем более там расширили возможности примерения чертежей.
Когда надо было расширять границы или захватывать очередное месторождение я просто прокладывал до нужной точки рельсы, ставил станцию разгрузки и добавлял её в расписание спец-поезда. А дальше можно было заниматься своими делами — приезжал спец-поезд и дроны выстраивали линию обороны без моего участия.
Может быть не стоит пихать в шину все подряд?:)
Мне очень нравится компоновка как у Nilaus.
Строка для поиска: Factorio Base-In-A-Book (название плейлиста этого ютубера)
Я играл с такой компоновкой. Это действительно очень экономично.
Спасибо за совет)
Я думал, как сделал лучше с Шиной и не пихать на всё подряд, но не придумал - если отступить от применённой мной конфигурации, то получается не SOA, а просто очень большой Монолит. В целом, он тоже имеет право на жизнь и, возможно, я ещё переиграю. Но пока так)
По поводу туториалов из Интернета - я их намеренно не использую т.к. моя задача - стараться максимально точно воспроизвести работу типичной Продуктовой команды разработчиков. Именно "типичную" - со всеми их косяками, костылями и прочее. В итоге я использую не готовые, идеальные знания/схемы для игры, а стараюсь самостоятельно, на лету генерировать решения - именно так работают программисты в общей массе, ИМХО.
Короче, это Архитектурная статья и она рассказывает не про идеальный мир, а про реальный со своими достоинствами и недостатками - именно это я и стараюсь не упускать.
Я думал, как сделал лучше с Шиной и не пихать на всё подряд, но не придумал - если отступить от применённой мной конфигурации, то получается не SOA, а просто очень большой Монолит. В целом, он тоже имеет право на жизнь и, возможно, я ещё переиграю. Но пока так)
Когда вам нужно создать хеш-мапу, вы не идете в сервис по созданию хеш-мап, вы просто пишете new HashMap(). Когда вам нужно опустить строку в нижний регистр, вы не идете в сервис по опусканию строк в нижний регистр, вы просто пишете toLowerCase().
Не важно какую архитектуру вы строите, всегда будут те или иные моменты, колторые будут представлены утилитными функциями. Собственно, одна из важнейших задач при построении архитекутуры завязаной на сервисы в той или иной форме - это понять какой код нужно тащить в сервисы, а какой - нет. Если же доводить до абсурда, то любая архитектура будет ужасной.
На примере факторио - тащить на шину медные провода, чтобы потом потреблять их в астрономических количествах при производстве зеленых схем - это то самое хождение в специальный сервис для создания хеш-мап. Это может быть оправдано, если вы ожидаете, что через какое-то время производство медных проводов будет изменено без изменения производства зеленых схем. Но в реальности, перестраивать производство медных проводов вы начнете вместе с производством зеленых схем когда дойдете до маяков и модулей. Таже самая история и с водой для электростанций, ядерным топливом для атомных электростанций и т.д.
По поводу туториалов из Интернета - я их намеренно не использую т.к. моя задача - стараться максимально точно воспроизвести работу типичной Продуктовой команды разработчиков.
В таком случае вам нужно воспроизвести еще 3 сценария:
Работа в команде в параллель.
Подключение нового человека к существующему проекту.
Возвращение разработчика в проект после перерыва.
Вот на этих сценариях SOA (по сравнению с монолитом) засияет новыми красками.
Именно "типичную" - со всеми их косяками, костылями и прочее
Но вы как раз и отказываетесь вставлять костыли в угоду "чистой архитектуре". А это ведь тоже важное свойство архитектуры - устойчивость к костылям, когда нужно запилить фичу здесь и сейчас не считаясь ни с чем. В реальном проекте такие штуки рано или поздно будут возникать хотим мы того или нет. И хорошая архитектура позволит вам вставить такой костыль, а потом его относительно безболезненно извлечь.
Первую игру в монолит я забросил т.к. задолбался его переделывать.
вторую игру я забросил, когда задолбался делать выводы для шины.
Третья моя игра будет тоже с общей шиной, но не с микросервисами (забрает с шины комплектующие, выдаёт продукт), а с макросервисами (забирает с шины БАЗОВЫЕ ресурсы-выдаёт продукт) это сильно уменьшит шину за счёт снижение количества видов ресурсов, которые надо транспортировать.
Спасибо за развёрнутый коммент!
Давайте по порядку:
Когда вам нужно создать хеш-мапу, вы не идете в сервис по созданию хеш-мап, вы просто пишете
new HashMap(). Когда вам нужно опустить строку в нижний регистр, вы не идете в сервис по опусканию строк в нижний регистр, вы просто пишетеtoLowerCase().
Не, ну это крайность уже - под функциями я имел в виду что-то более широкое типа buy_ticket(), calculate_tax() и типа того. В SOA у меня получилось около 100 таких функций и мне кажется, что это похоже на настоящее приложение.
Касательно отдельного сервиса для медных проводов - рассматривайте это не какую-то мелочь, а, например, сервис курса доллара в банке - вроде бы просто передаётся цифра, но без неё банк перестаёт нормально функционировать. А поскольку эту цифру нужно взять и надёжного источника (центробанка), пройти там систему защиты, несколько раз перепроверить результат и всё это добро повторяется, условно, раз в минуту - я охотно верю, что это отдельный сервис.
В таком случае вам нужно воспроизвести еще 3 сценария:
Согласен, ибо сам думал это проверять. Но не сейчас - может потом сделаю отдельную статью про "уходы/приходы сотрудников в большой проект на движке Factorio" :)
Но вы как раз и отказываетесь вставлять костыли в угоду "чистой архитектуре".
Я бы назвал это по другому: я пытаюсь симулировать, что я через тернии следую к "чистой архитектуре") Ключевое тут - затраченное время и любые костыли будут именно его тратить. Так или иначе, я лучше реализацию пока придумать не смог: чтобы и идеалы не потерять, и в дерьме не утонуть :)
Не, ну это крайность уже - под функциями я имел в виду что-то более широкое типа
buy_ticket(),calculate_tax()и типа того. В SOA у меня получилось около 100 таких функций и мне кажется, что это похоже на настоящее приложение.Касательно отдельного сервиса для медных проводов - рассматривайте это не какую-то мелочь, а, например, сервис курса доллара в банке - вроде бы просто передаётся цифра, но без неё банк перестаёт нормально функционировать. А поскольку эту цифру нужно взять и надёжного источника (центробанка), пройти там систему защиты, несколько раз перепроверить результат и всё это добро повторяется, условно, раз в минуту - я охотно верю, что это отдельный сервис.
Ну вот мне кажется что медные проводники - это как раз та самая крайность.
Если задаться вопросм в каких ситуациях потребуется менять производство зеленых схем, а в каких ситуациях - производство медных проводников, то оказывается, что при любом расширении производства зеленых схем придется аналогично расширять и производство проводников. И наоборот, желание как-то увеличить производство проводников возникает только при расширении производства зеленых схем (потомучто все остальные потребители проводников просто теряются на фоне зеленых схем). На лицо единый источник изменений. И SRP в таком случае не противоречит объединению этих двух производств в одно. В результате и возникает идея утащить производство медных проводников к зеленым схемам.
С другой стороны, если играть в слепую, то то что зеленые схемы будут жрать 90% всех проводников и то что производства будут обновляться вместе не очевидно до самого эндгейма. И в таком ключе держать производство провдников отдельно кажется разумным. Но в какой-то момент появляется возможность увидеть проблему и сделать рефакторинг. И вот тут те архитектуры, которые позволяют делать такой рефакторинг безболезненно дадут выигрышь.
И в настоящей разработке ведь происходит так же. По мере развития проекта те или иные сервисы могут соединяться и разделяться. Архитектура приложения должна изменяться вместе с изменениями требований, вместо того чтобы слепо следовать принципам установленным в самом начале, ведь эти принципы могут уже не соответствыовать потребностям проекта.
В свое время мы с товарищами тоже прошли путь от макаронно-монолитной фабрики до микро-"цеховой" архитектуры с шиной на поездах, которым немного пропатчили мозги модом LTN. Особенно приятно, когда ты впервые пробуешь перенести архитектурные принципы из реальных проектов в игру, и понимаешь что они работают. Единственное, что пока не смогли перенести в игру - это оркестрацию с последующим автоматическим масштабированием, но эта проблема была закостылена книжкой со всеми нужными чертежами и строительный пауком, что позволяло развернуть новый цех за 5-10 минут, включая сюда его полную настройку для работы.
Удачи, будем ждать, йей!
Прежде всего хочу сказать, что играть вслепую, не пользуясь чужим опытом и рецептами, — это именно то, как надо проходить Factorio в первый раз. Эта игра в первую очередь про борьбу со сложностью, а суметь победить сложность разработкой собственный, а не копипастом типовых решений — это весьма полезный опыт. Но когда вы закончите с этим проектом, попробуйте познакомиться с общепринятыми лучшими практиками, особенно с использованием поездов и настоящей service-oriented architecture, в Factorio известной под именем city blocks (ту самую, название которой обыгрывается в видео в этом комментарии).
Собственно говоря, main bus в Factoio похожа на шину сообщений в SOA только названием. Вы не можете просто описать интерфейс сервис-шина и ожидать, что она сама займется маршрутизацией сообщений до потребителей. Вооружившись теорией графов и пространственным воображением можно показать, что вашу шину можно преобразовать в спагетти-монолит просто расположив те же и так же связанные сборочные автоматы более компактно. Кстати говоря, если вместо еженедельной войны с бизнесом в качестве метода проектирования использовать водопад и заранее рассчитать объемы производства необходимые для запуска ракеты до начала строительства — то окажется, что значительная доля мощностей была и не нужна вовсе.
Я знаю правило по поводу увеличения количество сотрудников в проекте вида "две женщины не могут родить в 2 раза быстрее"
Вот два свежих мировых рекорда в категории Any% (где можно изменять настройки генерации ресурсов на карте): одиночный, менее чем за полтора часа, и мультиплеер в количестве девяти восьми человек, за… час. И надо думать, с планированием и коммуникацией дело обстояло куда лучше, чем в типичном проекте.
И, собственно, то, из-за чего я собственно и пишу этот комментарий: тестировать подходы к проектированию базы запуская одну ракету — все равно что тестировать варианты архитектуры веб-сервера на одном соединении. Эндгейм в Factorio начинается с запуска ракеты. Закончив на этом моменте вы просто не успеваете столкнуться с теми узкими местами и проблемами, для решения которых все эти распределенные архитектуры и создавались. Чтобы оценить производительности базы используют единицу измерения RPM (rockets per minute) которая в свою очередь равна тысяче SPM (science per minute), количеству science pack каждого вида, которые база способна стабильно выдавать. При попытке стабильно получить хотя бы 1 rpm имеющиеся подходы к проектированию, скорее всего, придется значительно пересмотреть.
https://www.twitch.tv/colonelwill 8K SPM без модов в мультиплеере.
построил базу 10K SPM в том году. одна база, не копипаста из нескольких блоков. убито около 300 часов на создание базы)))) не выкладывал никуда. это с примерно пятой попытки только получилось. реальные проблемы на таких масштабах начинаются в ЖД, которые требуют крайне тщательного планирования расположения блоков и конфигурации жд путей. то есть все начинает упираться в пропускную способность ЖД.
в ЖД главное это быстрые перекрестки, обычно используемые типа круга, или простых пересечений медленнее перекрестка с буффером в 3-4 раза, еще в 1.5-2 раза увеличить можно переходом на 4 путную жд, думаю до 20к spm хватит
я уперся в производительность игры на 6k SPM с ситиблоками
Это на каком железе?
Ryzen 7 5800, неожиданно для меня было что проблема в инсертерах, надо на выгрузку из заводов таймер прикручивать, чтобы по 12 выгружали. И компоненты для ракеты на месте делать, их поездами возить не выгодно, стеки всего по 10. В остальном работает прекрасно, ups пока на уровне 30-40, настройки лтн пришлось поменять, на 2 обновления за тик, иначе заказы долго создавались
Спасибо за коммент! И я даже согласен с большинством утверждений)
Давайте по порядку:
Прежде всего хочу сказать, что играть вслепую, не пользуясь чужим опытом и рецептами, — это именно то, как надо проходить Factorio в первый раз.
Именно это я и пытался достигнуть при прохождении - играть как будто в первый раз. Конечно, некий опыт всё равно накапливается, но не существенно. Всё потому-что если я начну использовать публичные наработки, то я сразу же сделаю приложение, близкое к идеалу. Но у меня другая задача: попробовать воспроизвести работу команды разработки со всеми её косяками - неверные решения, ошибки программной логики, ошибки проектирования, внезапные проблемы с Жуками. В моём понимании Бескосячное производство существует только в Agile-книгах)
Собственно говоря, main bus в Factoio похожа на шину сообщений в SOA только названием
Согласен, но другого я ничего не придумал более: если сделать подобную шину с Маршрутизацией, то получится тот же Монолит, но очень широкий. Если же использовать поезда, то получится как раз схема из следующей статьи. В итоге я остановился на подобном компромиссе. Как я уже говорил в первой части - если после публикации увижу грубую ошибку, то я перепройду и пересчитаю результат. Но это будет в конце. К сожалению....
когда вы закончите с этим проектом, попробуйте познакомиться с общепринятыми лучшими практиками, особенно с использованием поездов и настоящей service-oriented architecture, в Factorio известной под именем city blocks
Пока я не завершу цикл статей из 6 частей - я другие примеры заводов смотреть не буду, чтобы не получить ложноположительные результаты в будущих Архитектурных стилях, сорри) Разбору всех их я в 7-ой части, где мы будем в поисках идеального приложения разбирать уже пользовательские заводы и даже спидраны. Так что да, я благодарен за то, что накидываете примеры, но обзор их будет в конце. К сожалению...
И, собственно, то, из-за чего я собственно и пишу этот комментарий: тестировать подходы к проектированию базы запуская одну ракету — все равно что тестировать варианты архитектуры веб-сервера на одном соединении.
Вот тут я уже не согласен. Если не заканчивать игру на одной ракете, то тогда, во-первых, не понятно где её вообще заканчивать; во-вторых, на это потратиться в разы больше времени и я не готов буду по несколько лет делать одну статью, сорри. Поэтому мне запуск первой ракеты показался хорошим компромиссом: исследовать больше нечего (все фичи сделаны), бизнес-цели достигнуты (полетели в космос) и прочее. По сути, с этого момента Приложение просто переходит в эксплуатацию и дальше разработка ограничивается только правкой редких багов. Как то так.
если я начну использовать публичные наработки, то я сразу же сделаю приложение, близкое к идеалу
Уж как хотите, но это так не работает. Если посадить хоть одного человека, хоть команду делать сколько-нибудь сложную систему на незнакомой технологии — она не получится близкой к идеалу только из-за того, что у них в процессе есть доступ к Stack Overflow.
Вы моделируете не команду профессионалов, которые умеют использовать свой инструмент, а новичка, который не знает ни языка, на котором пишет, ни паттернов проектирования и лучших практик, и к тому же лишен доступа к глобальной сети. К примеру, массово транспортировать провода или шестеренки на конвейерах считается самым настоящим антипаттерном, хотя и по разным причинам, а правильно спроектированная кольцевая развязка на ж/д не приведет к дедлоку независимо от количества поездов в системе.
Если не заканчивать игру на одной ракете, то тогда, во-первых, не понятно где её вообще заканчивать
Как я уже говорил, общепринятой метрикой является количество science pack всех цветов, производимое в минуту. Типичная база, запустившая первый спутник, после некоторых оптимизаций будет выдавать 50-100 spm, а разговоры про highload начинаются с 1000 spm или одной ракеты в минуту. И довести базу, выдающую 100 spm, до тысячи — это ну никак не "просто переходит в эксплуатацию", особенно при подобном перерасходе ресурсов. Остановившись на одной ракете вы по сути выдаете MVP, потратив ресурсов как на полноценное приложение, и доделка до полноценной базы, которая держит нагрузку стабильно и постоянно, а не один раз на презентации, потребует дополнительной доработки.
если сделать подобную шину с Маршрутизацией, то получится тот же Монолит, но очень широкий. Если же использовать поезда, то получится как раз схема из следующей статьи.
Набор ограничений, который вы применяете к "шине", совершенно не похож не только на ESB из SOA, но и на дизайн-паттерн главной шины в Factorio. На шину пускают только базовые материалы вроде железа-меди-камня, продукты нефтепереработки и некоторые промежуточные материалы, которые потребляются в больших количествах и при этом достаточно сложны в производстве, чтобы делать их централизованно, например, green/red circuits. Внутрь одного блока стараются запихнуть максимальное количество операций, в идеале на входе железо и медь, а на выходе — science packs. Отсюда и рекомендация не использовать ленты для транспортировки шестеренок: если они нужны в каком-то блоке — просто поставьте там сборочный автомат. Пускай он будет загружен на 10%, но это несравнимо дешевле, чем отдельная линия на шине.
В итоге вы придерживаетесь правил, которые не похожи ни на реальные архитектурные стили, ни на паттерны Factorio, при этом ограничиваете размер приложения уровнем, на котором нет необходимости в использовании распределенных архитектур в принципе, и реализуете это все от лица джуна, который знает только базовый синтаксис языка и не имеет доступа к гуглу. Само по себе такое времяпрепровождение ничем не хуже любого другого, но в чем смысл при этом что-то измерять и насколько можно доверять сделанным на основании этого выводам?
Все сложные рецепты так или иначе забываются если их не сохранять в книгу, остается только общий план. Я уже и не помню с подсказками или без проходил первый раз.
на шине не заметил балансировку и равномерный отбор ресурсов, для 4 конвейеров схемы весьма простые. Или лесенка делителей (сплитер) имеет приориты выхода на одну сторону?
В контексте архитектуры, это должно иметь значение, ведь первый "жадный" пользователь съест почти все ресурсы, не оставив последнему ничего.
На самом деле как работало стоковое распределение из Шины меня вполне устраивало и поэтому я не стал там что-то менять. Если бы не устраивало - я бы это быстро бы заметил и начал что-то придумывать.
Я, ради интереса, попробовал поставить счётчики на подобную схему
В итоге результат был такой:
То есть при такой схеме от любого ответвления уходит только 1/8 всего потока, что меня вполне устраивало
Это можно увидеть на скриншоте из той игры, что я делал по статье:
И, по сути, единственное место, где наблюдается "жадные" ветки - только в тех местах, где уже дальнейший ход предметов невозможен:
То есть как раз где-то в конце, где всегда находятся последние и актуальные заводы. Именно поэтому я написал в статье:
Зато если построить завод в текущем конце Шины, то все эти зависшие ресурсы из Шины идут именно на новое производство и мы на первое время получаем заметный прирост данный предметов. Из-за этого на графиках всегда можно заметить пик производства в самом начале, а потом оно нормализуется.
Тянуть по шине медные провода... Кажется, понятно, почему получилось так долго. Вы, видимо, пытались тянуть по шине вообще ВСЁ вместо того, чтобы организовать базовые вещи в том месте, где они потребляются. Условно, медные провода - рядом с микросхемами, а не в шину. Электропечи - рядом с научными пакетами, а не в шину и оттуда на пакеты (больше они все равно нигде больше не нужны). И так далее.
похоже основной источник проблем тут:
"Во-первых, хоть я и расширял создание Зеленых микросхем - их всё равно
катастрофически мало. А всё потому-что их производство находится очень
далеко от актуального производства и большая часть продукции "сжирается"
по пути."
расстояние не имеет большого значение, тут просто потребление больше чем производство, от этого все медленно и работает, что на всех не хватает
Поставили вначале одно производство зелных схем и надеемся что их хватит на все. Нужен просто учет, допустим производство дает 4 конвеера, каждый потребитель забирает по половине конвеера, значит после 8 потребителей надо ставить еще одно производство схем. и тоже самое с ресурсами для производства схем, пр добавлении производств потребляющих базовые ресуры( железо, медь ..) надо добавлять конвееры с ними на шину
Аналогичная проблема с водой для электростанций, уперлись в пропускную способность трубы, аналогично надо ставить еще насос и тянуть дополнительную трубу
Да, всё правильно. По сути мы обыграли ситуацию, что в начале разработки мы и представить себе не могли о том, какие проблемы у нас будут в середине разработки. Поэтому понаделали ошибки, которые решали уже по ходу методом костылинья.
Напоминаю, что у нас тут цель не расчитать идеальное производство в игре Factorio и реализовать его. Тут у нас цель эмитировать процесс разработки ПО (со всеми косяки, костылями, ошибками и прочим) - именно поэтому я стараюсь больше действовать интуитивно, чем расчётливо.
так обнаруженные проблемы не решались
в процессе разработки обнаружено, что зеленых схем не хватает, и ничего не делается для того чтобы увеличить их производство
просто говорится отмазка, что производство дескать далеко находится
логично же обнаружив, что все зеленые схемы кончаются на шине на какомто производстве, после этого производства поставить еще одно производство зеленых схем, если уж в начале шины увеличить производство нельзя
Здравствуйте!) Есть новости про следующую часть? :)
Всё это очень интересно, но всё же не корректно сравнивать жуков с бюджетом, а длину шины с реальными затратами на доставку сообщений.
Реальной шине без разницы на каком конце находится модуль, она доставляет данные с примерно одинаковой скоростью во все подключенные модули. Реальную шину расширять не так сложно. Более того, код шины уже чаще всего написан, оттестирован, оптимизирован и поддерживает масштабирование. Всё, что в реальности остаётся сделать разработчикам — это подключить независимые друг от друга модули, каждый из которых может разрабатываться отдельно и никак не влиять на другие как в монолите, где все завязаны друг на друга. Монолит очень тяжело пилить в больших командах. Это как раз тот случай, когда 9 женщин не родят младенца за 1 месяц, а в SOA и подобных, где есть шина, родят.
Жуки тоже очень эфемерное сравнение. И как я описал выше, всё наоборот, дешевле пилить SOA, когда никто друг другу не мешает, когда шина уже есть, чем смешивать всё в монолите, зависеть от почти любых изменений каждой из команд и из-за этого конфликтовать друг с другом.
По жукам согласен. На текущий момент я ничего лучше не придумал. Есть есть идеи, как лучше поведение игровых жуков ассоциировать с реальной разработкой - готов слушать.
По большим командам тоже согласен: в SOA они будут эффективней работать вместе, чем в Monolith'е. Хотя мы на это не тестировали.
По шине - не уверен в доводах:
Во-первых, кто-то эту шину написал, оттетсировал, оптимизировал и поддерживает в плане масштабирования - то есть потратил на это человекочасы. У меня получилось высчитать 30-40% трудозатрат на шину относительно общих трудозатрат на разработку. Если, по вышему мнению, есть ошибки в расчётах - я готов слушать и, при необходимости, пересчитать.
Во-вторых, с подключением независимых сервисов к шине вообще проблем никаких не было. Происходило это достаточно шаблонно: подключил один сервис - размножил способ подключения на другие.
Касательно одинаковой скорости шины на все сервисы - скорее всего я согласен. Но тут я не придумал ничего более стабильного, чем на каждый сервис отдирать по 1/8 ресурсов. В данной архитектуре шина должна оставаться простой с точки зрения логики работы и просто связывать сервисы друг с другом. Если там начать делать сложную логику балансировки, то тогда на шину потратиться сильно больше процента времени относительно общей разработки. Хотя может это и окупится в плане общей скорости разработки - тут нужно отдельно пробовать (не обещаю)
Проверяем Архитектурные стили на движке Factorio (часть 2, SOA)