Если кратко, то инструментальные измерения деградации показывали длительное время на операциях чтения/записи при получении/отправке пакетов из/в сеть на больших RPS (расчеты приводил выше).
Обязанности аналитика могут различаться в разных компаниях, мне более близок подход в текущей финансовой организации: Бизнес-аналитик и Системный аналитик.
Первая категория хорошо разбирается в предметной области, бизнес-потребностях и т.д. Вторая является "связующим звеном" между бизнесом и разработкой, те что то между техническим писателем и архитектором (кому насколько хватает компетенций).
По своему мнению (разработчика), люди без технического опыта могут, конечно, описать, как должна работать система (технически), протоколы взаимодействия, структуру БД, интеграции, и т.д. (как это описывают грамотные архитекторы), но они не знают/не видят рисков и возможных сложных ошибок в решениях (те их знания - скорее теоретические, не подкрепленные практическим опытом). Хорошие архитектурные решения с их стороны требуют, как минимум, плотных консультаций с разработкой.
Нужна экспертиза по Си и грамотный разработчик в команде, не всегда (редко когда) есть желание нанимать новых людей и плодить зоопарк. К тому же на GO побольше кадровый выбор.
Могу добавить что информация актуальна на конец 2022, может быть в .Net 8 - более стабильной мажорной версии - это поведение поменялось в лучшую сторону.
PS помню еще .net 5, где попытки обратиться к GRPC-стриму, который был переведен в Dispose состояние (программистские ошибки, да), но все же такой баг в коде приводил к дедлокам на уровне платформы и stopper-у всего приложения.
Так что в те времена складывалось впечатление о "сырости" .net-ного GRPC.
Все же хочется снизить риск человеческих ошибок при разборе голых байт, и в принципе использовать более удобные инструменты если нет противопоказаний к обратному.
Тут скорее вопрос к реализации сетевого стека в части GRPC на .net под Linux, если при прочих равных такое же решение на GO прекрасно едет.
Так как в реальном проекте главное - это именно решить проблему, с гарантией, что лучше чем пытаться тюнить текущий стек «на костылях». Хотя именно в .Net такую критику - что "вы не умеете его готовить" - по данной проблеме, встречаю постоянно)
Не совсем так. Голый TCP - это стандарт Asterisk а, и мы должны были его придерживаться только в первой точке в цепочке по работе с голосом, которая взаимодействует именно с Астером. Далее - по GRPC цепочке - пакеты можно было укрупнять и обогащать, увеличивая задержки + появляются сквозные идентификаторы, признаки попутного анализа пакетов голоса (например, есть ли в них речь или пакет пустой), те в структуре GRPC пакетов уже не только голые аудио-байты. К тому же же yandex-speech-recognition или text-to-speech работают по протоколу GRPC.
Понятно зачем это делается. Учитывая что проблема с военным столом за последний год работы в компании не была решена никак. А тут еще и закон об электронных повестках вышел.
Увы, легаси, этот проекта на 6.0 живет (вместе со всей конторой).
Если кратко, то инструментальные измерения деградации показывали длительное время на операциях чтения/записи при получении/отправке пакетов из/в сеть на больших RPS (расчеты приводил выше).
Обязанности аналитика могут различаться в разных компаниях, мне более близок подход в текущей финансовой организации: Бизнес-аналитик и Системный аналитик.
Первая категория хорошо разбирается в предметной области, бизнес-потребностях и т.д. Вторая является "связующим звеном" между бизнесом и разработкой, те что то между техническим писателем и архитектором (кому насколько хватает компетенций).
По своему мнению (разработчика), люди без технического опыта могут, конечно, описать, как должна работать система (технически), протоколы взаимодействия, структуру БД, интеграции, и т.д. (как это описывают грамотные архитекторы), но они не знают/не видят рисков и возможных сложных ошибок в решениях (те их знания - скорее теоретические, не подкрепленные практическим опытом). Хорошие архитектурные решения с их стороны требуют, как минимум, плотных консультаций с разработкой.
Нужна экспертиза по Си и грамотный разработчик в команде, не всегда (редко когда) есть желание нанимать новых людей и плодить зоопарк. К тому же на GO побольше кадровый выбор.
Могу добавить что информация актуальна на конец 2022, может быть в .Net 8 - более стабильной мажорной версии - это поведение поменялось в лучшую сторону.
PS помню еще .net 5, где попытки обратиться к GRPC-стриму, который был переведен в Dispose состояние (программистские ошибки, да), но все же такой баг в коде приводил к дедлокам на уровне платформы и stopper-у всего приложения.
Так что в те времена складывалось впечатление о "сырости" .net-ного GRPC.
Все же хочется снизить риск человеческих ошибок при разборе голых байт, и в принципе использовать более удобные инструменты если нет противопоказаний к обратному.
Тут скорее вопрос к реализации сетевого стека в части GRPC на .net под Linux, если при прочих равных такое же решение на GO прекрасно едет.
Так как в реальном проекте главное - это именно решить проблему, с гарантией, что лучше чем пытаться тюнить текущий стек «на костылях». Хотя именно в .Net такую критику - что "вы не умеете его готовить" - по данной проблеме, встречаю постоянно)
Не совсем так. Голый TCP - это стандарт Asterisk а, и мы должны были его придерживаться только в первой точке в цепочке по работе с голосом, которая взаимодействует именно с Астером. Далее - по GRPC цепочке - пакеты можно было укрупнять и обогащать, увеличивая задержки + появляются сквозные идентификаторы, признаки попутного анализа пакетов голоса (например, есть ли в них речь или пакет пустой), те в структуре GRPC пакетов уже не только голые аудио-байты. К тому же же yandex-speech-recognition или text-to-speech работают по протоколу GRPC.
Понятно зачем это делается. Учитывая что проблема с военным столом за последний год работы в компании не была решена никак. А тут еще и закон об электронных повестках вышел.