200 записей можно дедовским методом фотографирования экрана на телефон. А потом или тупо дома переписать руками или распознавалку прилепить. А про 60 миллионов может быть блеф.
Ну вот, например, можно использовать один switch, а можно сбацать фабрику с абстрактными методами и реализовать их в подклассах. И всё это только ради того, что switch в коде нам глаз мозолит и «нарушает принципы». Из одной функции мы получаем несколько классов. Я бы подумал над разумностью плодить ещё несколько классов в проекте, где их и так тысячи. Здесь 3 класса, там еще 10… и так для каждого switch. О скорости сборки, производительности и даже банальной навигации по исходникам тоже не стоит забывать (я сейчас не только про этот случай).
Статья интересная, но я бы хотел увидеть ещё механизм обновления всего стека сервисов при изменении api без потери запросов на клиентах.
Например, такой кейс, по минмуму
Есть БД. 2 инстанса — мастер и слэйв.
Есть миддл-сервис (микросервис), тоже 2 инстанса.
Есть веб-сервер (держит сессии, делает аутентификацию), 2 инстанса.
Есть балансировщик (nginx, допустим).
И есть 100500 клиентов (броузеры + мобильные приложения).
Мы добавляем много нового функционала, в результате которого меняется структура БД, меняется api между фронт-сервером и микросервисами, меняется клиентское api.
Обновить всё сразу мы не можем, так как часть клиентов обновляться не хочет, приложение для iOS проходит проверку и т.п. + мы должны поддерживать старых клиентов.
Вопрос. Как сделать так, чтобы ни один клиент не пострадал? Я описал реальный кейс и нечто похожее (но более простое) делал руками (руками запускал и останавливал контейнеры, запускал скрипты миграции и всё контролировал лично).
А мне вот интересно было бы посмотреть на конкретного человека, который внезапно взял и сказал: «А давайте наедем на nginx». Любое такое дело начинается с какого-то конкретного муда... человека. И послушать его аргументы.
Нет, я конечно не уверен, потому в целом не против WAF, но полагаю, что первичная фильтрация в конфиге nginx быстрее, чем прогон через правила WAF? Вариант «посмотреть» не совсем ко мне, я вообще разработчик, а WAF мне интересен только в плане того, что на нём могут потеряться нужные мне запросы. А насчёт пентеста я попробую узнать.
Как вы считаете, насколько необходим WAF, если веб-сервер имеет жёсткое json-rpc api, фиксированный набор аргументов и полностью самописных клиентов (свои собственные http-заголовки)? Несколькими простыми проверками в конфиге nginx я могу отсеять 99% левого траффика. А веб-сервер также собственного изготовления, в нём нет прямого взаимодействия с БД, нет вообще веб-контента, а только ДТО из json в другие форматы (в том числе бинарные).
Включал я мастер-мастер, когда идёт по 300 запросов в секунду, не успевает она. Особенно фигово, когда репликация разваливается, очень сложно потом хоть что-то поднять. Haproxy в работе использую, но не в данном случае. Может быть, стоит поэкспериментировать.
Соглашусь, пожалуй. А для важных данных другие требования и другие решения нужны. Здесь важна в первую очередь скорость. Если бы надежность стояла на первом месте, я бы смотрел куда-нибудь в сторону кассандры, например, с фактором репликации 2 или 3.
Допустим, конфликты репликации я порешаю, но они — это следствие проблемы, а не причина. Один сервис так и будет писать в первый тарантул, а второй — в другой. Слэйв будет иметь все данные мастера, но мастер данных слэйва всё равно не получит.
Обвязка вокруг всего этого получается большая и сложная, сопоставимая по сложности с самим сервисом. А хочется чего-то такого, чтобы раз — и заработало. Хотя бы того, чтобы затраты окупились, ибо потеря клиентских сессий на короткий промежуток времени раз в год экономически выгоднее поддержки сложной инфраструктуры. Сейчас сервис по доступности вполне укладывается в 99,99%.
Первый вариант вообще хорош, и кодить не нужно ) Вообще мы пока не поимели этой проблемы, а пока в разряде вероятных. Но меня беспокоит.
Второй вариант я обдумывал, но сервис «сбоку» точно также гипотетически может потерять только одну ноду, при том, что сами java-сервисы его будут нормально видеть. Как вариант, если мы примем допущение, что слэйв видит мастер, то он по факту начала приемов запросов на запись может послать запрос мастеру на прекращение работы. Однако здесь мы оказываемся в той же самой ситуации, что слэйв может потерять мастер. Мне кажется, что если ваш первый вариант дополнить грамотным размещением серверов с учетом топологии сети, то вероятность таких ошибок можно минимизировать. Но не исключить.
А что делать приложению, которому надо работать, но база отвалилась? У него есть резервный адрес, куда можно ходить, и он туда идёт. Оно не знает, мастер там или не мастер.
Тоже верно, но нам нужно, чтобы реплика становилась мастером, а делает это она, когда начинает принимать запросы на запись снаружи, как и было запланировано )
Всё правильно, им хорошо, они оба стали независимыми инстансами без репликации. Так как один из сервисов начал писать на слэйв, а слэйву ничего не мешает принимать запросы на добавление данных (больше того, так и было задумано), но возникают ошибки репликации, которые мы видим в логах ядра, после чего репликация разваливается. Ошибок именно на запись данных в lua-коде я не наблюдал, сервисы просто становятся назависимыми и продолжают работу.
Да, он, в принципе, знает, что репликация развалилась, но на уровне логов ядра, а как получить такое событие в lua-скрипте, я не знаю. И вполне может при этом начать работать на запись данных, если индексы это позволяют. Ошибки есть только если дублирование по индексам происходит, но это не поможет решить нашу проблему.
Все метрики у нас свои, встроены в код через prometheus-агенты, которые есть для всех основных языков. На самих WCF у нас сделана рест-дырка, а на стороне java-сервиса используется Apache http client, подсчитать запросы которого обычным Counter от Prometheus не составляет труда.
Например, такой кейс, по минмуму
Есть БД. 2 инстанса — мастер и слэйв.
Есть миддл-сервис (микросервис), тоже 2 инстанса.
Есть веб-сервер (держит сессии, делает аутентификацию), 2 инстанса.
Есть балансировщик (nginx, допустим).
И есть 100500 клиентов (броузеры + мобильные приложения).
Мы добавляем много нового функционала, в результате которого меняется структура БД, меняется api между фронт-сервером и микросервисами, меняется клиентское api.
Обновить всё сразу мы не можем, так как часть клиентов обновляться не хочет, приложение для iOS проходит проверку и т.п. + мы должны поддерживать старых клиентов.
Вопрос. Как сделать так, чтобы ни один клиент не пострадал? Я описал реальный кейс и нечто похожее (но более простое) делал руками (руками запускал и останавливал контейнеры, запускал скрипты миграции и всё контролировал лично).
муда...человека. И послушать его аргументы.Второй вариант я обдумывал, но сервис «сбоку» точно также гипотетически может потерять только одну ноду, при том, что сами java-сервисы его будут нормально видеть. Как вариант, если мы примем допущение, что слэйв видит мастер, то он по факту начала приемов запросов на запись может послать запрос мастеру на прекращение работы. Однако здесь мы оказываемся в той же самой ситуации, что слэйв может потерять мастер. Мне кажется, что если ваш первый вариант дополнить грамотным размещением серверов с учетом топологии сети, то вероятность таких ошибок можно минимизировать. Но не исключить.