Целостность данных в микросервисной архитектуре - как ее обеспечить без распределенных транзакций и жесткой связности Базы данных и системы хранения
Chief Data Architect в ManyChat, отвечает за все pipeline и платформу данных для аналитики (хранилище, BI, ETL, интеграционные сервисы), все в AWS.
До этого — руководитель Data Platform в Avito. В область ответственности Data Platform входили системы больших данных (сотни Тб), OLTP-базы (PostgreSQL), NoSQL-базы (MongoDB, Redis, Tarantool, VoltDB), а также системы очередей и потоковой обработки данных (RabbitMQ, NSQ, Spark). Все про данные, их движение и обработку.
Помимо работы в ManyChat, Николай преподает в НИУ ВШЭ и занимается научными исследованиями в области современных методологий построения хранилищ данных, таких как Data Vault и Anchor Modeling, а также в области технологий BlockChain.
Тезисы
На дворе 2018 - все любят микросервисы и пилить монолиты.
При этом у монолита с единой базой есть плюс - целостность и согласованность данных о, например, списании денег за услугу и применении услуги можно гарантировать обычной транзакцией на уровне СУБД (PostgreSQL, Oracle и т.п.).
А что будем делать, если деньги в одном сервисе, а услуги - в другом, и у каждого сервиса своя изолированная база? И подобных бизнес-кейсов все больше и больше. Сколько-нибудь опытный человек сразу отбросит попытку сделать распределенные транзакции. Что же делать?
Разумеется, у идеологов микросервисной архитектуры (Крис Ричардсон и т.п.) есть ответ. И не один. Давайте я расскажу об этих ответах, их плюсах, минусах и рисках, насколько мы в Авито смогли разобраться.
