LINUX.ORG.RU

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

 ,


1

3

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

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

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

★★★★★

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

Если так смотреть, то на чём это всё едет вообще дело десятое. Конечный васян ничего этого трограть не будет, всё уже написано до него, хоть там xml/json+rabbitmq/activemq, хоть xmlrpc+http/tcp/udp, хоть чёрт лысый. Конечный васян пишет

int aplusb(int a, int b) {
    return a + b;
}
А всю осталную работу - включение aplusb и параметов в метод микросервиса и документацию система может сгенерить сама при сборке, например. Для васяна остаётся именно вход, обработка, выход и больше ему вообще знать ничего не надо.

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

Владимир

Архитектуры бывают разные ...
Как-то задал вопрос одному дельфийцу - «Без тебя же твой код ни кто не поймет».
Он отвечает - «Так так и задумано».

anonymous
()
Ответ на: +1! от Moisha_Liberman

Современный программист это как обезьяна

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

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

Он отвечает - «Так так и задумано».

Так тут как раз всё наоборот. Код должен и может быть выкинут и переписан. Микросервисы мелкие, а то, что там происходит заявлено интерфейсами и протоколом.

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

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

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

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

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

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

Ну так я и не ожидаю, что сложность куда-то испарится.

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

Ну так и идея-то в том...

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

Для того же JSON я могу назвать несколько либ. JSON-C, JFES, JSMN, Jansson... Конечно я могу их использовать. Конечно я могу потом взять какой-то MQ и изобрести опять сетевой обмен. Но... смысл?

Код становится сложнее, пухнет, зависимости растут... Зато «стильно, модно. молодёжно педовато бородато».

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

А вот тут соглашусь.

Да. Всё верно.

UPD. Равно как соглашусь с подколом по годам. Да, всё так. Скорость реизобретения колеса всё возрастает. Видимо, уплотняется время и пространство. =)))

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

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

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

Микросервисы мелкие, а то, что там происходит заявлено интерфейсами и протоколом.

Ну ведь это можно и в рамках монолита задекларировать и проверить.

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

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

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

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

crutch_master ★★★★★
()
Ответ на: Ну так и идея-то в том... от Moisha_Liberman

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)

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

Гм. Вот не соглашусь, на сколько я понимаю всё как раз строго наоборот: интерфейс более-менее формализован и понять какой именно сервис не работает проще чем в монолите.

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

Ты бы сначала про юниксвей-то подумал. Про правило «не усложняй». Ага-ага, мне не обязательно каждую программу делать сервером или вообще заставлять её гулять по сети. Потому что есть netcat, например. А ещё программа может вписываться в другой шаблон поведения — её просто надо запустить и взять вывод. Из такого сервер, я думаю, делать не надо. Как и из фильтра.

А ещё про do one thing and do it well — тоже сюда. Зачастую микросервисы либо делают половину one thing (хорошо, если половину, а не десятую долю), либо, если посмотреть с другой стороны, любой микросервис делает уже не одну вещь, а очень много: держит на себе rest-api, тасует логи… Ну ты понимаешь.

Только с json вместо текстовых потоков и http вместо pipe,stdin,stdout,stderr.

Текстовые потоки может обработать любая программа. Работать с json и http же не должно быть задачей любой программы.

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

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

Микросервисы — это пародия на новое издание классического пути Юникса от тех, кто о нём ни разу не слышал и слышать не желает.

Ну и в конце концов, unix way — он совсем не про service as a software substitute.

anonymous
()

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

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

Текстовые потоки может обработать любая программа. Работать с json и http же не должно быть задачей любой программы.

Разбирать обобщённые текстовые потоки — задача, а json объекты — не задача? Ну, как скажете.

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

Но ведь и в монолитах есть модульность,

1. В монолитах бывает затруднительно запустить пару дополнительных экземпляров модуля на сосденем хосте в случае увеличения нагрузки, а вот с микросервисами — легко.

2. До потребностей из пункта «1» ещё нужно дорасти. Сейчас любая шашлычница проектирует архитектуру на случай если она разрастётся до размеров амазона или гугля.

ugoday ★★★★★
()

den73 нашел очередной заговор...

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

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

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

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

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

Ну я вот пойду в эти микросервисы, если вообще пойду, именно за деньгами. Т.е. сишники (которых не мало) доступны. А знатоки микросервисов стоят гораздо дороже. При том, написать просто функцию сложения на Си и вставить её в программу стоит на 2-3 порядка дешевле, чем написать микросервис для сложения и развернуть его по трудозатратам (количеству операций, которые нужно выполнить). Я уж не говорю о том, что про Си всё давно известно и ничего не меняется, а все эти хайпо-технологии все сырые (вода из них прямо сочится) и постоянно меняются. Написав однажды, сразу попадаешь на поддержку хотя бы по причине постоянных изменений. Т.е. разговоры о том, что микросервисы что-то там удешевляют и делают проще с т.з поддержки - ну просто наглейшая ложь, это видно даже издалека. Я могу понять про масштабируемость, но дешевизна и управляемость процесса - не про то.

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

Нужно всё же разделять запуск дополнительных экземпляров и вопросы управления процессом разработки. Про доп. экземпляры я спорить не стану.

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

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

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

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

Решил перейти на тёмную стороны силы?

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

Да не вопрос!

Хочется «дешёвых» решений? Отлично. Пусть будут. Но ведь за всё рано или поздно приходится платить.

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

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

Да. Именно.

И, замечу, действительно серьёзные проекты, они так и пишутся и поддерживаются/сопровождаются. Годами (в случае поддержки и сопровождения).

И тут даже язык программирования не важен. Не хотите копаться в С, значит, будете копаться в «не-С», но всё равно будете.

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

таскать с собой http-сервер в комплекте

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

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

Процессы обмениваются данными с использованием протокола! До каких пор будет продолжаться это безобразие?!!!

ugoday ★★★★★
()

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

WEB приложение. с чего начать (комментарий)

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

Докер не забудь!!!

И AWS Lambda c Redshift и конечно RedHorse...

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

HTTP уже давно не только текст.

а машины потерпят

Вся суть докероманов in a nutshell. Правда, тут не только уже машины терпят, но и здравый смысл.

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

Здравый смысл говорит, человек должен думать — машина работать.

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

При том, написать просто функцию сложения на Си и вставить её в программу стоит на 2-3 порядка дешевле, чем написать микросервис для сложения и развернуть его по трудозатратам (количеству операций, которые нужно выполнить).

Ну да. Только вот дело функцией не ограничивается. А написать на си что то заметно сложнее функции сложения - это уже на 2-3 порядка дороже чем микросервис.

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

При том, написать просто функцию сложения на Си и вставить её в программу стоит на 2-3 порядка дешевле, чем написать микросервис для сложения и развернуть его по трудозатратам (количеству операций, которые нужно выполнить)

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

Я уж не говорю о том, что про Си всё давно известно и ничего не меняется, а все эти хайпо-технологии все сырые

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

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

На основании того, что? Первое - это не так. Второе - как везде, зависит от реализации, тут спорить не о чем. Сделаешь нормально, будет хорошо и дёшево, сделаешь через жопу - будет наоборот.

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

В лиспе (да и во многих других средах) для этого есть trace. Т.е. решение существует.

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

Другое дело, что в недотехнологиях

Так других нет. И кодеры другие не возьмутся из ниоткуда.

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

А сосать эвенты из очереди, это, извините меня, тупо job queue, а не микросервис. Это еще в лохматые годы делали.

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

В итоге получались разнообразные глюки с фейерверками — а решалось 90% проблем 1шт.(одним штука) бэкграунд-воркером и очередью задач :)

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

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

Это умеет и делает практически любая программа (как минимум, пишет в stderr или специально отведённое место). Кроме очевидного cantrip'a, например.

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

Это умеет и делает практически любая программа (как минимум, пишет в stderr или специально отведённое место). Кроме очевидного cantrip'a, например.

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

кубернетес — это джавоскрипт в мире девопсов

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

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

как постановки задач от бизнеса, так и реализации от разработчика — т.е по сути энтерпрайз

Вот, вся суть этой идеалогии микросервисов. Докеромакаки же суют их везде, где только можно присунуть, зачастую не заморачиваясь с сетью, изоляцией и здравым смыслом. В 99% небольших проектов для задач экономной изоляции можно было бы воспользоваться LXC, или сделать несколько KVM виртуалок, если речь о БД. Кстати БД в докере — отдельный сверхразум, заслуживающий пенетрации девопсовских рук в их собственные анусы, желательно по локоть.

И точно так же их можно учуять за километр.

Чепуха. Деньги не пахнут.

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

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

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

ну так и хреново это.

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

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

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

а потом файлов становится 200к. или 300к.

как решает проблему монолит? он просит процы и память, а дырки потихоньку кончаются.

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

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