Спасибо за ответ. Да, для билда знаю, что можно, но не мой кейс. Я уже пытаюсь сейчас просто на базе убунты скопировать все бинари из базового образа aws+.net и базово оно работает, но есть конфликты в установке ffmpeg'а, что-то где-то оверрайдится. Разбираюсь :)
Преоптимизация - зло :) Решайте проблемы по мере их поступления )
А по поводу решений - кэширования, вынесения "очень тяжёлых" операций на другие сервера, работа с пользователем (грамотная отработка Loading'а, визуализация + retry policy), а проще всего просто накиньте мощности в пиковые нагрузки - быстро и эффективно. +расследования на ботлнеки.
@zhainar
>почему одна фича может затрагивать более одного микросервиса
допустим нужно что-то на фроне поменять. оно тянет смену формата данных. данные тянутся через бэк фронта и сервис данных (где, допустим +1 поле запросить нужно например)
Т.е. уже 3 сервиса (фронт, апи1, апи2-dal уровня). Первые два обычно в рамках одной команды (не всегда), а третий уже точно под data тимой скорее всего.
>кто является клиентом этой фичи с точки зрения инфраструктуры?
не очень понял, но видимо фронт. изменения ему нужны, бэки лишь "подстраиваются" и допиливаются
s_lim, как вариант, ты просто можешь задеплоить приложение которое будет просто выводить приходящие вебхуки в консоль. А оттуда уже - просто сохраняешь в json и читаешь в программе, эмулируя по сути его.
Примерный сценарий такой : шлёшь первое сообщение и сохраняешь id кому слать, и что слать и во сколько - в памяти/файл/базу данных. И во втором потоке раз в секунду, допустим, проверяешь - а есть ли чё-нить оправить? (итерируешься по сохраненным данным и сверяешь дату). Через 24 часа при очередном "заходе" - сообщение подхватится по условию и нужно послать второе сообщение, данные для которого у тебя уже сохранены.
Спасибо, почитаю, слышал лишь вскользь о ecs и fargate
Сколько там сегодня - все те же 30 сообщений в секунду?
да, верно. спс за хайлайт
дорого, долго настраивать и почти бесполезно в AWS
слышал, что настраивается вроде как наоборот довольно быстро, а по поводу стоимости тут конечно вопрос, не очень хочется отдельный EC2 держать с практической точки зрения, но чисто для опыта хочется попробовать.
А почему бесполезно? Не очень хочется влезать в cloudWatch, хочется всё же бОльшего контроля и гибкости тут в плане дашбордов/алертов и тд (понимаю, что это будет отражаться на стоимости).
Боюсь банального копирования и развития вне моего участия с целью наживы - и только. В чём проприетарщина, если все коды будут открыты для модификации? Я лишь две цели преследую
1) полезность для людей
2) не остаться в дураках. т.к. я в этот софт вложил уже 2 года периодической разработки. И не позволю кому-то ставить это на коммерчесские рельсы, если до такого дойдёт.
Я специально указал в комментах, что первый более детальный, второй более общий, именно в такой последовательности они и должны идти. Ваше решение это, к сожалению, не решение.
Готового скорее всего нет, всё модульное. Отдельно win сервис, отдельный iis и отдельная логика по возвращению данных на клиент. В качестве последнего можно использовать или ajax-call'ы, или long pooling или SignalR, как вариант
