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