Pull to refresh
45
31.2
Razoomnick @Razoomnick

Пользователь

Send message

Очередь есть, без нее никак. Просто вместо отдельного сервиса это таблица в базе. Соответственно, из этой таблицы берут, там же обновляют статус и так далее. Пока что это отлично работает.

Что касается того, почему это не отдельный сервис:

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

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

  3. В случае отключения или зависания обработчика его задачи по его каталогам должны перераспределиться на другие обработчики. Перед этим там считаются данные для каталога.

Задач относительно немного, и с таким набором требований оказалось проще самим написать логику очереди, чем использовать готовое решение. Когда эта часть станет узким местом, будем внедрять готовый MQ.

Спасибо, устраняем проблемы. Часть уже исправили, часть еще в процессе.

Спасибо. Я знал про эту возможность, но почему-то не пользовался. Попробуем на практике.

Спасибо за замечания, будем исправлять.

Вопрос с хостингом закрывает человек в ЕС.

Логи хранятся в sql базе данных, поскольку работа с ними производится через Entity Framework, СУБД может быть любой.

С этой подводной лодки я никуда не денусь, это мой проект, и все риски на мне, если что.

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

Ой, Razor конечно. Не знаю, как прочитал прошлый ваш комметнарий, и почему Razor не увидел.

Ничего из перечисленного, олд скул: сервер генерирует html, на клиенте - jquery, пара плагинов, самописные скрипты.

Соглашусь с вами. Велосипед не бесплатный, и его поддержка тоже не бесплатная. И лучше платить позже, чем раньше. Если честно, у меня тоже нет данных, чтобы сказать, что хуже, а что лучше даже применительно к нашему проекту. Просто поделился опытом, что такой подход тоже работает, а в небольших командах - хорошо работает, и не является источником каких-либо проблем.

Что касается отказа от очередей, решение не принципиальное - не нужны нам очереди, и все тут. Скорее ситуативное - пока нет необходимости, не усложняем. Увидим, что приплыли, пора - будем внедрять.

Просто в контексте стартапа это "приплыли" может и не наступить, и скорее всего - по причинам, которые никак не связаны ни с очередями, ни с микросервисами, ни с фреймворком для SPA.

Возможно, я не до конца корректно донес свою мысль. Кафка или условный MQ всем хороши, и на больших масштабах выиграют у велосипеда, я не сомневаюсь. Но пока у вас небольшая команда и нагрузка, с которой справляется велосипед - лучше простой велосипед для конкретной задачи в конкретных условиях. Но об ограничениях велосипеда нужно знать и помнить, безусловно.

А можете раскрыть чуть подробнее, в чем состоит заблуждение? Можете ссылкой, или сориентируйте, что гуглить. Без сарказма, я хочу лучше разобраться в этом.

Если что, под "предсказуемой памятью" я подразумевал следующее: нам нужно в памяти иметь дерево на, скажем, 100 миллионов узлов. Тогда мы точно знаем, сколько оно займет памяти, сколько из нее будет потрачено на ссылки, сколько - на непосредственно данные.

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

Про пентесты - не понял, если честно. Речь про DOS с возможным повреждением памяти и выполнением произвольного кода? Но .NET - виртуальная машина, её задача - такого не допускать, и про такие атаки я не слышал. Мы же не на плюсах пишем.

Что касается джавы, то соглашусь отчасти. Все-таки .NET для веба лучше подходит по моему субъективному мнению, а C# как язык приятнее. Что касается тайпскрипта и пайтона, то у них преимуществ для решения наших задач я не вижу. Я реально много времени провел в DotTrace, и, боюсь, что в случае с пайтоном и тайпскриптом приемлемой скорости я бы не добился. В общем, сделайте скидку на то, что C# - мой основной язык, а с перечисленными вами у меня гораздо меньше опыта.

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

Я думал, что вся статья об этом и есть. Что сначала нужно найти бизнес-модель, а потом - масштабироваться. Не наоборот. И что с поиском бизнес-модели и места на рынке микросервисы никак не помогают, а сложность вносят и ресурсы тратят.

Сначала клиенты и продажи, потом микросервисы и шины данных.

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

Для миграций сами пишем скрипты по накатыванию. Потом, при обновлении версии, они накатываются на все базы клиентов. Код для этого мы тоже написали сами. Скрипты должны приводить схему к точно такому же виду, как у новой созданной через Entity Framework базы.

Задачи мы делим на небольшие автономные подзадачи, если это возможно. Продакшен обновляется несколько раз в день, поэтому все скрипты в большинстве своем - простые, и до этого протестированные разработчиком и на демо-сервере.

Когда что-то идет не так, пишем скрипт по откату. К счастью, такого опыта пока реально мало, ни одной базы мы пока что не убили. К несчастью, на этот случай нет четкого плана. Что-то типа "Откатим, если что. Если совсем все плохо будет, будем поднимать бекап".

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

  2. Для этого есть интеграции с другими системами. Остатки мы можем забирать из API маркетплейсов, выгружать из 1С, забирать из произвольных файлов в соответствии с тем, как это настроил пользователь. Например, типичный случай: продавец не весь ассортимент держит у себя на складе, часть - берет у поставщиков или партнеров. Те регулярно присылают ему на почту файл с информацией, что у них есть, в каком количестве, по какой цене. Наша система автоматически проверяет почту, разбирает новые файлы и обновляет информацию о ценах и наличии товаров. Я бы не сказал, что это именно складской учет, он сложнее. Скорее - единое окно для работы с максимумом доступной информации.

А ссылки на фиктивные судебные решения - это разве не оно?

Ну как минимум на неуважение к суду тянет, если не на что-то большее.

У меня были в последние лет 6 айфон X, самсунг M21 и пиксель 6a.

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

Наиболее критичное для меня - время работы от батареи, тут самсунг лучше всех, айфон хуже всех, пиксель посередине. Пикселя и самсунга всегда хватает, айфон бесит тем, что быстро разряжается.

По количеству предустановленного мусора, который не удаляется штатными средствами, самсунг хуже всех, пиксель и айфон на одном уровне.

По фотографиям - пиксель 6a примерно на уровне айфона X. Деталей больше у пикселя, по цветопередаче айфон приятнее. Самсунг значительно хуже.

Конкретно у моего пикселя экран синит, у айфона и самсунга приятнее цвета.

По ценам - айфон в разы дороже, пиксель незначительно дороже самсунга.

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

Мне показалось, что ситуация иная. API уже спроектировано до нас и не нами, и является частью некоторой системы. Мы же реализуем совместимую, насколько возможно, систему, которая этот API предоставляет, и хотим запускать на ней приложения, спроектированные для оригинальной системы. Но, как всегда, ресурсы ограничены, и чем-то нужно жертвовать. Автор рассказывает, как именно сделать заглушки для методов, которые мы не смогли или не успели реализовать.

В статье приведены примеры c оригинальной Windows и её версией для Xbox. Я бы их дополнил Windows и WINE, Windows и ReactOS, .NET и Mono (хоть это уже история), Windows и ExaGear.

Согласен, можно.

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

Information

Rating
155-th
Location
Беларусь
Date of birth
Registered
Activity