LINUX.ORG.RU

микросервисная архитектура - ура!

 ,


1

3

Читаю статью в Википедии про микросервисную архитектуру. Рад за пацанов: во-первых, теперь на ту же задачу можно потратить x1000 вычислительных мощностей. Даёшь докер-контейнеры на AWS инстансах! Во-вторых, поскольку главного в системе нет, то понять, что происходит и почему ничего не работает, становится крайне нетривиальной задачей. Т.е. огромная наукоёмкость, усложнение самих микросервисов (они ведь должны подробно отчитываться о своём состоянии, иначе невозможно сделать мониторинг и понять, работает ли система или нет). Я уж не говорю о том, что всё это разворачивается в ЦОДах, соответственно, понятно, кому выгодно: Амазону и прочим поставщикам облачных услуг. А наживку бизнесу подкинули в виде «независимости команд, занимающихся разными частями», типа разделяй и властвуй. Прямо настроение улучшилось, какой грубый развод и как хорошо прокатывает. Особенно порадовало «исключение по возможности унаследованного кода».

Но мне нужно найти работу. И я обнаружил, что в моём приложении аж целых две базы данных образовались совершенно естественным путём. Одна - это база безопасности пользователей (хранит, например, пароли). Вторая - это база контента - я хочу иметь на сайте кнопочку «скачать базу». Именно её и буду раздавать.

Соответственно, неужели я имею шанс применить микросервисы, так, чтобы показывать работодателям? Подскажите, правильно ли я понял всю эту тему, и куда копать за примерами? Использую postgresql и голанг.

★★★★★

Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от GT

ли сделать несколько KVM виртуалок,

это вместо докера?

Кстати БД в докере

А на самом деле БД в докере, работают так же, как и все остальные типы программ в докере.

Толковому админу они будут платить меньше, чем йоба-хипстеру-девопсу,

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

ugoday ★★★★★
()
Ответ на: комментарий от Rastafarra

Job queue тоже может работать на большом количестве машин, проблема только в оркестрации воркеров.

WitcherGeralt ★★
()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от ugoday

это вместо докера?

Вместо докера — LXC/LXD. Докер не плох как инструмент, и применим для многих задач. Бомбит у меня не от докера, а от докеромакак-фанатиков, которые его во все щели суют. БД в конейнере — зло, даже в LXC.

А на самом деле БД в докере, работают так же, как и все остальные типы программ в докере.

Ага, особенно когда на одной ноде, например, три докер контейнера: с MySQL, Redis и Mongo. И все они, по факту, работают с одной и той же памятью. Очень умно.

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

Я поработал в кровавом энтырпрайзе девопсом, мне хватило. Мне здравый смысл и порядок на серверах ради собственного спокойствия дороже и важнее, чем +20-30% к ЗП.

GT
()
Ответ на: комментарий от GT

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

anonymous
()
Ответ на: комментарий от Rastafarra

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

Вы теплое с мягким путаете. Микросервисы там не причём. Это больше на MapReduce задачу похоже. Тут YARN+Spark нужны, а не микросервисы в докерах.

Deleted
()
Ответ на: комментарий от Rastafarra

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

anonymous
()
Ответ на: комментарий от anonymous

Пахнут и издают крики в данном случае ...

Завистливые, остановившиеся в развитии неудачники, окружающие успешных девопсов.

ugoday ★★★★★
()
Ответ на: комментарий от Rastafarra

Базы данных имеет смысл изолировать друг от друга, особенно области памяти, поэтому я и написал про KVM вместо докера. И докер, и LXC фактически не изолируют области памяти, поэтому у вас всё обрабатывается в кучу. SQL и noSQL базы в одной памяти — это зло, которое в лучшем случае ведёт к потере производительности, а в худшем — к потере данных. Про шарды с БД в контейнерах так же можно забыть.

GT
()
Ответ на: комментарий от anonymous

БД в конейнере — зло, даже в LXC.

БД в контейнере очень удобно при разработке — не надо геморроиться с установкой, держать зоопарк версий. А вот на проде за такое надо по рукам бить.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от GT

Ну и главный вопрос: а ЗАЧЕМ вам селить базу данных в контейнер? Особенно в докер, к которому без костыля даже по SSH не подцепишься?

GT
()
Ответ на: комментарий от Deleted

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

GT
()
Ответ на: комментарий от GT

Вместо докера — LXC/LXD.

Это другие (и крайне нишевые), хотя и похожие, технологии для решения других задач.

БД в конейнере — зло,

Пруфов не будет.

Ага, особенно когда на одной ноде, например, три докер контейнера: с MySQL, Redis и Mongo.

Ужос-то какой. Используют одну ноду вместо трёх. А бюджет за них Пушкин осваивать будет?

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

А вы мастер проекций. Ещё любите дёргать слова из контекста.

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

anonymous
()
Ответ на: комментарий от GT

Ну и главный вопрос: а ЗАЧЕМ вам селить базу данных в контейнер?

Очевидно за тем же, зачем и всё остальное.

в докер, к которому без костыля даже по SSH не подцепишься?

Если вы заходите в докер по ssh, значит вы используете его очень-очень неправильно.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

На одной ноде — используйте KVM, изолируйте, никто не мешает. А если ноды три, то задача может стоять в репликации всех трёх баз между ними.

GT
()
Ответ на: комментарий от anonymous

те мысли, которые вы проигнорировали

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

GT
()
Ответ на: комментарий от Deleted

Проще было бы поставить через какой-нибудь Guix. Серьёзно, хуже аргумента за докер «докер лучше менеджера пакетов, потому что всё встаёт сразу и как надо» ничего придумать нельзя.

anonymous
()
Ответ на: комментарий от ugoday

Чтобы изолировать работу разных баз с памятью друг от друга. Если вы не знаете и не понимаете, зачем это делать, то вы, видимо, девопс.

GT
()
Ответ на: комментарий от anonymous

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

GT
()
Ответ на: комментарий от GT

Вы используете докер как виртуальную машину. Докер это плохая виртуальная машина. Отсюда боль, страданья, унижение. Не используйте докер как виртуальную машину. Спасибо.

ugoday ★★★★★
()
Ответ на: комментарий от GT

Чтобы изолировать работу разных баз с памятью друг от друга.

Докера достаточно. Квм усложняет развёртывание и оркестрацию и вообще нужен тут как собаке пятая нога.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Проекция и подёргивание контекста — не объяснение. И не добродетель.

anonymous
()
Ответ на: комментарий от ugoday

С чего вы взяли, что я использую докер как виртуальную машину? Если я запустил в докере приложение, которое работает на проде и которое мне крайне нежелательно выключать вместе со всем контейнером, то в чём профит того, что я не имею возможности отладки и диагностики приложения внутри контейнера?

GT
()
Ответ на: комментарий от ugoday

В каком месте его достаточно? Нет, докер не изолирует области памяти, с которыми будут работать базы. Это может сделать только гипервизор. Учите матчасть и как cgroups изолирует ресурсы.

GT
()
Ответ на: комментарий от ugoday

А как они могут работать, ведь там иммутабельная файловая система? Через монтирование сторонних ФС, в которых и находится база?

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Да докеромакаки просто прокидывают файлы базы с ноды, в контейнер. По факту получается «изолированная» СУБД в контейнере, которая работает с базой, лежащей на ноде. Зачем — неизвестно. Наверное, чтобы если что-нибудь подохло в контейнере, единственный способ починить был один, перезапустить контейнер. Упрощают жизнь, не то что мы, старые пердуны.

GT
()
Ответ на: комментарий от anonymous

Проще было бы поставить через какой-нибудь Guix. Серьёзно, хуже аргумента за докер «докер лучше менеджера пакетов, потому что всё встаёт сразу и как надо» ничего придумать нельзя.

Не, анон, ты не прав. Когда у тебя несколько проектов и у всех разные БД/версии, то менеджером пакетов не обойдёшься. Нахрена мне на рабочей тачке MySQL, Postgres, Redis и Mongo сразу, да ещё и кучи разных версий? Я не хочу систему этим засирать. А в докере раз, и поднял контейнер; два, и пофиксил баг в старом релизе; три, и прибил контейнер. И волосы остаются гладкими и шелковистыми.

Deleted
()
Ответ на: комментарий от GT

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

Modus operandi докера исключает подобный образ мысли. Контейнер это не виртуальная машина, куда можной зайти по ssh и запустить/прибить какие-нибудь процессы. Это один процесс + окружение на основе cgroups+namespaces. С которым можно делать всё-то же самое, что и с обычным процессом, но не более.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Не соглашусь. Нормальная контора, работающая на заказах в рамках одной технологии, составляет у себя решебник, из которого и сляпывает новое решение для следующего клиента. А здесь меня как производителя ПО ставят в ситуацию, когда мой решебник устаревает каждый день. Такая вот своеобразная инфляция. Выгодная в первую очередь тем, кто стоит за хайпом. Конечно, она выгодна и индустрии в целом, т.к. повышает стоимость решений для конечных пользователей и приносит много денег. Но это нечестный способ зарабатывать, и с кармической точки зрения в нём ничего хорошего нет.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Через монтирование сторонних ФС, в которых и находится база?

Да. Именно так. Можно ещё docker-volume использовать, но только для совсем некритичных к производительности вещей, там IOPS'ы проседают жутко.

ugoday ★★★★★
()
Ответ на: комментарий от den73

Я в одной такой работал. В результате в одном проекте в качестве SQL базы данных использовался ElasticSearch. Ну, вот такой у нас был решебник. ;-(

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Так если у меня все приложения такие? И если я хочу в контейнере сделать systemctl restart %smth%, а не класть весь контейнер? Если у меня база/сервер/приложение начали медленно отвечать и мне надо нос в лог засунуть? В чём тут профит одного процесса в докере, который можно только положить? Тем более, если это база?

GT
()
Ответ на: комментарий от den73

И такая инфляция не позволяет маленькой ИТ-конторе накопить свой капитал (решебник), это выгодно школьникам, т.к. самое главное в таких условиях - это быстрый мозг. Мастерство уже никому не нужно. Дальше опять пошёл бы нацпол, но я заставлю себя замолчать.

den73 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

А вот на проде за такое надо по рукам бить.

prod/stage/test/dev окружения должны быть максимально унифицированны.

P.S. И даже так всё равно будут случаи, когда у разработчика всё отлично работало, а в продакшене отчего-то поломалося.

P.P.S. Некоторые вместо докера AWS используют, т.к. содержать толпу инстансов для разработчиков всё равно дешевле, чем отвечать баблом за простой или порчу данных заказчика.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

GT
()
Ответ на: комментарий от Deleted

на рабочей

А можно и не на рабочей.

MySQL, Postgres, Redis и Mongo сразу, да ещё и кучи разных версий?

Где-то сверху было описание всего этого, простите, свинарника. Если свинарник — ваш случай, то вы что-то могли сделать не совсем так.

Не совсем, правда, понимаю, чем ваше «я не хочу засирать» коренным образом отличается от Guix. В случае что Guix, что докера вы примерно одинаково засираете систему. Я не вижу особых различий. Разве что Guix не полезет маниакальным образом изолировать всех и вся, наворачивая NAT и закидывая вам тонны правил iptables, запрещая по религии что-то там модифицировать внутри. Может, даже рута не попросит.

anonymous
()
Ответ на: комментарий от GT

И если я хочу в контейнере сделать systemctl restart %smth%

docker run --rm -d facepalm

Если у меня база/сервер/приложение начали медленно отвечать и мне надо нос в лог засунуть?

ELK! Для бедных — man docker-logs

В чём тут профит одного процесса в докере

Потому что эта модель под которую заточен докер и под которую заточены все инструменты в докере. Вы, конечно, можете сопротивляться, но тогда вы будете страдать. Хотя бы от недоумения. Как мартышка и очки.

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

prod/stage/test/dev окружения должны быть максимально унифицированны

Т.е. если у меня на проде HA Postgres кластер, то и для разработки/тестирования я тоже должен такие кластеры использовать? Не жирно ли будет? Достаточно версии БД зафиксировать.

Для дева вполне хватит БД в докере. Там ни бекапы, ни HA не нужны. А вот с продом пусть SREшники разбираются. Я туда даже лезть не хочу.

P.S. И даже так всё равно будут случаи, когда у разработчика всё отлично работало, а в продакшене отчего-то поломалося.

Для этого есть стейджинг (максимально приближенный к проду) с авто тестами.

Deleted
()
Ответ на: комментарий от Deleted

у меня на проде HA Postgres кластер, то и для разработки/тестирования я тоже должен такие кластеры использовать? Не жирно ли будет?

Докер позволяет на одном ноутбуке запустить 3 постгреса в HА, точно как же, как в проде, только с меньшим количеством данных. Ещё и на томкэт с апачем место останется. В результате:

1. Сокращается цикл внесли ошибку -> получили обратную связь -> исправили ошибку, что благодатно сказывается на развитии продукта.

2. Упрощается тестирование.

3. Мы перстаём терять время в бесконечных:

Ops: у нас не работает, девелоперы поправьте.

Dev: а у нас всё работает, деплойте лучше.

Ops: мы деплоим правильно, у вас программа глючная!

Dev: ничего не знаем, can not reproduce!

ugoday ★★★★★
()
Ответ на: комментарий от Deleted

Не жирно ли будет?

В чем жирность? При наличии configuration management и виртуальной среды, читай облака, клепать prod-like кластеры - дело минут.

Гораздо дешевле чем синхронизировать твой докер с опциями прода.

Для внешних сервисов, которые тебе не надо править, тюнить и дебажить самому, иметь готовую поддерживаемую dev-инфраструктуру вполне разумно.

Собственно для тех которые надо дебажить и править - тоже. Выдать полный доступ всем на всё, и настроить полный редеплой каждую ночь по крону.

alpha ★★★★★
()
Ответ на: комментарий от ugoday

Пора уже докер-бинго составлять. Что у нас есть? Уже есть: JS, базы в контейнерах + костыли для данных в контейнере, который, как известно, иммутабелен, фейлсейфен и переносибелен, «на ту же задачу можно потратить x1000 вычислительных мощностей» aka «вы добавьте ещё ядер и гигов и всё заработает», подсаживание на энтерпрайз-иглу в виде чужих облаков, оно же service as a software substitute и иже с ними во все поля,

пиши все на разных языках и фреймворках,

2k19,

масштабирование,
нужно внедрить Kubernetes, чтобы решить проблемы с Docker,

«Микросервисы это новое издание классического пути Юникса» aka тотальное непонимание юниксвей по причине сомнительного бэкграунда, json, rest и http во все поля по причине всё того же сомнительного бэкграунда,

«кластер», «кубернетес», «атомарный» и т.д. А по факту такой человек о cgroups и chroot даже не слышал,
несколько БД, SQL и noSQL aka свинарник интерфейсов (осталось добавить по две mq),
будет ждать, когда всё упадёт, чтобы обвинить в этом админа aka в фейлах наших священных технологий виноваты отсутствующие ядра с терабайтами, кто угодно, но только не мы,

«это как виртуалка, только не виртуалка», «докер лучше менеджера пакетов, потому что всё встаёт сразу и как надо», «В результате в одном проекте в качестве SQL базы данных использовался ElasticSearch» aka мы не знаем sql, зато любим json дл гроба, docker-x, docker-y, docker-z, «Упрощается тестирование» (интересно, за счёт ли парадигмы Чорного Ящика или вопреки?), мы перестаём терять время в пререканиях между админами и разработчиками aka жрём ресурсы и виним во всём админов, либо просто переносим сервера дяде

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

anonymous
()
Ответ на: комментарий от anonymous

Что у нас есть?

Анонимус, который боится технологий в которых он не разбирается.

ugoday ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.