Микросервисы сейчас очень горячая тема, и кажется, что вне зависимости от размера проекта, вся сфера применения зависит от микросервисов. Это также делает невозможным общение с другими, если вы не пользуетесь микросервисами.
Просто из собственного опыта работы, хотя наш проект тоже микросервисный. Но если честно, в процессе развития бизнеса я не осознавал, что есть большая разница между разработкой микросервисов и разработкой монолитных проектов (только для развития бизнеса).
Писать одни демки для изучения микросервисов бесполезно, текущий фреймворк имеет высокую степень инкапсуляции, даже если код работает, то все равно туманно. Изучение микросервисов больше связано с выяснением того, что представляет собой каждый компонент в микросервисах? Почему именно эти компоненты? Что, если нет? Как реализована функция?
Если вы понимаете это, вы можете сказать, что у вас есть общее представление о микросервисах.
Зачем нужен реестр
Первая проблема, которая должна столкнуться в микросервисах, заключается в том, как общаться между различными услугами? В монолитной службе, если требуется связь между различными службами, обычно сервис обнажает интерфейс, а затем другие сервисы делают запросы через HTTP, то, очевидно, то же самое можно сделать в микросервисах.
Но проблема здесь в том, что в единственном сервисе цель, которую нам нужно запросить, прямо прописана в запрашиваемом URL, потому что сервисов, которые могут это сделать, не так много. Что необходимо учитывать в микросервисах, так это целесообразность ручного ведения списка сервисов при наличии большого количества сервисов? Как уведомить другие службы, если служба масштабируется горизонтально? После того, как служба не работает, как вовремя выйти в автономный режим и так далее.
Функции реестра
Наличие реестра позволяет лучше и удобнее управлять каждым сервисом в приложении, а также является связующим звеном между различными распределенными узлами. Реестр в основном обеспечивает следующие основные функции:
- Регистрация и обнаружение сервисов. Динамическое увеличение или уменьшение числа сервисных узлов и динамическое уведомление потребителей сервисов после увеличения или уменьшения сервисных узлов без необходимости обновления конфигурации потребителями.
- Конфигурация службы. Динамическое изменение конфигурации службы и отправка ее поставщикам и потребителям службы без перезапуска службы.
- Проверка работоспособности и удаление служб: активная проверка работоспособности служб и удаление служб из списка служб для служб, находящихся в режиме простоя.
Реализация реестра
Основная функция реестра состоит в том, чтобы сохранить конкретную информацию службы, а затем прочитать эту информацию потребителями службы. Общий процесс, вероятно, выглядит так:
Помимо регистрации сервиса в реестре есть собственно антирегистрация сервиса
В настоящее время реализация реестра разделена на два режима: клиентский (регистрация внутри приложения) и серверный (регистрация вне приложения).
Реестр клиентов
В настоящее время наиболее репрезентативным реестром, реализованным клиентом, является eureka.Хотя версия eureka 2.0 ранее была объявлена как закрытая, в настоящее время она не оказывает большого влияния. В дальнейшем вы можете рассмотреть nacos с открытым исходным кодом Alibaba.
Eureka — это компонент обнаружения и регистрации стоимости и услуг, основанный на языке Java, включая сервер и клиент.
Сервер в основном используется для хранения служебной информации и регулярной проверки службы. Клиент используется для регистрации служебной информации на сервере и получения служебной информации с сервера.
Вышеприведенное изображение представляет собой архитектурную диаграмму eureka, предоставленную официальным лицом eureka.
На рисунке хорошо видно, что сервер eureka также развернут как сервис, а клиент подключен к приложению через sdk. Клиент регистрирует и обновляет службу на сервере, а клиент получает служебную информацию с сервера, и различные службы выполняют удаленные вызовы в соответствии с полученной служебной информацией.
Чтобы обеспечить высокую доступность услуг, перемещая несколько серверных служб eureka, разные серверы eureka регистрируются друг с другом для достижения высокой доступности услуг.
Центр регистрации серверов
eureka — это пакет SDK, предоставляемый реестром для сервера и клиента.Бизнес-сторона реализует регистрацию и обнаружение службы путем введения пакета SDK, предоставленного реестром. Реестр на стороне сервера реализует функцию регистрации службы через компоненты вне приложения. В настоящее время используется больше компонентов реестра на стороне сервера, таких как zookeeper, consul и так далее. Вот пример зоопарка.
Zookeeper является подпроектом Apache Hadoop. Это служба каталогов древовидного типа, поддерживающая отправку изменений. Она подходит в качестве центра регистрации для служб Dubbo. Обладает высокой промышленной мощностью и может использоваться в производственных средах. официальный регистрационный центр Dubbo.
Вышеприведенная картинка является основным принципом работы зоопарка, предоставленного официальным сайтом dubbo в качестве регистрационного центра.
Возьмите dubbo в качестве корневого каталога, создайте каталог с полным именем интерфейса службы и создайте каталог поставщиков для хранения информации об интерфейсе поставщика услуг, каталог потребителей для хранения информации об интерфейсе потребителя службы и каталог configurators для хранения конфигурации службы. Информация.
Когда поставщик услуг запускается, под поставщиками создается служебная информация, которую может получить потребитель. Зарегистрируйте наблюдателя в каталоге provider поставщика услуг с помощью механизма наблюдателя, предоставляемого zk, чтобы при расширении или отключении службы потребитель мог немедленно использовать ее.
Вопросы о реестре
В микросервисах реестр как место для хранения всех сервисных центров не должен быть одной машиной. Потому что, если реестр недоступен, поставщик услуг не сможет выставить свои услуги внешнему миру, а потребители не смогут получить конкретный адрес службы, которую им нужно вызывать, и все приложение рухнет. Первое, что необходимо гарантировать, — это высокая доступность реестра.
Выбор между согласованностью и доступностью
Когда дело доходит до высокой доступности, теорию CAP нельзя обойти, CAP просто означает, что нам нужно сделать выбор между доступностью сервисов и согласованностью между сервисами. Следует ли пожертвовать доступностью для обеспечения строгой согласованности или следует пожертвовать доступностью ради строгой согласованности?
Реестр типов CP
Zookeeper — типичный компонент высокой доступности типа CP. Zookeeper реализует алгоритм paxos.Кластер zookeeper имеет ноду в качестве лидера.Если нода-лидер зависнет, zk проведет выборы лидера по протоколу ZAB, но в процессе выборов zk не может предоставлять внешние сервисы.
Более того, когда в кластере zk возникает проблема разделения мозгов из-за сетевых разделов, поскольку протокол ZAB требует участия более половины узлов, некоторые или все узлы zk могут быть не в состоянии предоставлять внешние услуги. Однако zk может гарантировать, что все доступные узлы будут иметь согласованные данные.Даже если узел выйдет из строя, он останется согласованным с другими узлами после восстановления.Это строгая согласованность, которую zk гарантирует за счет доступности.
Реестр типов точек доступа
Центр регистрации, аналогичный eureka, относится к типу AP. Eureka обеспечивает высокую доступность за счет запуска нескольких серверных служб eureka.Каждый сервер eureka является и поставщиком, и потребителем.Каждый сервер eureka регистрирует себя как службу с другими серверами eureka, так что каждый сервер eureka принадлежит другим серверам.Реплика. В режиме эврика все узлы равны, и нет ни лидера, ни цветка.
Когда серверный узел в кластере выходит из строя, запросы могут быть напрямую переданы другим узлам. Даже если возникает сетевой раздел, хотя разные разделы не могут обмениваться данными, узлы в каждом разделе могут нормально обмениваться данными и предоставлять внешние службы, что обеспечивает доступность реестра в случае простоя серверного узла.
Проблема заключается в том, что поскольку разные разделы не могут обмениваться данными, данные одних узлов могут отличаться от данных других, что означает отказ от строгой согласованности в обмен на доступность системы.
Выбор реестра
Прежде всего, мы должны прояснить, что наличие реестра не должно напрямую влиять на вызов службы. Вызов между службами вызывается напрямую через такие протоколы, как http или rpc, а реестр предоставляет только адрес вызова. Возможность нормального использования услуги не может быть определена непосредственно по информации узла центра регистрации.
Даже если есть проблема с реестром, пока сама служба не упала, по идее, она все равно должна нормально предоставлять услуги. Поэтому для нас очевидно, что центр регистрации типа AP лучше, чем центр регистрации типа CP.
Конечно, в процессе реальной реализации многие фреймворки будут пытаться максимально исправить эти проблемы, например, eureka будет регулярно синхронизировать данные каждой ноды, чтобы добиться максимальной согласованности данных. Во время реализации реестра zk в dubbo служебная информация также кэшируется локально, и решение об исключении служб не полностью зависит от zk-информации. Следовательно, фактический выбор все же должен быть определен в соответствии с его реальной ситуацией и наличием других потребностей.
смешанное языковое развитие
В микросервисах каждый сервис представляет собой независимое целое. Каждая служба не требует, чтобы разные модули в одном приложении были реализованы на одном языке. В настоящее время языки разработки крупных компаний диверсифицированы, и языки, разработанные разными направлениями бизнеса, могут быть разными.Смешивание языков - это проблема, с которой мы должны столкнуться, поэтому существует проблема вызовов службы между несколькими языками.
Для реестров в приложении, таких как eureka. Поскольку регистрация и обнаружение сервисов зависят от SDK, если вы хотите использовать eureak, вам нужен SDK, реализованный на соответствующем языке.В настоящее время существует множество языков, таких как python и node.js. В настоящее время компонент Springcloud Sidecar также может включать другие языки в систему Springcloud.
Для реестра вне приложения реализация операции на стороне клиента обычно обеспечивается этим промежуточным программным обеспечением. Затем сам язык реализует такие функции, как регистрация службы и управление. В настоящее время многие языки действительно имеют связанные проекты с открытым исходным кодом.
Решение о выживании узла
Реестр строгой согласованности, гарантирующий тип CP, и реестр, гарантирующий доступность типа AP, упоминались ранее. Для реестра важнее всего управлять информацией об узлах в нем. Информация о службе должна быть записана при запуске службы, а служба должна быть удалена при возникновении проблемы со службой.
Но проблема заключается в том, как реализовать эту операцию удаления.В настоящее время реализация центра реестра использует обнаружение пульса для определения состояния работоспособности службы. В обычных условиях, если служба не работает, модуль обнаружения пульса не может связаться со службой, чтобы определить, что узел не может нормально работать, и служба удаляется из реестра.Этот процесс не представляет проблемы. Однако, если есть проблема с сетью, такая как сетевое дрожание или сетевой раздел, обнаружение пульса не должно иметь возможности нормального обмена данными в это время, но если служба удалена напрямую по этой причине, должна быть проблема, потому что узел может фактически предоставлять услуги в обычном режиме. Таким образом, должен быть механизм, гарантирующий, что этот процесс не удалит узлы из реестра грубо.
суждение клиента
Многие современные реализации фреймворков локально кэшируют информацию об узлах микросервисов. На самом деле, эти узлы используются различными службами, и эти узлы имеют наибольшее влияние на то, можно ли использовать эти службы в обычном режиме.
Клиент кэширует информацию об узле.Когда сервер определяет, что есть проблема со службой, и отправляет запрос на обновление, клиент не удаляет ее сразу, а может сначала провести идентификацию. После того, как приходит последующий сервисный запрос, все равно определяется, что сервис доступен, и сервис удаляется только тогда, когда отправленный запрос не может получить нормальный ответ. Клиент сам решает, доступен ли узел, но это должно поддерживаться механизмом отказоустойчивости.
Динамическое определение сердцебиения
В случае частых дрожаний сети информация об узле центра регистрации будет быстро меняться, и клиенту будет отправлено большое количество информации.Когда есть много сервисов, может быть занята большая полоса пропускания, и обычные запросы не могут обрабатываться.
Поэтому необходим механизм динамической настройки частоты обнаружения сердцебиения центра регистрации.При обнаружении частых сетевых дрожаний частота обнаружения сердцебиения настраивается в соответствии с условиями сети, такими как 1/2, 10/1 и т. д. нормальные условия. Когда сеть работает нормально, определение сердцебиения также возвращается в нормальное состояние.
резюме
Реестр — это ключевой компонент микросервисной архитектуры, обеспечивающий нормальные вызовы между различными сервисами, а также такие функции, как горизонтальное расширение сервисов. При выборе регистрационного центра необходимо учитывать бизнес-сценарии.