index0h: Подведу итог - вы считаете, что хранение сервисов в отдельных репозиториях необходимо для пресечения желаения программиста вызвать метод рядомстоящего класса/модуля из другого микросервиса в обход условленного транспорта?
P.S.: не воспринимайте так буквально фразу "заниматься бизнесом")) я должен был написать "заниматься имплементацией бизнес-логики".
index0h: Кстати, я не обратил внимания - вы сказали, что лучше хранить все микросервисы в отдельных репозиториях, но кроме сообщения о сильносвязанной системе ничего более не сказали. Поделитесь мыслями - почему вам было бы удобнее так работать, какие преимущества вы получили бы при таком подходе?
index0h: Из жтого вытекает вопрос - как хранить контракты между сервисами? И, как мне кажется, это было бы просто делать, если бы все сервисы находились в одном репозитории и использовали одни и те же "базовые" модели или одно единое описание контракта.
В этом случае ошибки были бы видны минимум на этапе изменения контракта, и максимум - на при мердже изменений другого разработчика.
Может быть тогда не стоит называть это микросервисами, а просто называть эту систему распределенной?
sim3x: согласен. однако у нас используется строгий workflow работы с GIT, при котором мердж не является проблемой, а все задачи аккуратно разбиваются на более мелкие, что исключает возмодные проблемы при мердже. Масло маслянное, но думаю мысль донес))
по поводу кол-ва связей - сложно сказать, что 100 - немного. Я подумаю и отвечу позже. А про QA - тоже согласен, только в ближайший год о них думать не стоит. Хотя даже если и стоит, и если их возбмут на работу пачками прямо завтра - все равно эта проблема не уйдет. Она просто перейдет от нашего отдела с их отделу. Тоже некрасиво
index0h: Или вот еще пример: Так как мы аггрегируем информацию с разных сторонных сервисов, но по одной и той же тематике (например изображения с раличных сайтов), то для нас имеет смысл каким либо образом формализовать сущности, которые используются в нашей системе (Например, сущность изображения). Мы формализовали ее, и теперь внутри каждого сервиса у нас происходит все так, как необходимо этому микросервису, а снаружи все обмениваются одной и той же формализованной (формализированной?) информацией. И все хорошо...
Пока мы не поняли, что наша формализованная сущность нуждается в изменении. В этом случае все сервисы должны быть изменены таким образом, что бы отдавать информацию в новом виде. Это проблемно, но если бы все сервисы находились бы в одном репозитории, все было бы проще - изменил модель, от которой все наследуются - и все готово.
Получается, что можно писать приложение как монолит, но запускать по-частям. Как например при работе с Gevent в Python (код пишется как обычный последовательный, но выполняется параллельно)
index0h: Главное неудобство, как мне кажется, в том, что при изменении некоторого сервиса одним разработчиком, другой не сразу узнает об этом (я работаю в VIM, а некоторые из коллег в PyCharm).
И соответсвенно, если я изменил сервис X, коллега изменил сервис Z (Z и X друг с другом каким то образом сообщаются), так, что они вместе не будет работать, то узнаем мы о проблеме только после того, как CI прогонит тесты (если ни вообще покрывают тот случай).
index0h: На данный момент транспорт и протокол зафиксированы между всеми сервисами. В CI билд каждого сервиа является шаблоном, по которому сибираются все они. Все они так же в случае успешной сборки и успешно пройденных интеграционных тестов отправляются на целевые сервера (в зависимости от того, какой релиз собрался - на staging, production или dev сервера).
Я не думаю о микросервисах как о SOA (тега microservices здесь почему-то нет)
Так же сейчас есть отдельный репозиторий, где хранятся ansible плейбуки и прочие provision скрипты
Так же каждый микросервис может работать (настолько, насколько это возможно) без других сервисов, от которых от зависит (это не совсем так, но к этому все идет - примем как данное)
С другой стороны есть задача - поддержание работоспособности всех сервисов в какой-то общей версии продукта. Сейчас это достигается путем соглашения о именовании веток. Например, если мы выпускаем релиз с номером "10", то в каждом проекте должена присутствовать ветка с названием release-10. И если у нас будет 100 сервисов, то необходимо будет проделывать много пустой работы с каждым сервисом
К тому же, для каждого сервиса необходимы свои тесты и билд процедуры на CI сервере. Если мы считаем, что сервисы должны быть в различных репозиториях - необходимо для каждого микросервиса создавать свою билд процедуру, которая будет его собирать. Это впролне логично, если мы пытаемся просто сделать сборку сервиса и запустить юнит тесты, но что если нам необходимо для каждого сервиса запустить интеграционные тесты? В жтом случае необходимо будет для каждого микросервиса прописывать зависимости от других микросервисов, которые необхоимы для тестирования текушего.
QML как я понимаю описываем именно интерфейс в декларативном стиле, предоставляя возможность на объекты созданного интерфейса вешать какие то обработчики уже из кода программы? И вся красота, которая требуется дизайнерами описывается как раз на QML? Соответсвенно я могу написать на QML (он показался мне элементарнейшим и довольно удобным) красочно-фантастический интерфейс на основе дизайна от художника, и к нему на любом языке написать какие то обработчики событий и все будет работать?
А если у меня есть одна программа, которая может работать в нескольких инстансах, но обрабатывать разные массивы данных или рабоатть на разных портах - я не могу никак это отметить?
Логично. Однако как быть в случае, если программист не использует в разработке node.js и фулл-стек фреймворки? Что если проект написан на Python, PHP, Erlang, или другом ЯП и своим фреймворком?
Нужна тулза именно для валидации. Хочу объявить какие поля какого типа, какие валидаторы у поля, какие дефолтные значения принимает поле и т. д. Какие варианты под эту задачу?
P.S.: не воспринимайте так буквально фразу "заниматься бизнесом")) я должен был написать "заниматься имплементацией бизнес-логики".