PS
При том, что количество и цели сервисов не известны в любой точке проекта, ибо эджайл, mvp, и тд
Size: a a a
2019 September 20
PD
Petr Shmotov
Ещё раз по шагам. Взаимодействие сервисов - это про архитектуру? Вроде да. Теперь вопрос - когда по вашему стоит проработать взаимодействие - в начале глобально и для всех, или для каждого микросервиса стоит рассматривать индивидуально?
Вначале, глобально, для всех.
Так как потом изменить это решение крайне дорого, а разные решения этой задачи не совместимы друг с другом (и еще с кучей внешних ограничений).
Так как потом изменить это решение крайне дорого, а разные решения этой задачи не совместимы друг с другом (и еще с кучей внешних ограничений).
PD
Но я вот не видел еще проекта, для которого хотя бы примерное количество и цели сервисов не были понятны на ранних точках.
Так как из предметной модели все вполне очевидно вытекает.
Так как из предметной модели все вполне очевидно вытекает.
PD
И чем больше система, тем более очевидны требования к коммуникациям )
PD
А если менять подходы к коммуникациям на каждом спринте - то зачем там архитектор? И что он вообще делает-то?
PS
Вначале, глобально, для всех.
Так как потом изменить это решение крайне дорого, а разные решения этой задачи не совместимы друг с другом (и еще с кучей внешних ограничений).
Так как потом изменить это решение крайне дорого, а разные решения этой задачи не совместимы друг с другом (и еще с кучей внешних ограничений).
Вот в этом мы и расходимся. Потому что у нас в зависимости от того, на что направлен сервис, выбирается способ взаимодействия - тот, который подходит оптимально под решаемую задачу: от graphql и grps, до amqp/msmq и тд
GK
Это не способы взамодействия. Взаимодействия могут синхронные и асинхронные, асинхронные могут быть Publish/Subscribe, Request/Reply, One-way и т.д.
AP
Документация всегда врет, статьи почти всегда (и нет возможности отличить правдивые от лживых), экспертное мнение всегда необъективно.
Так что таки нужно разворачивать, настраивать, проводить нагрузочное тестирование, разбираться в реальных гарантиях и ограничениях, читать код.
Где-то самому архитектору, где-то вместе с программистами или DBA/OPS, но понимать внутренности нужно.
Иначе будут получаться ненадежные, плохосопровождамые и нерасширяемые системы.
Ой, а ведь все крупные системы, где архитекторы код не пишут - именно такие. Что телеком, что крупные банки...
Так что таки нужно разворачивать, настраивать, проводить нагрузочное тестирование, разбираться в реальных гарантиях и ограничениях, читать код.
Где-то самому архитектору, где-то вместе с программистами или DBA/OPS, но понимать внутренности нужно.
Иначе будут получаться ненадежные, плохосопровождамые и нерасширяемые системы.
Ой, а ведь все крупные системы, где архитекторы код не пишут - именно такие. Что телеком, что крупные банки...
Для того, чтобы развернуть и потыкать, не всегда нужно читать код. Но согласен, что это просто альтернативный подход, а суть та же, что и при читании кода
GK
Также нужно определиться с типом организации взамодействия, хореография или оркестровка
GK
иногда в одном и том же решении можут быть как синхронные так и асихронные взамодействия разных типов, и оркестрока и хореография
PD
Petr Shmotov
Вот в этом мы и расходимся. Потому что у нас в зависимости от того, на что направлен сервис, выбирается способ взаимодействия - тот, который подходит оптимально под решаемую задачу: от graphql и grps, до amqp/msmq и тд
И для меня это свидетельство отсутствия архитектуры в проекте вообще.
Так как приводит к необходходимости для каждой пары взаимодействующих микросервисов решать с нуля задачи надежности, гарантий, взаимодействий и т.п. И зачастую выяснять, что организовать взаимодействие конкретной пары вообще нереально (так как один сервис использует нетфликсовскую работу с облаком, а другой рассчитывает на истио и они не совместимы вообще, я уж не говорю про разные реализации grpc в разных языках и фреймворках и мешах)
Так как приводит к необходходимости для каждой пары взаимодействующих микросервисов решать с нуля задачи надежности, гарантий, взаимодействий и т.п. И зачастую выяснять, что организовать взаимодействие конкретной пары вообще нереально (так как один сервис использует нетфликсовскую работу с облаком, а другой рассчитывает на истио и они не совместимы вообще, я уж не говорю про разные реализации grpc в разных языках и фреймворках и мешах)
GK
И для всего этого уже выбираются инструменты
PD
Это не способы взамодействия. Взаимодействия могут синхронные и асинхронные, асинхронные могут быть Publish/Subscribe, Request/Reply, One-way и т.д.
Этого мало, увы. Нужно глубже опускаться, так как гарантии уж очень разные для разных подходов и инструментов.
И нужно уметь совмещать разные подходы минимальным количеством совместимых инструментов, а это ой как не просто.
Ну и помнить о надежности, развертывании и т.п.
И нужно уметь совмещать разные подходы минимальным количеством совместимых инструментов, а это ой как не просто.
Ну и помнить о надежности, развертывании и т.п.
GK
А на самом деле ещё сложнее. Используется EDA или нет. Если используется, то точно будет асинхрон и паб/саб, а значит и брокер. И тогда уже важно какой, точнее понятно, что если не IoT, то Kafka)
PD
Зачастую вообще НФТ диктуют инструменты, а уже под них - подходы к взаимодействию...
PD
А на самом деле ещё сложнее. Используется EDA или нет. Если используется, то точно будет асинхрон и паб/саб, а значит и брокер. И тогда уже важно какой, точнее понятно, что если не IoT, то Kafka)
Ну, а почему кафка, а не RMQ? А если нужно 10M топиков? А что между датацентрами? А есть ли у всех используемых языков нормальные клиенты к кафке? И т.д...
GK
Этого мало, увы. Нужно глубже опускаться, так как гарантии уж очень разные для разных подходов и инструментов.
И нужно уметь совмещать разные подходы минимальным количеством совместимых инструментов, а это ой как не просто.
Ну и помнить о надежности, развертывании и т.п.
И нужно уметь совмещать разные подходы минимальным количеством совместимых инструментов, а это ой как не просто.
Ну и помнить о надежности, развертывании и т.п.
Да, согласен. Дальше нужно опускается ниже. Вопрос, должен ли это делать архитектор и если да, то какой
GK
Зачастую вообще НФТ диктуют инструменты, а уже под них - подходы к взаимодействию...
Точно
GK
Ну, а почему кафка, а не RMQ? А если нужно 10M топиков? А что между датацентрами? А есть ли у всех используемых языков нормальные клиенты к кафке? И т.д...
Да я пошутил)) сорри
PS
И для меня это свидетельство отсутствия архитектуры в проекте вообще.
Так как приводит к необходходимости для каждой пары взаимодействующих микросервисов решать с нуля задачи надежности, гарантий, взаимодействий и т.п. И зачастую выяснять, что организовать взаимодействие конкретной пары вообще нереально (так как один сервис использует нетфликсовскую работу с облаком, а другой рассчитывает на истио и они не совместимы вообще, я уж не говорю про разные реализации grpc в разных языках и фреймворках и мешах)
Так как приводит к необходходимости для каждой пары взаимодействующих микросервисов решать с нуля задачи надежности, гарантий, взаимодействий и т.п. И зачастую выяснять, что организовать взаимодействие конкретной пары вообще нереально (так как один сервис использует нетфликсовскую работу с облаком, а другой рассчитывает на истио и они не совместимы вообще, я уж не говорю про разные реализации grpc в разных языках и фреймворках и мешах)
Палка о двух концах. Там где требуется минимальный латенси приходится идти таким путем. Потому что серебряной пули, чтобы для всех задач сразу и в начале, не существует.