Size: a a a

Архитектура ИТ-решений

2020 November 02

ОИ

Олег Игонин... in Архитектура ИТ-решений
Gennadiy Kruglov
Как сказал на прошлой неделе один из моих коллег: "я просто архитектор".

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

ОИ

Олег Игонин... in Архитектура ИТ-решений
Gennadiy Kruglov
Как сказал на прошлой неделе один из моих коллег: "я просто архитектор".

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Как сказал архитектор, который укусил меня лет 10 назад: "я как утка, плаваю, летаю, хожу, но всё это делаю херово". Кто-то лучше плавает, кто-то летает, но в целом, наша роль многогранна.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Парни, а чего у нас с шиной к эластику на сегодняшний день?
Kafka перед es с возможностью сделать replay/resend?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
Парни, а чего у нас с шиной к эластику на сегодняшний день?
Kafka перед es с возможностью сделать replay/resend?
что значит, шиной к эластику?)
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
что значит, шиной к эластику?)
Ну ты же не будешь полагаться на http-отлупы уровня "ой, у меня ингест-нода тут немного отвалилась" или "красный статус, кластер в дауне"?
У тебя кто-то в таких случаях должен хранить state

Не очень логично, если это будут staleless микросервисы
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Я знаком с базовым паттерном App -> kafka -> ES
Может, что лучше сейчас есть
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Istomin
Ну ты же не будешь полагаться на http-отлупы уровня "ой, у меня ингест-нода тут немного отвалилась" или "красный статус, кластер в дауне"?
У тебя кто-то в таких случаях должен хранить state

Не очень логично, если это будут staleless микросервисы
"Event sourcing on the database end. That means, a message queue or event streaming system such as Kafka front the ElasticSearch indexing. This approach will buffer the requests in case ElasticSearch is performing cluster updates or leader elections that might potentially result in data loss."
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
Я знаком с базовым паттерном App -> kafka -> ES
Может, что лучше сейчас есть
ES - это эластик?)

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

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
ES - это эластик?)

Микросервисы stateless,  да. Они сами по себе состояния не хранят. Состояние хранит база. Поэтому микросервисы могут скалироваться линейно, падать, подниматься и пр
Да, elastic
Понятно, что мы на микросервисах ничего не храним - поэтому и нужна очередь.
Конечно, было бы логично иметь очередь в самом эластике, и по какому-нибудь MQ-протоколу туда посылать - но пока нужны внешние решения
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
"Event sourcing on the database end. That means, a message queue or event streaming system such as Kafka front the ElasticSearch indexing. This approach will buffer the requests in case ElasticSearch is performing cluster updates or leader elections that might potentially result in data loss."
Слишком сложно. У тебя есть микросервисы, событийно-ориентированная архитектура. Микросервисы обмениваются событиями через Кафку. К Кафке, к этим же топикам, через которые обмениваются сообщениями микросервисы, цепляется Эластик. Всё
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
Да, elastic
Понятно, что мы на микросервисах ничего не храним - поэтому и нужна очередь.
Конечно, было бы логично иметь очередь в самом эластике, и по какому-нибудь MQ-протоколу туда посылать - но пока нужны внешние решения
Женя, остановись))) У микросервисов свои базы, именно базы, их может быть несклько (CQRS). При этом микросервисы могут быть stateless
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если микросервисы stateless, это не значит, что они не могут сбрасывать своё состояние в базу. Кафка для другого - для обмена сообщенями
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
Женя, остановись))) У микросервисов свои базы, именно базы, их может быть несклько (CQRS). При этом микросервисы могут быть stateless
Смотри - базы в микросервисах это ок. в том же 2013 у нас по инстансу neo4j стояло в каждом инстансе, event sourcing в чистом виде, правда, без CQRS  :)

Я выше про то, что bulk http в случае реализации near-primary Elasticsearch Datastorage не подходит, и ему на фронт нужна шина
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Т.е. я про аспект, что ты в таком сценарии больше не можешь позволить bulk http post, т.е. не готов потерять "пару логов" - так как в ES идут бизнес-данные.

С 7.5 в ES хороша занялись resilience  - там и снапшоты нормальные, и restore
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
Смотри - базы в микросервисах это ок. в том же 2013 у нас по инстансу neo4j стояло в каждом инстансе, event sourcing в чистом виде, правда, без CQRS  :)

Я выше про то, что bulk http в случае реализации near-primary Elasticsearch Datastorage не подходит, и ему на фронт нужна шина
Во-первых, где и зачем нужна такая конструкция
Во-вторых, тебе нужна не шина, а гарантированная доставка. Гарантированная доставка реализована обычно в брокерах сообщений. Кафка, строго говоря, брокером сообщений не является, но поскольку в ней реализована гарантированная доставка, то Кафка ок
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
Т.е. я про аспект, что ты в таком сценарии больше не можешь позволить bulk http post, т.е. не готов потерять "пару логов" - так как в ES идут бизнес-данные.

С 7.5 в ES хороша занялись resilience  - там и снапшоты нормальные, и restore
Нахера использовать Elastic для primiry store (write model) для бизнес-данных?
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
Нахера использовать Elastic для primiry store (write model) для бизнес-данных?
О, ты дошел до сути вопроса )
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
Нахера использовать Elastic для primiry store (write model) для бизнес-данных?
Твой выход )
Что раскатаем? Greenplum? Hive?  Если у тебя есть пара миллионов рублей - что раскатаем?
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Понятно, что за 70 млн можно пойти вот сюда
источник