Pull to refresh

Comments 23

Может где-то и есть источник, в котором также лаконично описано всё, что связано с построением архитектуры приложения, но мне он на глаза не попадался. Статья торт. Жду продолжения.

Собственно да. По сути это тот же монолит, но гораздо легче масштабируется и решает большую часть проблем. Интересно, увидим ли в "микросервисном" подходе кучу квадратов 200*200 разделённых железкой, что является вторым типичным масштабируемым решением.

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

Пропускная способность ЖД практически бесконечна, по крайней мере легко масштабируется.

А жуки это походу девопсы прибегающие на слишком прожорливую архитектуру по ресурсам.

А какие архитектурные стили используют спидранеры?

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

пожалуй монолит на коленке

когда один из разработчиков устраивал speedrun, то у них был посекундно расписанный план для каждого участника "забега": что должно быть добыто/построено к какому времени и на какой позиции. Так что на коленке скорее план действий)

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

Есть мнение, что запуск ракеты - это только MVP.

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

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

Либо за несколько проектов нарабатывается опыт, и место для расширения выделяется заранее.

ПС. The factory must grow

Архитектура из микросервисов ситиблоков наше всё!

Я подумал над этим и понял, что нет.

В таком понимании обыграть будет сложно ситуацию:

  • Исследования - после запуска ракеты новые исследования не добавляют в игру новых сложностей, а просто делает "Сильнее, Выше, Быстрее". В общем, это уже не наполнение продукт фичами, а больше оптимизация на этапе эксплуатации. Не более.

  • Цель - если конечная цель не запуск ракеты и переход на АЭС, то тогда неизвестно что сделать взамен. Разрастись на определённое количество кв.км? Достичь определённой скорости производства? хз.

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

Обычно когда "меряются" мегабазами, упоминают именно что скорость производства либо количество запусков ракеты в минуту.

Автоматизация запуска ракет - аналог роста числа пользователей.

У форума с 1000 пользователями и соцсети с миллионами разные архитектуры.

Желаем автору терпения для реализации следующих паттернов.

Монолит я видел, это даже в Factorio первый способ создания фабрики. Пока не присоединяется ЖД с отдаленными станциями добычи руды. Но вот интересно, к чему относится «Главная шина» и многоблоковая база на основе мода LTN?

"Главная шина" — это тот же монолит, но с хорошей архитектурой.


Многоблоковая база на основе LTN — это микросервисы. ЖД сеть тут играет роль MQ, а LTN — оркестратор :-)

Ну мне кажется что «шина» ближе к SOA. С одной стороны ты можешь добавлять новые заводы до бесконечности, пока на Шине есть ресурсы для переработки, но с другой продукция всегда идет в одну сторону

Сейчас как раз занимаюсь SOA и скажу тебе - "ты чертовский прав."

Единственное, что продукцию можно и в противоположную сторону завернуть, вот только от этого становится только сложнее.

В общем, ждите вторую часть)

На самом деле, статья "может получиться хорошим обучающим материалом" и для начинающих разработчиков.

Это интересно, применять серьезные подходы к проектированию в, на первый взгляд, простых играх.

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

Жду продолжения.

Only those users with full accounts are able to leave comments. Log in, please.