Микросервисы на .net — оптимальный протокол «общения»?

Есть всего 2 базовых принципа сообщения:
1. Влияние на систему (действие). Это API. Как правило json REST
2. Реакция системы на действие (так же используется как низкая связанность). Это очереди сообщений.

В целом все зависит от юзкейса и нет общего универсального протокола. Много разных архитектур и все хороши по-своему. Лично я использую везде REST API и после любого (успешного и нет) вызова отправляю в ESB сообщение. Если мне нужно влиять на другую подсистему (например, после принятия заказа отправить его в отдел продаж для подтверждения) то я использую Consumer для отправки в другое api.

Лично я по опыту такую схему использую:
если, согласно бизнес логике, вызов был
1. синхронный - то используется REST запрос, json. Может быть целая цепочка вызовов.
2. асинхронный - то публикация события в шину RabbitMQ. Одно событие может потом порождать цепочку событий.
2.1 бывает первые вызовы идут REST - но потом происходит публикация события и т.д. этот вариант все равно считается асинхронным.

Зависит от того, какого рода "общение" происходит между сервисами.
Для получения данных от других сервисов логично использовать REST.
Если мы говорим о публикации событий, то логично использовать очереди (например, нужно пересчитать агрегаты при обновлении данных).
Если мы говорим про распределенные транзакции, то тут очереди и саги (архитектурный шаблон). Нужен отдельный сервис, который будет координировать шаги транзакций, обрабатывать отказы и т.д.. Советую посмотреть на такой проект для .NET, как MassTransit.
Также стоит продумать над вопросом логирования и трассировки, чтобы можно было получить все логи конкретного пользовательского запроса со всех микросервисов.

"Смешались к кучу люди, кони...."
RabbitMQ и пр. MQ всего лишь посредник. Их задача - удобно доставлять информацию. Что там будет внутри сообщения - другой вопрос.
Заморачиваться едиными правилами/единым форматом для протокола - стоит, да.
В наше время для мелких проектов - скорее JSON, HTTP.
Для крупных проектов лучше что-то более строгое и формализованное Protobuf, XML.
Для документирования OpenAPI/Swagger. И/или специализированные инструменты типа Postman.
Если скорости критичны, то использовать бинарные с предопределенной типизацией.
Если критичная скорость разработки, то использовать текстовые без типизации.

Раньше использовать брокеры сообщений (RabbitMQ, ActiveMQ, NATS, ZeroMQ), в итоге пришел к общению посредством ServiceDiscovery.
Т.е. в сети есть сервис который хранит таблицу адресов других сервисов и периодически ее раздает. Плюс проходит по таблице и пингует не пропал ли какой сервис из доступа. Остальные сервисы общаются друг с другом напрямую, получая адрес нужного сервиса из таблицы. При этом, если запущено несколько одинаковых сервисов, то передача данных им идет через round-roobin балансировку (конечно это для stateless сервисов, если есть состояние придется усложнить алгоритм общения).
Транспорт может быть любой, использую REST или протокол поверх TCP как более быстрый вариант.