Подавать жалобы
Раньше я выполнял RPC вручную, но недавно связалсяSpringCloud, глубоко опечален. Основные моменты заключаются в следующем:
1) Огромный объем кода, долгое время на поиск багов, сверхсложный дизайн
2) Управление версиями хаотичное, и часто возникают необъяснимые ошибки конфигурации (поэтому 2.0 убит и не решается пойти в производство)
3) Некоторые коды Netflix действительно озадачивают, и они вообще не учитывают масштабируемость.
4) Экологическая цепочка огромна, а стоимость обучения высока.
Учащимся, которые готовятся использовать микросервисы, рекомендуется исправить следующую версию, а не обновлять ее или переходить на более раннюю версию по своему желанию. взять котаbasedirСказать,1.5.8прибыть1.5.13прибыть1.5.16Версии меняются, и если вы не будете осторожны, произойдут несчастные случаи.
server:
port: 21004
context-path: /
tomcat:
basedir: file:.
Как указано выше,basedirпервый из.изменить наfile:., и изfile:.заменить., и нет совместимого кода. Вы хотите убить инженера?
предисловие
Сегодня главная тема обсуждения平滑的上下线功能. Так называемый гладкий, относится к освобождению без восприятия, чтобы не ждать глубокой ночи, чтобы сделать это тайно. Некоторые запросы могут занять больше времени, но не будут отклонены, особенно для платежей, неприятно не тратить деньги, неприятно тратить деньги и ничего не получать. В целом, SpringCloud полностью функционален, и его очень удобно использовать спустя некоторое время.
Наши микросервисы обычно интегрируют следующее.
Ну и огромная экология
проблема
Потом приходит проблема, регистрация SpringCloud в реестре проходит черезRestназывается интерфейс. это не может быть похожеZooKeeperТаким образом, обратная связь от рассматриваемого узла вступает в силу своевременно. не может быть похожеRedisПереходя к тренировке вращения так быстро, это слишком деликатно и страшно, что вращение будет нарушено. Как показано ниже:
1) После отключения экземпляра ServiceA вызов шлюза Zuul не может завершиться ошибкой. 2) После того, как экземпляр ServiceB отключается, вызов Feign ServiceA не может завершиться ошибкой. 3) Сервисы Eureka могут быстро определять, когда сервисы онлайн и оффлайн.
Грубо говоря, одно дело, как сократить время обнаружения Zuul и других зависимых сервисов после того, как сервис отключится, и сделать так, чтобы запрос не провалился в это время.
решить проблемы со временем
Фактор воздействия
1) Проблема с двухуровневым кешем Эврики (что это за хрень)
EurekaServer по умолчанию имеет два кеша, один — ReadWriteMap, а другой — ReadOnlyMap. Когда поставщик услуг регистрирует службу или поддерживает пульс, ReadWriteMap будет изменен. Когда вызывающая служба запрашивает список экземпляров службы, она по умолчанию читает из ReadOnlyMap (это можно настроить в родной Eureka, но не в SpringCloud Eureka, и чтение ReadOnlyMap будет включено), что может уменьшить конкуренцию при чтении-записи ReadWriteMap. замки, увеличение пропускной способности. EurekaServer регулярно обновляет данные из ReadWriteMap в ReadOnlyMap
2) время сердцебиения
После того, как поставщик услуг зарегистрирует услугу, она будет регулярно пульсировать. Это определяется временем обновления службы в конфигурации Eureka поставщика услуг. Другой конфигурацией является время истечения срока службы.Эта конфигурация настраивается в поставщике услуг, но используется в EurekaServer, но конфигурация по умолчанию EurekaServer не включает это поле. Время сбоя сканирования EurekaServer необходимо настроить до того, как активный механизм сбоя EurekaServer будет включен. Когда этот механизм включен: каждый поставщик услуг будет отправлять свое собственное время истечения срока службы, EurekaServer будет регулярно проверять время истечения срока действия каждой службы и время последнего пульса, если в течение времени истечения не получено ни одного пульса, и нет В защищенном режиме , этот экземпляр будет удален из ReadWriteMap
3) Интервал опроса службы вызывающего абонента для извлечения списка из Эврики.
4) Кэш ленты
Решение
1) Отключить кеш ReadOnlyMap в Eureka (сторона Eureka)
eureka.server.use-read-only-response-cache: false
2) Включить проактивную сбой и интервал обнаружения отказа каждого активного 3S (конец Eureka)
eureka.server.eviction-interval-timer-in-ms: 3000
рисунокeureka.server.responseCacheUpdateInvervalMsиeureka.server.responseCacheAutoExpirationInSecondsЭто не очень полезно, когда активная инвалидация включена. 180 по умолчанию действительно достаточно, чтобы свести людей с ума.
3) Срок действия услуги (поставщик услуг)
eureka.instance.lease-expiration-duration-in-seconds: 15
Если по истечении этого времени не будет получено контрольного сигнала, EurekaServer удалит экземпляр. EurekaServer должен установить eureka.server.eviction-interval-timer-in-ms, иначе эта конфигурация недействительна.Эта конфигурация обычно в три раза превышает конфигурацию времени обновления службы. Стандартные 90-е!
4) Конфигурация времени обновления службы, сердцебиение будет активным каждый раз (поставщик услуг)
eureka.instance.lease-renewal-interval-in-seconds: 5
30 секунд по умолчанию
5) Интервал вытягивания списка сервисов (клиентская сторона)
eureka.client.registryFetchIntervalSeconds: 5
30 секунд по умолчанию
6) время обновления ленты (клиент)
ribbon.ServerListRefreshInterval: 5000
Лента даже имеет кеш, по умолчанию 30 секунд
Эти таймауты влияют друг на друга, и все три места нужно настроить.Если не быть внимательным, то возникнет ситуация, когда сервис будет не в оффлайне, а сервис не будет в онлайне. Я должен сказать, что этот набор параметров SpringCloud по умолчанию просто забавен.
Повторить попытку
Итак, каково самое продолжительное время недоступности, когда сервер отключается? (То есть запрос упадет на оффлайновый сервер, и запрос не пройдёт). По стечению обстоятельств это основное время равноeureka.client.registryFetchIntervalSeconds+ribbon.ServerListRefreshInterval,О8секунды. Если посчитать время, когда сервер активно выходит из строя, то это время увеличится до11秒.
Если у вас есть только два экземпляра, в крайних случаях время обнаружения для подключения службы к сети также занимает 11 секунд, что составляет 22 секунды.
В идеале, между этими 11 секундами запрос не выполняется. Добавьте, что ваш QPS равен 1000, а развернуто четыре узла, тогда количество неудачных запросов за 11 секунд будет1000 / 4 * 11 = 2750, что недопустимо. Поэтому мы должны ввести механизм повторных попыток.
Для Spring Cloud относительно просто ввести повторную попытку. Но мало его настроить, так как используется повтор, необходимо контролировать таймаут. Вы можете выполнить следующие действия:
- Представьте pom (не забудьте об этом)
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>
- добавить конфигурацию
ribbon.OkToRetryOnAllOperations:true
#(是否所有操作都重试，若false则仅get请求重试)
ribbon.MaxAutoRetriesNextServer:3
#(重试负载均衡其他实例最大重试次数,不含首次实例)
ribbon.MaxAutoRetries:1
#(同一实例最大重试次数,不含首次调用)
ribbon.ReadTimeout:30000
ribbon.ConnectTimeout:3000
ribbon.retryableStatusCodes:404,500,503
#（那些状态进行重试）
spring.cloud.loadbalancer.retry.enable:true
# (重试开关)
система выпуска
Хорошо, механизм был объяснен ясно, но на практике он все еще очень сложен и раздражает. Например, есть два экземпляра сервиса, я хочу опубликовать один за другим, прежде чем опубликовать второй, я должен подождать не менее 11 секунд. Если скорость руки слишком высока, это катастрофа. Поэтому необходима поддерживающая система выпуска.
Прежде всего, вы можете запросить Eureka через запрос остатка и активно изолировать инстанс, С помощью этого шага вы можете сократить время, когда сервис недоступен, по крайней мере, на 3 секунды (это все еще рентабельно).
Затем упакуйте и протолкните пакет через упаковочный инструмент. Замена онлайн по очереди.
На рынке нет такого инструмента непрерывной интеграции, поэтому систему выпуска необходимо настраивать, что также является частью рабочей нагрузки.
Пока речь идет только о том, чтобы решить функцию микросервисов SpringCloud плавно онлайн и оффлайн, что касается оттенков серого, это уже другая тема. Квалифицированным компаниям разумно выбирать саморазвитие, чтобы не снижать функцию до такого уровня.
Но в целом не беспокойтесь, выживет ваша компания или нет, пока неизвестно. Netflix выдержал это, могут ли все, кто это делает, быть сильнее его?