Комментарии 10
Полезная статья!
С этим полностью согласен
Ну и немного юмора
После написания основной части кода приступаем к документации сервиса, ибо это самая важная часть — нет документации, нет сервиса.
Ну и немного юмора
Спасибо за статью! :))
У меня есть конкретный вопрос, который из статьи в статью обходится стороной или упоминается вскользь. Что используется в качестве транспорта для общения между сервисами? Ведь архитектура подразумевает наличие множество добавляемых инстансов? Единственно что слышал — RabbitMQ. Но он не очень-то подходит для этого. Есть ли мейнстримовые решения по интересней?
Сервисы между собой общаются по http, никкакой специальной инфрастуктуры, пока, для этого не поднято. Пишем максимально автономные сервисы, чтобы было как можно меньше связей между ними.
Как меняете протокол взаимодействия? Версионность? Он один для всех?
Версионность это боль, нет версионности — нет боли). Взаимодействуют по http стандартными POST и GET запросами. Есть в планах попробовать grpc.
Что если потребуется поменять api, сделав его несовместимым, а при этом старый api уже используется 10 другими сервисами, и у команд, разрабатывающих их, обновление совместимости с вашим api не в приоритете задач??
Мне кажется, что либо микро, либо автономные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
5 этапов разработки микросервиса