LINUX.ORG.RU

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

 ,


1

3

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

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

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

★★★★★

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

Но я понимаю.

НетЪ, ты не понимаешь :)

Смысл микросервисов в установлении сословных отношений.

Смысл микросервисов как и любых сервисов — минимизация связности и масштабирование.

А вот исполнители, которые пишут сервисы, должны быть разделены, т.к. это плебс.

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

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

Непонятно, почему ты решил что api один на всех.

Потому что API подразумевает сервис и клиента, значит, сервис и клиент уже между собой повязаны через одинаковость этого API. И я так понимаю, основная сложность - не в API, а в отказоустойчивости. Я тут в своих полутора «сервисах» не могу продумать все сценарии аварий и их преодоления. Если же автономных элементов приложения набирается штук 5, то это уже адский треш. Больше 5 можно построить в иерархию, но 5 - уже много. И это только аварии, а есть ещё просто затыки по эффективности.

А в целом спасибо за инфу.

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

А сам контракт на API ведь един?

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

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

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

Я имею в виду, что он един в рамках всего конкретного экземпляра системы, функционирующего в данный момент времени. Не?

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

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

Не совсем так...

1)По мне так это «слишком сложно», в том же браузере на js эта функция (назовем ее json_rpc) пишется в 5 строк(обернуть данные(имя функции и параметры) в json, послать запрос, распарсить json в объект), и потом вызывается одной строкой.

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

Хотя, даже взаимодействие клиент-сервер тут под вопросом. Не обязательно же браузер. Вполне возможно что и GUIня так может работать и тот же CLI. Мы тут не ограничены одним браузером. Как надо, так и пишется (хоть вон, с Qt/Qml под Sailfish OS). Если по хорошему, то технология не должна нас ни в чём ограничивать. Наиболее яркий пример здесь и общедоступный, это поддержка XML-RPC в том же livejournal. Удалённый клиент это вообще не вопрос (для той же Saifish, кстати, клиент для ЖиЖи есть, если что).

Если говорить о взаимодействии «сервис-сервис(-ы)», то эта технология удобна тем, что микросервисы могут быть раскиданы по куче серверов и один микросервис может запрашивать данные/результаты обработки у произвольного числа своих «собратьев». Этот интерфейс упрощает такого рода обмен. Нет необходимости в долгих обсуждениях чего мы завернём в JSON, а чего не будем.

По реализации. Здесь вообще всё просто. Как хотите, так и реализуйте. Начиная с банальных cgi (и того, что в либе есть свой веб-сервер abyss, который можно в своём коде использовать) и кончая модулями к серверам, реализацией с libevent/libev/libuv. Даже есть реализации для питона, руби, перла. Насколько они работоспособны я не смотрел, мне и С хватает, но язык вообще не ограничивает инструментарий создания такого микросервиса с поддержкой xml-rpc. Здесь вопрос не «как реализовать», здесь вопрос «а как надо реализовать», т.к. требований по тому же масштабированию может быть вагон и маленькая тележка и проект, в начале ютившийся на одном сервере, где-то в уголке ДЦ вполне может расползтись на энное число серверов. При чём, без переписывания, только конфиги поправить.

Т.е., либа одна, а вариантов её применения — уйма. И, собственно, не json единым...

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

сервис и клиент уже между собой повязаны через одинаковость этого API

Сервис «повязан» сам по себе, своим контрактом. Клиентов у него может быть миллион разных, о которых он знать не знает.

В этом и фишка, что твоя задача как автора микросервиса не под конкретного клиента что-то пилить, а под абстрактный контракт.

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

alpha ★★★★★
()
Ответ на: Не совсем так... от Moisha_Liberman

Посмотрел в википедии. Я не пойму одного: там надо вызвать процедуру и дождаться результата её выполнения?

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

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

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

Да.

В коде выше пример есть. Это клиент. Сервер (пример на основе cgi) есть по ссылке выше.

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

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

если клиент и сервер соблюдают одну версию контракта

Клиент соблюдает какую-то из поддерживаемых версий контракта объявленных сервером.

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

alpha ★★★★★
()
Ответ на: Да. от Moisha_Liberman

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

Также устроен и ajax - мы отправляем сообщение и вешаем некое действие на получение ответа.

И в голанге есть каналы между горутинами, но нет вызова горутин.

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

Каждый микросервис есть сервер имени себя и сам своим контрактом рулит.

Да нет, контрактом всё же должен рулить архитектор. Хотя это, конечно, зависит от того, у кого длиннее :) Или, может, в микросервисах принято как-то по-другому :)

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

А я тем временем посмотрел на вакансии со словом голанг и почему-то никому не нужны джуны. Вот это действительно херовая ситуация, и чё делать - непонятно. Есть ряд вопросов, которые я близко не понимаю. Например, «нужно ли ждать базу». Т.е. на архитектора я точно не тяну. Хм-хм, неужели опять придётся искать работу на Дельфи :)

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

Не совсем так.

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

Там есть типы данных вида array, string, struct. И вернуться в ответ на один запрос их может произвольное число. Решаемо, в общем.

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

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

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

Так в том то и дело что технически ничем. Отсюда закономерно растет вопрос нафига нужно хттп когда можно просто дернуть метод у объекта.

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

Хотя если его использовать совместно с горутинами, то может и ничего. А как это решается на Си - я не знаю.

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

Конечно может.

Дерьмо случается. Только тут что микросервиса, что монолиты ни как не защищены. Может лечь канал, может сервак в даун отправиться. Это отказ. И технологическая подоснова тут... Мало связана. Но в случае с микросервисами как правило есть и дублирование (если оно действительно нужно) и балансировка нагрузки (если она действительно нужна). Прилёг один сервак, второй-третий откликнутся.

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

Ну что, дево-пёс - это тоже работа, нужная людям. Поищу заново, спасибо!

den73 ★★★★★
() автор топика
Ответ на: Конечно может. от Moisha_Liberman

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

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

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

Отсюда закономерно растет вопрос нафига нужно хттп когда можно просто дернуть метод у объекта.

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

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

нужно писать алгоритмы так, чтобы всё чинилось само

Мне кажется не так. Для микросервисов и т.п. нужно писать в стиле: не смог и сразу зарепортил ошибку.

Чинится «само» оно будет на уровне инфры: кубернетес или балансер или кто там ещё следит за количеством фейлов приходящих от конкретного сервиса и если их много, то перепосылает запрос, переналивает сервис, редиректит трафик и т.п. с помощью всяких хитрых техник. (Собственно потому и http, что стандарт, для него есть готовые инструменты разнообразной балансировки, контроля, маршрутизации и т.п.)

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

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

Только тут что микросервиса, что монолиты ни как не защищены.

Монолиты тут защищены лучше, т.к. у них функционал размазан по меньшему количеству распределённых сущностей, обладающих своим темпом отказов, как-то контейнеров, виртмашин, ЦОДов и прочая.

А тут получается, что практически на каждое действие нужно думать «а что, если принимающая сторона умрёт во время обработки запроса»?

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

гы, ну развесь монолит между несколькими ЦОДами, обезопась себя от тракториста )

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

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

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

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

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

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

Не. Не так.

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

Сервисы живут на доменных именах. Не на адресах, а именно на именах. Кто запрещает посадить на одно имя несколько сервисов и организовать доступ к ним через резольвинг по round-robin? В этом случае лёг один сервак с сервисами, остальные живы и работают. «Отряд не заметил потери бойца», ну разве что админы забегали чего-то...

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

Они ни чем не защищены. =)))

Тут я соглашусь с анонимусом. =)))

А тут получается, что практически на каждое действие нужно думать «а что, если принимающая сторона умрёт во время обработки запроса»?

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

Moisha_Liberman ★★
()
Ответ на: Не. Не так. от Moisha_Liberman

Кто запрещает посадить на одно имя несколько сервисов и организовать доступ к ним через резольвинг по round-robin?

балансировщики нагрузки F5 или тот же быстрый nginx - норм

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

Не. Не разводят.

У говновебмагазина денег не хватит. Если по серьёзному. У них и задач таких нет. Знакомый главбуха Уазилий намазал им там какое-то двигло, оно как-то работает, Уазилий пошёл играть в танки, все остальные вроде довольны. На фиг им «отказоустойчивость»? И прочие пироги и плюшки?

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

Микросервисы — очередная разводка лохов с размножением бессмысленных рабочих мест для малограмотных айтишников.

грамотные айтишники - такие грамотные...

бизнес тоже умеет в функциональную декомпозицию

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

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

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

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

А дальше нужно уже на голанге написать репликацию. И тут возникает проблема: а что, если в базе «секреты» всё записалось, а при записи в базу «контент» отвалилась сеть? Тогда получится рассогласование данных. Получается, нужно менять логику: отделить репликацию в отдельное нечто (службу, микросервис, не знаю, как назвать), которая будет упорно долбиться и обе базы и пытаться реплицировать постоянно.

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

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

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

https://github.com/budden/semdict/blob/b1c6a4003bd3170c56653dd46e92c9a416a7b6...

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

Мне тут сказали (и по вакансиям тоже вижу), что я как раз могу рассчитывать только на позицию девопса.

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

Мне тут сказали (и по вакансиям тоже вижу), что я как раз могу рассчитывать только на позицию девопса.

чтоб стать devops`ом тебе следует повысить уровень абстракции )

anonymous
()
Ответ на: Они ни чем не защищены. =))) от Moisha_Liberman

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

Ну это прямо вот так наивно не сработает. Допустим я в банкомате. Что мне, каждый раз списывать со счёта 100 долларов? Так деньги быстро закончатся. Т.е. нужно продумывать содержание запросов. Далее, если эн сервисов начнут постоянно повторять запросы, забъётся любая пропускная способность. Каскадное развитие аварии и эффект домино.

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

повысить уровень абстракции )

Ты имеешь в виду, надо абстрагироваться от мелких технических деталей и сказать: не работает, ну и ... с ним?

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

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

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

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

alpha ★★★★★
()
Ответ на: повысить уровень абстракции ) от den73

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

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

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

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

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

Т.е. «записать статью» использует базу «секреты» только для проверки валидности сессии. А сама работа с контентом происходит только в базе «контент».

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

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

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

Хотя это было всё же связано с разработкой, выкаткой в релиз не занимался.

а DevOps (акроним от англ. development и operations) — это набор методик, с помощью которых можно автоматизировать процессы между командами разработчиков и ИТ-специалистов, чтобы они могли быстрее и надежнее собирать, тестировать и внедрять релизы программного обеспечения.

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

Чем не логичное разделение?

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

Давай поставим вопрос по-другому:

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

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.