Резюме

В настоящее время большинство системных архитектур представляют собой микросервисные архитектуры.Даже если нет управления реестром и службами, должно быть несколько служб, а одиночных служб меньше. Обычно нам нужно больше вызывать rpc-интерфейс в приложении, поэтому задумывались ли вы когда-нибудь о разнице между вызовом между микросервисами и прямым вызовом в приложении? Вас часто спрашивают о микросервисах на собеседованиях?微服务间的方法调用和应用内方法调用的有啥区别Этот маленький момент, расскажите о моем опыте

Характеристики вызова микросервиса

Начнем с одного приложения

Монолитное приложениеОдноэлементная ссылка напрямую собирает данные через сервисный узел и возвращает их вызывающей стороне. Все вызовы методов происходят внутри приложения.

Приложение микросервиса

Служба сведений о продукте должна вызывать несколько служб, таких как продукты и маркетинг, для сбора данных страницы сведений о продукте.

Разница между вызовом микросервиса и вызовом внутри приложения заключается в том, что он является межпроцессным или даже межузловым.Что это значит?

При использовании k8s для организации микросервисов мы можем размещать разные сервисы в разных док-контейнерах на одном узле, но, учитывая ненадежную сеть и устойчивость к сбоям, Сервисы неизбежно будут размещены на разных узлах/стойках, поэтому следующее будет обсуждаться между узлами.

означает два

зависит от внешнего
Если это межузловой, есть сетевой вызов. Мы знаем, что интернет ненадежен

Существует несколько известных ложных выводов о сетях.

Сеть надежная Задержка равна нулю (задержка может быть равна 0). Пропускная способность бесконечна Сеть безопасна Топология не меняется Транспортные расходы равны нулю (время передачи по сети равно 0) Сеть однородна

Что нам нужно сделать

После того, как вышеупомянутые две проблемы существуют, нам нужно обратить внимание на то, на что нам нужно обратить внимание при написании вызовов методов между микросервисами.

зависит от внешнегоВ дизайне микросервисной архитектуры есть важный принцип, который называется严出宽进, Строгий означает, что вещи, которые вы предоставляете другим службам, должны проверяться максимально строго. Широкий прогресс означает, что нужно быть терпимым при вызове чужих интерфейсов и быть совместимым с различными ситуациями. Например, вам нужно учитывать чужие узлы не работают/тайм-аут API/API недоступен и другие факторы.

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

Кроме того, частота ошибок интерфейса службы, от которой я завишу, очень высока в течение определенного периода времени, а вызывающая сторона все еще отправляет запросы, поэтому всегда будет получать неправильные результаты.В настоящее время эти запросы на самом деле недействительны, поэтому клиент требуется в это время.предохранитель, больше не звоните на сервер, дайте серверу время на восстановление, повторите попытку через некоторое время и снова позвоните, когда будет обнаружено, что сервер доступен.

сетевой вызов

Сетевые вызовы отнимают много времени, поэтому для повторного использования соединений необходимо использовать технологию пулинга, например, в одном приложении нам необходимо подключиться к базе данных, а пул соединений с базой данных будет использоваться для повышения эффективности операций с данными. То же самое верно и для вызовов микросервисов.Мы рекомендуем соединения http/tcp с другими службами, а также необходимо установить пул соединений. Другой сервис может зависеть от нескольких микросервисов, и на подключение к другим сервисам не может повлиять проблема с подключением к сервису, поэтому необходимо сделатьИзоляция пула соединений.

Вызовы между службами могут завершаться сбоем, поэтому нам нужен механизм повторных попыток.Например, из-за проблемы с тайм-аутом, вызванной дрожанием сети, мы можем улучшить доступность API с помощью повторных попыток. Но подумайте о плохой ситуации, действительно есть проблема с сетью или сервером в течение определенного периода времени. Если для тайм-аута клиента задано большое значение, клиент ожидает в течение длительного времени, а затем добавляется механизм повторных попыток, который заполняет соединения клиента и делает API-интерфейсы, связанные с клиентом, недоступными.

несколько случаев

Поделитесь несколькими случаями сбоев при вызовах микросервисов, чтобы помочь вам мыслить сценариями为啥要分享这些案例呢，因为TMD的这些案例都是血的教训，造成线上故障，不是我的错，却要我背锅

Дело 1:

Запущена новая функция продукта, которую нужно продвигать, она размещена в другом модуле продукта с относительно большим трафиком для отображения некоторых данных функций нашего продукта.

По какой-то причине наш сервис имитировал данные вызова rpc, возвращая null. В итоге вся первая полоса других сервисов зависла, зависла и зависла.

Типичная проблема с сильными и слабыми зависимостями, вызывающий объект не имел дело с типом зависимости, очевидно, что это была слабая зависимость, с которой не обращались, и она стала сильной зависимостью, что привело к зависанию функции.

Случай 2:

Зависимая служба должна быть основана на первичном ключе.List<id>Чтобы выполнить пакетный запрос, полагайтесь на службу для разделения подтаблиц подбазы данных, обновите SDK Выполните маршрутизацию таблицы в предоставленном клиенте sdk и разделите идентификатор пакета на N вызовов rpc. Это делается для того, чтобы пакетные запросы не разорвали пул соединений с базой данных.

сетевой вызов игнорируется

Случай 3Другие называют интерфейс нашего сервиса, этот интерфейс RT (длительный) P95 Глядя на мониторинг сервера, время возврата интерфейса нормальное, и на сервере нет никаких отклонений.

Тайм-аут установлен неправильно

Суммировать

Между вызовами микросервисов и вызовами внутри приложения существует большая разница. Мы не можем игнорировать вызовы между сервисами. Нам нужно знать проблемы, с которыми он сталкивается.

Зависимый от внешнего, внешний ненадежен
С сетевыми звонками

Решение можно преобразовать в 4

В соответствии с потребностями бизнеса определите тип зависимости и выполните соответствующий переход на более раннюю версию.
Установите разумный тайм-аут
Вызывающему абоненту необходимо установить изоляцию пула соединений для различных вызовов службы.
У вызывающего абонента должен быть автоматический выключатель

Эти проблемы кажутся очень простыми, но, по моему наблюдению, действительно много людей написали бесчисленное количество вызовов rpc, не осознавая этих проблем.

Обратите внимание на [Храм аббата] и начните путь технической практики с аббатом.