Re[52]: Помогите правильно спроектировать микросервисное при
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.02.26 16:11
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, gandjustas, Вы писали:


G>>·>Так ведь по большому счёту разница невелика с т.з. усилий на разработку. А перформанс, он и в африке перформанс.

G>>Разница огромная.
G>>В бизнес-приложениях:
G>>- ключевую роль играет стоимость разработки. Никому не нужно бизнес-приложение, которое стоит дороже самого бизнеса, какое бы крутое это приложение не было. Это линейный фактор.
G>>- не надо соревноваться по скорости с другими системами. Поэтому перформанс в них — гигиенический фактор. Достигая определенного уровня он перестает давать ценность. Зато стоимость каждого следующего улучшения перформанса растет геометрически. Если разницу между 100мс и 20мс никто глазами не заметит, то нет смысла делать даже 20 мс.
·>Пока ВНЕЗАПНО не наступает какая-нибдуь чёрная пятница или новогодние распродажи.
ВНЕЗАПНО длительность транзакции напрямую не влияет на масштабируемость систем. По сути все распределенные транзакции длительность увеличивают, но также увеличивают и пропускную способность.


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

·>В трейдинге плюс к этому ещё и штрафы влепят от всяких FCA.
За что?

G>>В трейдинге другие факторы:

G>>- перформанс это must фактор, так как если ты работаешь медленее конкурентов, то ты просто не достигаешь целей.
G>>- консистентность вообще можно не учитывать, так как все денные в программе уже устарели
G>>- стоимость разработки программы на фоне размера счета — погрешность округления
·>Ээ, так ещё есть трейдинг по другую сторону баррикады. Например, сама биржа по сути те же заказы (orders) и склад (биржевой стакан). И продать больше — никак нельзя.
В на бирже чуть проще, там же ордеры по одному инструменту по сути уже сериализованы этим самым "стаканом". остается только инженерная задача распределения "стаканов" по сервакам так, чтобы максимизировать надежность и скорость записи (шардирование)

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

·>"меньше"? Ты хотел сказать "больше"?
Да, не исправил при переписывании

G>> В трейинге по сути один сценарий — приход информации от биржи, а в результате надо выдать пачку ордеров

·>Ну вот по обсуждаемой теме есть ещё например portfolio/index трейдинг, где ордера бывают на десяток тысяч позиций. И сложные сценарии price negotiation, споттинг, букинг и т.п.
Что из этого не укладывается в сценарий: получить данные от биржи и выдать ордеры?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.