Архитектурные ошибки Genesyx из-за финансового подхода к разработке

Регистрация

Архитектурные ошибки финансового подхода

Архитектурные ошибки финансового подхода
23.09.2024 12:03:34

Я уже упоминал, что на старте работы над Genesyx наделал архитектурных ошибок в серверном коде, потому что моя основная деятельность была связана с разработкой финансового софта, где критична точность и надежность. Подраскрою немного эту тему, ведь проблемы эти никуда не ушли и их тоже нужно будет побороть до запуска Genesyx 3D в массы.

Когда вы пишите приложения для финансовых институтов (банков, брокеров, хедж фондов и пр.), самое худшее, что можно сделать - накосячить с данными. Например два раза провести одну и ту же транзакцию, в результате чего клиент заплатит дважды, или ошибиться в запятой где-то в незаметном месте, что приведет к тому, что клиент желая потратить 1,000 каких-то денежных единиц потратит вместо этого 1,000,000. Это налагает некоторый стиль программирования, который подразумевает максимальную точность и надежность. А это всегда делается в ущерб производительности и масштабируемости. Поэтому операции в финансовых приложения обычно делят на различные модули или даже отдельные продукты, которые работают поверх различных баз данных и на разном железе, а интеграции между ними протекают в отдельных процессах.

Вот и у меня на момент начала разработки Genesyx за спиной было лет 10 опыта в разработке финансовых приложений и 0 в геймдеве, поэтому Genesyx получился очень точным и надежным, но если вопросы производительности со временем удалось решить, то вопрос масштабируемости все еще стоит ребром.

Я до сих пор с недоумением смотрю на современные игры где разработчики, выкатывая минорное обновление умудряются класть всю систему и проводить мейнтенанс в течение 6-8 часов... И это-то в эпоху Docker-контейнеров и blue-green деплоймента. В моем случае обновление всегда сводилось к перезаписи бинарей и прочих ресурсов + перезапуску приложения. На все про все - 10-15 секунд и снова все работает. При этом игроки видели подвисание на эти самые 10-15 секунд и больше ничего. Все бои продолжались, в том же состоянии, в каком были на момент перезапуска, кто ушел в пустоши продолжал там оставаться, крафт не сбрасывался (за исключением ситуаций когда я налажаю с выкатываемым кодом, в этом случае полежим минут 5-10 пока найду и решу проблемы) и т.п.. Все потому, что в любой момент времени актуальное состояние находится в базе, а значит каждый раз, когда его нужно поменять - данные читаются из базы и сразу обновляются в базе. Это дает сумасшедшую надежность, но это же и убивает масштабируемость, ведь база - самое конкурентное место, которое только может быть и в такой модели запустить даже 50 боев параллельно будет попросту невозможно.