Центр конфигурацииЭто очень важная часть системы архитектуры Интернета, ноДля чего существует центр конфигурации,Есть ли центр конфигурации с самого начала?,Этокакую проблему это решает, что является предметом обсуждения сегодня.
С усложнением интернет-бизнеса увеличивается количество пользователей и трафика",многоуровневое обслуживание— единственный путь эволюции архитектуры.
Как показано на рисунке выше, приложение сайта будет вызывать службу, а вышестоящая служба будет вызывать базовую службу, и зависимости станут очень сложными.
Для той же услуги:
(1) часто имеет несколько исходящих вызовов;
(2) Для обеспечения высокой доступности часто используется кластер, состоящий из нескольких узлов для предоставления услуг;
Как показано на рисунке выше, пользовательская служба службы пользовательского центра имеет три узла.IP1/ip2/ip3 предоставляют услуги вышестоящему потоку.Если какой-либо узел выйдет из строя, это не повлияет на доступность службы.
ТакВот проблема:
Как вызывающая сторона поддерживает конфигурацию нижестоящего сервисного кластера?
Есть ли ощущение, когда сервисный кластер увеличивает или уменьшает количество узлов?
Ранний этап: архитектура «Конфигурационный тайник»
«Конфигурация частная» — это начальный этап настройки.Верхний поток вызывает нисходящий, и каждый восходящий имеет эксклюзивный частный файл конфигурации для записи информации о конфигурации каждого узла, называемого нисходящим.
Как показано выше:
(1) Пользовательская служба пользовательского центра имеет три узла: ip1/ip2/ip3;
(2) service1 обращается к пользовательскому центру, у него есть специальный файл конфигурации s1.conf, а настроенный у нас кластер — ip1/ip2/ip3;
(3) service2 также вызывает пользовательский центр Аналогично, есть файл конфигурации s2.conf, в котором записано, что кластер us — ip1/ip2/ip3;
(4) web2 также вызывает пользовательский центр Аналогично w2.conf кластер us настроен как ip1/ip2/ip3;
Голос за кадром: Звучит знакомо? Большинство компаний делают это в самом начале.
Каковы недостатки архитектуры «настроенного тайника»?
увидеть одинизменение емкостипотребности:
(1) Эксплуатация и техническое обслуживание обнаруживают, что производительность жесткого диска узла ip1 ухудшилась, и информируют отдел исследований и разработок о том, чтобы отключить узел ip1 в будущем;
(2) В связи с продвижением операционной деятельности 8 мая трафик в будущем резко возрастет, и R&D планирует добавить два узла ip4 и ip5;
Что нам теперь делать?
Лицо, ответственное за пользовательский центр, должно уведомить всех вышестоящих вызывающих абонентов, изменить «частную» конфигурацию, перезапустить восходящий поток и подключиться к новому кластеру. После того, как на ip1 не будет трафика, уведомите службу эксплуатации и обслуживания, чтобы перевести узел ip1 в автономный режим, чтобы завершить весь процесс сжатия и расширения.
Что не так с этой схемой?
Когда сложность бизнеса высока, количество сотрудников, занимающихся исследованиями и разработками, велико, а зависимости между сервисами сложны, это не так просто.
Вопрос первый: Уж больно звонилка, это ты меняешь емкость, почему я тот, кто модифицировал конфигурацию и перезапускал? Это типичный дизайн архитектуры с «обратной зависимостью», когда восходящий и нисходящий потоки связаны через конфигурацию, что нецелесообразно.
Вопрос второй: Сторона обслуживания очень болезненна, он не знает, сколько апстримов звонили ему, и он может найти апстрим только следующими способами:
-
групповой рев
-
отправить электронное письмо, чтобы узнать
-
Найдите ip-адрес через соединение, спросите об эксплуатации и обслуживании через ip-адрес, найдите лицо, ответственное за машину, а затем найдите соответствующую службу вызова через лицо, отвечающее за машину.
Голос за кадром: Звучит знакомо?
В любом случае, очень вероятно, что он будет пропущен, что затруднит переход трафика ip1 в автономный режим и равномерную миграцию трафика ip4/ip5. Как его оптимизировать?
Среднесрочная: архитектура «глобальной конфигурации»
Модернизация архитектуры — это не одношаговый процесс, для начала решим поставленную выше задачу «изменить конфигурацию и перезапустить» с наименьшими затратами.
Схема «Глобальная конфигурация»: Дляобщего обслуживания, создайте глобальный файл конфигурации и устраните тайники конфигурации:
(1) Сформулируйте спецификации на уровне эксплуатации и обслуживания и создайте новый глобальный файл конфигурации, такой как /opt/global.conf;
Голос за кадром: Если конфигураций много, обратите внимание на вертикальное разделение конфигурации.
(2) Для сервера, если это общий сервис, информация о кластере настраивается в global.conf;
(3) Для вызывающего абонента вызывающий запрещает конфиденциальность конфигурации и должен прочитать общую нисходящую конфигурацию из global.conf;
Каковы преимущества глобальной конфигурации?
(1) Если пропускная способность нисходящего потока изменяется, необходимо изменить только одну конфигурацию global.conf вместо каждой модификации восходящего потока;
(2) Когда вызывающий объект перезапустится в следующий раз, он автоматически переместится в расширенный кластер;
(3) Стоимость модификации очень мала, и каталог считываемого файла конфигурации изменился;
Что не так с глобальной конфигурацией?
Если вызывающий объект никогда не перезапускается, нет возможности перенести трафик в новый кластер.
Есть ли способ добиться автоматической миграции трафика?
Ответ да, нужно только представитьДва несложных компонента, трафик вызывающего абонента может быть автоматически перенесен:
(1) Компонент мониторинга файлов ****FileMonitor
Функция заключается в отслеживании изменения файла.Его можно легко реализовать с помощью таймера для регулярного отслеживания ModifyTime или md5 файла.При изменении файла реализуется обратный вызов.
(2) Компонент динамического пула соединений ****DynamicConnectionPool
«Компонент пула соединений» — это подкомпонент RPC-клиента, который поддерживает соединения с несколькими узлами RPC-сервера. Так называемый «динамический пул соединений» означает, что количество соединений в пуле соединений может динамически увеличиваться и уменьшаться.
Голос за кадром: Взаимное исключение с помощью блокировок легко реализовать.
После введения этих двух компонентов:
(1) После изменения файла глобальной конфигурации компонент мониторинга файлов выполняет обратный вызов;
(2) Если компонент динамического пула соединений обнаружит, что некоторые узлы уменьшены в конфигурации, он динамически уничтожит соответствующее соединение.Если некоторые узлы будут добавлены, он динамически установит соединение и автоматически завершит расширение и сжатие нижестоящих узлов;
Окончательная версия: Архитектура «Центра конфигурации»
Архитектура «глобальной конфигурации» — это решение, которое можно быстро внедрить и решить проблему «модифицированной конфигурации и перезапуска», но оно все еще не может решить проблему, заключающуюся в том, что поставщик услуг «не знает, сколько восходящих потоков вызвало себя».
Если вы сами не знаете, сколько восходящих вызовов:
«Ограничение по звонящему»
«Нарисуйте глобальный граф зависимостей архитектуры»
Удовлетворить такие потребности трудно,что делать?
Архитектура «Центра конфигурации» может быть идеально решена.
Сравнивая схемы архитектуры «Глобальной конфигурации» и «Центра конфигурации», вы обнаружите, что конфигурация состоит изстатические файлыобновитесь додинамическая служба:
(1) Вся подсистема центра конфигурации состоит из zk, сервисов conf-center, хранилища конфигурации БД и фона конфигурации conf-web;
(2) Конфигурация всех нижестоящих служб задается в центре конфигурации в фоновом режиме;
(3) Все восходящие потоки должны получить конфигурацию, вам нужно зайти в центр конфигурации, чтобы зарегистрироваться, и получить информацию о конфигурации нижестоящего сервиса (ip1/ip2/ip3);
Когда нижестоящим службам необходимо расширяться или сокращаться:
(4) установить фон конфигурации conf-web, добавить ip4/ip5, уменьшить ip1;
(5) Служба conf-центра отправляет измененную конфигурацию вызывающему абоненту, который зарегистрировался, чтобы обратить внимание на соответствующую конфигурацию;
(6) В сочетании с компонентом динамического пула соединений автоматическое расширение и сжатие завершены;
Каковы преимущества архитектуры «центра конфигурации»?
(1) вызывающему абоненту не нужно перезапускаться;
(2) Сторона обслуживания четко знает восходящие зависимости от центра конфигурации, чтобы реализовать ограничение тока в соответствии с вызывающей стороной;
(3) легко получить зависимости глобальной архитектуры из центра конфигурации;
Болевая точка один и болевая точка два решаются одновременно.
Что не так с архитектурой «Центра конфигурации»?
Во-первых, сложность системы относительно высока;
Во-вторых, требования к надежности центра конфигурации относительно высоки, и одно место связано со всей системой.
Суммировать
Какие болевые точки вы пытаетесь решить?
восходящая боль: именно нисходящий поток расширяет емкость, а восходящий меняет конфигурацию и перезапускается;
нисходящая боль: не знаю, кто зависит от себя;
В заключение, управление услугами сложно реализовать.
Как решить вышеуказанные болевые точки?
1. Архитектура «Настроить личное хранилище»;
Во-вторых, структура «глобального конфигурационного файла»;
3. Архитектура «Центр конфигурации»;
Знай это, знай почему.