Pull to refresh

Comments 10

С этим полностью согласен
После написания основной части кода приступаем к документации сервиса, ибо это самая важная часть — нет документации, нет сервиса.


Ну и немного юмора
image
У меня есть конкретный вопрос, который из статьи в статью обходится стороной или упоминается вскользь. Что используется в качестве транспорта для общения между сервисами? Ведь архитектура подразумевает наличие множество добавляемых инстансов? Единственно что слышал — RabbitMQ. Но он не очень-то подходит для этого. Есть ли мейнстримовые решения по интересней?
Сервисы между собой общаются по http, никкакой специальной инфрастуктуры, пока, для этого не поднято. Пишем максимально автономные сервисы, чтобы было как можно меньше связей между ними.

Как меняете протокол взаимодействия? Версионность? Он один для всех?

Версионность это боль, нет версионности — нет боли). Взаимодействуют по http стандартными POST и GET запросами. Есть в планах попробовать grpc.

Что если потребуется поменять api, сделав его несовместимым, а при этом старый api уже используется 10 другими сервисами, и у команд, разрабатывающих их, обновление совместимости с вашим api не в приоритете задач??

Если какой-то метод в апи нужно сделать несовместимым, то можно оставть старый метод и создать новый. Новые клиенты будут пользоваться новым, старые старым.

Мне кажется, что либо микро, либо автономные.

Sign up to leave a comment.

Articles