[Перевод] Курс по основам архитектуры веб-приложений

база данных Архитектура сервер Программа перевода самородков

Основные концепции сетевой архитектуры, которые должны изучить начинающие разработчики веб-приложений

Обзор основной архитектуры веб-приложений

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

Пользователь ищет в Google ключевое слово «Сильный красивый туман и солнечные лучи в лесу».первый результатЭто флагманский продукт нашей компании: Storyblocks - станция с векторными изображениями, пользователи нажимают на результат поиска, чтобы перейти на страницу сведений об изображении. За работой пользователя клиентский браузер запрашивает у DNS-сервера сервер, на котором находится изображение, и отправляет запрос на доступ.

Запросы пользователей обращаются к сайту для обработки запросов посредством балансировки нагрузки (случайным образом выбирается один из нескольких серверов). Сервер ищет информацию об изображении из службы кэширования и извлекает другую информацию из базы данных. Мы заметили, что в это время изображение еще не просчитано для цветопередачи, поэтому отправляем задачу «цветопередача» в очередь задач. В это время сервер, на котором находится служба, асинхронно обрабатывает задачу и своевременно обновляет результат в базе данных.

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

Сервер сбалансирует нагрузку отображаемой HTML-страницы, прежде чем вернуть ее в браузер пользователя. Страница содержит скрипты Javascript и файлы ресурсов CSS, которые хранятся в облачной системе хранения, подключенной к нашей CDN, а браузер пользователя получает контент напрямую через CDN. Наконец, браузер явно отображает страницу для просмотра пользователем.

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

1. DNS

DNS (сервер доменных имен) — это аббревиатура от сервера доменных имен, представляющего собой инфраструктуру, от которой зависит Интернет. Проще говоря, DNS обеспечивает поиск по ключу-значению доменных имен и IP-адресов, например (google.comИмя домена соответствует IP-адресу 85.129.83.120), что очень необходимо, чтобы ваш компьютер мог направлять запросы на определенный сервер. Точно так же, как телефонный звонок, доменное имя связано с IP-адресом так же, как контактное лицо связано с номером телефона. Раньше вам нужен был телефонный справочник для записи телефонных номеров других людей, теперь вам нужен DNS-сервер, чтобы найти IP-адрес, соответствующий доменному имени. Таким образом, вы можете думать о DNS как о телефонной книге мира Интернета.

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

2. Балансировка нагрузки

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

В большинстве случаев веб-разработки выбирают горизонтальное масштабирование. Причина проста: серверы выйдут из строя, сети отключатся, а центры обработки данных потеряют электроэнергию. Несколько серверов могут гарантировать, что ваше приложение сможет продолжать работать, даже если оно отключено для обслуживания. Другими словами, приложение является «отказоустойчивым». Кроме того, горизонтальное масштабирование сводит к минимуму взаимодействие различных серверных служб (веб-сервер, база данных и т. д.), позволяя запускать разные службы на разных компьютерах. Другой момент заключается в том, что существует верхний предел вертикального расширения, и оно не может быть расширено, когда оно достигает определенного предела. В мире нет суперкомпьютера, который мог бы выполнять все вычисления приложения Типичным примером является поисковая платформа Google, даже если другие компании не могут достичь таких масштабов. Другие компании, такие как наша компания Storyblocks, одновременно запускают сервисы на 150–400 инстансах AWS EC2. Предоставление вычислительной мощности за счет вертикального масштабирования является довольно сложной задачей.

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

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

3. Сервер веб-приложений

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

Для реализации сервера приложений обычно требуется определенный язык (Node.js, Ruby, PHP, Scala, Java, C# .NET и т. д.) и соответствующий фреймворк MVC (Node.js Express, Ruby on Rails, Scala Play, PHP Лараве и Java's Spring и др.). Мы не будем повторять здесь детали языка и фреймворка, а заинтересованные читатели могут их подробно изучить.

4. Сервер базы данных

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

Хотя в этой статье мы стараемся не вдаваться в подробности конкретной технологии в архитектуре, здесь я хотел бы особо упомянуть SQL и NoSQL в базе данных.

SQL (язык структурированных запросов) расшифровывается как язык структурированных запросов.Выпущенный в 1970-х годах, он обеспечивает стандартную форму запросов к реляционным базам данных и широко распространен. Базы данных SQL хранят данные в виде таблиц, которые связаны друг с другом через идентификаторы (обычно int). В качестве простого примера мы хотим сохранить историческую информацию об адресе пользователя. Вам нужно подготовить две таблицы, user table users и user_addresses, и связать их с user_id, как показано ниже. Связь между таблицами достигается за счет использования user_id в качестве внешнего ключа в таблице user_addresses.

Если вы не знаете SQL, рекомендуется здесьКурсы Академии Ханаучиться. SQL настолько распространен в веб-разработке, что необходимо понимать его основу как архитектуру приложения.

NoSQL, как это буквально означает «не-SQL», — это новый тип базы данных, используемый для работы с огромными объемами данных в крупномасштабных веб-приложениях (большинство SQL не могут хорошо поддерживать горизонтальное масштабирование и могут поддерживать только вертикальное масштабирование). с некоторых сторон). Если вы совершенно не знакомы с NoSQL, рекомендуем следующие статьи:

Я также хотел бы упомянуть немного между прочим,В отрасли обычно используется SQL в качестве поверхностного вызова баз данных NoSQL., если вы не понимаете SQL, его все равно необходимо изучить, и в современных бизнес-сценариях этого трудно избежать.

5. Кэш-сервис

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

  • Службы поисковых систем (например, Baidu) кэшируют некоторые общие результаты запросов, такие как «собака», «Джей Чоу», вместо того, чтобы вычислять их в реальном времени с каждым запросом.
  • Службы социальных сетей (такие как Facebook) кэшируют данные, которые пользователи видят каждый раз, когда они входят в систему, такие как последние сообщения в блогах, друзья и т. д. Вот статьяКак Facebook кэшируетстатья.
  • Наша компания (Storyblocks) кэширует на стороне сервера React HTML-страницы, результаты поиска, результаты опережающего ввода и т. д.

Наиболее часто используемые технологии серверного кэширования — Redis и Memcache. Я буду обсуждать это подробно в других статьях позже.

6. Очередь задач и сервер

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

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

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

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

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

7. Сервис полнотекстового поиска

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

Пример на рисунке выше показывает, что три заголовка документа преобразуются в инвертированный индекс, и документы можно быстро получить по определенным ключевым словам заголовка. Обычно стоп-слова (в английском: in, the, with и т. д., в китайском: I, this, and, ah и т. д.) в индекс не добавляются.

Хотя мы можем делать полнотекстовый поиск прямо по базе данных, напримерMySQL поддерживает полнотекстовый поиск, но обычно мы запускаем отдельную «службу поиска» для вычисления и хранения инвертированного индекса, а также предоставляем интерфейс запроса. В настоящее время основными службами полнотекстового поиска являютсяElasticsearch,иSphinx,Apache Solrи так далее.

8. Услуги

Когда приложение достигает определенного масштаба, оно обычно разделяется на одно приложение в виде «микросервиса». Эти микросервисы невидимы для внешнего мира, но внутри приложения сервисы взаимодействуют друг с другом. Например, наша компания имеет различные службы эксплуатации и обслуживания, а также услуги по выполнению планов:

  • Сервис пользователяХраните все пользовательские данные веб-сайта платформы, легко предоставляйте возможности перекрестных продаж и унифицированный пользовательский интерфейс.
  • Контент-сервисХраните метаданные мультимедийных файлов и предоставляйте интерфейс загрузки файлов и информацию об истории загрузки.
  • платежный сервисОбеспечьте интерфейс платежной информации клиента.
  • Сервис экспорта PDFОбеспечьте единый интерфейс для преобразования HTML в соответствующие файлы PDF и загрузки их.

9. Данные

Успех или неудача крупных компаний сегодня заключается в том, «как правильно управлять данными», стандартизируя поток данных, когда приложение достигает определенного масштаба. Вообще говоря, есть три шага: обработка данных, хранение данных и анализ данных:

  1. обработка данныхПриложение реагирует на события взаимодействия с пользователем и отправляет данные на платформу обработки потоков данных (которая предоставляет интерфейс обработки потоковых данных) для обработки. Часто необработанные данные преобразуются или обрабатываются и передаются на другую платформу обработки потока данных. AWS Kinesis и Kafka — наиболее часто используемые инструменты для потоковой обработки этого типа.
  2. хранилище данныхНеобработанные данные и преобразованные данные хранятся в облаке. Например, AWS Kinesis предлагает конфигурацию под названием «firehose», которая хранит необработанные данные на своей облачной платформе Amazon S3, что очень удобно в использовании.
  3. анализ данныхПреобразованные данные загружаются в хранилище данных для последующего анализа. Наша компания использует в качестве хранилища данных AWS Redshift, которым также пользуются многие стартапы, крупные компании обычно выбирают Oracle или другие сервисы хранилища данных. Когда объем данных очень велик, может потребоваться использование Hadoop-подобной технологии NoSQL MapReduce для последующего анализа.

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

10. Облачное хранилище

«Облачное хранилище — это простое, масштабируемое и удобное для пользователей средство получения, хранения и обмена данными по всей сети» ——Сервис облачного хранилища AWS. К любому файлу, хранящемуся в локальной файловой системе, можно получить доступ через облачное хранилище и использовать протокол HTTP для доступа и взаимодействия с ним через RESTful API. Amazon S3 — самое популярное облачное хранилище, и наша компания хранит в нем самые разные вещи — от мультимедийных материалов, видео, картинок, аудио до CSS, Javascript и даже данных о поведении пользователей.

11. CDN

CDN относится к сети доставки контента, технологии, которая предоставляет материальные услуги, такие как хранение статического HTML, CSS, Javascript и изображений. Извлечение этих статических ресурсов из всей сети происходит намного быстрее, чем с одного исходного сервера. Он работает путем распределения контента между пограничными серверами по всему миру, а не только на одном исходном узле. Например, на рисунке ниже пользователь в Испании посещает веб-сайт с исходным узлом, расположенным в Нью-Йорке, но статический материал страницы загружается через пограничный сервер CDN в Великобритании, что позволяет избежать избыточных трансатлантических HTTP-запросов и ускоряет увеличить скорость доступа.

Источник изображения

эта статьяОбъясняет более подробно, почему используется CDN. В общем, веб-приложения могут использовать CDN для хранения ресурсов, таких как CSS, Javascript, изображения и видео и даже статические HTML-страницы.

некоторые мысли

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

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

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из ИнтернетаНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории