Как хранить исходный код микросервисов?

Question

[kazhuravlev]

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

• Имеется проект по интеграции большого кол-ва сторонних сервисов.
  
• В архитектуре проекта заложен удобный механизм создания микросервиса на каждый сторонний проект, с которым мы интегрируемся.
  
• На данный момент имеется 20 микросервисов
  
• Планируемое кол-во микросервисов к концу года - 100
  
• Создание микросервиса на каждую интеграцию оправдано
  
• Исходный код каждого микросервиса хранится в отдельном GIT репозитории
  
• Есть несколько микрсервисов, которые являются вспомогательными для всей системы (нормализаторы, поисковый механизм, веб морда, etc)
  
• Каждый микросервис для интеграции с внешней системой является частью нашего проекта и не может функционировать вне проекта
  

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

Answer 1

[index0h]

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

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

Comments

[kazhuravlev]

С другой стороны есть задача - поддержание работоспособности всех сервисов в какой-то общей версии продукта. Сейчас это достигается путем соглашения о именовании веток. Например, если мы выпускаем релиз с номером "10", то в каждом проекте должена присутствовать ветка с названием release-10. И если у нас будет 100 сервисов, то необходимо будет проделывать много пустой работы с каждым сервисом

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

[index0h]

Не думайте о микросервисах, как о SOA))

Инструкции для CI вполне можно хранить в заранее оговоренном виде, например как у того же travis: .travis.yml
> В жтом случае необходимо будет для каждого микросервиса прописывать зависимости от других микросервисов, которые необхоимы для тестирования текушего.
Тут - только эмуляторы, на основании спецификации. В отличии от SOA тут нет понятия "я работаю с сервисом А", вместо этого "я пытаюсь работать по спецификации с неизвестным сервисом". Подход микросервисов предполагает, что связанные с ними могут в любой момент отвалиться по любым причинам.

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

[kazhuravlev]

index0h: На данный момент транспорт и протокол зафиксированы между всеми сервисами. В CI билд каждого сервиа является шаблоном, по которому сибираются все они. Все они так же в случае успешной сборки и успешно пройденных интеграционных тестов отправляются на целевые сервера (в зависимости от того, какой релиз собрался - на staging, production или dev сервера).

Я не думаю о микросервисах как о SOA (тега microservices здесь почему-то нет)

Так же сейчас есть отдельный репозиторий, где хранятся ansible плейбуки и прочие provision скрипты

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

[kazhuravlev]

index0h: Главное неудобство, как мне кажется, в том, что при изменении некоторого сервиса одним разработчиком, другой не сразу узнает об этом (я работаю в VIM, а некоторые из коллег в PyCharm).

И соответсвенно, если я изменил сервис X, коллега изменил сервис Z (Z и X друг с другом каким то образом сообщаются), так, что они вместе не будет работать, то узнаем мы о проблеме только после того, как CI прогонит тесты (если ни вообще покрывают тот случай).

[kazhuravlev]

index0h: Или вот еще пример: Так как мы аггрегируем информацию с разных сторонных сервисов, но по одной и той же тематике (например изображения с раличных сайтов), то для нас имеет смысл каким либо образом формализовать сущности, которые используются в нашей системе (Например, сущность изображения). Мы формализовали ее, и теперь внутри каждого сервиса у нас происходит все так, как необходимо этому микросервису, а снаружи все обмениваются одной и той же формализованной (формализированной?) информацией. И все хорошо...

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

Получается, что можно писать приложение как монолит, но запускать по-частям. Как например при работе с Gevent в Python (код пишется как обычный последовательный, но выполняется параллельно)

[index0h]

kazhuravlev увы, от этого вы не сможете застраховаться.
Все изменения должны быть задекларированы в спецификациях API каждого из сервисов. Если X перешел на новую версию API, а Z с ней работать не умеет - в интеграционных тестах смысла нет потому как контракт у вас выполняться не будет в любом случае.

Если это ошибки в имплементации API одного из сервисов - это должно вылезти в тестах этого же сервиса.

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

Безусловно есть очень большой минус в данном подходе: 7-меро одного таки ждут.

[kazhuravlev]

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

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

Может быть тогда не стоит называть это микросервисами, а просто называть эту систему распределенной?

[kazhuravlev]

index0h: Вобще неважно как это называть, лишь бы разработчики могли сосредоточиться на бизнесе а не на выравнивании контрактов и интерфейсов

[index0h]

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

[kazhuravlev]

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

[index0h]

@kazhuravlev
> лишь бы разработчики могли сосредоточиться на бизнесе а не на выравнивании контрактов и интерфейсов
))) Разработчики не занимаются бизнесом, а имплементируют бизнес логику. Контракты и интерфейсы нужно выдерживать в любом случае, иначе система будет вести себя не предсказуемо.
Еще раз: один репозиторий вас ни капли не спасет.
Как пример функция login($login, $pass): я залью туда "" и ресурс, что произойдет? По хорошему я должен словить исключение, и это будет контрактом.

Поймите, один репозиторий - вас рано, или поздно приведет к монолиту, что бы вы не делали. И в один прекрасный момент при заливке только сервиса Х вы будете обязаны заливать всю систему, со всеми вытекающими.

[kazhuravlev]

index0h: Подведу итог - вы считаете, что хранение сервисов в отдельных репозиториях необходимо для пресечения желаения программиста вызвать метод рядомстоящего класса/модуля из другого микросервиса в обход условленного транспорта?

P.S.: не воспринимайте так буквально фразу "заниматься бизнесом")) я должен был написать "заниматься имплементацией бизнес-логики".

[index0h]

> Поделитесь мыслями - почему вам было бы удобнее так работать, какие преимущества вы получили бы при таком подходе?
Многие из системы предрасположены к репликации. Например: почтовые рассылки (Z). В случае повышения нагрузки не составит труда поднять еще несколько нод под это дело. При этом даже в случае, если X ведет себя не корректно - Z будет работать корректно.

Пример из жизни: есть задача по вытягиванию платежных данных пользователя и отправки их партнерам. Я использовал один из классов соседней подсистемы, которая это дело умеет. Но как результат - не работает. Оказалось, что этот класс оставлен только для обратной совместимости и более не используется. В случае разделения на сервисы подобная ситуация невозможна, потому как спецификация API обязана быть, как документ.

Основной плюс подобного подхода - это независимая разработка сервисов. Например фронт сайты требуют что бы быстро (на вчера), красиво, ну и качество так себе. Сервис платежей разрабатывается в более медленном темпе и должна быть: безопасной, 100 раз перепроверенной. Сервис чатов живет тоже в своем темпе, он не на столько безопасен, как платежи, но должен выдерживать огромную нагрузку.

Так же плюсом является то, что каждый из сервисов определяет свои собственные требования к окружению. Например фронт сайтики - вполне ок на php, тяп-ляп и в продакшн. Платежи - ява. Чаты - нода, или erlang. Чатонить специфическое, например тегирование пользователей - можно на golang.

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

[index0h]

kazhuravlev
> Подведу итог - вы считаете, что хранение серв....
Это одна из причин.

> P.S.: не воспринимайте так буквально фразу...
)))

Answer 2

[sim3x]

разнести по разным репам
использовать штатные механизмы ЯП для установки и работы с кодом (pip, rvm, composer, ...)

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

пока количество связей не гигантское ~100 - изолировать комбинации сервисов и тестировать отдельно.
Когда перевалит за сотню - стоит взять пару QA и поручить им приемочное (функциональное) тестирование всего комплекса

Comments

[kazhuravlev]

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

[sim3x]

kazhuravlev: только кажется

когда кто-то будет мерджить 100+ веток в один репозиторий... вот тогда ему перестанет казаться

[kazhuravlev]

sim3x: согласен. однако у нас используется строгий workflow работы с GIT, при котором мердж не является проблемой, а все задачи аккуратно разбиваются на более мелкие, что исключает возмодные проблемы при мердже. Масло маслянное, но думаю мысль донес))

по поводу кол-ва связей - сложно сказать, что 100 - немного. Я подумаю и отвечу позже. А про QA - тоже согласен, только в ближайший год о них думать не стоит. Хотя даже если и стоит, и если их возбмут на работу пачками прямо завтра - все равно эта проблема не уйдет. Она просто перейдет от нашего отдела с их отделу. Тоже некрасиво