Развертывание и сравнение промежуточного программного обеспечения сообщений: rabbitMQ, activeMQ, zeroMQ, RocketMQ, Kafka, Redis

Не существует лучшего промежуточного программного обеспечения очереди сообщений (называемого промежуточным программным обеспечением сообщений), есть только наиболее подходящее промежуточное программное обеспечение сообщений.
Распространенные сценарии использования очередей сообщений:

非实时性: Когда результат не нужно получать сразу, а нужно контролировать параллелизм, самое время использовать очередь сообщений. В основном он решает такие проблемы, как связывание приложений, асинхронная обработка и отключение трафика.
应用耦合: Несколько приложений обрабатывают одно и то же сообщение через очередь сообщений, чтобы избежать сбоя при вызове интерфейса и вызвать сбой всего процесса (например: заказ -> инвентарь).
异步处理: Несколько приложений обрабатывают одно и то же сообщение в очереди сообщений и одновременно обрабатывают сообщения между приложениями, что сокращает время обработки по сравнению с последовательной обработкой (сценарии «укажи на несколько», широковещательные сценарии (зарегистрируйтесь для отправки текстовых сообщений, отправки электронных писем) и т. д.). .)
限流削峰: используется в действиях всплеска или мгновенной покупки, чтобы избежать ситуации, когда система приложения зависает из-за чрезмерного трафика; (устанавливайте размер очереди в соответствии с допуском службы и возвращайтесь к концу действия, если он превышает, у нас часто бывают всплески в крупных торговых центрах, а в наших сердцах еще нет буквы Б?), чтобы снизить стресс и избежать простоев в обслуживании.
消息驱动的系统: система разделена на очереди сообщений, производителей сообщений и потребителей сообщений. Производитель отвечает за генерацию сообщений, а потребители (их может быть несколько) отвечают за обработку сообщений (разделение труда (каждый из которых соответствует соответствующему очередь), гибкое приложение (обработка приема/обработка времени))

Очереди сообщений — одно из основных средств асинхронного RPC.

Два режима:

点对点: у каждого сообщения есть только один потребитель (Consumer), который не может использоваться повторно (после использования сообщение больше не находится в очереди сообщений).
发布/订阅: После публичной учетной записи WeChat (Тема) все (подписчики) подписываются на внимание, после того, как официальная платформа управления учетной записью WeChat (издатель) публикует информацию, все получают информацию о WeChat, Фактически, она делится на вытягивание / push . Один активный толчок, а другой пассивный притяжение
基于发布/订阅模式做扩展就是横向扩展，多个队列及消费分组订阅(提高消费能力)

pull: Инициатива лежит на стороне потребителя.Преимущество в том, что он потребляет по требованию (съел шведский стол, и взял столько, сколько можно съесть), а обработка сообщений, накопленных в очереди на стороне сервера, относительно проста (нет необходимости для записи статуса, статус на стороне потребителя); недостаток в том, что сообщение задерживается. (не знаю, когда вытащить обновление.) В это время некоторые друзья спросят, почему бы вам не позвонить серверу, чтобы уведомить его (есть поговорка, что если вы не в своем положении и не занимаетесь своими делами, то уведомление сервера должно зафиксировать статус уведомления) и увеличить пропускную способность связи, конечно, это тоже можно выбрать и используется в сочетании с push в соответствии с реальной ситуацией (мужчины и женщины не устают работать вместе), чтобы улучшить характер сообщения в реальном времени)
push: Инициатива лежит на стороне сервера.Преимущество в том, что производительность в реальном времени высока, и серверная сторона может управлять нагрузкой унифицированным образом, но легко привести к медленному потреблению (вы должны учитывать, сторона потребителя выдержит.Ведь вы сказали, что понимаете, но только другая сторона будет знать, насколько хорошо вы понимаете); недостаток в том, что статус отправки сообщений - централизованное управление, что очень напрягает (рассылать сообщения, нужно записывать статус, нужно делать бэкапы, а вы и папа и мама, не надоели)
对于顺序消息，这种场景有限且成本太高的方式就得慎重考虑了，对那种全局有序但允许出现小误差的场景(日志推送)，pull模式就非常适合了(所以说kafka为啥常用于日志处理、大数据等方面)，要问为什么？自己去领悟

Выбор промежуточного программного обеспечения сообщений в реальной разработке основан на нескольких аспектах:

功能: Это больше, очередь с приоритетом, очередь с задержкой (делите разные очереди с задержкой, чтобы избежать переупорядочивания и потребления производительности, недостаток в том, что вы сами это понимаете), очередь недоставленных сообщений (поставить не удалось успешно протолкнуть), режим потребления (pull/push), Потребление броадкастов, возврат сообщения (его можно отследить, иначе не знаешь, кому оно продается), накопление сообщений + сохраняемость, отслеживание сообщений (панель ссылок, легко найти), фильтрация сообщений (фильтрация по правилам, разные типы сообщения отправляются) В разные темы), многопротокольная поддержка (универсальная), кросс-языковая поддержка (популярность), управление потоком (хе-хе, выше), упорядочение сообщений (хотите повторить?), механизм безопасности (идентификация аутентификация, аутентификация полномочий) (чтение и запись)), идемпотентность сообщений (если вы обещаете знать, если не знаете, вы должны делать то, что обещаете), транзакционные сообщения (не хочу говорить) и т. д.
性能: обычно относится к его пропускной способности (тело сообщения одинакового размера и возможности создания и потребления тела сообщения разных размеров), производительность и функции часто противоречат друг другу, и вы не можете иметь и то, и другое.
高可靠、高可用: Давайте сначала поговорим о надежности, в основном о сохраняемости сообщений (пока сообщения пишутся, они будут потребляться, а данные не будут потеряны из-за сбоев (это хороший тест)). Если это с точки зрения системы, то его необходимо измерять по общему измерению (не только по промежуточному программному обеспечению сообщений, но и по трем измерениям: производство, сервер и потребитель).
Кроме того, он доступен главным образом потому, что один из них — это зависимость от внешних сервисов (например, kafka полагается на zookeeper), зависимость также делится на сильную зависимость и слабую зависимость, а другой — безопасность, обеспечиваемая собственным механизмом резервного копирования (например, master репликация ведомых устройств). , добавление нескольких ведомых устройств для усиления гарантии также приведет к пустой трате ресурсов, большую часть времени ведомое устройство может простаивать).
运维: Обычно это оценка аудита, мониторинг, напоминание о тревоге, аварийное восстановление, расширение емкости, развертывание обновлений и т. д. С одной стороны, это зависит от размера поддержки промежуточного программного обеспечения, с другой стороны, это зависит от сложности объединения автоматических эксплуатация и техническое обслуживание
社区力度及生态发展: Это легко понять.В начале использования фреймворка с открытым исходным кодом я в принципе бегал счастливо, но время от времени я всегда попадал в яму.Смогу ли я выбраться, зависит от моих собственных сил и силы сообщества с другой стороны.
成本:Попробуйте приспособить собственную систему стека технологий команды, команде стека C гораздо проще углубиться в zeroMQ, чем писать kafka на Scala.

先贴一个图(网上Q来的)，一些功能支不支持主要取决于它使用的模式，看完上面详细说明应该就比较清楚

先从比较有代表性的两个MQ(rabbitMQ,kafka)，功能对比(图还是Q来的)

Применение:

RabbitMQ, который следует протоколу AMQP и разработан на языке erlanng с высокой степенью параллелизма, используется для доставки сообщений в реальном времени, что требует высокой надежности.
Kafka в основном используется для обработки активных потоковых данных и обработки больших объемов данных.

С точки зрения архитектурной модели:

RabbitMQ следуетAMQP协议, брокер RabbitMQ состоит из Exchange, Binding и очереди, в которой exchange и Binding образуют ключ маршрутизации сообщения; клиентский Producer связывается с сервером, подключая канал, а Consumer получает сообщения из очереди для потребления (длинные соединение, очередь будет отправлять сообщения, когда есть сообщение) На стороне потребителя цикл потребителя считывает данные из входного потока). RabbitMQ ориентирован на брокера, для сообщений есть механизм подтверждения.
Kafka следует общей структуре MQ: производитель, брокер и потребитель. Она сосредоточена на потребителе. Информация о потреблении сообщений хранится на потребителе на стороне клиента. В соответствии с точкой потребления потребитель извлекает данные из посредника пакетами; нет механизма подтверждения сообщения.

Пропускная способность:

RabbitMQ немного уступает kafka по пропускной способности.Отправные точки у них разные. rabbitMQ поддерживает надежную доставку сообщений, поддерживает транзакции и не поддерживает пакетные операции; исходя из требований к надежности хранилища, хранилище может использовать память или жесткий диск.
Kafka имеет высокую пропускную способность и внутри использует пакетную обработку сообщений и механизм нулевого копирования.Хранение и получение данных представляет собой последовательную пакетную операцию на локальном диске со сложностью O (1), а эффективность обработки сообщений очень высока.

Доступность:

RabbitMQ поддерживает зеркальную (зеркальную) очередь, основная очередь выходит из строя, и зеркальная очередь вступает во владение.
Брокер Kafka поддерживает активный режим ожидания.

Балансировка нагрузки кластера:

Балансировка нагрузки rabbitMQ требует поддержки отдельного балансировщика нагрузки.
Kafka использует zookeeper для управления брокерами и потребителями в кластере и может регистрировать темы в zookeeper; с помощью механизма координации zookeeper производитель сохраняет информацию брокера о соответствующей теме, которая может быть отправлена брокеру случайным образом или путем опроса; и производитель может быть указан на основе семантики Sharding, сообщение отправляется на шард брокера.

rabbitMQ

Разработано на основе erlang
Это промежуточное программное обеспечение для сообщений протокола AMQP, реализованное на языке Erlang, изначально возникшее в финансовой системе и используемое для хранения и пересылки сообщений в распределенной системе. RabbitMQ развивается по сей день и получает признание все большего числа людей, что неотделимо от его превосходных показателей в плане надежности, доступности, масштабируемости и богатого функционала.
преимущество:

Благодаря характеристикам языка erlang, mq имеет лучшую производительность и высокий параллелизм;
Надежный, стабильный, простой в использовании, кроссплатформенный, поддерживает несколько языков и имеет полную документацию;
Имеется механизм подтверждения сообщения и механизм сохраняемости, а надежность высокая;
Настраиваемая маршрутизация;
Богатый интерфейс управления, а также масштабное применение в интернет-компаниях;
Высокий уровень общественной активности;

недостаток:

Хотя в сочетании с преимуществами параллелизма самого языка erlang производительность выше, но это не способствует вторичной разработке и обслуживанию;
Реализована архитектура брокера, что означает, что сообщения могут ставиться в очередь на центральном узле перед отправкой клиентам. Эта функция делает RabbitMQ простым в использовании и развертывании, но замедляет его работу, поскольку центральный узел увеличивает задержку, а сообщение становится больше после инкапсуляции;
Необходимость изучения более сложных интерфейсов и протоколов, а стоимость обучения и обслуживания высока;

activeMQ

На основе Java-разработки
Это промежуточное программное обеспечение, ориентированное на сообщения, созданное Apache и написанное на языке Java, полностью основанное на спецификации JMS1.1, обеспечивающее эффективную, масштабируемую, стабильную и безопасную передачу сообщений на уровне предприятия для приложений. Однако по историческим причинам бремя слишком велико, и текущая доля рынка не так велика, как у последних трех промежуточных программ для сообщений.Его последняя архитектура называется Apollo (промежуточная программа для сообщений JD.com разработана на основе activeMQ).
преимущество:

Кроссплатформенность (написание JAVA не имеет ничего общего с платформой, ActiveMQ может работать практически на любой JVM)
Можно использовать JDBC: данные можно сохранять в базе данных.
Поддержка JMS: поддержка единого интерфейса JMS;
Поддержка автоматического переподключения;
Имеет механизм безопасности: поддерживает различные механизмы настройки безопасности на основе shiro, jaas и т. д., может аутентифицировать и авторизовать очередь/тему
Идеальный мониторинг: имеет идеальный мониторинг, включая веб-консоль, JMX, командную строку Shell, API REST Jolokia;
Дружественный интерфейс: предоставленная веб-консоль подходит для большинства ситуаций, и можно использовать множество сторонних компонентов, таких как hawtio;

недостаток:

Активность сообщества не такая высокая, как у RabbitMQ;
Будут необъяснимые проблемы и сообщения будут потеряны;
Не подходит для сценариев приложений с тысячами очередей;

zeroMQ

На основе разработки C
Известная как самая быстрая очередь сообщений в истории, она разработана на основе языка C. ZeroMQ — это библиотека очередей обработки сообщений, которая может эластично масштабироваться между многопоточностью, многоядерностью и хостами.Хотя большую часть времени мы привыкли классифицировать ее в семейство очередей сообщений, она принципиально отличается от предыдущих. не является сервером очереди сообщений, он больше похож на набор низкоуровневых сетевых коммуникационных библиотек, которые просто добавляют уровень инкапсуляции к исходному Socket API.
преимущество:

Известна как самая быстрая система очереди сообщений, особенно для сценариев с высокой пропускной способностью.
Развертывается отдельно или интегрируется в приложение, нет необходимости устанавливать и запускать сервер сообщений или промежуточное ПО, т.к. ваше приложение будет играть роль сервиса
Возможность реализации расширенных/сложных очередей, но разработчикам необходимо самостоятельно комбинировать несколько технических фреймворков.
Кроссплатформенная, многоязычная поддержка
Может использоваться как коммуникационная библиотека Socket

недостаток:

Обеспечьте только непостоянные очереди, то есть, если машина выйдет из строя, данные будут потеряны.

rocketMQ

На основе разработки Java (промежуточное ПО для сообщений Ali)
Это промежуточное программное обеспечение для обмена сообщениями с открытым исходным кодом от Alibaba. Оно было передано в дар Apache Foundation. Оно разработано на Java и обладает характеристиками высокой пропускной способности, высокой доступности и подходит для крупномасштабных распределенных системных приложений. Оно испытало крещение Double 11, и его силу нельзя недооценивать.
преимущество:

Одна машина поддерживает более 10 000 постоянных очередей.
Все сообщения RocketMQ являются персистентными.Они сначала записываются в системный pagecache (кэш страниц), а затем сбрасываются, чтобы и в памяти, и на диске была копия данных.При доступе они читаются прямо из памяти.
Модель проста, а интерфейс прост в использовании (интерфейсы JMS во многих случаях не очень практичны).
Производительность очень хорошая, и в брокере может накапливаться большое количество сообщений (кластер содержит один или несколько серверов, эти серверы называются брокерами);
Поддержка различных видов потребления, включая потребление кластера, широковещательное потребление и т. д.
Распределенный дизайн расширения каждого канала, HA ведущий-ведомый (кластер высокой доступности);
Степень разработки более активна, а обновление версии происходит очень быстро.

недостаток:

Существует не так много поддерживаемых клиентских языков, в настоящее время java и c++, из которых c++ является незрелым;
Внимание и зрелость сообщества RocketMQ не так хороши, как первые два;
Нет веб-интерфейса управления, но предоставляется инструмент управления CLI (интерфейс командной строки) для запроса, управления и диагностики различных проблем;
Такие интерфейсы, как JMS, не реализованы в ядре mq;

kafka

На основе разработки Scala и Java
Первоначально это была распределенная система обмена сообщениями с несколькими разделами, несколькими копиями и распределенной системой обмена сообщениями на основе зоопарка, разработанная LinkedIn с использованием языка Scala и переданная в дар Apache Foundation. Это высокопроизводительная распределенная система обмена сообщениями публикации и подписки, которая широко используется благодаря своей горизонтальной масштабируемости и высокой пропускной способности. В настоящее время все больше и больше систем распределенной обработки с открытым исходным кодом, таких как Cloudera, Apache Storm, Spark, Flink и т. д., поддерживают интеграцию с Kafka.
преимущество:

Богатый клиентский язык, поддержка java, .net, php, ruby, python, go и других языков;
Отличная производительность, запись одной машины в TPS составляет около миллиона в секунду, а размер сообщения составляет 10 байт;
Обеспечивает полностью распределенную архитектуру и имеет механизм реплик, обладающий высокой доступностью и надежностью, и теоретически поддерживает бесконечное накопление сообщений;
Поддержка пакетных операций;
Потребители используют метод Pull для получения сообщений, сообщения упорядочены, и благодаря контролю можно гарантировать, что все сообщения будут потребляться и потребляться только один раз;
Существует отличный сторонний веб-интерфейс управления Kafka Kafka-Manager;
Он относительно зрел в области ведения журналов и используется многими компаниями и проектами с открытым исходным кодом;

недостаток:

Если на одной Kafka-машине больше 64 очередей/разделов, нагрузка значительно возрастет: чем больше очередей, тем выше нагрузка и больше время отклика на отправку сообщений.
При использовании метода короткого опроса производительность в реальном времени зависит от интервала опроса;
Ошибка потребления не поддерживает повторную попытку;
Порядок сообщений поддерживается, но когда агент выйдет из строя, сообщения будут не в порядке;
Обновления сообщества идут медленно;

redis

Механизм PUB/SUB Redis, модель публикации-подписки. Используется списковая структура данных Redis. Лучший шаблон использования — создавать сообщения lpush и сообщения Consumer brpop, а также устанавливать тайм-аут, чтобы снизить нагрузку на Redis. Только когда Redis не работает и данные не сохраняются, данные теряются.Согласно бизнесу, AOF и сокращение интервала сохранения можно использовать для обеспечения высокой надежности, а также можно использовать несколько клиентов для повышения скорости потребления. Однако, по сравнению с профессиональными очередями сообщений, статус сообщений в этой схеме слишком прост (отсутствие статуса) и нет механизма подтверждения. - нажать в очередь.

Redis не поддерживает группировку (это очень важно, недостаток отражается при выполнении балансировки нагрузки), но его можно использовать как облегченную очередь, но redis его отец сделал Disque, можно попробовать.

Установка развертывания

rabbitMQ

Несколько важных концепций:

Брокер: Проще говоря, это сущность сервера очереди сообщений.
Обмен: Обмен сообщениями, который указывает, по каким правилам сообщение направляется в какую очередь.
Очередь: носитель очереди сообщений, каждое сообщение будет помещено в одну или несколько очередей.
Binding: Binding, его функция состоит в том, чтобы связать обмен и очередь в соответствии с правилами маршрутизации.
Ключ маршрутизации: ключевое слово маршрутизации, биржа доставляет сообщения в соответствии с этим ключевым словом.
vhost: виртуальный хост, в одном брокере можно открыть несколько vhosts, чтобы разделить разрешения для разных пользователей.
производитель: Производитель сообщений — это программа, которая доставляет сообщения.
потребитель: потребитель сообщений — это программа, которая принимает сообщения.
канал: канал сообщений.В каждом соединении клиента может быть установлено несколько каналов, и каждый канал представляет задачу сеанса.

Использовать процесс:

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

автономный
Для установки RabbitMQ требуется среда Erlang
Так что сначала установите erlang, а потом RabbitMQ.В середине определенно будет много проблем.В разных средах разные проблемы.Большинство из них - проблемы зависимых пакетов,и вы можете решить их самостоятельно.

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

Настроить внешний доступ

# rabbitmq.config文件默认是没有的，这里是直接新建
vi rabbitmq.config
# 添加下面内容
[{rabbit, [{loopback_users, []}]}].

удалить гостя

rabbitmqctl  delete_user guest

Добавить пользователя

rabbitmqctl add_user <username> <newpassword>

Предоставление прав суперадминистратора новым пользователям

rabbitmqctl set_user_tags <username> administrator

Запустите службу (рекомендуется запускать в фоновом режиме)

service rabbitmq-server start &

Откройте пользовательский интерфейс управления (рекомендуется работать в фоновом режиме)

rabbitmq-plugins enable rabbitmq_management &

Доступ: ip: 15672, авторизуйтесь под новым добавленным пользователем

kafka

Несколько важных концепций:

Брокер: кластер Kafka содержит один или несколько серверов, которые называются брокерами.
Тема: Каждое сообщение, опубликованное в кластере Kafka, имеет категорию, которая называется темой.
Раздел: Раздел — это физическое понятие, и каждая тема содержит один или несколько разделов.
Производитель: отвечает за публикацию сообщений брокеру Kafka.
Потребитель: потребитель сообщений, клиент, который читает сообщения от брокера Kafka.
Группа Потребителей: Каждый Потребитель принадлежит к определенной Группе Потребителей (имя группы может быть указано для каждого Потребителя, если имя группы не указано, оно принадлежит к группе по умолчанию).

автономный
Kafka использует Zookeeper для хранения информации о кластере, поэтому вам нужно сначала установить zookeeper, а Zookeeper написан на Java, поэтому вам нужно сначала установить jdk

jdk: версия 1.8 и выше (инструмент мониторинга Kafka KafkaOffsetMonitor необходимо использовать позже, а версия jdk в настоящее время зависит от выше)
zookeeper: новая версия kafka поставляется с zookeeper

ссылка для скачивания:kafka.apache.org/downloads

# 下载解压
mkdir kafka && cd kafka
wget http://mirrors.shuosc.org/apache/kafka/1.0.0/kafka_2.11-1.0.0.tgz
tar -xzf kafka_2.11-1.0.0.tgz
cd kafka_2.11-1.0.1
# 启动zookeeper
bin/zookeeper-server-start.sh config/zookeeper.properties
# 启动kafka
bin/kafka-server-start.sh config/server.properties
# 创建Topic test
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
# 参数描述：
# create: 创建Topic
# zookeeper：zookeeper集群信息，多个用,分开
# replication-factor：复制因子
# partitions：分区信息
# topic：主题名

# 向topic发送消息
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
> 随便输入

# 向topic获取消息
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning
# 就能看到前面输入的消息了

Инструмент мониторинга Кафки
У Kafka нет собственного веб-интерфейса, здесь используется KafkaOffsetMonitor, программа запускается в виде jar-пакета, который более удобен в развертывании. Безопаснее использовать только функцию мониторинга.

KafkaOffsetMonitor размещен на Github и может быть загружен через Github. ссылка для скачивания:GitHub.com/morningstar…

# 下载好之后cd到KafkaOffsetMonitor所在目录，可以直接启动，也可以编写shell脚本来启动
java -cp KafkaOffsetMonitor-assembly-0.4.1-SNAPSHOT.jar com.quantifind.kafka.offsetapp.OffsetGetterWeb
--port 8089
--zk 127.0.0.1:2181 
--refresh 5.minutes 
--retain 1.day

скрипт для запуска

mkdir kafka-monitor.sh
chmod  +x kafka-monitor.sh
vi kafka-monitor.sh
# 把之前启动的命令复制进来，如：
#! /bin/bash
java -Xms512M -Xmx512M -Xss1024K \
     -cp KafkaOffsetMonitor-assembly-0.4.1-SNAPSHOT.jar \
     com.quantifind.kafka.offsetapp.OffsetGetterWeb \
     --zk localhost:2181 \
     --port 8089 \
     --refresh 10.seconds \
     --retain 5.days
# 保存，然后就可以启动脚本了

zk : адрес узла zookeeper, если их несколько, разделенных запятыми.
port : порт приложения (если не задан, в логе будет выводиться случайный номер порта)
Refresh : как часто приложение обновляет и сохраняет точки в базе данных.
сохранить : как долго сохранять в БД
dbName : имя сохраненного файла базы данных, по умолчанию offsetapp

Подробное описание параметра на github:

доступ: ip: порт

    Topic：订阅的主题
    Partition:分区编号
    Offest：表示该parition已经消费了多少条message
    logSize:表示该partition已经写了多少条message
    Lag：表示有多少条message没有被消费。
    Owner：表示消费者
    Created：该partition创建时间
    Last Seen：消费状态刷新最新时间。

Уведомление
Эта машина может получить доступ, но другие машины не могут получить к ней доступ. Это проблема брандмауэра, откройте соответствующий порт или закройте брандмауэр.
Если к нему можно получить доступ, но информация не отображается, отображается только черный экран, потому что публичные библиотеки, такие как ajax.googleapis.com, от которых зависит страница пользовательского интерфейса, заблокированы.
Решение

Эпилог

Продолжение следует....
личный блог~
короткая книга~