написать впереди
В начале вызов между службами основан на доменном имени.Доменное имя на самом деле хорошая вещь, и его очень удобно использовать, но все запросы вызовов должны проходить через разрешение доменного имени и балансировку нагрузки, что относительно плохая производительность, и они зажаты посередине.Компоненты превратятся в узкие места в производительности и потенциальные одноточечные риски.Позже все обнаружили, что лучше делать прямые сквозные звонки.Тогда для подключения нужна одна вещь два конца цепочки вызовов, которая является реестром.
Источник изображенияАнализ и сравнение основных центров регистрации микросервисов
Центр регистрации предоставляет услугу обнаружения регистрации, которая используется для подключения вызывающего звена.Providerа такжеConsumerДве конечные точки. Необходимо управлять емкостью масштабирования службы реестра, отработкой отказа, распределением потока этих основных функций, сама по себе также требуется высокая доступность и должным образом решать вопрос согласованности данных между центральным узлом, зарегистрированным в рамках межрегионального развертывания, поэтому я предпочитаю, чтобы в реестре считалось предвзятая система продукта, его стоимость зависит от масштаба услуг и систем управления, чтобы соответствовать, хотя считается, что он будет производиться очень рано, но масштаб пола непрост, небольшая услуга для самого реестра, зависящего от масштаба, не очевидна, нет средств для достижения установленной формулы, они будут располагать большим сервисным реестром, к функциям предъявляются более жесткие требования.
КП или АП
Независимо от того, следует ли выбрать строгую согласованность или высокую доступность, в настоящее время выбор основной технологии тяготеет к последнему, но это не означает,CPКомпоненты не существуют, ноAPКомпоненты больше соответствуют позиционированию реестра в Интернете.
Высокая доступность интернет-систем всегда является главным приоритетом, так как время недоступности системы обычно напрямую связано с повреждением имущества. В списке служб на один или два узла меньше и на один или два узла больше за короткий промежуток времени. Для большинства служб такая асимметрия трафика не очевидна. Требуется только реестр для восстановления согласованности в течение короткого промежутка времени. реестр не должен влиять на связь между двумя конечными точками при обычном вызове во время выполнения.
Отпустить ЗК.
CPпредставленzookeeper,на сегодняшний деньzookeeperтакже является очень популярным компонентом для реестров, отчасти благодаряdubbo.dubboсуществуетzookeeperДва узла в древовидной структуре используются для обслуживания службы.Providerа такжеComsumer, Список, зарегистрированный в двух узлах ниже, проверьте, зависят ли службы здравоохраненияzookeeperПредоставленная функция эфемерного узла на самом деле такая же, какsessionЖизненный цикл кластера связан воедино, но проблема временных узлов заключается в том, что данные изменчивы.После перезапуска отказавшего узла кластера и потери списка служб это может привести к крупномасштабному параличу служб и выскочкам электронной коммерции.PDDЭта проблема возникала раньше.
Источник изображенияофициальный сайт Дуббо
CPНаиболее серьезная проблема заключается в том, что он не может поддерживать аварийное восстановление компьютерного зала, напримерABCтри машинных зала, машинный залCСеть изолирована от двух других машинных залов и развернута в машинном зале.CизzookeeperУзел не может обеспечить запись, что означает, что компьютерный залCразвернутыйProviderЕго нельзя масштабировать или перезапустить, и лучше оставить его таким, какой он был во время сбоя, иначеProviderЛюбая операция будет сопряжена с высоким риском и напрямую повлияет на развертывание в машинном зале.CизComsumer.
Кстати, я думаю,zookeeperЭто действительно хорошо.Его позиционирование - это служба распределенной координации, и она не предназначена специально для реестра.Вы не можете оценить его с точки зрения оценки реестра.Функции, которые вы хотитеzookeeperВ основном с помощьюCuratorОн готов к использованию при условииelection,при условииZAB,TPSЭто немного ниже (на самом деле, все в порядке), но он может соответствовать большинству обслуживающих весов.
Эврика борьба
Eureka—— Интернет-компонент Netflix, посвященный знаменитостям,APпредставитель реестра.EurekaОглядываясь назад сегодня, 1.x — надуманная реализация, потому что ее архитектура со дня ее рождения означает, что существует высокая вероятность возникновения проблем после того, как масштаб данных вырастет в будущем, и общая масштабируемость кластера очень низкий.EurekaУзел означает, что есть еще один поток данных между всей точкой-точкой, и этот видPeerПоток данных механизма «точка-точка» может легко заполнить сетевую карту, вызывая нагрузку на сервер. Согласно общедоступной информации,EurekaКогда размер экземпляра составляет около 5000, будут очевидные узкие места в производительности или даже служба будет недоступна.
Но с другой стороны,EurekaСтруктура понятна, эксплуатация и техническое обслуживание очень удобны, иEurekaтак какSpringCloudРекомендованный центр регистрации был реализован, и количество внутренних пользователей также значительно.Видно, что его производительность не является проблемой при соответствующем масштабе обслуживания.Из общей информации Ctrip также видно, что его внутренняя центр регистрации также похож наEurekaВидно, что абсолютно идеального архитектурного решения не существует, и самое главное, что подходит именно вам и соответствует потребностям вашего бизнеса.
Источник изображенияInfoQ: Углубленная интерпретация архитектуры центра регистрации микросервисов EUREKA, автор Ma Junwei
EurekaАрхитектура с несколькими узлами на стороне сервера на самом деле немного децентрализована. Она намеренно поддерживает характеристики без сохранения состояния каждого узла, но цена заключается в том, что каждый узел содержит полный объем данных. Новые добавленные данные могут быть записаны на любой узел, и затем отправляется этим узлом на другие узлы и в конечном итоге достигает согласованности.
Данные не являются постоянными, а хранятся только в памяти, что обеспечивает лучшую производительность чтения и записи и более короткое время отклика, но не может справиться с узкими местами данных, а синхронизация данных, вызванная расширением больших узлов, может привести к заполнению сетевой карты. Эта точка иredisКластеры похожи. клиент30sПериодически сообщать пульс и списки служб клиентского кэша — не о чем говорить.EurekaОчень интересным моментом является то, что его узлы кластера реализуют механизм самозащиты, чтобы предсказать, есть ли проблема с кластером или с клиентом, Реализация проста, но идея вполне практична.
Eureka 2.0Проектная документация отражает мышление о чтении и записи, по сути, для повышения производительности и емкости кластера, но очень прискорбно, актуально.2.0ГосударствоDiscontinued, не должно быть зрелых продуктов за короткое время.
Сеть источника изображения
Диван-Реестр = Будущее?
Хотя нетEureka 2.0, но может быть получен с открытым исходным кодом от antSofa-RegistryУзнать о реализации подобных идей вConfigServerТем не менее, из общедоступной информации, внутренний Али должен быть первым, кто напишет, чтобы написать и написать о разделении в регистрационном центре.
Источник изображенияАрхитектура ConfigServer, автор Ку Хаотянь
Непосредственным преимуществом этой архитектуры является то, что она может поддерживать большие объемы данных, первый уровеньsessionКластер можно бесконечно масштабировать по горизонтали, и вообще не нужно общаться друг с другом,sessionКластер поддерживает все топологические отношения, требуемые реестром, в памяти, а клиент подключается только к частиsessionМашины в кластере, еслиsessionЕсли машина зависнет, клиент выберет другую для повторного подключения;dataКластер хранит все исходные данные через сегменты, обеспечивает высокую доступность за счет реплик «главный-подчиненный» между сегментами, а затем передает исходные данные вsessionКластер сохраняется для чтения клиентами.
Недостатки также очевидны: человеческий фактор, а также затраты на эксплуатацию и техническое обслуживание этой архитектуры определенно выше, чемEureka.
Межрегиональное развертывание
Это практически неизбежная проблема для реестра.Высокая доступность, аварийное восстановление в машинном зале и задержка в сети — все это приведет к необходимости развертывания узлов реестра в разных регионах.Это приведет к еще одной проблеме, связанной с тем, как синхронизировать данные.
В этом случае невозможно обеспечить согласованность данных между кластерами удаленного центра регистрации через регистрацию клиентов или репликацию потока данных узла кластера, вместо этого будет разработан отдельный компонент синхронизации данных для реализации межрегионального центра регистрации через межрегиональный выделенные линии.Синхронизация данных, если выделенная линия отключена, центры регистрации в соответствующих регионах могут по-прежнему независимо обслуживать вызов услуг в локальном домене.Когда выделенная линия будет восстановлена, данные двух будут продолжать синхронизироваться , объединены и исправлены, и, наконец, добиться согласованности. Если вам интересна эта точка знаний, вы можете узнать о нейNacos-Syncкомпонент, даNacosСпециально запущенный проектом сервис синхронизации данных с открытым исходным кодом.
напиши в конце
В статье пропущены некоторые общие концепции реестров, такие как многоуровневая модель данных, локальное кэширование списков сервисов, методы проверки работоспособности, компромиссы между двухтактными и т. д. Я не думаю, что имеет смысл описывать эти детали.
Много раз я думаю, что самое важное для понимания компонента — это понять процесс его архитектурной эволюции.Это ценный опыт, вы можете понять и изучить направление и причину каждой архитектурной эволюции.