Да, всё правильно. По сути мы обыграли ситуацию, что в начале разработки мы и представить себе не могли о том, какие проблемы у нас будут в середине разработки. Поэтому понаделали ошибки, которые решали уже по ходу методом костылинья.
Напоминаю, что у нас тут цель не расчитать идеальное производство в игре Factorio и реализовать его. Тут у нас цель эмитировать процесс разработки ПО (со всеми косяки, костылями, ошибками и прочим) - именно поэтому я стараюсь больше действовать интуитивно, чем расчётливо.
По жукам согласен. На текущий момент я ничего лучше не придумал. Есть есть идеи, как лучше поведение игровых жуков ассоциировать с реальной разработкой - готов слушать.
По большим командам тоже согласен: в SOA они будут эффективней работать вместе, чем в Monolith'е. Хотя мы на это не тестировали.
По шине - не уверен в доводах:
Во-первых, кто-то эту шину написал, оттетсировал, оптимизировал и поддерживает в плане масштабирования - то есть потратил на это человекочасы. У меня получилось высчитать 30-40% трудозатрат на шину относительно общих трудозатрат на разработку. Если, по вышему мнению, есть ошибки в расчётах - я готов слушать и, при необходимости, пересчитать.
Во-вторых, с подключением независимых сервисов к шине вообще проблем никаких не было. Происходило это достаточно шаблонно: подключил один сервис - размножил способ подключения на другие.
Касательно одинаковой скорости шины на все сервисы - скорее всего я согласен. Но тут я не придумал ничего более стабильного, чем на каждый сервис отдирать по 1/8 ресурсов. В данной архитектуре шина должна оставаться простой с точки зрения логики работы и просто связывать сервисы друг с другом. Если там начать делать сложную логику балансировки, то тогда на шину потратиться сильно больше процента времени относительно общей разработки. Хотя может это и окупится в плане общей скорости разработки - тут нужно отдельно пробовать (не обещаю)
Когда вам нужно создать хеш-мапу, вы не идете в сервис по созданию хеш-мап, вы просто пишете new HashMap(). Когда вам нужно опустить строку в нижний регистр, вы не идете в сервис по опусканию строк в нижний регистр, вы просто пишете toLowerCase().
Не, ну это крайность уже - под функциями я имел в виду что-то более широкое типа buy_ticket(), calculate_tax() и типа того. В SOA у меня получилось около 100 таких функций и мне кажется, что это похоже на настоящее приложение.
Касательно отдельного сервиса для медных проводов - рассматривайте это не какую-то мелочь, а, например, сервис курса доллара в банке - вроде бы просто передаётся цифра, но без неё банк перестаёт нормально функционировать. А поскольку эту цифру нужно взять и надёжного источника (центробанка), пройти там систему защиты, несколько раз перепроверить результат и всё это добро повторяется, условно, раз в минуту - я охотно верю, что это отдельный сервис.
В таком случае вам нужно воспроизвести еще 3 сценария:
Согласен, ибо сам думал это проверять. Но не сейчас - может потом сделаю отдельную статью про "уходы/приходы сотрудников в большой проект на движке Factorio" :)
Но вы как раз и отказываетесь вставлять костыли в угоду "чистой архитектуре".
Я бы назвал это по другому: я пытаюсь симулировать, что я через тернии следую к "чистой архитектуре") Ключевое тут - затраченное время и любые костыли будут именно его тратить. Так или иначе, я лучше реализацию пока придумать не смог: чтобы и идеалы не потерять, и в дерьме не утонуть :)
Можешь предположить, добавление модов это получается использование более сложного языка или это просто усложнение бизнес функций продукта?
Хороший вопрос, но я не думаю, что я тут эксперт т.к. мне моды не зашли особо. А с учётом того, что я специально ограничил себе игру (не использовать логические сети, отключил эволюцию жуков, запретил использовать статических дрон-станций), я думаю, что моды бы особо мне не помогли - бы их тоже ограничил :). Разве что моды на передвижение персонажа были бы кстати (типа мода на телепорты), но это уже дисбаланс. Так что я не знаю, сорри)
Спасибо за коммент! И я даже согласен с большинством утверждений)
Давайте по порядку:
Прежде всего хочу сказать, что играть вслепую, не пользуясь чужим опытом и рецептами, — это именно то, как надо проходить Factorio в первый раз.
Именно это я и пытался достигнуть при прохождении - играть как будто в первый раз. Конечно, некий опыт всё равно накапливается, но не существенно. Всё потому-что если я начну использовать публичные наработки, то я сразу же сделаю приложение, близкое к идеалу. Но у меня другая задача: попробовать воспроизвести работу команды разработки со всеми её косяками - неверные решения, ошибки программной логики, ошибки проектирования, внезапные проблемы с Жуками. В моём понимании Бескосячное производство существует только в Agile-книгах)
Собственно говоря, main bus в Factoio похожа на шину сообщений в SOA только названием
Согласен, но другого я ничего не придумал более: если сделать подобную шину с Маршрутизацией, то получится тот же Монолит, но очень широкий. Если же использовать поезда, то получится как раз схема из следующей статьи. В итоге я остановился на подобном компромиссе. Как я уже говорил в первой части - если после публикации увижу грубую ошибку, то я перепройду и пересчитаю результат. Но это будет в конце. К сожалению....
когда вы закончите с этим проектом, попробуйте познакомиться с общепринятыми лучшими практиками, особенно с использованием поездов и настоящей service-oriented architecture, в Factorio известной под именем city blocks
Пока я не завершу цикл статей из 6 частей - я другие примеры заводов смотреть не буду, чтобы не получить ложноположительные результаты в будущих Архитектурных стилях, сорри) Разбору всех их я в 7-ой части, где мы будем в поисках идеального приложения разбирать уже пользовательские заводы и даже спидраны. Так что да, я благодарен за то, что накидываете примеры, но обзор их будет в конце. К сожалению...
И, собственно, то, из-за чего я собственно и пишу этот комментарий: тестировать подходы к проектированию базы запуская одну ракету — все равно что тестировать варианты архитектуры веб-сервера на одном соединении.
Вот тут я уже не согласен. Если не заканчивать игру на одной ракете, то тогда, во-первых, не понятно где её вообще заканчивать; во-вторых, на это потратиться в разы больше времени и я не готов буду по несколько лет делать одну статью, сорри. Поэтому мне запуск первой ракеты показался хорошим компромиссом: исследовать больше нечего (все фичи сделаны), бизнес-цели достигнуты (полетели в космос) и прочее. По сути, с этого момента Приложение просто переходит в эксплуатацию и дальше разработка ограничивается только правкой редких багов. Как то так.
На самом деле как работало стоковое распределение из Шины меня вполне устраивало и поэтому я не стал там что-то менять. Если бы не устраивало - я бы это быстро бы заметил и начал что-то придумывать.
Я, ради интереса, попробовал поставить счётчики на подобную схему
То есть при такой схеме от любого ответвления уходит только 1/8 всего потока, что меня вполне устраивало
Это можно увидеть на скриншоте из той игры, что я делал по статье:
И, по сути, единственное место, где наблюдается "жадные" ветки - только в тех местах, где уже дальнейший ход предметов невозможен:
То есть как раз где-то в конце, где всегда находятся последние и актуальные заводы. Именно поэтому я написал в статье:
Зато если построить завод в текущем конце Шины, то все эти зависшие ресурсы из Шины идут именно на новое производство и мы на первое время получаем заметный прирост данный предметов. Из-за этого на графиках всегда можно заметить пик производства в самом начале, а потом оно нормализуется.
Я думал, как сделал лучше с Шиной и не пихать на всё подряд, но не придумал - если отступить от применённой мной конфигурации, то получается не SOA, а просто очень большой Монолит. В целом, он тоже имеет право на жизнь и, возможно, я ещё переиграю. Но пока так)
По поводу туториалов из Интернета - я их намеренно не использую т.к. моя задача - стараться максимально точно воспроизвести работу типичной Продуктовой команды разработчиков. Именно "типичную" - со всеми их косяками, костылями и прочее. В итоге я использую не готовые, идеальные знания/схемы для игры, а стараюсь самостоятельно, на лету генерировать решения - именно так работают программисты в общей массе, ИМХО.
Короче, это Архитектурная статья и она рассказывает не про идеальный мир, а про реальный со своими достоинствами и недостатками - именно это я и стараюсь не упускать.
В статье у меня Архитектурный вопрос поднимается и его суть в том, как сделать идеальное приложение по производительности, а более общее: как это приложение будет тестироваться, масштабироваться, описываться, быстро писаться и прочее.
Именно в этом аспекте я пытаюсь сделать статью: мне нужно сделать не идеальное приложение, а именно оценить плюсы и минусы каждого Архитектурного стиля.
В SOA же используется Шина, а это уже внутрипрограммная логика, поэтому я тут использовал конвейеры: во-первых, потому-что я установил такие ассоциации в первой части; во-вторых, чтобы потом не повторяться, когда буду делать EDA.
Касательно логических сетей - я их не использую т.к. я не смог придумать ассоциацию для них в реальной разработке. То есть ЖД - это сеть; конвейера - функции; логическая сеть - хз. Ну и для более точных измерений мне нужна как можно менее нагруженная игра и логическая сеть вносит сюда фактор оптимизации, на которую придётся потратить время и которая собьёт графики в положительную сторону. В общем, я пока не готов к этому.
Кстати, по этой же причине я и не использую статичные Дрон-станции - я просто не могу придумать ассоциацию их с реальной разработкой.
Ну и моды у меня тоже запрещены, чтобы не сбивать баланс и ещё иметь возможность публиковать свои сохранения для широких масс.
Я думал использовать ЖД, но проблема в том, что у меня тут на схеме ЖД является сетью, а в это уже ближе к API и/или очередям. Я буду ещё использовать подобную схему с ЖД, но уже в Архитектурном стиле "Событийно-управляемая архитектура (Event-Driven Architecrute или EDA". Вот схема и, как видите, она чем-то похожа на SOA:
Исследования - после запуска ракеты новые исследования не добавляют в игру новых сложностей, а просто делает "Сильнее, Выше, Быстрее". В общем, это уже не наполнение продукт фичами, а больше оптимизация на этапе эксплуатации. Не более.
Цель - если конечная цель не запуск ракеты и переход на АЭС, то тогда неизвестно что сделать взамен. Разрастись на определённое количество кв.км? Достичь определённой скорости производства? хз.
Я сейчас делаю SOA и скажу, что уже посреди сюжета хорошо видны плюсы и минусы Архитектуры, хотя и высчитать их в цифрах мне ещё предстоит. В общем, подход работает, а значит смысла менять что-то нет.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Да, всё правильно. По сути мы обыграли ситуацию, что в начале разработки мы и представить себе не могли о том, какие проблемы у нас будут в середине разработки. Поэтому понаделали ошибки, которые решали уже по ходу методом костылинья.
Напоминаю, что у нас тут цель не расчитать идеальное производство в игре Factorio и реализовать его. Тут у нас цель эмитировать процесс разработки ПО (со всеми косяки, костылями, ошибками и прочим) - именно поэтому я стараюсь больше действовать интуитивно, чем расчётливо.
По жукам согласен. На текущий момент я ничего лучше не придумал. Есть есть идеи, как лучше поведение игровых жуков ассоциировать с реальной разработкой - готов слушать.
По большим командам тоже согласен: в SOA они будут эффективней работать вместе, чем в Monolith'е. Хотя мы на это не тестировали.
По шине - не уверен в доводах:
Во-первых, кто-то эту шину написал, оттетсировал, оптимизировал и поддерживает в плане масштабирования - то есть потратил на это человекочасы. У меня получилось высчитать 30-40% трудозатрат на шину относительно общих трудозатрат на разработку. Если, по вышему мнению, есть ошибки в расчётах - я готов слушать и, при необходимости, пересчитать.
Во-вторых, с подключением независимых сервисов к шине вообще проблем никаких не было. Происходило это достаточно шаблонно: подключил один сервис - размножил способ подключения на другие.
Касательно одинаковой скорости шины на все сервисы - скорее всего я согласен. Но тут я не придумал ничего более стабильного, чем на каждый сервис отдирать по 1/8 ресурсов. В данной архитектуре шина должна оставаться простой с точки зрения логики работы и просто связывать сервисы друг с другом. Если там начать делать сложную логику балансировки, то тогда на шину потратиться сильно больше процента времени относительно общей разработки. Хотя может это и окупится в плане общей скорости разработки - тут нужно отдельно пробовать (не обещаю)
Добрый день!
Пока ещё пишу и пришлось взять паузу из-за переезда. Думаю, что весной будет готова статья
Спасибо за развёрнутый коммент!
Давайте по порядку:
Не, ну это крайность уже - под функциями я имел в виду что-то более широкое типа
buy_ticket(),calculate_tax()и типа того. В SOA у меня получилось около 100 таких функций и мне кажется, что это похоже на настоящее приложение.Касательно отдельного сервиса для медных проводов - рассматривайте это не какую-то мелочь, а, например, сервис курса доллара в банке - вроде бы просто передаётся цифра, но без неё банк перестаёт нормально функционировать. А поскольку эту цифру нужно взять и надёжного источника (центробанка), пройти там систему защиты, несколько раз перепроверить результат и всё это добро повторяется, условно, раз в минуту - я охотно верю, что это отдельный сервис.
Согласен, ибо сам думал это проверять. Но не сейчас - может потом сделаю отдельную статью про "уходы/приходы сотрудников в большой проект на движке Factorio" :)
Я бы назвал это по другому: я пытаюсь симулировать, что я через тернии следую к "чистой архитектуре") Ключевое тут - затраченное время и любые костыли будут именно его тратить. Так или иначе, я лучше реализацию пока придумать не смог: чтобы и идеалы не потерять, и в дерьме не утонуть :)
Спасибо)
Хороший вопрос, но я не думаю, что я тут эксперт т.к. мне моды не зашли особо. А с учётом того, что я специально ограничил себе игру (не использовать логические сети, отключил эволюцию жуков, запретил использовать статических дрон-станций), я думаю, что моды бы особо мне не помогли - бы их тоже ограничил :). Разве что моды на передвижение персонажа были бы кстати (типа мода на телепорты), но это уже дисбаланс. Так что я не знаю, сорри)
Возможно и организуем, если совсем не перегорю) Но это перспектива нескольких лет, так что хз)
Спасибо)
Спасибо за коммент! И я даже согласен с большинством утверждений)
Давайте по порядку:
Именно это я и пытался достигнуть при прохождении - играть как будто в первый раз. Конечно, некий опыт всё равно накапливается, но не существенно. Всё потому-что если я начну использовать публичные наработки, то я сразу же сделаю приложение, близкое к идеалу. Но у меня другая задача: попробовать воспроизвести работу команды разработки со всеми её косяками - неверные решения, ошибки программной логики, ошибки проектирования, внезапные проблемы с Жуками. В моём понимании Бескосячное производство существует только в Agile-книгах)
Согласен, но другого я ничего не придумал более: если сделать подобную шину с Маршрутизацией, то получится тот же Монолит, но очень широкий. Если же использовать поезда, то получится как раз схема из следующей статьи. В итоге я остановился на подобном компромиссе. Как я уже говорил в первой части - если после публикации увижу грубую ошибку, то я перепройду и пересчитаю результат. Но это будет в конце. К сожалению....
Пока я не завершу цикл статей из 6 частей - я другие примеры заводов смотреть не буду, чтобы не получить ложноположительные результаты в будущих Архитектурных стилях, сорри) Разбору всех их я в 7-ой части, где мы будем в поисках идеального приложения разбирать уже пользовательские заводы и даже спидраны. Так что да, я благодарен за то, что накидываете примеры, но обзор их будет в конце. К сожалению...
Вот тут я уже не согласен. Если не заканчивать игру на одной ракете, то тогда, во-первых, не понятно где её вообще заканчивать; во-вторых, на это потратиться в разы больше времени и я не готов буду по несколько лет делать одну статью, сорри. Поэтому мне запуск первой ракеты показался хорошим компромиссом: исследовать больше нечего (все фичи сделаны), бизнес-цели достигнуты (полетели в космос) и прочее. По сути, с этого момента Приложение просто переходит в эксплуатацию и дальше разработка ограничивается только правкой редких багов. Как то так.
На самом деле как работало стоковое распределение из Шины меня вполне устраивало и поэтому я не стал там что-то менять. Если бы не устраивало - я бы это быстро бы заметил и начал что-то придумывать.
Я, ради интереса, попробовал поставить счётчики на подобную схему
В итоге результат был такой:
Сейв
То есть при такой схеме от любого ответвления уходит только 1/8 всего потока, что меня вполне устраивало
Это можно увидеть на скриншоте из той игры, что я делал по статье:
И, по сути, единственное место, где наблюдается "жадные" ветки - только в тех местах, где уже дальнейший ход предметов невозможен:
То есть как раз где-то в конце, где всегда находятся последние и актуальные заводы. Именно поэтому я написал в статье:
Спасибо за совет)
Я думал, как сделал лучше с Шиной и не пихать на всё подряд, но не придумал - если отступить от применённой мной конфигурации, то получается не SOA, а просто очень большой Монолит. В целом, он тоже имеет право на жизнь и, возможно, я ещё переиграю. Но пока так)
По поводу туториалов из Интернета - я их намеренно не использую т.к. моя задача - стараться максимально точно воспроизвести работу типичной Продуктовой команды разработчиков. Именно "типичную" - со всеми их косяками, костылями и прочее. В итоге я использую не готовые, идеальные знания/схемы для игры, а стараюсь самостоятельно, на лету генерировать решения - именно так работают программисты в общей массе, ИМХО.
Короче, это Архитектурная статья и она рассказывает не про идеальный мир, а про реальный со своими достоинствами и недостатками - именно это я и стараюсь не упускать.
Спасибо за совет.
Тут только есть одна проблема - из моего окружения в ЭТО играть никто не хочет :)
Спасибо!
В статье у меня Архитектурный вопрос поднимается и его суть в том, как сделать идеальное приложение по производительности, а более общее: как это приложение будет тестироваться, масштабироваться, описываться, быстро писаться и прочее.
Именно в этом аспекте я пытаюсь сделать статью: мне нужно сделать не идеальное приложение, а именно оценить плюсы и минусы каждого Архитектурного стиля.
Но работы много ещё)
Да, спасибо за отзыв!
В SOA же используется Шина, а это уже внутрипрограммная логика, поэтому я тут использовал конвейеры: во-первых, потому-что я установил такие ассоциации в первой части; во-вторых, чтобы потом не повторяться, когда буду делать EDA.
Касательно логических сетей - я их не использую т.к. я не смог придумать ассоциацию для них в реальной разработке. То есть ЖД - это сеть; конвейера - функции; логическая сеть - хз. Ну и для более точных измерений мне нужна как можно менее нагруженная игра и логическая сеть вносит сюда фактор оптимизации, на которую придётся потратить время и которая собьёт графики в положительную сторону. В общем, я пока не готов к этому.
Кстати, по этой же причине я и не использую статичные Дрон-станции - я просто не могу придумать ассоциацию их с реальной разработкой.
Ну и моды у меня тоже запрещены, чтобы не сбивать баланс и ещё иметь возможность публиковать свои сохранения для широких масс.
Я думал использовать ЖД, но проблема в том, что у меня тут на схеме ЖД является сетью, а в это уже ближе к API и/или очередям. Я буду ещё использовать подобную схему с ЖД, но уже в Архитектурном стиле "Событийно-управляемая архитектура (Event-Driven Architecrute или EDA". Вот схема и, как видите, она чем-то похожа на SOA:
Сейчас как раз занимаюсь SOA и скажу тебе - "ты чертовский прав."
Единственное, что продукцию можно и в противоположную сторону завернуть, вот только от этого становится только сложнее.
В общем, ждите вторую часть)
Я подумал над этим и понял, что нет.
В таком понимании обыграть будет сложно ситуацию:
Исследования - после запуска ракеты новые исследования не добавляют в игру новых сложностей, а просто делает "Сильнее, Выше, Быстрее". В общем, это уже не наполнение продукт фичами, а больше оптимизация на этапе эксплуатации. Не более.
Цель - если конечная цель не запуск ракеты и переход на АЭС, то тогда неизвестно что сделать взамен. Разрастись на определённое количество кв.км? Достичь определённой скорости производства? хз.
Я сейчас делаю SOA и скажу, что уже посреди сюжета хорошо видны плюсы и минусы Архитектуры, хотя и высчитать их в цифрах мне ещё предстоит. В общем, подход работает, а значит смысла менять что-то нет.