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

anonymous 13.06.2016 22:07

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

Відповісти

Підтримати

Дмитрий Вежнин 13.06.2016 22:53

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

Відповісти

Підтримати

anonymous

anonymous 13.06.2016 23:51

Все зависит от ваших нужд, как и всегда.
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 извращенцев кто делал бы очереди на монге.

Відповісти

Підтримати

Дмитрий Вежнин

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 08.06.2016 20:39

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

Відповісти

Підтримати

Дмитрий Вежнин 10.06.2016 18:52

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

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

Відповісти

Підтримати

Włodzimierz Rożkow

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 11.06.2016 22:43

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 підтримується активно.

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

Відповісти

Підтримати

Дмитрий Вежнин

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 12.06.2016 00:28

Проблемы с дебагом были? И как их решали?

Головне що забув додати — незручно моніторити логи одночасно з декількох задеплоєних сервісів. SaaS рішення яке ми використовуємо дає сильну затримку і там поганий UI, в результаті доводиться повторювати раз за разом мантру ssh [email protected]; docker ps; docker logs -f iddqd; одночасно в декількох терміналах і потім дивитися що там відбувається.
Оце реальна проблема і я ще не добрався до її рішення.

Відповісти

Підтримати

Дмитрий Вежнин

Alex Borysov Software Professional в Google 12.06.2016 02:06

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

Відповісти

Підтримати

Włodzimierz Rożkow

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 12.06.2016 11:45

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

Відповісти

Підтримати

Alex Borysov

Mykola Gurov тролль 12.06.2016 17:30

docker logs -f iddqd;

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

Відповісти

Підтримати

Włodzimierz Rożkow

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 12.06.2016 18:56

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

Відповісти

Підтримати

Mykola Gurov

Конь в Пальто 12.06.2016 21:29

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

Відповісти

Підтримати

Włodzimierz Rożkow

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 13.06.2016 13:58

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

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

Відповісти

Підтримати

Дмитрий Вежнин

Дмитрий Вежнин 13.06.2016 16:40

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

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

Відповісти

Підтримати

Włodzimierz Rożkow

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 13.06.2016 16:42

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

Відповісти

Підтримати

Дмитрий Вежнин

Дмитрий Вежнин 13.06.2016 16:54

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

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

Відповісти

Підтримати

Włodzimierz Rożkow

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 13.06.2016 16:56

Ну, шарить DB-сущности тоже не вариант.

В нас один і той самий клас часто використовується і для мапінгу в базу і для видачі клієнту (з відповідними @JsonView).

коммуникации идут не только с java-сервисами

This. Такого не так багато правда.

Відповісти

Підтримати

Дмитрий Вежнин

Alexey Vasiliev Software Architect в Railsware 08.06.2016 12:46

Коментар порушує правила спільноти і видалений модераторами.

Alexey Vasiliev Software Architect в Railsware 08.06.2016 12:46

martinfowler.com/bliki/MonolithFirst.html

Відповісти

Підтримати

Nikita Galkin GDE, Fractional CTO/Principal Engineer, Node.js Tech Speaker 08.06.2016 12:29

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

Відповісти

Підтримати

Дмитрий Вежнин 10.06.2016 18:57

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

Відповісти

Підтримати

Nikita Galkin

Nikita Galkin GDE, Fractional CTO/Principal Engineer, Node.js Tech Speaker 10.06.2016 19:24

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

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

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

Відповісти

Підтримати

Дмитрий Вежнин

Sergey Solution Architect 08.06.2016 12:26

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

Відповісти

Підтримати

Дмитрий Вежнин 08.06.2016 12:47

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

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

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

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

Відповісти

Підтримати

Sergey

Sergey Solution Architect 08.06.2016 13:29

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

Відповісти

Підтримати

Дмитрий Вежнин

Artem Astafyev Solution Architect в DataArt 08.06.2016 14:19

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

«вау, давайте заюзаем воон ту крутую технологию»

Когда я пришел в этот проект, то увидел все вышеперечисленные проблемы. Теперь приходится сливать сервисы обратно :)

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

То что вы написали, как раз обеспечивает Spring Core :) И для этого совершенно необязательно выносить взаимодействие сервисов из JVM на уровень HTTP или JMS.

Відповісти

Підтримати

Sergey

Дмитрий Вежнин 08.06.2016 16:57

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

Відповісти

Підтримати

Artem Astafyev

Sergey Solution Architect 08.06.2016 17:17

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

Відповісти

Підтримати

Дмитрий Вежнин

Нестор Иванович 08.06.2016 23:15

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

Відповісти

Підтримати

Sergey

Alex L 08.06.2016 09:38

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

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

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

Відповісти

Підтримати

Yevhenii Dehtiar E-commerce Consultant, Software Engineer 08.06.2016 13:11

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

Відповісти

Підтримати

Alex L

Vasya Pupking 08.06.2016 20:14

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

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

Відповісти

Підтримати

Alex L

Alex L 09.06.2016 00:03

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 09.06.2016 00:18

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

Відповісти

Підтримати

Alex L

Alex L 09.06.2016 00:27

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 09.06.2016 00:36

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

Відповісти

Підтримати

Alex L

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 08.06.2016 20:41

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

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

Відповісти

Підтримати

Alex L

Valentyn Ponomarenko Працює в Oracle 08.06.2016 03:20

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

Відповісти

Підтримати

Vasya Pupking 08.06.2016 08:13

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

Відповісти

Підтримати

Valentyn Ponomarenko

Vitaliy Marenkov Back-end developer – eTravel S.A. 08.06.2016 12:30

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

Відповісти

Підтримати

Vasya Pupking

Mobile 08.06.2016 13:40

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

Відповісти

Підтримати

Vitaliy Marenkov

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 08.06.2016 16:39

в логи все пишется

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

Відповісти

Підтримати

Mobile

Vasya Pupking 08.06.2016 20:16

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

Відповісти

Підтримати

Vitaliy Marenkov

Valentyn Ponomarenko Працює в Oracle 08.06.2016 17:40

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

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 20:19

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

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

Відповісти

Підтримати

Valentyn Ponomarenko

Valentyn Ponomarenko Працює в Oracle 09.06.2016 05:52

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

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 07.06.2016 23:02

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

Відповісти

Підтримати

Костя Третяк 07.06.2016 23:39

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

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

Відповісти

Підтримати

Vasya Pupking

Конь в Пальто 08.06.2016 00:11

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

Відповісти

Підтримати

Vasya Pupking

Нестор Иванович 08.06.2016 01:00

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

Відповісти

Підтримати

Конь в Пальто

Дмитрий Вежнин 10.06.2016 19:01

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 10.06.2016 20:50

Честно говоря, аналоги по микросервисам от других компаний я не пробовал, по этому ничего по ним сказать не могу, но вот интересно что сами 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 в будущем

Відповісти

Підтримати

Дмитрий Вежнин

Vasya Pupking 07.06.2016 20:23

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

Відповісти

Підтримати

Нестор Иванович 08.06.2016 00:53

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 00:59

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

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 08.06.2016 01:27

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 01:55

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

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 08.06.2016 01:58

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 08:16

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

Відповісти

Підтримати

Нестор Иванович

Дмитрий Вежнин 08.06.2016 11:58

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 20:34

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

Відповісти

Підтримати

Дмитрий Вежнин

DNA Exp 08.06.2016 02:01

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

Відповісти

Підтримати

Нестор Иванович

DNA Exp 08.06.2016 02:00

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

Відповісти

Підтримати

Vasya Pupking

Нестор Иванович 08.06.2016 02:19

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

Відповісти

Підтримати

DNA Exp

DNA Exp 08.06.2016 02:25

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

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 08.06.2016 03:07

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

Відповісти

Підтримати

DNA Exp

Vasya Pupking 08.06.2016 08:17

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

Відповісти

Підтримати

DNA Exp

Vasya Pupking 08.06.2016 08:12

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

Відповісти

Підтримати

DNA Exp

DNA Exp 08.06.2016 09:01

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

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

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

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

Відповісти

Підтримати

Vasya Pupking

Denys Slipetskyy Lead Software Engineer в EPAM 08.06.2016 13:55

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

Відповісти

Підтримати

DNA Exp

DNA Exp 08.06.2016 16:51

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

Відповісти

Підтримати

Denys Slipetskyy

Vasya Pupking 08.06.2016 20:07

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

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

Відповісти

Підтримати

DNA Exp

DNA Exp 08.06.2016 20:44

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 20:48

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

Відповісти

Підтримати

DNA Exp

DNA Exp 08.06.2016 21:21

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

MSMQ

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

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 22:01

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

Відповісти

Підтримати

DNA Exp

Дмитрий Вежнин 08.06.2016 22:03

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

Відповісти

Підтримати

DNA Exp

DNA Exp 08.06.2016 22:18

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

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

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

Відповісти

Підтримати

Дмитрий Вежнин

Vasya Pupking 09.06.2016 00:20

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

кто это сказал то?

Відповісти

Підтримати

DNA Exp

Дмитрий Вежнин 09.06.2016 13:06

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

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

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

Відповісти

Підтримати

DNA Exp

DNA Exp 10.06.2016 19:35

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

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

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

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

Відповісти

Підтримати

Дмитрий Вежнин

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 08.06.2016 16:46

дополнительной защите от падения серверов,

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 20:39

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

Відповісти

Підтримати

Tim Tretyak

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 09.06.2016 19:46

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

Например, сдох у тебя какой-нить рекомендейшен сервис

Нет уж — давайте возьмем какой-нить мандатори сервис. Где вся инфраструктура остановилась и ждет его.

балансер с брейкером найдут другой рабочий из списка зарегестрированных

Т.е. при проектировании уже должна быть заложена реданданси на все микросервисы? Стэйтфул?
Кстати балансер тоже вполне себе сервис и вполне себе дохнет.

Или вообще ничего рекомендовать не будут

Это какой-то ну очень притянутый и уникальный случай. Для него все красиво, спору нет. Но только для него.
Мне же, наоборот, больше приходят в голову приложения, где от разбивки монолита страдает все, т.к. взаимодействие перемещается из микросекундной памяти в миллисекундный ввод-вывод с нахлобученной моделью OSI сверху, точки отказа в железе умножаются на 5, а дебаг начинает требовать серверного и сетевого (а иногда и SAN) админов за плечами.
А можно ли назвать самодостаточные по производительности блоки микросервисами — я не уверен.

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 09.06.2016 21:03

Нет уж — давайте возьмем какой-нить мандатори сервис. Где вся инфраструктура остановилась и ждет его.

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

Т.е. при проектировании уже должна быть заложена реданданси на все микросервисы? Стэйтфул?Кстати балансер тоже вполне себе сервис и вполне себе дохнет.

Заполняем пробелы в знаниях и читаем как выполняется балансировка в микросервис архитектуре (хинт: клиентская балансировка, в разрезе темы этого топика читаем о Ribbon-e)

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

У Netflix -а сотни микросервисов (я точно не помню цифру, но вроде как на одном из докладов звучала цифра около 600 + (!) ) . Очень много других компаний тоже начинают переходить к этому решению, видя плюсы (для больших систем конечно). Но то такэ

Відповісти

Підтримати

Tim Tretyak

Valentin Nechayev уповноважений по милицях в Дарницькі печери 10.06.2016 07:53

Заполняем пробелы в знаниях и читаем как выполняется балансировка в микросервис архитектуре

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

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

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

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 10.06.2016 08:43

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

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

Відповісти

Підтримати

Valentin Nechayev

Костя Третяк 08.06.2016 08:34

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

Відповісти

Підтримати

DNA Exp

DNA Exp 08.06.2016 09:21

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

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

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

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

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

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

Відповісти

Підтримати

Костя Третяк

Vasya Pupking 08.06.2016 20:46

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

эта проблема давно решена

А это не такое простое задание тестировать модульно микросервис. Потому что он настолько мал, что он часть чегото, какогото флоу.

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

Відповісти

Підтримати

DNA Exp

DNA Exp 08.06.2016 21:25

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

Відповісти

Підтримати

Vasya Pupking

Vasya Pupking 08.06.2016 22:02

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

Відповісти

Підтримати

DNA Exp