Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Микросервисы рулят! Или нет?

Привет всем,
хочу попросить совета у экспертного сообщества ДОУ.

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

С появлением Netflix OSS использование микросервисной архитектуры стало гораздо более дружелюбным и оправданным даже в небольших проектах. В интернете есть много отзывов об успешном переходе на микросервисную архитектуру на базе Netflix OSS/Spring Cloud. В частности, весной на хабре появилась статья-tutorial «Микросервисная архитектура, Spring Cloud и Docker» с примером на GitHub, которая уже фактически на пальцах разжевывает как управлять, настраивать, логировать, мониторить и деплоить зоопарк сервисов. Выглядит, честно говоря, впечатляюще:

Хотелось бы услышать отзывы от тех людей, кто пробовал использование Netflix OSS/Spring Cloud на практике.

Уменьшает ли микросервисная архитектура общую сложность разработки и поддержания проекта?

Можете ли указать плюсы и минусы такого подхода? Чего ждать. Какое ваше общее впечатление?

Стали бы использовать такой же подход в следующий раз?

Upd: Похоже, что самый глвный вопрос я и не задал:
Чего делать не стоит, если хочешь получить хорошее приложение на микросервисной архитектуре?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Eureka + Hystrix офигенны, там уже зашит circut breaker и есть офигенный UI для health check’ов. Впечатления крайне положительные.

А про очереди сообщений можете что-нибудь рассказать?

Все зависит от ваших нужд, как и всегда.
Kafka если нужно обрататывать безумное количество сообщений (100к+ в секунду например). Например activity stream для дальнейшей обрабоки в OLAP. Она скейлиться линейно, при том, что все из под коробки реплицируется. Многие говорят что у нее latency большой, но это уже не так, потому что изобрели kafka streams, а раньше это таки были батчи.
ActiveMQ если ентерпрайз и нужно все гибко конфигурировать (там реализованны enterprise integration patterns, в общем это отдельная тема).
Еще есть RabbitMQ/ZeroMQ, но они на 20-30к сообщений в секунду начинают тупить @ тормозить (и я говорю не о одной ноде, а о кластере), но зато юзать их крайне легко.
SQS я на проде не юзал, но настраивается он легко, буквально в пару кликов в AWS консоли, и перформанс у него — ок. И стоит он дешево — $0.5 за миллион сообщений, первый миллион в месяц — бесплатно, что обычно гораздо дешевле чем разворачивать инстансы EC2 с кафкой.

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

p.s. Если юзаете MongoDB или Redis, то там тоже есть механизм pub/sub, только в монге он durable, а в редиске все храниться in-memory. Но я пока не видел никого, кроме Meteor.js извращенцев кто делал бы очереди на монге.

Привіт, вже рік як робимо проект точнісінько на цьому стеку (Spring Cloud Netflix, Docker, AWS). Турбіну та серво правда ми не налаштовували — для цього є NewRelic поки що. ELK теж не прикручували, використовуємо SaaS логер, але я хочу прикрутити.
Проблем особливих не було окрім деяких нюансів настройок Eureka в AWS хмарі з апплікейшеном всередині Docker контейнеру, все інше працює як годинник. Задавай питання.

Вопросов уйма, было бы классно, если бы вы нашли время подробно на них ответить :)

1 Как реализовали коммуникацию между сервисами? Вызовы, аснихронные вызовы?
2 Использовали ли очередь сообщений? Если да, то на каком движке? Какой процент коммуникации приходится на вызовы, а какой на обмен сообщениями
3 Как себя показал Docker? После года использования не возникло ли желание перейти на что-то лучше/новее?
4 Вашему проекту уже год, получается ли удерживать новую бизнес-логику в сервисах, не размазывается ли она по ним?
5 Проблемы с дебагом были? И как их решали?

1 Как реализовали коммуникацию между сервисами? Вызовы, аснихронные вызовы?
Ribbon-aware RestTemplate або Feign (супер штука). Поки що синхронно.
Использовали ли очередь сообщений
SQS але вона більше для відкладених задач, є сервіси які слухають чергу і щось роблять.
Какой процент коммуникации приходится на вызовы, а какой на обмен сообщениями
Я би сказав 90 на 10.
Как себя показал Docker?
Чудово показав. 0 проблем с налаштуванням, 0 проблем з деплойментом, ми його використовували з самого-самого початку. Рекомендую.
После года использования не возникло ли желание перейти на что-то лучше/новее?
Чесно кажучи не знаю що є «новее» в світі контейнерів. Якщо ви про оркестрацію, то ми поки що обходимося парою bash скріптів і ECS, до Kubernetes, Spinnaker etc ще не дійшли.
Вашему проекту уже год, получается ли удерживать новую бизнес-логику в сервисах, не размазывается ли она по ним?
В принципі так. Проте є пара сервісів які за об’ємом значно більші інших, ми їх будемо розділяти потім.
Проблемы с дебагом были? И как их решали?
Так я спочатку ми деплоїли через ElasticBeanstalk, а там не можна задати нормальний порт маппінг, то ремоут дебаг відпав як клас. Замість того зробили профілі які дозволяють використовувати реальні ендпоїнти локально, тобто запускаєш в себе сервер і він приєднується до всієї інфраструктури ну а далі вже його кверяєш.
Зараз ми використовуємо ECS і там можна робити нормальний порт маппінг, але я згадав про це тільки щойно :).

В основному проблеми були з тим що при неправильному request body спрінг кидає 400 помилку без пояснень що куди, довелось писати свій ErrorHandler. Далі буває таке що одна операція приводить в дію 4 сервіси і десь посередині падає і вертається не той ексепшн що треба, теж доводиться трохи копати.

Багато мороки було з амазонівськими сервісами, SDK чесно кажучи не дуже, написаний в лоб і деякі речі дуже неочевидні, але це не стосується мікросервісів.

Також багато часу пішло на те щоб нормально завести Eureka. Тут є дві проблеми, по-перше, аплікейшен всередині контейнеру має свій IP і по-замовчуванню постить його в Eureka, по-друге, в нас є python апплікейшени для яких довелося брати python-eureka клієнт і допилювати його до робочого, бо те що є на гітхабі з коробки не дзижчить, по-третє воно не дуже добре працює в private subnets, там теж треба хачити.

Також бачу проблему в тому що сам NetFlix відмовився від Ribbon, Feign і ще чогось, тобто від вендору ми підтримки вже не отримаємо.

Натомість сам spring-cloud-netflix підтримується активно.

Крім того до недоліків я би відніс великий розмір кінцевого архіву, по-дефолту там купа барахла яке треба акуратно виключати.

Проблемы с дебагом были? И как их решали?
Головне що забув додати — незручно моніторити логи одночасно з декількох задеплоєних сервісів. SaaS рішення яке ми використовуємо дає сильну затримку і там поганий UI, в результаті доводиться повторювати раз за разом мантру ssh ec2-user@10.0.23.49; docker ps; docker logs -f iddqd; одночасно в декількох терміналах і потім дивитися що там відбувається.
Оце реальна проблема і я ще не добрався до її рішення.

Решается довольно стандартно: трейсинг (например, Zipkin) + лог-менеджмент (Splunk, Logstash, etc)

Я знаю що стандартно, просто ще не дістався проблеми (там нижче про ELK писав). Крім того, у випадку з амазоном треба продумувати як воно буде працювати коли інстанс відвалиться і тд.

docker logs -f iddqd;
проблем с захлебывания докера логами не было? Сам не в теме, но несколько раз слышал что в продакшине в stdout лучше много не писать.

Була проблема що по дефолту stdout писався в файл на локальному диску інстанса в результаті чого при великій кількості логів тупо закінчувалося місце на диску і все падало. Як вирішили вже не пам’ятаю, якийсь ротейт налаштували.

Проблема решается с помощью написания своего логгера и имплементации его во все микросервисы.
Далее они все сбрасывают в любой паб/саб и из него уже гребет эластиксерч( у нас используем редис как паб саб) . Плюс можно написать свой риалтаймовый логвъювер. Что мы и сделали. Очень удобно дебажить .

Ще така штука була — так як сервіси написані на Java і мають шарити між собою деякі ентіті, то щоб уникнути жорсткої зав’язки на ліби ми навелосипедили автогенерацію json-схеми + кодогенерацію классів по схемі. Тепер щоб оновити класи якщо помінялась схема треба тільки виконати gradle generateSchema -Pservice=PORTAL приміром, генератор сам піде на діскавері, дістане IP сервера, потім піде на нього, по ендпоїнту дістане схему ну і далі згенерує класи в потрібному пакеті.

Звісно можна кидатися нетипізованими мапками туди-сюди, але так зручніше.

Т.е. вместо того, чтобы сделать один подключаемый jar’ник с общими классами, вы
а) сделали json-схему
б) кодогенерацию java классов по схеме
в) автоматизировали этот процесс.

В чем преимущество вашего решения с генерацией идентичных классов перед просто подключаемым jar’ником с этими классами?

Класи з моделями містять вагон DynamoDB антоацій та інших речей, що не хотілось би шарити. Генерація проходить по чистому респонсу з рест сервісу.
Тут можна звісно сперечатися, але вирішальним було рішення СТО який волів не створювати жорстких залежностей по коду між подулями.

Ну, шарить DB-сущности тоже не вариант.
Имхо, ваш вариант оправдан, если коммуникации идут не только с java-сервисами. А если только java, то вполне хватило бы shared dto-объектов.

P.S. Но CTO, конечно, виднее, на то они и CTO, чтобы на 2 шага вперед думать.

Ну, шарить DB-сущности тоже не вариант.
В нас один і той самий клас часто використовується і для мапінгу в базу і для видачі клієнту (з відповідними @JsonView).
коммуникации идут не только с java-сервисами
This. Такого не так багато правда.

Вот вам микрочеклист
1) Архитектурная и организационная потребность в микросервисной архитектуре
2) Стандартизация процесса разработки и деплоя микросервисов.
3) Принципы для SOLID для микросервиса (www.infoq.com/...tions/microservices-solid)
4) Тестирование martinfowler.com/...les/microservice-testing
5) Спецификация актуальная и используемая на каждом этапе разработки.

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

Кейсы писать не буду — вечер пятницы )))
Коммуникация — для синхронных операций или REST, или очередь с res/req (RabbitMQ/etc). Для асинхронных очередь с pub/sub (RabbitMQ/etc). Для RPC бинарный протокол (thrift, protobuff) или очередь с res/req (RabbitMQ/etc).

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

Вообще решением вопросов как организовывать архитектуру занимаются специальные люди — архитекторы.

If you can’t build a well-structured monolith, what makes you think microservices is the answer? :)

Для меня микросервисы — это что-то вроде инкапсуляции на макро уровне.

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

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

Другое дело, что за все приходится платить. Spring позволяет разбить приложение на компонетны и легко управлять их взаимодействием, не хватало чего-то такого для микросервисов. И вот с поялвнием связки «Netflix OSS + Docker» ситуация стала получше. Насколько получше сказать пока не могу — время покажет.

Гораздо логичней начать со сбора нефункциональных требований к каждой конкретной системе и их анализа чем с подхода чем с «вау, давайте заюзаем воон ту крутую технологию».
Исходя из опыта, типичных нефункциональных требований и «постановки задачи» в стартпосте, я предположу что для типичного проекта применение микросервисов принесет больше геморроя чем бенефитов. Хотя бы потому что любая распределенная система предоставляет гораздо больше способов ненавязчиво и внезапно прострелить себе ногу и голову чем монолитная. Навскидку: перфоманс, CAP теорема, eventual consitency(как следствие решения CAP теоремы), сложности с мейтенансом(развернуть и отдебажить локальный енв), усложнение девелопмента вообще, проблемы версионирования интерфейсов и независимого деплоймента сервисов... и еще много разных неожиданностей, помноженные на неоптимальное разбиение системы на модули.
С другой стороны, хорошо структурированный монолит легко бьется на сервисы, если возникнет такая потребность. Поэтому я в типичном случае я бы рекомендовал послушать старичка Фаулера и начать с того чтобы спроектировать монолитную систему, удовлетворяющую требованиям и отходить от нее сознательно только в тех случаях когда это необходимо.

Подпишусь под каждым словом. У меня проект начался с фразы заказчика

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

Да, но стоит ли ждать, пока проект вырастет настолько, что придется дробить монолит? Почему бы сразу не попробовать спроектировать его как набор микросервисов, если с 90% вероятностью к этому все придет?

C 90% вероятностью монолита хватит за глаза. А если монолит научить горизонтально масштабироваться, то его хватит в 99% :)
В оставшемся проценте команда
— наберется опыта в предметной области
— стабилизирует свой технический уровень
— переколбасит пару раз компоненты и стабилизирует структуру
— бизнес поймет свою нишу и перестанет кидаться из стороны в сторону, как следтсвие — требования стабилизируются
— разбиение на микросервисы будет производиться неспеша и более тщательно(выделяем только то что действительно надо) и поэтмоу вопросы интеграции, версионирования, синхронизации данных и т.д. будут прорабатываться более тщательно
Ну и не могу не напомнить про старину Оккама с его вечноострой и вечноактуальной бритвой.

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

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

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

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

Подтверждаю,строил и поддерживаю инфраструктуру на докере. Пришлось перелопатить абсолютно всю документацию и форумы. Знать надо много и хоть и есть прекрасные оркестраторы. Я пользуюсь Rancher, но консолью много нетривиального приходилось решать

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

я же написал, что моки используются, читай внимательно.

так замокать надо не когда что-то пошло не так, а на этапе работы над тестами

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

)) , не, я тут один русско/украиноязычный

Есть неудобности с тем, что нужно все или большую часть сервисов нужно включать и держать запущеными локально или при дебаге
Там нижче вже написали. Стаби на кожну інтеграцію + спрінг профілі все вирішують без проблем.

Мы создавали проект на микросервисной архитектуре — мое впечатление. Легко маштабировать, сложно поддерживать и отлаживать и страдает общий перформанс, по сравнение с монолитными приложением. Ну и подержу старика Фаулера, когда он говорил, что если ваше монолитное приложение не имеет четко выделенных модулей, то и не фиг лезть в этим в микросервисы — они вам не помогут, получите это habrastorage.org/...e23e02db893eaad6ee760.jpg

в чем были сложности поддержки?

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

в логи все пишется и потом тулзы на питоне что бы в ручную не лопатить

в логи все пишется
Самая стандартная ситуация — в логах ресивера сетевой таймаут, в логах сендера — ничего.
И?

есть мысли прикрутить zipkin чтоб решать проблемы трасировки, посмотрим как пойдет

@Vitaliy Marenkov примерно ответил и одним постом сложно описать все ситуация.
1. Одна из проблем в поддержке в том, что команда у заказчика была довольно низко квалифированная.
2. Второе — перед развитием микросервисов нужно хорошо подумать доменную область и уделить ей очень большой кусок планирования, потому что часто между сервисами вы пересываете один и теже обьекты и просто мапите их из одного в другой и обратно.
3. Сложности отладки уже упомянули ниже — ты начинаешь искать проблему и находишь, что в корневом сервисе кто-то переписал таким образом, что в логер ничего не пишется, а этом аффектит все сервисы по цепочке.

Да и вообще чего там много шума — SOA как концепиция модульной разработки появилась в 70x:))

первые 2 пункта это ж не проблема микросервисов, как архитектуры и подхода =). Да и третий тоже проблема команды, а не подхода.

— И кто сказал, что эти Битлз здорово поют?!.. Гнусавят, картавят, гундосят, заикаются, фальшивят...
— И где же ты так их слушал?
— Мне Рабинович по телефону напел.

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

А по недостаткам уже все описану тут — highscalability.com/...ces-not-a-free-lunch.html или тут — rclayton.silvrback.com/failing-at-microservices

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

Автор просто жирним виділив кого саме він хоче почути, можливо таких просто немає:

Хотелось бы услышать отзывы от тех людей, кто пробовал использование Netflix OSS/Spring Cloud на практике.

Ну этот показывает только что большая часть проектов или легаси или моноблоки с историей.
А те кто пилят свежак — не сильно разговорчивы :)

ну java как следует закоболилась за последние годы, если нет JSF и GWT народ уже пляшет, а вы сервисы....
Вообще я в прошлом году делал с нуля мобильный банкинг но там было в лоб — cxf и обтесаный монолит от интернет банка.

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

Честно говоря, аналоги по микросервисам от других компаний я не пробовал, по этому ничего по ним сказать не могу, но вот интересно что сами Netflix говорят что они начинают отказываться от частей OSS (например от Ribbon-а).

Ribbon comprises of multiple components some of which are used in production internally and some of which were replaced by non-OSS solutions over time. This is because Netflix started moving into a more componentized architecture for RPC with a focus on single-responsibility modules.
...
Our team has instead started building an RPC solution on top of gRPC. We are doing this transition for two main reasons: multi-language support and better extensibility/composability through request interceptors. That’s our current plan moving forward.
Так что может выкатят какие-то совершенно новые решения как новые части OSS в будущем

У нас Netflix/Spring Cloud стек. впечатления положительные и, если делаешь с нуля — правильный выбор. Распилить существующий проект уже не так просто.
Та часть, которая на микросервисах, у нас еще не в проде, но разработка и тестирование нравятся
П.с. по схеме в топике — непонятно нафига Риббон и Хистрикс сделаны частями account, notification и statistic сервисов, если это клиентские библиотеки, а сервисы эти, судя по схеме, никакие другие сервисы не вызывают. В общем схема эта вводит в заблуждение того, кто не особо знаком с нетфликс стеком

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

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

у меня к сожалению дата леер такого размера что пилить оооочень не комфортно
5K+ таблиц
Клауды пока вообще мимо. Кое кто Oracle DataGrid использует например как сторедж

Ну да, такой энтерпрайз монстр так просто не распилишь )
клауд имел ввиду spring cloud, а так у нас давно AWS. Стартап )

хорошо вам )
у нас же даже введение java 8 это Big Deal
при чем новые фичи будут под запретом лол

сочувствую. в стартапах с этим конечно попроще

А можете рассказать про ваш стек технологий? И что из Netflix используйте?

основное приложение — ничего особенного. Монолит, спринг, MySQL, MongoDB. То, что на основе микросервис архитектуры — Spring Config, Eureka, Feign, Hystrix, Ribbon, надо бы еще какой-нить Zipkin прикрутить. + Там же Spring Integration, Kafka, Mongo.

Жертвы реляционной модели. Сочуствую.

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

патчинг на лету ... Как много в этом слове
имел несчастье поработать с проектом на osgi
ну вот такое можно только врагам посоветовать, количество подводных камней такое что аж страшно

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

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

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

глупости. Плюсы совсем не в развертывании а в легкой замене частей, вплоть до переписывания с нуля на другом языке, горизонтальном масштабировании только частей, а не всего приложения, легкой организации polyglot persistence, дальнейшем развитии single responsibility principle, дополнительной защите от падения серверов, упрощении разработки приложения несколькими командами, упрощении (!) тестированния и тп и тд.

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

Это как ? Часть приложения давайте напишем на паскале, часть на джаве, часть на бейсике, а часть на питоне ? Отличное приимущество для какого-нибудь стартапа.

упрощении разработки приложения несколькими командами, упрощении (!)

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

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

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

Это как ? Часть приложения давайте напишем на паскале, часть на джаве, часть на бейсике, а часть на питоне ? Отличное приимущество для какого-нибудь стартапа.
вполне себе нормальное требование. Например, где-то нужна скорость разработки, а в каком-то другом куске — перфоманс. Будешь писать на одном и том же языке? Или вот тебе кейс из моего проекта. Мы в клауде на линуксах, основной язык — джава. Один из клиентов попросил слать ивенты в его систему, которая на виндоус стеке, еще и довольно старая, давно не меняется и единственный способ туда что-то отправить — запихнуть в их MSMQ.. Если не знаешь, msmq работает только на виндовых машинах и интегрирована с .net -ом , а вот с джавой все много хуже. Есть аж одна рабочая либа, последний коммит (т.ч. и багфикса) в репо которой был несколько лет назад. Логичный выход — виндовая машина с .net микросервисом, который пихает данные в msmq. Не?

Деление приложения на крупные компоненты на разных языках вроде SQL, Шарп, Джава, Си, Джаваскрипт и тд это нормально. Но это не имеет никакого отношения к микросервисам.

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

Смешались люди кони.
Еще раз, вы привели невалидный пример
Если перед разработчиком стоит задача внедрить

MSMQ

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

У меня самого связка С\С++ несколько компонент, Дот Нет несколько компонент, MS SQL, ASP.NET, Днипра, но они пилятся не как микросервисы а как отдельные компоненты которые интегрированы через вебсервисы.
Это SOA.

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

Можете объяснить, чем по вашему мнению отличаются микросервисы от SOA? Вы пытаетесь провести границу, но с ходу не очевидно

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

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

Микросервис — разделяем компоненты если это вообще возможно.
Таким образом плодится множество мелких сервисов, которые вроде бы могли жить и в монолите, но теперь все шарят всех.

Микросервис — разделяем компоненты если это вообще возможно.
кто это сказал то?

Мне кажется вы не совсем правильно понимаете слово "микро" в данном контекте. (Это как компьютеры и микро-компьютеры. Наши персональные компьютеры - это и есть микро-компьютеры из 80-х.)

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

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

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

Мне кажется вы не совсем поняли мысль и идею микросервисов. Конечно же такого понятия как Одна машина = Один микросервис нет. На одном сервере их может крутится десятками. Если в Netflix 600 микросервисов, то это абсолютно не означает что там 600 серверов, это конечноже бред. Само по себе деление «микро» подразумевает логическое деление компонент. При этом оно происходит настолько часто, что появляются дополнительные проблемы. Например появляется координатор. В обычном SOA он не нужен, можно прописать эндпоинты в конфигах напрямую. Появляются дополнительные проблемы с отладкой, появляются целые компоненты по логированию, хотя опять же в обычной экосистеме SOA они могут быть намного проще.

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

Вам стоит внимательней изучить материалы, в том числе тот пример который Вы запостили в первом своем посте.

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

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

Как-то уж совсем глубоко теоретически кмк.

Например, сдох у тебя какой-нить рекомендейшен сервис
Нет уж — давайте возьмем какой-нить мандатори сервис. Где вся инфраструктура остановилась и ждет его.
балансер с брейкером найдут другой рабочий из списка зарегестрированных
Т.е. при проектировании уже должна быть заложена реданданси на все микросервисы? Стэйтфул?
Кстати балансер тоже вполне себе сервис и вполне себе дохнет.
Или вообще ничего рекомендовать не будут
Это какой-то ну очень притянутый и уникальный случай. Для него все красиво, спору нет. Но только для него.
Мне же, наоборот, больше приходят в голову приложения, где от разбивки монолита страдает все, т.к. взаимодействие перемещается из микросекундной памяти в миллисекундный ввод-вывод с нахлобученной моделью OSI сверху, точки отказа в железе умножаются на 5, а дебаг начинает требовать серверного и сетевого (а иногда и SAN) админов за плечами.
А можно ли назвать самодостаточные по производительности блоки микросервисами — я не уверен.
Нет уж — давайте возьмем какой-нить мандатори сервис. Где вся инфраструктура остановилась и ждет его.
мандатори сервис логично запустить в несколько инстансов на разных серверах, чтоб когда дохнут одни, другие (или хотя-бы один) инстансы оставались живы и выполняли задачи.
Т.е. при проектировании уже должна быть заложена реданданси на все микросервисы? Стэйтфул?Кстати балансер тоже вполне себе сервис и вполне себе дохнет.
Заполняем пробелы в знаниях и читаем как выполняется балансировка в микросервис архитектуре (хинт: клиентская балансировка, в разрезе темы этого топика читаем о Ribbon-e)
....Мне же, наоборот, больше приходят в голову приложения, где от разбивки монолита страдает все....
У Netflix -а сотни микросервисов (я точно не помню цифру, но вроде как на одном из докладов звучала цифра около 600 + (!) ) . Очень много других компаний тоже начинают переходить к этому решению, видя плюсы (для больших систем конечно). Но то такэ
Заполняем пробелы в знаниях и читаем как выполняется балансировка в микросервис архитектуре

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

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

У Netflix -а сотни микросервисов (я точно не помню цифру, но вроде как на одном из докладов звучала цифра около 600 + (!)

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

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

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

Ви оце зараз описали теорію чи практику? Я сам теоретик в цьому плані, прочитана мною інфа говорить рівно протилежне:
— «несогласованность версий» — ви про що? Про те, що один сервіс залежить від іншого, а тому благололучно падають обидва? Тоді у вас не мікросервіси, а моноліт;
— дебаг у мікросервісів відмінний, бо чим краща ізольованість, тим швидше можна виявити неполадку завдяки модульним тестам.

“несогласованность версий” — ви про що? Про те, що один сервіс залежить від іншого, а тому благололучно падають обидва? Тоді у вас не мікросервіси, а моноліт;

Ну микросервисы не строятся по принципу Shared Nothing. Они друг от друга часто зависят и версии могут разойтись. А дальше

дебаг у мікросервісів відмінний

Скорей не дебаг, я логирование о чем прийдется отдельно позаботится.


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

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

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

В джава мире все както слишком просто. Вверху торчит пример студенческой бухгалтерии в котором уже участвуют с 10 «нужных» фреймворков. Неужели все действительно так нужно.

вообще не понял о чем комментарий...

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

Подписаться на комментарии