LINUX.ORG.RU

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

 ,


1

3

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

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

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

★★★★★

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

а в чем проблема то?

anonymous
()

на ту же задачу можно потратить x1000 вычислительных мощностей. Даёшь докер-контейнеры на AWS инстансах

тут фишка в том что иначе эти вычислительные мощности расходуются ещё менее эффективно из-за простоев

Bad_ptr ★★★★★
()

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

О, да. Микросервисов штук 7 понадобится. Еще фронтенд запили как SPA на реакте. Все кипятком ссаться будут и в калифорнию позовут на $200к.

Пиши все на разных языках и фреймворках. Больше строчек в резюме. Типа синьёр ангуляр гоу реакт спринг девелопер.

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

Deleted
()

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

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

убили нынешние разработчики

У семи синьоров микросервисы без мониторинга.

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

Можно уточнить пропаганду чего именно ты мне приписываешь?

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

Зашибись! Жаль, я на прошлой работы только до докера дорос, с кубернетесом не пришлось столкнуться. А что есть второе? Это инструменты дармовые или платить надо кому-то?

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

Ну насчёт SPA я как-то совсем пас. Есть всё же грань добра и зла :( Всё-таки этот контейнеровоз может доставить груз, а как работают SPA приложения, мне совсем как пользователю не понравилось. Т.е. непонятно, могут ли они в принципе работать.

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

Ты ж, вроде, плевался на golang, а теперь микросервисы думаешь на нём пилить? :-D Микро - это один из архитектурных вариантов, не обязательно ВСЁ делать микро.

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

большинство опенсорс, почти всё пилят на go, и суета как на клондайке.

ты кажется писал, что на java девелопил. если да, то посмотри https://developers.redhat.com/blog/2019/03/07/quarkus-next-generation-kuberne..., чтобы уловить содержание хайпа.

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

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

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

Не, на ява я не писал никогда. Спасибо, почитаю уже завтра.

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

Сервисам не обязательно нужно быть микро, чтобы эффективно маштабироваться. А размер геморроя приносимый с микросервисной архитектурой в сервис с сотней юзеров не стоит этой «эффективной» маштабируемости. У нас есть один проект, который сделан по канонам микросервисов. В теории он, да, легко маштабируется. Но его можно было вполне сделать монолитным. И не надо было гонять json'ы с данными туда-сюда, не было бы геморроя с ACLями и невозможностью гарантировать консистентность данных и не надо было бы городить service-discovery и балансировщик, писать мозголомные деплой скрипты и т.д.

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

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

И да, я делал приложение для клиринга финансовых сделок на JavaEE в сраном веблоджике 7 лет назад, до этого хайпа с микросервисами. И всё прекрасно горизонтально маштабировалось и даже распределённые транзакции отлично работали. И жрало это всё ресурсов не больше, чем современный spring boot.

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

в сервис с сотней юзеров

Там и не нужно.

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

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

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

В 90% проектов, что я видел, это именно то и означало — микросервисы ради микросервисов. К тому же выделить высоконагруженный компонент из монолита отнюдь не тривиальная задача. Обычно там внутри все очень сильно связанное. А сосать эвенты из очереди, это, извините меня, тупо job queue, а не микросервис. Это еще в лохматые годы делали.

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

В теории он, да, легко маштабируется. Но его можно было вполне сделать монолитным. И не надо было гонять json'ы с данными туда-сюда, не было бы геморроя с ACLями и невозможностью гарантировать консистентность данных и не надо было бы городить service-discovery и балансировщик, писать мозголомные деплой скрипты и т.д.

Это всё нужно для трудоустройства таких псевдоайтишников как alpha. Рабочие места на пустом месте, имитация бурной деятельности, переливание из пустого в порожнее. Ждем схлопывания пузыря короче. А пока лучше в сторонку отойти от ойти.

anonymous
()

2014 — нужно внедрить микросервисы для решения проблем с монолитами.
2016 — нужно внедрить Docker, чтобы решить проблемы с микросервисами.
2018 — нужно внедрить Kubernetes, чтобы решить проблемы с Docker.

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

Когда речь о микросервисах, это не означает, что вообще всё должно быть микро

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

Deleted
()

теперь на ту же задачу можно потратить x1000 вычислительных мощностей.

Собственно с чего бы это? Микросервисы это новое издание классического пути Юникса. Только с json вместо текстовых потоков и http вместо pipe,stdin,stdout,stderr. От того, что вы grep и zip вынесли в разные процессы количество работы не увеличилось и вычислительные мощности используются так же.

Даёшь докер-контейнеры на AWS инстансах!

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

они ведь должны подробно отчитываться о своём состоянии, иначе невозможно сделать мониторинг и понять, работает ли система или нет

healthcheck endpoint, логи вот это вот всё.

Я уж не говорю о том, что всё это разворачивается в ЦОДах, соответственно, понятно, кому выгодно:

А где ещё разворачиваться серверному приложению?

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

OOP так же продавали.

и куда копать за примерами?

А посмотрите исходники кубернетеса. Во-первых, это отлиный пример хорошо сделанной микросервисной архитектуры, а, во-вторых, знанием о k8s само по себе весьма востребованно.

ugoday ★★★★★
()

Немного не так. =)

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

Это не развод. Просто несколько независимых команд пилят каждая свой участок единого проекта, вот и всё. Ничего нового. Границы каждой команды определены. Соглашения об интерфейсах достигнуты.

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

Блин... На дворе шёл 2019 год и рота красноармейцев... =))) Зачем? Зачем всё это? Ну откройте уже для себя сервис syslog-то. Если есть состояние отказа, то именно в логи и надо его пихать. В логах и искать в последствии. Если приложение работает штатно, то ему нечего сказать, вот пусть оно ни чего и не говорит.

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

Дальше. В комментах было про json. У меня всегда на этом моменте глаз дёргается. А это-то зачем? Ну оно понятно что к 2019г. деградаия достигла таких масштабов что программисты вплотную забыли об XML-RPC, который даже на С можно (xmlrpc-c), но с XML-RPC взаимодействие распределённых сервисов или микросервисов, т.е., сервисов, выполняющих максимум одну задачу, это просто и безболезненно. Нет необходимости обёртывать результаты в json, передавать куда-то, там парсить... Всё намного проще становится.

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

Нет необходимости обёртывать результаты в json, передавать куда-то

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

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

Сравните реализации?

Или погуглите? Потом расскажите что проще и надёжнее работает?

Впрочем, нет. Найдите мне хотя бы одну толковую спецификацию на тот же REST, например? На XML-RPC показать? Или сами нагуглите?

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

Это ты федорастов упустил, которые докер переписывают.

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

А Вам бы бросить чушь молоть.

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

XML-RPC в принципе игнорирует все семантики и все глаголы http/https, там путаться не в чем, там только POST используется. Библиотека проста как 3 копейки. Впрочем, Вы же мне всё равно не поверите?

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

деградаия достигла таких масштабов что программисты вплотную забыли об XML-RPC

Запросы гоняются через какой-нибудь MQ. Зачем там xml-rpc/http(s)? Json меньше даёт накладных расходов.

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

В теории он, да, легко маштабируется. Но его можно было вполне сделать монолитным. И не надо было гонять json'ы с данными туда-сюда

У вас там не микросервисы, а разрезаный монолит, раз всё это можно легко переделать туда-сюда.

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

Обычно там внутри все очень сильно связанное.

Ради этого всю эту бодягу и заварили, чтобы не было «очень сильно связанное». Если делать очень сильно связанные микросервисы, то это - шило на мыло.

crutch_master ★★★★★
()

Но мне нужно найти работу.

Микросервисная архитектура - это интерфейсы, протоколы, херак-херак и в продакшн и никто не страдает если что-то надо переписать или кого-то уволить.

crutch_master ★★★★★
()

Владимир

Не плохим примером микро-сервисной архитектуры являются сервисы Windows.

PS: Когда люди становятся «шибко умными», то они 2+2 вычисляют не по правилам арифметики, а с использованием тройного интеграла

anonymous
()
Ответ на: Немного не так. =) от Moisha_Liberman

Это не развод. Просто несколько независимых команд пилят каждая свой участок единого проекта, вот и всё. Ничего нового. Границы каждой команды определены. Соглашения об интерфейсах достигнуты.

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

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

А посмотрите исходники кубернетеса.

Спасибо, посмотрю.

OOP так же продавали.

Ну да, маркетинг рулит :)

А где ещё разворачиваться серверному приложению?

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

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

Ну в общем-то увеличилось. Коммуникация не дармовая.

Но ладно, не суть. Раз оно кому-нибудь нужно, то будем этим обмазываться (может быть).

den73 ★★★★★
() автор топика

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

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

anonymous
()

Владимир.

Государства также имеют микро-сервисную архитектуру.
Dll-s также являются примерами а-ля микро-сервисов ...
Не знаю хорошо это или нет, но для меня разработка - прежде всего проектирование хорошей архитектуры /как говорится «были бы кости, а ...»/.

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

А прикинь, что для этого микросервисы не нужны.

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

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

Не. Не в этом дело.

XML-RPC, он не зря из двух акронимов состоит. Иногда важно как именно мы оборачиваем данные (XML), а иногда важен как раз Remote Procedure Call. Т.е., мы вообще не думаем о том, какой там протокол передачи http(s) или ещё что. Велосипед изобретать не нужно. Придумывать каким именно MQ пользоваться, как данные передать, как их обернуть, как получить и как распарсить... Всё это лишнее.

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

По ТЗ пишем теперь консольного клиента. Написали. Работает. Теперь заказчик прибегает и кричит что в моде GUI, давай сделаем GUI. Давай. Сделали. Опять прибегает заказчик и кричит что веб это теперь наше всё, даёшь вебню во все поля. Не вопрос.

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

Вся эта работа уже реализуется одной библиотекой (в случае «всеми любимого» С). Мне не нужно велосипедить MQ, мне не нужно велосипедить JSON, мне просто нужно использовать одну библиотеку. Реал-тайм не факт что нужен всегда, так что http/https тут вполне нормально смотрится да и работать с ним напрямую в библиотеке не нужно, если честно.

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

В общем, если честно, то RESTful и этот ваш json, это всё попытки заново изобрести если не XML-RPC, то уж точно SOAP. И зачем, не понимаю... Всё же уже есть. А! Ну да... Ну да... xmlrpc-c =))) Ну, что поделать... =)))

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

Не совсем.

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

Всё хорошо выходит как правило только на бумаге. А на практике... «чем дальше в лес, тем ну его на хер». Одни велосипедят одно, другим в башку другое стрельнуло, тоже велосипедят. А так есть спека на тот же xml-rpc (http://xmlrpc.scripting.com/spec.html), вот и всё. И придумать что-то там этакое уже становится сложнее.

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

+1!

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

Плюсую. Неистово плюсую... Современный программист это как обезьяна (привет, дедушка Дарвин!), которая пришла в сознание в кабине истребителя, который на полной скорости херачит в воздухе. За что дёрнуть или на что нажать не понимает, а когда понимание придёт, то... проект уже всё, разбился. Возможности-то есть же. Вон они и рычажки и кнопочки... =)))

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

Moisha_Liberman ★★
()

Микросервисы не про перформанс, не про экономию ресурсов, и не надо их лепить в каждом проекте «чтобы было». Микросервисы - это про высокую нагрузку, resilience, fault tolerance, elasticity, etc.
Посмотри/почитай старину Фаулера, посмотри пару докладов с конференций про переезд на микросервисы. Поучи архитектурные паттерны.
Возможно, постепенно начнёшь прозревать. Плюсов много, минусов тоже.

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

2014 — нужно внедрить микросервисы для решения проблем с монолитами.
2016 — нужно внедрить Docker, чтобы решить проблемы с микросервисами.
2018 — нужно внедрить Kubernetes, чтобы решить проблемы с Docker.

2019 — нужно внедрить helm чтобы решить проблемы с кубернетис

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