Разговор о серверной инфраструктуре Интернета

Эта статья была обновлена ​​2016.12.12, добавлена ​​расширенная глава.

Для интернет-предприятия серверные службы являются неотъемлемой частью. Помимо бизнес-приложений, что должны делать базовые сервисные средства для обеспечения стабильности бизнеса, надежности, простоты обслуживания и высокой доступности? Глядя на всю систему интернет-технологий в сочетании с текущим положением компании, основные технологии/средства, которые я лично считаю важными или очень важными, показаны на следующем рисунке:

• Шлюз API
• Бизнес-приложения и серверная инфраструктура
• Кэш, база данных, поисковая система, очередь сообщений
• файловое хранилище
• Единый центр аутентификации
• Система единого входа
• Единый центр конфигурации
• Структура управления услугами
• Единый диспетчерский центр
• Единая служба журналов
• инфраструктура данных
• мониторинг неисправностей
• расширять

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

Шлюз API

При разработке мобильных приложений интерфейсы, предоставляемые серверной частью, обычно требуют поддержки следующих функций:

• балансировки нагрузки
• Контроль доступа к API
• Аутентификация пользователя

Общая практика заключается в использовании балансировки нагрузки nginx, а затем в API-интерфейсе управления доступом и аутентификации пользователей в каждом бизнес-приложении. Более оптимальным способом является создание двух последних общедоступных библиотек для всех бизнес-вызовов. Но в целом, общественность нуждается в трех характеристиках, все бизнес, более желательным образом, интегрируется вместе как услуга, либо динамически модифицирует механизмы контроля доступа и аутентификации, также может снизить каждый из этих механизмов затрат на интеграцию бизнеса. Эта служба — Api Gateway (blog.CSDN.net/Храм Парк Чжисин Ухоу/Арити…), вы можете реализовать его самостоятельно или использовать для его реализации программное обеспечение с открытым исходным кодом, напримерKong. Как показано ниже:

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

Бизнес-приложения и серверная инфраструктура

Бизнес-приложения делятся на: онлайн-бизнес-приложения и внутренние бизнес-приложения.

• Онлайн бизнес-приложения: Интернет непосредственно к приложениям пользователя, интерфейсы и т. Д., Типичная функция: объем запроса, высокая параллелизм, высокая доступность, низкая допуск для отказа.
• Внутреннее бизнес-приложение: Это приложение для внутренней компании. Например, внутренняя платформа управления данными, рекламная платформа и т. д. По сравнению с онлайн-приложениями для бизнеса, его характеристики: высокая конфиденциальность данных, низкое давление, небольшой параллелизм и допустимые сбои.

Бизнес-приложения разрабатываются на основе базового фреймворка бэкенда, для бэкенда Java должно быть несколько фреймворков:

• Фреймворк MVC: От популярных десятилетней давности Struts1 и 2 до наиболее уважаемых SpringMVC, Jersey и JFinal, разработанных китайцами, Ali WebX и т. д. Эти фреймворки, особенно популярные позже, имеют свои достоинства. Главный фактор при выборе — посмотреть, есть ли в вашей команде кто-то, кто может заниматься вторичной разработкой и настройкой для определенного фреймворка. Во многих случаях для этих общих фреймворков вам нужно выполнить определенную разработку для удовлетворения конкретных потребностей. Например, многие команды передают параметры, используя номенклатуру UnderScore (подчеркивание соединяет слова), но Java использует номенклатуру LowCamel. Для SpringMVC его можно указать псевдонимом аннотации, но указывать псевдоним для каждого параметра слишком неэффективно. Кроме того, ModelAttribute не поддерживает псевдонимы. Лучшим способом является единообразное преобразование параметров в Camel на уровень рамок Достигните своих целей.
• Структура IOC. Не нужно много говорить о преимуществах, которые приносит ioc. В настоящее время самый популярный Spring в Java, естественно, поддерживает IOC с момента своего рождения.
• Фреймворк ORM: MyBatis в настоящее время является самым популярным фреймворком orm. Кроме того, JdbcTemplate, предоставленный в Spring ORM, тоже хорош. Конечно, для требований разделения подбазы данных, подтаблицы и главного-ведомого вам обычно необходимо реализовать собственную структуру ORM для ее поддержки, такую ​​​​как tddl Али, Dangdangsharding-jdbc(На уровне источника данных это решает проблему подтаблицы подбазы данных, разделения чтения и записи, прозрачности для приложения, нулевого вторжения). Кроме того, многие компании имеют собственное промежуточное программное обеспечение для баз данных, такое как Cobar от Ali, Atlas от 360, NetEase, для унифицированного решения таких проблем, как подбаза данных и подтаблица, разделение ведущий-ведомый, переключение ведущий-ведомый, кэширование и т.д. восстановление после сбоев на уровне сервиса DDB, а также официально предоставляемыхMySQL ProxyИ открытый источникMyCat,kingshardи заряженoneproxy. В настоящее время существует определенная шкала онлайн-использования Kingshard, конечно, если у вас нет недостатка в деньгах, вы также можете использовать oneproxy.
• Структура кеша: структура кеша в основном относится к унифицированной инкапсуляции операций серверов кеша, таких как Redis и memcached.Как правило, можно использовать RedisTemplate Spring или jedis для собственной инкапсуляции для поддержки распределенных решений на стороне клиента, master -раб и др.
• Инфраструктура определения производительности приложений JavaEE: для онлайн-приложений JavaEE необходимо интегрировать унифицированную структуру в каждый бизнес, чтобы определять время и статус каждого запроса, вызова метода, соединения jdbc, соединения Redis и т. д.jwebapЭто инструмент тестирования производительности, который можно использовать, но, поскольку он не обновлялся в течение многих лет, рекомендуется, если это возможно, выполнить вторичную разработку на основе этого проекта.

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

Для этих фреймворков наиболее критическая техническая команда основывается на наиболее подходящем выборе конституции, имеет возможность развивать свои собственные фреймворки в лучшую сторону. Кроме того, необходимо предоставить шаблон или инструмент для создания серверных приложений (например, архетип maven) членам команды, вы можете позволить каждому участвовать в разработке новых приложений, быстром создании прототипов приложений без необходимости сделать некоторую структуру, построенную повторяющейся работой.

Кэш, база данных, поисковая система, очередь сообщений

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

тайник

Как гласит правило пяти минут кэширования: если к части данных часто обращаются, она должна быть помещена в память. Кэш здесь представляет собой решение для хранения данных с очень высокой эффективностью чтения и записи, которое может справляться с большим числом одновременных запросов на доступ и обычно не требует гарантий постоянства. Но по сравнению с другими хранилищами кэш обычно основан на памяти, стоимость относительно высока, поэтому злоупотреблять им нельзя.

Кэш можно разделить на: локальный кеш и распределенный кеш.

• Локальный кэш: в основном относится к механизму кэша в памяти. В Java Guava Guava предоставляет механизм внедрения для локального кэширования. Конечно, вы также можете реализовать собственную местную схему кэширования, используя ConncurChamp Java.
• Распределенный кеш: относится к отдельной службе кеша. Несколько лет назад memcached был более популярен, но это было всего лишь хранилище KV и поддерживалось слишком мало структур данных. Сейчас наиболее популярным является Redis, который может поддерживать богатые структуры данных, а управляемый событиями однопоточный неблокирующий ввод-вывод также может справляться со сценариями с высокой степенью параллелизма. Помимо официального кластера Redis, более популярными кластерными решениями являются стручки гороха.codis, твиттерtwemproxy.

Для использования кэша необходимо обратить внимание на следующие моменты:

• Механизм аннулирования кеша: когда для ключа установлен срок действия, когда кеш удаляет этот ключ? Вообще говоря, существуют следующие способы:
  • Демон успеет просканировать ключ, ему не удалось найти ключ, а затем удалить
  • Когда вы прочитаете ключ, вы решите, не сработал ли ключ.Если вы ошибетесь, удалите его и верните пустой.
• Механизм устранения кеша: как удалить ключ в кеше, когда кеш-память достигает верхнего предела. Redis предлагает следующие стратегии удаления данных:
  • volatile-lru: выбирает наименее использованные данные из набора данных со сроком действия, установленным для удаления
  • volatile-ttl: выберите данные, срок действия которых истекает, из набора данных, для которого установлено время истечения срока действия.
  • volatile-random: произвольный выбор удаления данных из набора данных с установленным временем истечения срока действия.
  • allkeys-lru: выбрать данные из набора данных, которые использовались реже всего.
  • Allkeys-Random: произвольно выберите данные из набора данных для устранения
  • no-enviction: запретить удаление данных

  Для его конкретного механизма реализации вы можете обратиться к«Проектирование и реализация Redis»Эта книга

• Механизм обновления кэша: Вообще говоря, существует четыре способа: Кэшировать отдельно, Чтение, Запись через, Запись после кэширования.Подробности см. в этом резюме Чен Хао:Процедура обновления кэша.
• Защита от перегрузки сервиса кэширования: перегрузка относится к сервису кэширования, связано с истекшим давлением, вызванным нанесением нанесения отрыва в задневских услугах, дальнейшем эффекте лавины. Это явление связано с обновлением и кэшем, когда кэш упустит какую стратегию, чтобы предпринять для обновления кэша, напрямую определяет механизм защиты от перегрузки сервисов. Обычно делится на варианты ответа клиента и сервера. Предыдущий подход: простая модель на основе тайм-аута, обычная модель на таймусе, основанная на простой модели обновления, обновления на основе обычных обновлений режима обновления на белом фоне. Последний сценарий является очень распространенным управлением трафиком и деградация услуг. Конкретно можно увидеть, что эта статья суммирует техническую команду Группы США:Пример перегрузки службы в кэш-приложении.

база данных

База данных — очень распространенный сервисный компонент в бэкэнд-разработке. Выбор базы данных должен определяться в соответствии с особенностями бизнеса и характеристиками структуры данных.

По носителю базы данных можно разделить на:

• База данных в памяти: данные в основном хранятся в памяти, и также могут быть приняты меры для сохранения данных на жестком диске. Например, режим памяти Redis и H2DB. Для такого типа базы данных из-за высокой стоимости памяти необходимо выполнить количественный анализ и оценку емкости хранилища, чтобы предотвратить недоступность службы из-за нехватки памяти.
• База данных на жестком диске. Этот тип базы данных, в котором данные хранятся на жестком диске, является наиболее распространенным. MySQL, Oracle, Postgresql, HBASE, H2DB, SqlLite и т. д. — все это базы данных на жестком диске. также,SSDBЭто база данных KV, основанная на жестких дисках SSD, которая поддерживает многофункциональные интерфейсы данных и является еще одним выбором для Redis.

По типу хранения данных и режиму данных базу данных можно разделить на:

• Реляционные базы данных: MySQL, Oracle и Postgresql являются реляционными базами данных и используют реляционные модели (реляционные модели относятся к моделям двумерных таблиц, а реляционная база данных состоит из двумерных таблиц и связей между ними. Организация данных) для организации базу данных.
• Нереляционные базы данных: нереляционные базы данных относятся к реляционным базам данных. Хранится в парах ключ-значение, а структура не является фиксированной, каждый кортеж может иметь разные поля, и каждый кортеж может добавлять некоторые свои собственные пары ключ-значение по мере необходимости, так что он не ограничен фиксированной структурой и может быть уменьшено на некоторое время и пространственные накладные расходы. Однако он не имеет строгой схемы данных реляционных баз данных и не подходит для сложных запросов и предприятий, требующих надежного управления транзакциями. Нереляционные базы данных можно разделить на:
  • База данных KV: база данных, которая хранит данные в основном в парах ключ-значение (ключ, значение). Представлен Redis, RocksDB (levelDB) и SSDB.
  • База данных документов. Общая форма также представлена ​​в виде пар ключ-значение, но в значении могут быть различные структуры данных: массивы, пары ключ-значение, строки и т. д. Представлен mongodb и Couchdb.
  • База данных столбцов: также известная как разреженная большая база данных, она обычно используется для хранения массивных данных. В отличие от баз данных строк, этот тип базы данных хранит данные на носителях в единицах столбцов. Представлены Hbase и Cassendra.

Очень важной вещью, связанной с базой данных, является индекс базы данных. Есть поговорка: «Овладение индексом равносильно освоению базы данных». На данный момент я не буду судить, действительно ли это утверждение является точным, но индекс действительно связан с производительностью чтения и записи базы данных. Необходимо иметь достаточное представление о принципе индексации базы данных, чтобы лучше использовать различные базы данных. Вообще говоря, Mysql, Oracle и Mongodb используют B-деревья в качестве индексов, которые учитывают характеристики традиционных жестких дисков и учитывают производительность чтения и записи и требования к поиску по диапазону, в то время как Hbase использует LSM для улучшения записи. производительность.Пожертвована производительность чтения.

поисковый движок

Поисковые системы также являются ключевым компонентом серверных приложений, особенно для контента и приложений электронной коммерции.Это очень распространенный пользовательский сценарий для поиска контента и товаров по ключевым словам и ключевым словам. Более зрелыми поисковыми системами с открытым исходным кодом являются Solr и Elasticsearch.Многие поисковые системы малых и средних интернет-компаний построены на основе этих двух систем с открытым исходным кодом. Все они реализованы на базе Lucence, основное отличие заключается в хранении termIndex, поддержке распределенной архитектуры и так далее.

Для использования поисковых систем требуется много времени на ознакомление с системой, построение сервисов и настройку функций. В этом процессе необходимо обратить внимание на следующие вопросы:

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

Для более подробной инженерной практики поисковых систем, пожалуйста, обратитесь к этой статье Youzan Engineer:Практика поисковой системы Youzan (инженерия)

Кроме того, поисковые системы также могут использоваться для многомерного анализа данных, т.GrowingIO,MixPanelФункция запроса отчетов данных в любом измерении. Конечно,druidМожет быть, это лучшее решение для реализации многомерного анализа, и у официального также есть сравнение с es:druid.IO/docs/latest….

очередь сообщений

Организационная структура программного обеспечения, от компонентно-ориентированного в начале до SOA и SAAS, представляет собой процесс постепенной эволюции. В нынешнюю эпоху преобладания микросервисов вам стыдно говорить, что ваша система — это всего лишь единая система без развязки на сервисы. Конечно, нет необходимости разделять маленькую систему, но действительно необходимо разделить сложную систему на сервисы один за другим, чтобы создать микросервисную архитектуру.

Итак, вопрос в том, как общаться между сервисами? Какой протокол используется? Как это называется? все вопросы для рассмотрения.

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

Асинхронный вызов - это очень распространенный прикладное сценарий сообщений промежуточного программного обеспечения. Кроме того, сценарии приложений очередей сообщений следующие:

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

В настоящее время основное программное обеспечение очереди сообщений в основном включает следующее:

• ActiveMQ: Простейшая очередь сообщений в Java является реализацией JMS и не определяет порядок, безопасность и повторную передачу сообщений.
• RabbitMQ: это реализация протокола AMQP, которая обеспечивает хорошую поддержку упорядочения сообщений, безопасности и повторной передачи. Он больше подходит для передачи сообщений в бизнес-сценариях, которые не допускают потери данных и имеют требования к транзакциям.
• Кафка: это очередь сообщений на основе журнала.Нижний уровень зависит от последовательного чтения файлов и предназначен только для добавления. Он подходит для некоторых сценариев массовой передачи журналов, которые не чувствительны к потере данных и подчеркивают производительность. Это очень популярная технология в области больших данных в последние годы.
• ZeroMQ: это библиотека шаблонов для сетевого программирования, которая моделирует и компонует общие формы сетевых запросов (управление группами, управление ссылками, публикация и подписка и т. д.), короче говоря, выше сокета и ниже MQ. Для MQ сетевая передача является лишь частью этого, и необходимо обрабатывать больше, чем хранение сообщений, маршрутизацию, обнаружение и поиск службы брокера, транзакцию, режим потребления (подтверждение, преобразование и т. д.), службу кластера и т. д.

файловое хранилище

Будь то бизнес-приложение, зависимые серверные службы или другие различные службы, в конечном итоге все зависит от базового хранилища файлов. Вообще говоря, характеристики, которым должно соответствовать файловое хранилище: надежность, устойчивость к сбоям и стабильность, то есть для гарантии того, что сохраненные данные не будут легко потеряны, даже если произойдет сбой, может быть план отката и должна быть обеспечена высокая доступность. На нижнем уровне в качестве решения можно использовать традиционный RAID.На следующем уровне HDFS от Hadoop является наиболее распространенным решением для распределенного хранения файлов.Конечно, общие файловые системы, такие как NFS и Samba, также обеспечивают простые характеристики распределенного хранилища.

Кроме того, если файловое хранилище действительно становится узким местом приложения или производительность файлового хранилища необходимо повысить для повышения производительности всей системы, то самый прямой и простой способ — отказаться от традиционного механического жесткого диска и заменить его на жесткий диск SSD. Когда многие компании решают проблемы с производительностью бизнеса, последним ключевым моментом часто является SSD. Это также самый прямой и эффективный способ обмена денег на затраты времени и труда. SSDB, описанная в разделе базы данных, представляет собой высокопроизводительную базу данных KV, которая использует функции SSDB после инкапсуляции LevelDB.

Что касается HDFS, если вы хотите использовать вышеуказанные данные, вам нужно пройти через hadoop. Некоторые технологии, подобные xx на yarn, являются решениями для запуска не-hadoop-технологий на hdfs (разумеется, для использования MR).

Единый удостоверяющий центр

Единый центр аутентификации в основном предоставляет услуги аутентификации для пользователей приложений, внутренних пользователей, приложений и т. д., в том числе

• Регистрация пользователя, проверка входа, аутентификация по токену
• Управление пользователями внутренней информационной системы и аутентификация входа
• Управление приложениями, включая создание секрета приложения, проверку информации о приложении (например, проверку подписи интерфейса) и т. д.

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

система единого входа

В настоящее время на многих крупных веб-сайтах используется система единого входа, которая, говоря простым языком, требует только одного входа пользователя для входа в несколько бизнес-приложений (права доступа могут быть разными), что очень удобно для пользователей. В мобильных интернет-компаниях различные внутренние управленческие и информационные системы также требуют системы единого входа. В настоящее время более зрелая и наиболее используемая система единого входа должна быть открыта Йельским университетом.CAS, может основываться наGitHub.com/AP и EO/CAS/…к индивидуальной разработке. Кроме того, китайский открытый исходный кодkissoЭтот тоже хорош. В основном принцип единого входа аналогичен следующему рисунку:

Единый центр конфигурации

В серверных приложениях Java распространенным способом чтения и записи конфигурации является запись файлов конфигурации в файлы свойств, yaml и HCON.При изменении вам нужно только обновить файл и повторно развернуть его, что можно сделать без участия кода. -уровень изменений.цель. Единый центр конфигурации — это единая служба, которая управляет соответствующими файлами конфигурации всех предприятий или базовых серверных служб на основе этого метода и имеет следующие функции:

• Возможность динамически изменять файлы конфигурации онлайн и вступать в силу
• Файлы конфигурации могут различаться между средами (разработки, тестирования, производства и т. д.).
• Простота использования: соответствующая конфигурация может быть введена в java через аннотацию и конфигурацию xml.

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

Структура управления услугами

Для внешних вызовов API или клиентского доступа к back-end API может использоваться протокол http или restful (конечно, его можно вызывать и напрямую через самый примитивный сокет). А вот для вызовов между внутренними сервисами они обычно вызываются через механизм RPC. Текущие основные протоколы RPC:

• RMI
• Hessian
• Thrift
• Dubbo

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

Таким образом, когда ваши системные службы постепенно увеличиваются, цепочка вызовов RPC становится все более и более сложной.Во многих случаях вам необходимо постоянно обновлять документы для поддержания этих взаимосвязей вызовов. Фреймворк для управления этими сервисами может значительно сэкономить утомительную ручную работу, которая с ним связана.

Традиционная ESB (Enterprise Service Bus) — это, по сути, схема управления службами, но между клиентом и сервером существует роль esb в качестве прокси-сервера.Все запросы должны проходить через esb, поэтому esb легко может стать узким местом в производительности. . Таким образом, на основе традиционного esb на следующем рисунке показана лучшая конструкция:

Как показано на рисунке, при использовании центра конфигурации в качестве концентратора взаимосвязь вызовов существует только между клиентом и сервером, предоставляющим службы, что позволяет избежать узких мест в производительности, присущих традиционному esb. Для этого проекта esb должен поддерживать следующие функции:

• Регистрация и управление поставщиками услуг
• Регистрация и управление потребителями услуг
• Управление версиями сервисов, балансировка нагрузки, управление потоком, деградация сервисов и т. д.
• Сервисная отказоустойчивость, автоматический выключатель и т.д.

Али с открытым исходным кодомdubboОн хорошо реализовал вышеперечисленное, и это также решение, которое в настоящее время используют многие компании. Однако по некоторым причинам dubbo больше не поддерживается, поэтому рекомендуется использовать Dangdang для его обслуживания позже.dubbox.

Единый диспетчерский центр

Во многих компаниях планирование времени является очень распространенным сценарием, таким как регулярная выборка данных и регулярное обновление статуса заказов. Обычная практика — полагаться на механизм cron в Linux или кварц в java для своего бизнеса. Единый центр планирования управляет всеми задачами планирования, поэтому кластер планирования можно настраивать, расширять и управлять задачами унифицированным образом.azkabanиoozieЭто механизм управления потоковой работой в Hadoop, который также можно использовать в качестве единого центра планирования. Конечно, вы также можете использовать cron или кварц для реализации собственного единого центра планирования.

• Планирование задач на основе выражений cron
• Динамически изменять, останавливать, удалять задачи
• Поддержка рабочего процесса задачи: например, после завершения задачи выполняется следующая задача.
• Задачи поддерживают сценарии, коды, URL-адреса и т. д.
• Запись в журнале выполнения задачи, аварийная сигнализация

Что касается кварца Java, здесь необходимо пояснить: этот кварц следует отличать от кварца весны, который представляет собой простую реализацию структуры кварца весны и в настоящее время является наиболее используемым методом планирования. Но он не поддерживает кластеры высокой доступности. Хотя кварц поддерживает кластеры, его очень сложно настроить. Многие решения теперь используют zookeeper для реализации кластеров пружинного кварца. Вот китайский с открытым исходным кодомuncode-shceduleЭто неплохо, и вы можете заняться вторичной разработкой в ​​соответствии с потребностями собственного бизнеса. Кроме того, Dangdang с открытым исходным кодомelastic-jobКроме того, добавлены более мощные функции, такие как эластичное использование ресурсов.

Единая служба журналов

Журналы необходимы для процесса разработки. Иногда время и навыки печати журналов могут отражать уровень кодирования инженеров. В конце концов, журналы — это самая непосредственная информация для онлайн-сервисов, позволяющая обнаруживать и устранять неполадки.

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

Унифицированную структуру ведения журналов можно реализовать, внедрив приложение log4j и logback, а затем распечатав журналы на сервере журналов с помощью вызовов RPC.

инфраструктура данных

Данные — это область, которая была очень горячей в последние годы. От «Lean Data Analysis» до «Growth Hacking» — все они подчеркивают исключительную роль данных. Многие компании также используют данные для продвижения дизайна продукта, рыночных операций, исследований и разработок и т. д. Подробности в предыдущей статье«Разговор о данных», чтобы сделать некоторые сводки о вещах, связанных с данными. Здесь необходимо пояснить, что только когда масштаб ваших данных действительно достигает масштаба, который не может быть обработан одной машиной, вы должны использовать технологии, связанные с большими данными, и никогда не использовать большие данные для больших данных. Во многих случаях проблемы, которые можно решить с помощью автономной программы + mysql, приходится решать с помощью Hadoop, что является пустой тратой времени и сил.

Здесь необходимо добавить, что для многих компаний, особенно тех, чей офлайн-бизнес не столь интенсивен, ресурсы кластеров больших данных во многих случаях тратятся впустую. Так родилсяxx on yarnРяд технологий позволяет технологиям, не основанным на Hadoop, использовать ресурсы кластеров больших данных, что может значительно улучшить использование ресурсов, например Docker on yarn (VoidBox от Hulu).

шоссе данных

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

• Сбор: после того как единая служба журналов печатает журналы в службе журналов, для их централизации требуется механизм сбора журналов. В настоящее время распространенными схемами сбора журналов являются: писец, Чуква, Какфа и Флюм. Сравнение показано на следующем рисунке:

  

• Передача: данные передаются в службу обработки данных через очередь сообщений. Для логов обычно выбирают очередь сообщений типа kafka.

Кроме того, ключевой технологией здесь является синхронизация данных между базой данных и хранилищем данных, то есть решение, используемое, когда данные для анализа синхронизируются из базы данных в хранилище данных, такое как hive. Проще и полезнееsqoopСинхронизация данных на основе временных меток. Кроме того, открытый исходный код AlibabacanalРеализована инкрементальная синхронизация на основе бинлога, что больше подходит для общих сценариев синхронизации, но на базе канала нужно еще много работы по развитию бизнеса. Порекомендуйте другой китайский с открытым исходным кодомMySQL-BinlogПринцип аналогичен каналу, по умолчанию предусмотрена функция фонового управления задачей, а реализовывать логику обработки необходимо только после получения бинлога.

Автономный анализ данных

Автономный анализ данных может быть отложен, как правило, он предназначен для анализа данных с требованиями не в реальном времени, а также генерирует отчеты T-1. В настоящее время наиболее часто используемыми технологиями автономного анализа данных являются Hadoop и Spark. По сравнению с hadoop, spark имеет большие преимущества в производительности, конечно же, требует больших аппаратных ресурсов.

Для Hadoop традиционное написание MR очень сложно и не способствует обслуживанию.Вы можете использовать hive вместо sql для написания mr, но предпосылкой должно быть понимание принципа hive. Вы можете обратиться к этому сообщению в блоге Meituan, чтобы узнать:Процесс компиляции Hive SQL. Для искры также есть искра sql, похожая на улей.

Кроме того, для автономного анализа данных еще одной ключевой проблемой является проблема перекоса данных. Так называемая асимметрия данных относится к неравномерному распределению данных региона, что приводит к низкой нагрузке на некоторые узлы и высокой нагрузке на некоторые узлы, что влияет на общую производительность. Поэтому для обработки данных очень важно решать проблему перекоса данных. Для перекоса данных улья вы можете увидеть:Сводка наклона больших данных Hive. Для проблемы наклона искры см .:Руководство по оптимизации производительности Spark — расширенный.

анализ данных в реальном времени

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

Для анализа данных в реальном времени следует отметить, что когда результаты обработки данных в реальном времени записываются в хранилище, необходимо учитывать проблемы параллелизма. Задачи читаются и пишутся одновременно. Обычное решение состоит в том, чтобы буферизовать данные во временном окне, а затем записывать их партиями.

Кроме того, обработка данных в режиме реального времени, как правило, основана на инкрементной обработке, которая ненадежна по сравнению с автономным режимом.В случае возникновения сбоя (например, сбоя кластера) или сбоя обработки данных трудно восстановить или исправить аномальные данные. Поэтому сочетание офлайн + в реальном времени является наиболее часто используемым решением для обработки данных.Лямбда АрхитектураЭто архитектурное решение, которое сочетает в себе автономную обработку данных и обработку данных в реальном времени.

Специальный анализ данных

Некоторые отчеты, созданные в результате автономного анализа данных и анализа данных в режиме реального времени, предназначены для справок аналитиков данных и менеджеров по продуктам, но во многих случаях онлайн-программы не могут удовлетворить потребности этих пользователей. В это время сторона спроса должна сама запросить хранилище данных. Для этих сторон SQL прост в использовании и легко описывается, что определяет, что это может быть наиболее подходящим способом. Таким образом, предоставление специального инструмента запросов SQL может значительно повысить эффективность работы аналитиков данных и менеджеров по продуктам. Presto, Impala, Hive — все это такие инструменты. Если вы хотите дополнительно предоставить покупателю более интуитивно понятный пользовательский интерфейс, вы можете создать внутреннийHue.

мониторинг неисправностей

Для онлайн-сервисов, ориентированных на пользователя, сбой является серьезной проблемой. Поэтому очень важно хорошо выполнять работу по обнаружению неисправностей и оповещению онлайн-сервисов. Мониторинг неисправностей можно разделить на следующие два уровня мониторинга:

• Мониторинг системы: в основном относится к мониторингу пропускной способности хоста, процессора, памяти, жесткого диска, ввода-вывода и других аппаратных ресурсов. Это можно отслеживать с помощью программ с открытым исходным кодом nagios, cacti и другого программного обеспечения с открытым исходным кодом. В настоящее время на рынке также существует множество сторонних сервисов, которые могут обеспечить мониторинг ресурсов хоста, например мониторинг сокровищ. Для мониторинга распределенных сервисных кластеров (таких как hadoop, storm, kafka, flume и другие кластеры) вы можете использоватьganglia. Кроме того, открытый исходный код XiaomiOpenFalconЭто также очень хорошо, охватывая системный мониторинг, мониторинг JVM и т. д., а также поддерживает пользовательские механизмы мониторинга.
• Бизнес-мониторинг: это мониторинг выше уровня ресурсов хоста, например, аномальные данные pv и uv приложения, сбой транзакции и т. д. Необходимо добавить в бизнес соответствующий код мониторинга, например, добавить запись журнала, в которой возникает исключение.

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

• В журнал аварийных сигналов следует записывать идентификатор неисправной машины, особенно в службах кластера.Если идентификатор машины не записан, будет сложно найти последующую проблему.
• Аварийные сигналы необходимо агрегировать, а не генерировать отдельный аварийный сигнал для каждой неисправности, что доставит большие проблемы инженерам.
• Чтобы классифицировать сигналы тревоги, вы не можете иметь одинаковый приоритет для всех сигналов тревоги.
• Использование WeChat в качестве программного обеспечения для сигналов тревоги может обеспечить скорость поступления сигналов тревоги при одновременном снижении стоимости SMS.

После аварийной сигнализации наиболее важным является ее устранение. Для стартапов 24-часовой режим ожидания является важным качеством.При возникновении тревоги необходимо как можно быстрее отреагировать на неисправность, найти проблему и решить ее в течение контролируемого времени. Для устранения неполадок в основном полагайтесь на журналы. Если журналы ведутся разумно, в целом проблема может быть быстро обнаружена, однако, если это распределенная служба и объем данных журнала особенно велик, поиск журнала становится сложной проблемой. Вот несколько вариантов:

• Платформа централизованного анализа журналов ELK (Elastic+Logstash+Kibana) создана для облегчения быстрого поиска и определения местоположения журналов. Для ознакомления с ELK см.:Используйте Elasticsearch + Logstash + Kibana для создания платформы централизованного анализа журналов.
• Установите распределенную систему отслеживания запросов (также называемую полноканальной системой мониторинга), особенно для распределенных систем.Микросервисная архитектура, что может значительно облегчить быстрое позиционирование и сбор информации об отдельных аномальных запросах при массовых вызовах, а также может быстро найти узкое место в производительности канала запроса. Vipshop'sMercury, АлиСоколиный глаз, СинаWatchMan, Твиттер с открытым исходным кодомZipkinВ основном на основе GoogleDapperПриходит диссертация. также,Механизм Tencent из окрашенного бревнаПо сути, механизм окраски также выполняется на основе информации ответа, основанной на отслеживании ссылок. Апач находится в стадии инкубацииHTraceЭто распределенное решение для отслеживания, разработанное для больших распределенных систем, таких как файловая система hdfs и механизм хранения hbase. Здесь следует упомянуть одну вещь: если ваша реализация микросервиса использует облако Spring, тоSpring Cloud SleuthЭто лучшая реализация распределенной трассировки.

расширять

1. Нетфликс

В последние годы Netflix открыл исходный код многих своих внутренних сервисов:github.com/NetflixВключая большие данные, создавать инструменты доставки, общие библиотечные услуги выполнения, постоянство данных и безопасность. Есть номер, соответствующий вышеупомянутой инфраструктуре:

• zuul

  Это интерфейсный шлюз всех серверных сервисов Netflix, который является шлюзом API, о котором мы упоминали выше, и в основном включает следующие функции:

  • Аутентификация, авторизация и безопасность: идентифицируйте законные внешние запросы и отклоняйте незаконные.
  • Мониторинг: отслеживайте все значимые данные, чтобы дать нам точное представление о продукте.
  • Динамическая маршрутизация. Динамическая маршрутизация запросов к соответствующей серверной службе по мере необходимости.
  • Стресс-тест: постепенно увеличивайте нагрузку на кластер до максимального значения.
  • Ограничение потока. Ограничьте поток запросов каждого типа и отклоните лишние запросы.
  • Статическое управление ответами: для некоторых запросов возвращайтесь непосредственно на периферию без переадресации на серверный кластер.
  • Устойчивость к нескольким регионам: маршрутизация запросов в нескольких регионах AWS.

• Eureka

  Это служба обнаружения регистрации службы Netflix, аналогичная функции dubbo. Включая балансировку нагрузки и отказоустойчивость.

• Hystrix

  hystrix — это библиотека классов. На основе командного режима реализована отказоустойчивость, деградация и изоляция зависимых сервисов. Полезно при использовании нескольких сторонних сервисов. Кроме того, вы можете добавить поддержку функций hystrix в dubbo, настроив фильтр, реализующий dubbo.

Кроме того, Netflix этих компонентов с открытым исходным кодом в совокупности состоит из Netflix OSS, предоставляет набор распределенных систем решения, который охватывает услугу, необходимую для выполнения распределенного открытия Micro Service, устойчивость к неисправности услуг, балансировка нагрузки, контроль доступа и так далее. Конечно, если вы выбираете Direct Docker, то сам k8s предоставляет этим вещам.

2. Весеннее облако

Spring cloudОн предоставляет нам полный набор инструментов и сред разработки для создания распределенных систем, в основном охватывающий различные компоненты и подпроекты, описанные в этой статье.Spring Cloud NetflixОн может интегрировать различные компоненты Netflix. Сейчас многие компании и команды внедряют микросервисы на базе облака Spring. Тем не менее, весна Облако содержит множество подпроектов, и для их понимания требуется много денег.

• Spring Cloud Config

  Единый центр конфигурации похож на упомянутый выше disconf, но его файлы конфигурации хранятся в системах управления версиями, таких как git и svn. Онлайн-обновление его конфигурации в режиме реального времени должно полагаться на Spring Cloud Bus.

• Spring Cloud Security

  Он предоставляет службы безопасности, такие как балансировка нагрузки клиента oauth2 и заголовок аутентификации, которые можно использовать в качестве реализации шлюза API.

• Spring Cloud Consul/Zookeepr

  Единое открытие, регистрация, регистрация и конфигурация услуг. Похож на Дуббо.

• Spring Cloud Bus

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

• Spring Cloud Sleuth

  Распределенная система отслеживания, которая может отслеживать траекторию ссылки и отнимающую много времени информацию одного запроса.

Вышеизложенное является частью моего опыта. Пожалуйста, укажите на неизбежные ошибки из-за ограниченных знаний.