Как правильно хранить файлы в микросервисной архитектуре?

Question

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

Answer 1

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

• Нужны ли все данные в любое время?
• Существуют ли случаи, связанные с гео / регионами?
• Как быстро должна выполняться операция чтения / записи?
• Нужно ли что-то кэшировать?
• Statefull или Stateless?
• Существуют ли эксплуатационные требования?Как это следует поддерживать?
• ...

Часть этого вашего микросервиса не должна знать, где на самом деле хранятся данные.В kubernetes вы можете использовать Persistent-Volumes https://kubernetes.io/docs/concepts/storage/persistent-volumes/, которые могут ссылаться на хранилище вашего Cloud-Provider или что-то еще.Микросервис должен просто смонтировать том и иметь возможность обрабатывать его как локальный файл.

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

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

См. Дополнительную информацию:

• http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/
• https://github.com/katopz/best-practices/blob/master/best-practices-for-building-a-microservice-architecture.md#stateless-service-instances
• https://12factor.net/backing-services
• https://blog.twitter.com/engineering/en_us/topics/infrastructure/2017/the-infrastructure-behind-twitter-scale.html

Answer 2

Мы в основном на прем.В итоге мы используем NFS.Путь к наименьшему сопротивлению, но, вероятно, не самый эффективный, и сделать его высокодоступным очень сложно.Если у вас есть шанс, я согласен с Денисом Пшеновым, что S3-подобная система, например, minio, может быть лучшей альтернативой.

Answer 3

Возможно, вам стоит взглянуть на проект rook (https://rook.io/).. Его легко настроить, и он предоставляет различные виды технологий хранения и сохранения для ваших CNA.

Answer 4

У вас есть куча разных вариантов, погуглив свой вопрос, вы найдете много ответов на любой бюджет и вкус.По сути, вам нужно хранилище высокой доступности, например AWS S3.Вы также можете настроить свой собственный выделенный сервер для хранения этих файлов, если хотите сократить расходы, но тогда вам придется беспокоиться о резервном копировании и доступности.Если вам нужен доступ с низкой задержкой к этим файлам, то вы также захотите, чтобы они находились за CDN.