Pull to refresh

Comments 16

Рекомендация 7. Не юзайте микросервисы, если у Вас общий код.

Кстати по поводу хелперов общих и самописных. На работе столкнулся с тем что в двух проектах использовались разные библиотеки для работы с JSON. Одна принимала JSON начинающийся как с массива [...], так и с объекта {...}, а другая только с объекта. В итоге пришлось делать на стыке костыль с упаковкой массива в объект перед передачей, а затем распаковывать его на принимающей стороне. Но там были не микросервисы, а два монолита которые решили интегрировать.

Рекомендация 1: Очень желательно, чтобы общего кода у микросервисов не было вообще.

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


Если есть два сервиса на одном языке использующих один источник данных: у вас в любом случае будет общий код для доступа к этому источнику данных.
Банальный пример: Java-сервисы работающие с очередями. У них будет как миниум библиотека JMS, а то и какая-нибудь обёртка над ней, например в виде Spring JMS.

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

Чем кастомный код отличается от стандартных библиотек кроме авторства?

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

Общие библиотеки / пакеты же
А, то есть статью кратко можно переписать так: «Разрабатывая микросервисы делайте нормальную архитектуру»?
Очень важные советы на самом деле. Это не так сложно, но чаще всего из-за отсутствия нормальных границ и возникают проблемы с SOA. печально что в топе популярности и в принципе на виде оказываются не полезные статьи, а «дерзкие» и «хайповые».

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

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

Гораздо большему количеству проектов не нужны микросервисы.
1. Монорепо — отдельный сложный вопрос, я про это не писал вообще, и монорепо — это не есть «общий код» в моём понимании (если это «правильный» монорепо, в котором сервисы лежат все отдельно);
2. По поводу монорепо и гугл — очень популярный вопрос, стоит начать отсюда: habr.com/ru/post/450230
3. «тащим» из опыта, обобщения статей и книг (ну например, www.amazon.co.uk/Building-Microservices-Sam-Newman/dp/1491950358), это всё не я выдумал, я лишь суммировал, как я это понимаю, после того, как не раз проверил на опыте.
Рекомендация 1: Очень желательно, чтобы общего кода у микросервисов не было вообще.

Это несколько странная рекомендация. Самый банальный пример — единая библиотека для RPC и трейсинга запросов.

да, поэтому это скорее идеальный случай, читайте Рекомендацию 2
Sign up to leave a comment.

Articles