С точки зрения компании нормальная ситуация — компания резко изменила свою культуру, попросила несогласных с новой культурой пойти своей дорогой, потом наберет новых из тех, кто подходит под новое виденье.
Приятного мало, но тут еще довольно мягко прошло, могли бы просто на мороз выкинуть.
По поводу видов вызовов: описанный подход сам по себе агностичен к виду коммуникации, но по моему мнению такие процессы лучше ложатся на асинхронную модель.
Обработка ошибок — это больное место в длинных конвейерных процессах) В простом случае в случае технической/инфраструктурной ошибки делаются ретраи, и при логической ошибке цепочка откатывается по шагам обратно с выполнением компенсирующих действий. Но на деле все не так просто...
Вы пробудили во мне интерес, поиграюсь на досуге, спасибо. Интересно, что там с отказоустойчивостью — когда инстанс БД приляжет, или там приложение, через которое бежит транзакция, перестанет отвечать, и входящие в транзакцию сообщения подхватит другая реплика.
после 2000-го в нашу индустрию пришли какие-то хипстеры… и начали по-новой придумывать то, что уже давно придумано и хорошо работает
Вы заблуждаетесь, если считаете, что было придумано что-то новое. Документоориентированные БД и брокеры сообщений существовали еще до X/Open XA. Разница в том, что изолированная транзакция (вроде сериализации через MVCC) — штука довольно дорогая сама по себе, а распределенная транзакция так и вовсе. Многим процессам важны скорость в ущерб атомарности или консистентности. Брокеры же сообщений вообще не про транзакции (хотя Kafka, являющаяся по сути БД, умеет в транзакции при записи).
Новые инструменты сделаны не потому, что "хипстеры хотели придумать что-то новое" — PostgreSQL до сих пор остается одной из самых популярных БД, хотя сложно представить что-то менее хипстерское. "Новые" инструменты решают в основном проблемы масштаба или скорости — когда либо данные перестает быть возможно держать на обычных БД вроде постгреса, либо скорость чтения/записи превышает возможности "старых" решений.
В случае с документоориентированными БД, за высокую скорость записи приходится дорого платить — контроль за консистентностью данных переходит с БД на приложение и плечи разработчика.
Аналогично с распределенными гетерогенными приложениями — за возможность делать масштабируемые сервисы, и разрабатывать language-agnostic и db-agnostic компоненты приходится платить тем, что контроль ACID переезжает из БД в приложение и также ложится на плечи разработчика/артихектора.
Одно можно сказать точно — покуда можно избежать "распределенных" сущностей, их нужно избегать.
Хотел уточнить в статье, но забыл — речь идет не про распределенные транзакции в рамках БД, а именно про распределенный процесс, который стремится к ACID.
Про стандарт выше тоже знаю, но на практике покрыть распределенный процесс одной "распределенной транзакцией БД" не выйдет — просто пропускная способность системы снизится почти до нуля, т.к. время одной такой транзакции будет до десятков минут, а по пути будет куча блокировок.
Кроме того, XA не решит проблемы конвейерных процессов: когда вам нужно для создания сущности пройтись по шагам, на каждом из который делается дюжина вызовов к какому-нибудь вендорскому решению (привет, vmware), но при этом уметь обработать ошибки, не переделывая всю цепочку целиком, а еще уметь переживать падение приложения без прерывания транзакции.
Собственно, такую задачу я изначально и решал, а в итоге вылилось в то, что это решает и проблему распределенных бизнес-транзакций.
Очень интересная тема с авторизациями консумеров и продьюсеров. Я правильно понимаю схему, что сначала нужно сходить в KSM и спосить "могу ли я (серт/кред) писать/читать такой-то топик), и уже потом писать в кафку? Или это непосредственно кафка делает?
Вопрос под таким углом: могу ли я явно запретить кому-то писать в кафку, если он знает адреса брокеров через KSM? Или если я хочу именно явного запрета (то есть чтобы несанкционированный трафик вообще не мог в топик попасть), то придется проксировать?
Хотим реализовать что-то подобное, но при этом давать сервисам, которым не очень доверяем, возможность писать в кафку, если у них есть валидная авторизация, но при этом чтобы возможности вообще не было, если авторизация невалидна (роли там нет etc.).
Ну это общие требования по записью в кластер с консенсусом по записи. То есть у вас должно не меньше половины+1 брокеров подтвердить доставку, тогда вы будете уверены, что при отвале части брокеров (1 при кластере из 3, 2 при кластере из 5 и т.п.) у вас сообщения не пропадуют.
При этом если требовать подтверждения ото всех брокеров, то увеличится время отправки, но зато меньше возни, если лидер отвалится. Мы тоже не паримся и пишем во все.
Скорее всего как-то так: большая контора типа убера или гугла начинает использовать го и бросает на него какие-то существующие отделы (не набирать же с улицы, если ты убер или гугл). Эти отделы писали до этого на чем-то вроде джавы или пхп, и у них сгорает стул оттого, что в Go нельзя делать также. Они пилят свои велосипеды, это становится корпоративным стандартом, а потом попадает в опенсорс. Ну а убер или гугл в опенсорс финги не выложат — думают другие новички в Go, и пошло-поехало.
По субъективному опыту, проблему с DI-контейнерами в Go испытывают те, кто активно пользовался этим в языках вроде Java, где это действительно нужно.
На деле в микросервисе обычно нет больше десятка внешних и внутренних зависимостей, которые нужно прокидывать через DI в различные части приложения, и это все отлично пишется в main по-очереди. Если у разработчика возникает проблема из-за того, что зависимостей много и их становится неудобно собирать и пробрасывать, то это звоночек о разрастании сервиса и о том, что он вобрал в себя слишком много ответственностей.
Другое дело, если речь идет о DI в монолите, но опять же, по опыту, компании, применяющие Go для написания монолитов ни о каком DI не задумываются...
Такая проблема есть и при использовании мыши, в графических редакторах часто решается нажатием клавиши-модификатора, которая увеличивает "масштаб движения" мыши (курсор проходит меньше за то же движение рукой" или делает это параллельно с увеличением картинки (что видно отдельные пиксели как крупные квадратики). Что-то похожее можно и для управления руками использовать, когда нужно пиксели двигать.
С точки зрения компании нормальная ситуация — компания резко изменила свою культуру, попросила несогласных с новой культурой пойти своей дорогой, потом наберет новых из тех, кто подходит под новое виденье.
Приятного мало, но тут еще довольно мягко прошло, могли бы просто на мороз выкинуть.
Телекомы уже давно делают все, что не относится непосредственно к телекому, потому что рынок телекома в мире уже закончился лет пять как.
Выше писали, что английский то cock — тоже петух.
При этом cocktail или cockroach(DB) людей не смущает.
P.S.: А вот по-русски — повар на корабле.
Все было хорошо, пока не увидел последнюю картинку. Это какой-то фарс
Увидел картинку — подумал, неужели Лилль? Ага, оказалось так и есть. Видел его только сбоку
Очень интересно, спасибо.
По поводу видов вызовов: описанный подход сам по себе агностичен к виду коммуникации, но по моему мнению такие процессы лучше ложатся на асинхронную модель.
Обработка ошибок — это больное место в длинных конвейерных процессах) В простом случае в случае технической/инфраструктурной ошибки делаются ретраи, и при логической ошибке цепочка откатывается по шагам обратно с выполнением компенсирующих действий. Но на деле все не так просто...
Хмм, попробую такое сформулировать и добавить. Конец действительно немного повис в воздухе, спасибо за идею.
Спасибо за ссылки!
В каком виде ожидали обобщение?
Вы пробудили во мне интерес, поиграюсь на досуге, спасибо. Интересно, что там с отказоустойчивостью — когда инстанс БД приляжет, или там приложение, через которое бежит транзакция, перестанет отвечать, и входящие в транзакцию сообщения подхватит другая реплика.
По поводу тезиса
Вы заблуждаетесь, если считаете, что было придумано что-то новое. Документоориентированные БД и брокеры сообщений существовали еще до X/Open XA. Разница в том, что изолированная транзакция (вроде сериализации через MVCC) — штука довольно дорогая сама по себе, а распределенная транзакция так и вовсе. Многим процессам важны скорость в ущерб атомарности или консистентности. Брокеры же сообщений вообще не про транзакции (хотя Kafka, являющаяся по сути БД, умеет в транзакции при записи).
Новые инструменты сделаны не потому, что "хипстеры хотели придумать что-то новое" — PostgreSQL до сих пор остается одной из самых популярных БД, хотя сложно представить что-то менее хипстерское. "Новые" инструменты решают в основном проблемы масштаба или скорости — когда либо данные перестает быть возможно держать на обычных БД вроде постгреса, либо скорость чтения/записи превышает возможности "старых" решений.
В случае с документоориентированными БД, за высокую скорость записи приходится дорого платить — контроль за консистентностью данных переходит с БД на приложение и плечи разработчика.
Аналогично с распределенными гетерогенными приложениями — за возможность делать масштабируемые сервисы, и разрабатывать language-agnostic и db-agnostic компоненты приходится платить тем, что контроль ACID переезжает из БД в приложение и также ложится на плечи разработчика/артихектора.
Одно можно сказать точно — покуда можно избежать "распределенных" сущностей, их нужно избегать.
Хотел уточнить в статье, но забыл — речь идет не про распределенные транзакции в рамках БД, а именно про распределенный процесс, который стремится к ACID.
Про стандарт выше тоже знаю, но на практике покрыть распределенный процесс одной "распределенной транзакцией БД" не выйдет — просто пропускная способность системы снизится почти до нуля, т.к. время одной такой транзакции будет до десятков минут, а по пути будет куча блокировок.
Кроме того, XA не решит проблемы конвейерных процессов: когда вам нужно для создания сущности пройтись по шагам, на каждом из который делается дюжина вызовов к какому-нибудь вендорскому решению (привет, vmware), но при этом уметь обработать ошибки, не переделывая всю цепочку целиком, а еще уметь переживать падение приложения без прерывания транзакции.
Собственно, такую задачу я изначально и решал, а в итоге вылилось в то, что это решает и проблему распределенных бизнес-транзакций.
Читал, что безопаснее всего в хвосте, т.к. он обычно отваливается. Не проверял.
Супер, спасибо за статью!
Очень интересная тема с авторизациями консумеров и продьюсеров. Я правильно понимаю схему, что сначала нужно сходить в KSM и спосить "могу ли я (серт/кред) писать/читать такой-то топик), и уже потом писать в кафку? Или это непосредственно кафка делает?
Вопрос под таким углом: могу ли я явно запретить кому-то писать в кафку, если он знает адреса брокеров через KSM? Или если я хочу именно явного запрета (то есть чтобы несанкционированный трафик вообще не мог в топик попасть), то придется проксировать?
Хотим реализовать что-то подобное, но при этом давать сервисам, которым не очень доверяем, возможность писать в кафку, если у них есть валидная авторизация, но при этом чтобы возможности вообще не было, если авторизация невалидна (роли там нет etc.).
Ну это общие требования по записью в кластер с консенсусом по записи. То есть у вас должно не меньше половины+1 брокеров подтвердить доставку, тогда вы будете уверены, что при отвале части брокеров (1 при кластере из 3, 2 при кластере из 5 и т.п.) у вас сообщения не пропадуют.
При этом если требовать подтверждения ото всех брокеров, то увеличится время отправки, но зато меньше возни, если лидер отвалится. Мы тоже не паримся и пишем во все.
Постоянно реклама на баше предлагает что-то из того, что неделю назад гуглил.
Скорее всего как-то так: большая контора типа убера или гугла начинает использовать го и бросает на него какие-то существующие отделы (не набирать же с улицы, если ты убер или гугл). Эти отделы писали до этого на чем-то вроде джавы или пхп, и у них сгорает стул оттого, что в Go нельзя делать также. Они пилят свои велосипеды, это становится корпоративным стандартом, а потом попадает в опенсорс. Ну а убер или гугл в опенсорс финги не выложат — думают другие новички в Go, и пошло-поехало.
По субъективному опыту, проблему с DI-контейнерами в Go испытывают те, кто активно пользовался этим в языках вроде Java, где это действительно нужно.
На деле в микросервисе обычно нет больше десятка внешних и внутренних зависимостей, которые нужно прокидывать через DI в различные части приложения, и это все отлично пишется в main по-очереди. Если у разработчика возникает проблема из-за того, что зависимостей много и их становится неудобно собирать и пробрасывать, то это звоночек о разрастании сервиса и о том, что он вобрал в себя слишком много ответственностей.
Другое дело, если речь идет о DI в монолите, но опять же, по опыту, компании, применяющие Go для написания монолитов ни о каком DI не задумываются...
Такая проблема есть и при использовании мыши, в графических редакторах часто решается нажатием клавиши-модификатора, которая увеличивает "масштаб движения" мыши (курсор проходит меньше за то же движение рукой" или делает это параллельно с увеличением картинки (что видно отдельные пиксели как крупные квадратики). Что-то похожее можно и для управления руками использовать, когда нужно пиксели двигать.
Ого. Неделю назад только прочитал его книжку про автоматное программирование.