Децентрализованное управление данными - инкапсуляция баз данных в микросервисы [закрыто]

Недавно я проходил курс по разработке программного обеспечения, и недавно было обсуждение / рекомендация об использовании модели «микросервисов», в которой компоненты службы разделены на подкомпоненты микросервиса, которые являются настолько независимыми, насколько это возможно.

Одна часть, которая была упомянута, состояла в том, что вместо того, чтобы следовать очень часто встречающейся модели наличия единой базы данных, с которой общаются все микросервисы, у вас будет отдельная база данных, работающая для каждого из микросервисов.

Более подробное и подробное объяснение этого можно найти здесь: http://martinfowler.com/articles/microservices.html в разделе «Децентрализованное управление данными».

самая существенная часть, говорящая это:

Микросервисы предпочитают позволять каждому сервису управлять своей собственной базой данных, либо разными экземплярами одной и той же технологии баз данных, либо совершенно разными системами баз данных - подход, называемый постоянством Polyglot. Вы можете использовать постоянство полиглота в монолите, но это чаще встречается в микросервисах.

Рисунок 4

Мне нравится эта концепция и, среди прочего, я вижу в этом сильное улучшение обслуживания и проектов, над которыми работают несколько человек. Тем не менее, я ни в коем случае не опытный архитектор программного обеспечения. Кто-нибудь когда-нибудь пытался это реализовать? С какими преимуществами и препятствиями вы столкнулись?

Давайте поговорим о положительных и отрицательных сторонах микросервисного подхода.

Первые негативы. Когда вы создаете микросервисы, вы добавляете сложность в свой код. Вы добавляете накладные расходы. Вы затрудняете копирование среды (например, для разработчиков). Вы делаете отладку прерывистых проблем сложнее.

Позвольте мне проиллюстрировать реальный недостаток. Рассмотрим гипотетически случай, когда у вас есть 100 микросервисов, вызываемых при создании страницы, каждая из которых работает правильно в 99,9% случаев. Но в 0,05% случаев они дают неправильные результаты. И в 0,05% случаев возникает медленный запрос на соединение, где, скажем, для соединения требуется тайм-аут TCP / IP, и это занимает 5 секунд. Около 90,5% времени ваш запрос работает отлично. Но примерно в 5% случаев вы получаете неправильные результаты, и примерно в 5% случаев ваша страница работает медленно. И каждый невоспроизводимый сбой имеет свою причину.

Если вы не будете много думать об инструментах для мониторинга, воспроизведения и так далее, это превратится в беспорядок. Особенно, когда один микросервис вызывает другой, который вызывает другого на несколько уровней. И как только у вас возникнут проблемы, со временем будет только хуже.

Хорошо, это звучит как кошмар (и больше чем одна компания создала огромные проблемы для себя, идя этим путем). Успех возможен только тогда, когда вы четко осознаете потенциальные недостатки и последовательно работаете над его устранением.

Так что насчет этого монолитного подхода?

Оказывается, что монолитное приложение так же легко модульно, как и микросервисы. И вызов функции на практике дешевле и надежнее, чем вызов RPC. Таким образом, вы можете разработать то же самое, за исключением того, что оно более надежно, работает быстрее и требует меньше кода.

Хорошо, тогда почему компании переходят на микросервисный подход?

Ответ заключается в том, что при масштабировании существует предел того, что вы можете сделать с монолитным приложением. После стольких пользователей, большого количества запросов и т. Д. Вы достигаете точки, когда базы данных не масштабируются, веб-серверы не могут хранить ваш код в памяти и т. Д. Более того, микросервисные подходы позволяют осуществлять независимое и постепенное обновление вашего приложения. Поэтому микросервисная архитектура - это решение для масштабирования вашего приложения.

Мое личное правило заключается в том, что переход от кода на языке сценариев (например, Python) к оптимизированному C ++, как правило, может повысить на 1-2 порядка как производительность, так и использование памяти. Переход к распределенной архитектуре в другом направлении увеличивает требования к ресурсам, но позволяет масштабировать до бесконечности. Вы можете заставить распределенную архитектуру работать, но сделать это сложнее.

Поэтому я бы сказал, что если вы начинаете личный проект, идите монолитно. Узнайте, как это сделать хорошо. Не распространяйте, потому что (Google | eBay | Amazon | и т. Д.). Если вы попали в крупную распределенную компанию, обратите пристальное внимание на то, как они заставляют ее работать, и не облажайтесь. И если у вас возникнет необходимость сделать переход, будьте очень, очень осторожны, потому что вы делаете что-то сложное, что легко очень и очень неправильно сделать.

Раскрытие, у меня есть почти 20-летний опыт работы в компаниях всех размеров. И да, я видел как монолитную, так и распределенную архитектуры близко и лично. Основываясь на этом опыте, я говорю вам, что распределенная микросервисная архитектура - это действительно то, что вы делаете, потому что вам нужно, а не потому, что это как-то чище и лучше.

Я искренне согласен с ответом btilly, но просто хотел добавить еще один позитив для Microservices, который, как мне кажется, является оригинальным источником вдохновения.

В мире микросервисов службы ориентированы на домены и управляются отдельными группами (одна группа может управлять несколькими службами). Это означает, что каждая группа может предоставлять услуги полностью отдельно и независимо от любых других служб (при условии правильного управления версиями и т. Д.).

Хотя это может показаться тривиальным преимуществом, подумайте об обратном в монолитном мире. Здесь, где одна часть приложения нуждается в частом обновлении, это повлияет на весь проект и любые другие команды, работающие над ним. Затем вам нужно будет ввести планирование, обзоры и т. Д., И весь процесс замедлится.

Что касается вашего выбора, а также с учетом ваших требований к масштабированию, также учитывайте любые требуемые структуры команды. Я бы согласился с рекомендацией btilly, чтобы вы начали Monolithic, а затем определили, где могут быть полезны микросервисы, но помните, что масштабируемость - не единственное преимущество.

Я работал в месте, где было достаточно независимых источников данных. Они поместили их все в одну базу данных, но в разные схемы, к которым обращались веб-сервисы. Идея заключалась в том, что каждая служба могла получить доступ только к минимальному количеству данных, необходимых для выполнения их работы.

Это было не очень сложно по сравнению с монолитной базой данных, но я думаю, что это было в основном из-за характера данных, которые уже были в изолированных группах.

Веб-сервисы были вызваны из кода веб-сервера, который генерировал страницу, так что это очень похоже на архитектуру ваших микросервисов, хотя, возможно, не так микро, как предполагает само слово, и не распространялось, хотя они могли бы быть (обратите внимание, что один WS действительно вызывал чтобы получить данные от сторонней службы, так что там был 1 экземпляр распределенной службы данных). Компания, которая сделала это, была больше заинтересована в безопасности, чем в масштабах, однако, эти сервисы и сервисы передачи данных обеспечили более безопасную поверхность атаки, так как уязвимость в одном не давала бы полного доступа ко всей системе.

Роджер Сессионс в своих превосходных информационных бюллетенях Objectwatch описал нечто похожее с его концепцией Software Fortresses (к сожалению, информационные бюллетени больше не онлайн, но вы можете купить его книгу).