LINUX.ORG.RU

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

 ,


1

3

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

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

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

★★★★★

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

Почему?

Транзакция либо прошла, либо ролбек. Т.е., снимаю $100 в банкомате, канал рухнул и что? Да ни чего. Здесь точно так же.

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

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

В общем, проблемы реально надуманные с применением микросервисов.

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

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

кстати, да, приставка «микро», по отношение к сервису, как правило, означает «stateless», т.е. Протокол_без_сохранения_состояния

любые другие интерпретации избыточны )

anonymous
()

SOA

кстати, складывается ощущение, что, споря о «микросервисах», участники дискуссии не понимают термин «сервисы», и начинают требовать обосновать необходимость декомпозиции, поэтому, советую сначала почитать: Сервис-ориентированная_архитектура

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

Тем что появляется нужда в репликации.

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

Зачем при создании пользователя надо что-либо обновлять в базе «контент», если этот пользователь ещё никакого контента не создал?

Например, профиль пользователя может содержать публичную инфу (мой веб-сайт, мои домашние животные и т.п). Логично разместить её в базе «контент». И естественно, что первым делом после регистрации чел полезет в профиль поставить аватарку. А - обана - сервис репликации на заморском докере был вытеснен из кеша из-за неактивности и теперь ждём 2 минуты, пока он поднимется.

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

кстати, да, приставка «микро», по отношение к сервису, как правило, означает «stateless», т.е.

Можно пруфлинк? Я читаю вот это: https://habr.com/ru/post/249183/

И там нет ничего про стейтлесс.

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

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

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

Микросервисы - это не способ доставки, или упаковки, это вариант дизайна софта из которого следует некие бонусы.

И микросервисная культура подразумевает что ты дизайнишь в соответствии с её принципами. А не пытаешься впихнуть уже задизайненное в неподходящий для этого формат.

Логично разместить её в базе «контент».

Вообще не логично. И даже неверно с точки зрения GDPR, персональных данных и т.п., как мне кажется.

И в принципе критерием выделения данных в отдельную базу должно быть не то, как эти данные надо защищать, а то как с этими данными надо работать. Какие функции на эти данные завязаны.

Если правка пользователя у тебя подразумевает правку контента, значит разделение на две базы неправильно. В таком случае надо хранить всё связанным в одной базе, а выдачу дампа делать за счет фильтров при экспорте или заполнения «секретных полей» рандомными значениями.

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

Хорошо, не будем в это углубляться. Даже если не в профиль, то он захочет увидеть сайт работающим. А на заголовке сайта (рассмотрим для примера форумный движок) есть, допустим, виджет «мои последние сообщения». Который берёт инфу из контента.

Ещё раз, изначально две базы появились для того, чтобы можно было выкладывать простые бекапы базы в общий доступ. Чтобы быть предметнее, вот заготовка ТЗ.

https://bitbucket.org/budden/ppr/src/380b861c15cca4bde1e39b0bf7a20dde506eb6b3...

Это движок англо-русского словаря для коллективной разработки.

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

целый тред, и ничего не понятно...

1. где происходит аутентификация?
2. где хранится информация по авторизации к ресурсам
3. где происходит авторизации при обращении к ресурсам
4. как сервер контента идентифицирует пользователя и ресурсы?
5. обязаны ли все участвующие серверы хранить контекст сессии для каждого пользователя, зачем?
6. что происходит при обрыве сессии пользователем или создании новой?
7. что подразумевается под понятием «сессия»?

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

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

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

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

виджет «мои последние сообщения». Который берёт инфу из контента.

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

Когда ты отправишь юзеру сообщение, у него появится запись в этой базе. И тогда виджет начнет показывать, что сообщение есть.

Опять же в момент создания пользователя, _для_ создания пользователя, лезть в «контент» не нужно.

Создал юзера в базе юзеров и ушел - вот это будет микросервис.

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

Спасибо за вопросы!

1. где происходит аутентификация?

Сейчас всё в одном процессе. Но в идеале можно было бы вынести во что-то отдельное. Буду использовать таблицу сессий и выдавать ключ сессии. Кстати, получается фигня с сессиями, т.к. они нужны и там, и там. Вероятно, в контент можно реплицировать код сессии, без ключа, тогда это несекретная инфа.

2. где хранится информация по авторизации к ресурсам

Можно хранить в контенте.

3. где происходит авторизации при обращении к ресурсам

В контенте, я так думаю. Сочиняя на ходу, на базе кода сессии. Проверка ключа происходит в воображаемом сервисе аутентификации, и дальше он вырезается из запроса.

4. как сервер контента идентифицирует пользователя и ресурсы?

Ресурсы - неважно, пользователя - по коду.

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

Думаю, нет.

6. что происходит при обрыве сессии пользователем или создании новой?

Что такое обрыв сессии? При штатном выходе сессия удаляется, в противном случае - живёт до таймаута.

7. что подразумевается под понятием «сессия»?

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

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

У тебя есть бизнес требование - обеспечить привязку контента к пользователю. У тебя нет _бизнес_-требования создавать в базе «контент» что-либо при создании пользователя.

Ты идешь от данных, а не от действий, от того у тебя возникает это непонимание. Микросервисы - это действия.

У тебя есть функции:

- создать пользователя

- показать контент по параметрам(в том числе пользователю)

- создать контент с привязкой к автору

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

Чтобы создать контент с привязкой к пользователю в момент создания контента твой микросервис по созданию контента получает запрос в котором есть собственно контент и есть id-пользователя, и этот микросервис за один раз создает этот элемент в одной конкретной базе «контент».

Чтобы получить данные по контенту пользователя ты опять-таки получаешь запрос с id пользователя в базе «контент».

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

Как он туда попадает? Это cookies или кто там ещё, за которые отвечает совсем другой отдельно стоящий микросервис авторизации.

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

Для того чтобы отобразить что у юзера нет сообщений в базе «контент» не надо этого юзера там создавать.

Ага, я этого ждал. Но это означает появление лишних веток в алгоритме виджета «мои сообщения». А если это не «мои сообщения», а «моя личка» и там должно лежать приветствие от администратора? Давай сразу отвечу за тебя: придёт приветствие попозже, не страшно. Но так получается, что у нас вся бизнес-логика заточена на то, что репликация может запоздать. Этого не хочется совсем.

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

Когда ты отправишь юзеру сообщение, у него появится запись в этой базе.

Тогда приём сообщения тоже должен иметь в виду, что репликация ещё не прошла.

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

Микросервисы - это действия.

Вот. Откуда это следует? Веб-сервер, выполняющий get запросы и отдающий статические файлы - не может называться микросервисом? Он же маленький и работает по протоколу http?

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

у нас вся бизнес-логика заточена на то, что репликация может запоздать

На то что никакой репликации не существует.

Микросервис отвечающий за создание пользователя НЕ посылает пользователю сообщений сам, он делегирует это сервису посылающему сообщения, и никак не отслеживает результат. Когда сообщения придут, они будет показаны. Это асинхронный процесс никак не связанный с процедурой создания пользователя. И приветственное сообщение ничем не отличается от других.

Он также не создает контента. Он создает только пользователя в базе пользователя. Это его единственная цель и единственная задача.

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

Запоздать...

На сколько? На секунду или на день?

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

UPD. Базы такие трюки позволяют. Но сервис получит уведомление о том, что учётка пользюка создана и можно продолжать работу. Пока пользюк перейдёт к другому сервису («получить личные сообщения») с точки зрения сервера пройдёт вечность.

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

Так, ну, теперь я могу пытаться это осознать (впрочем, я пока не понимаю, почему _именно_это_ называется микросервисами).

Хорошо, приветственное сообщение на форуме в данном случае никому не нужно. А представим себе, что это гостиница. Стоит человек с чемоданом, пот со лба отирает. В «приветственном» сообщении ему должен прийти код от замка его номера. В описанной тобой схеме, кто отвечает за то, что это сообщение придёт? Кто отвечает за сроки?

den73 ★★★★★
() автор топика
Ответ на: Запоздать... от Moisha_Liberman

На сколько? На секунду или на день?

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

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: Запоздать... от Moisha_Liberman

А что мешает повесить триггер

Есть такое страшное слово «распределённая транзакция». Я кое-что делал на SQL (поддерживал две системы в течение довольно многих лет), но ни разу не пользовался. Потому что такая транзакция умеет завешивать группы серверов и потом непонятно, что делать. Теоретически должно работать, но на практике - я не уверен. Т.е. спихнуть это дело на сервер базы данных будет неблагородно. Если же это получится, то в чём профит от моей работы и от микросервисов? Это тогда не голанг и микросервисы, а старый добрый SQL.

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

Т.е. если база одна, то всё норм. Если мы разделили базу, то сразу репликация. Причём, я сам никогда не пользовался штатными репликациями и вокруг меня не видел пользователей таковых. Все велосипедят.

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

В обычном случае - никто. У пользователя будет кнопочка - повторить отправку сообщения.

Когда в онлайн-банк логинишься, там тебе кнопочка «послать SMS ещё раз» всегда висит на главной. И «напишите в суппорт, если не получилось».

В зависимости от сложности системы можно делать сервис на проверку консистентности, сравнения входа с выходом и т.п. Но это будет вне описываемых микросервисов. Отдельная штука которая будет проверять end-to-end функциональность, а не пытаться что-то понять в рамках одного сервиса.

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

Можно пруфлинк?

лень искать обоснование, много специалистов по сервисам SOA считают так, остальные определения - производные (недельные сроки, спринты, количество строк, коробки пиццы и прочие)

демагогические упражнения, лучше попробуй придумать распределённую систему для торгового предприятия с представительствами в Москве, Воронеже, Краснодаре, Казани, Йобурге - резервируемую, управляемую, надёжную - и ты пешком придёшь к сервисам и балансировкам

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

Не.

Распределённая транзакция здесь не вариант. Здесь просто триггер. И функционально он привязан именно к созданию учётной записи. Микросервис создаёт запись. БД обрабатывает этот факт и не более того.

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

Смысл своего кода для решения этой проблемы и отказ от механизмов СУБД не ясен.

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

Только я добавлю...

и ты пешком придёшь к сервисам и балансировкам

Сперва сплясав на граблях. Но тут... Лучше разок на взрослых сплясать чем пару раз на детских. ;)))

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

много специалистов по сервисам SOA считают так

Слушай, ну прекрасно. Я прочитал определение SOA, микросервисов в википедии, и пост на хабре проискал в поисках «state» и «состоя». Нигде не говорится про стейтлесс. Т.е. как и обычно в случае хайп-технологий, туман и недоразумения начинаются прямо с определений :(

демагогические упражнения, лучше попробуй придумать распределённую систему для торгового предприятия с представительствами в Москве, Воронеже, Краснодаре, Казани, Йобурге - резервируемую, управляемую, надёжную - и ты пешком придёшь к сервисам и балансировкам

Я такую делал, правда, для опта. Там, конечно, не нужно было никаких балансировок, а репликация как раз была нужна, т.к. базы были автономны. Но там были люди, которые отслеживали ситуацию и приходили с ошибками.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: Только я добавлю... от Moisha_Liberman

Сперва сплясав на граблях. Но тут... Лучше разок на взрослых сплясать чем пару раз на детских. ;)))

На самом деле тут вопрос, у какого плясуна гонорар больше.

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

Дык...

Ракушку (защиту паха) и шлем для защиты головы одевать надо. =)))

UPD. Но насчёт stateless я согласен. Сделал операцию — уходи из сервиса. Другие операции это другие сервисы.

Moisha_Liberman ★★
()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: Не. от Moisha_Liberman

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

Всем спасибо, но надо немного и покодить :) Надеюсь, что в следующих сессиях вы меня ещё поучите уму-разуму :)

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

почему _именно_это_ называется микросервисами

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

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

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

для опта. Там, конечно, не нужно было никаких балансировок, а репликация как раз была нужна, т.к. базы были автономны. Но там были люди, которые отслеживали ситуацию и приходили с ошибками.

как бы тебе так объяснить... что неправильно это

с другой стороны, если заказчик доволен...

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

Ну, удачи. =)

Триггер дожен был бы добавлять приветственное сообщение при регистрации новой учётной записи.

Делать две базы (раздельных) можно, но смысла нет. Если раздавать дампы базы, то можно не дампить или не класть в дамп таблицу учётных записей.

А так-то да, Бог в помощь. =)

Moisha_Liberman ★★
()
Ответ на: А Вам бы бросить чушь молоть. от Moisha_Liberman

http+json требуют как правило две реализации (которые только по отдельности специфицированы), одну на json, одну на http/https как транспорт. А XML-RPC это единая спека. Одна.

Для вас, Козлов^W Либерман, придумали JSON-RPC.

anonymous
()
Ответ на: Ага... от Moisha_Liberman

На Си оно тоже есть. Так что, если извращенное чувство прекрасного заставляет писать на Си, тоже нет проблем использовать JSON-RPC.

anonymous
()
Ответ на: Есть. от Moisha_Liberman

RPC есть RPC. А по сравнению с Sun RPC, XML-RPC - это такой же гироскутер.

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

Да, я в курсе.

Только SUN RPC в лучшие-то свои годы был не особо распространён.

Я бы больше сейчас сравнивал XML-RPC, SOAP, REST, а про SUN RPC уже забыть можно.

UPD. И нет. RPC только по своему смыслу RPC. Реализации там очень разные. XML-RPC это в большей степени упрощённая реализация.

Moisha_Liberman ★★
()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: Скорее, Тесла. от Moisha_Liberman

насчёт теслы — разумно.

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

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

Вообще-то, старина Екклесиаст прав.

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

я писал то, что мы называли «сервисами» ещё до того, как микросервисы стали мейнстримом.

Та же фигня. Но сейчас хотя бы вопросы деплоя как-то более-менее, но хоть решились.

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

Просто, не стоит делать культа ни из еды, ни из кода. В микросервисах, в их текущей инкарнации, есть немало минусов. Но и немало плюсов.

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

Но наличие сетевого вызова в отдельной точке совсем никак не влияет на масштабируемость. Если код написан с оглядкой на масштабируемость, то простой запуск дополнительного блоба поднимет тебе число обработчиков. Если о масштабируемости не думали то все 100500 микросервисов упруться в тонкое место.

ya-betmen ★★★★★
()
Ответ на: Вообще-то, старина Екклесиаст прав. от Moisha_Liberman

за экклесиаста не скажу, но...

«микросервисы» — это вопрос горизонтальной масштабируемости. проблем этот подход приносит тоже чуть более чем много. всё решают деньги.

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

замена локального вызова на сетевой увеличивает сложность системы на порядок. в остальном — всё верно :)

anonymous
()

Подскажите, правильно ли я понял всю эту тему, и куда копать за примерами?

Пока монолитный линукс успешно живёт почти тридцать лет, «микросервисную архитекуру» GNU HURD все те же тридцать лет не могут до ума довести. Расскажи об этом работодателю. Спроси, готов ли он подождать три десятка лет для запуска своего стартапа.

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

...это когда работодатель у тебя уже есть. у тс-а другая ситуация.

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

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

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