предисловие

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

Особенности системы:

Пользовательский модуль: Регистрация и управление пользователями
Товарный модуль: отображение и управление товарами
Модуль транзакций: создание транзакций и управление

текст

Этап 1. Создайте сайт на одной машине

В первые дни веб-сайта мы часто запускали все наши программы и программное обеспечение на одном компьютере. На данный момент мы используем контейнер, такой какTomcat,Jetty,Jboss, а затем напрямую использовать технологию JSP/Servlet или использовать некоторые платформы с открытым исходным кодом, такие какMaven + Spring + Struts + Hibernate,Maven + Spring + Spring MVC + Mybatis.最后再选择一个数据库管理系统来存储数据，如MySQL,SqlServer,Oracle, то черезJDBCПодключить и управлять базой данных.

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

Этап 2. Разделение сервера приложений и базы данных

С онлайн-сайтом трафик постепенно увеличивается, постепенно увеличивается нагрузка на сервер, когда сервер не перегружен, мы будем готовы поднять нагрузку на сайт. Если мыуровень кодаБыло сложно оптимизировать, в отсутствие производительности одной машины,Добавить машинуЭто хороший способ не только эффективно повысить грузоподъемность системы, но и экономически выгоден.

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

Архитектура после отделения сервера приложений от базы данных показана на следующем рисунке:

Этап 3. Кластер серверов приложений

Поскольку трафик продолжает расти, один сервер приложений больше не может удовлетворить спрос. Предполагая, что нагрузка на сервер базы данных отсутствует, мы можем поставить сервер приложений изодинсталДва или даже более чем один, чтобы распределять запросы пользователей по разным серверам, тем самым увеличивая грузоподъемность. иНесколько серверов приложенийМежду ними нет прямого взаимодействия, все они полагаются на базу данных для предоставления услуг внешнему миру. известный делатьотказоустойчивостьпрограммное обеспечение имеетKeepAlived,KeepAlivedЭто программное обеспечение аналогично механизму переключения уровней 3, 4 и 7. Это не эксклюзивный продукт для аварийного переключения определенного программного обеспечения, а продукт, который можно применять к различному программному обеспечению.KeepAlivedсотрудничатьipvsadmмогу сделать сновабалансировки нагрузки, можно охарактеризовать как артефакт.

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

Здесь система развивается, и появятся следующиеЧетыре вопроса:

Кто перенаправляет запрос пользователя на конкретный сервер приложений?
Существуют ли какие-либо алгоритмы и стратегии переадресации, которые можно использовать?
Как сервер приложений возвращает запрос пользователя?
Если пользователи каждый раз обращаются к разным серверам, как поддерживать согласованность сеансов?

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

1. Проблема балансировки нагрузки

Как правило, есть 5 решений:

1. HTTP-перенаправление

HTTPПеренаправление — это перенаправление запросов на прикладном уровне. Запрос пользователя действительно поступилHTTPПеренаправление сервера балансировки нагрузки.Сервер требует от пользователя перенаправления в соответствии с алгоритмом.После того как пользователь получает запрос на перенаправление, он снова запрашивает реальный кластер.

Преимущества: простота и удобство использования;
Недостаток: плохая производительность.

2. Балансировка нагрузки разрешения доменных имен DNS

DNSБалансировка нагрузки разрешения доменного имени заключается в том, что когда пользователь запрашивает DNS-сервер для получения IP-адреса, соответствующего доменному имени, DNS-сервер напрямую предоставляет IP-адрес сервера после балансировки нагрузки.

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

3. Обратный прокси-сервер

Когда запрос пользователя достигает обратного прокси-сервера (достиг компьютерного зала сайта), обратный прокси-сервер перенаправляет его на указанный сервер в соответствии с алгоритмом. общийApache,NginxМожет действовать как обратный прокси-сервер.

Преимущества: простота развертывания;
Минусы: прокси-серверы могут стать узким местом в производительности, особенно при одновременной загрузке больших файлов.

4. Балансировка нагрузки IP-уровня

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

Преимущества: лучшая производительность;
Недостаток: пропускная способность балансировщика нагрузки становится узким местом.

5. Балансировка нагрузки на уровне канала передачи данных

После того, как запрос достигает балансировщика нагрузки, балансировщик нагрузки изменяетMACадрес, чтобы достичь балансировки нагрузки, иIPОтличие балансировки нагрузки в том, что после того, как запрос получил доступ к серверу, он возвращается непосредственно к клиенту. Больше не нужно проходить через балансировщик нагрузки.

2. Кластерное планирование и алгоритм пересылки

1. Алгоритм циклического планирования rr

Как следует из названия, опрос для распределения запросов.

Преимущество: простота реализации
Недостаток: не учитывает вычислительную мощность каждого сервера.

2, алгоритм взвешенного планирования wrr

Мы устанавливаем вес для каждого сервераWeight, планировщик балансировки нагрузки планирует сервер в соответствии с весом, и количество вызовов сервера пропорционально весу.

Преимущества: Учитывая разницу в вычислительной мощности серверов

3. алгоритм хеширования оригинального адреса sh

извлечь пользователейIP, согласно хеш-функции, чтобы получитьkey, а затем в соответствии с таблицей статического отображения исследуйте и обработайте соответствующиеvalue, целевой серверIP. Если целевая машина перегружена, она вернет null.

Преимущества: один и тот же пользователь может получить доступ к одному и тому же серверу.

4, алгоритм хеширования целевого адреса dh

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

Преимущества: один и тот же пользователь может получить доступ к одному и тому же серверу.

5, lc Алгоритм наименьших соединений

Возьмите запрос на пересылку запроса на сервер.

Преимущество: Делает нагрузку на каждый сервер в кластере более равномерной.

6, взвешенный алгоритм наименьшего соединения wlc

существуетlcНа основе добавить веса для каждого сервера. Алгоритм:（活动连接数 * 256 + 非活动连接数） ÷ 权重, первым выбирается сервер с меньшим вычисленным значением.

Преимущество: Запросы можно распределять в соответствии с возможностями сервера.

7, SED Самый короткий алгоритм желаемой задержки

По сути, sed похож на wlc, разница в том, что количество неактивных подключений не учитывается. Алгоритм:（活动连接数 +1 ) * 256 ÷ 权重, первым выбирается сервер с меньшим вычисленным значением.

8. Алгоритм nq никогда не ставит в очередь

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

9, Алгоритм наименьшего соединения LBLC на основе местоположения

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

10. LBLCR с алгоритмом наименьшего соединения на основе локальности репликации.

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

3. Проблема режима возврата запроса кластера

1. НАТ

Балансировщик нагрузки получает запрос пользователя и перенаправляет его на конкретный сервер, после того как сервер обработает запрос, он возвращает его балансировщику, а балансировщик возвращает пользователю.

2. ДР

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

3. ТУН

То же, что и выше, но безIP Tunnelingпротокол,Хорошая кроссплатформенность, который поддерживается большинством систем.

4. Проблема согласованности сеанса кластера

1. Сессия липкая

Session stickyЭто распределение запросов одного и того же пользователя в определенном сеансе на фиксированный сервер, чтобы нам не нужно было решать проблему кросс-сервера.sessionПроблема, общий алгоритм имеетip_hashАлгоритмы, а именно два упомянутых выше алгоритма хеширования.

Преимущества: простота реализации;
Недостаток: сессия исчезает при перезапуске сервера приложений.

2. Репликация сеанса

Session replicationреплицируется в кластереsession, чтобы каждый сервер сохранял данные всех пользователейsessionданные.

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

3. Централизованное хранение данных сеанса

SessionЦентрализованное хранилище данных заключается в использовании базы данных для храненияsessionданные, реализованныеsessionОтвязка от сервера приложений.

Преимущества: по сравнению сSession replicationрешение, нагрузка на пропускную способность и память между кластерами значительно снижается;
Минусы: требует обслуживания храненияSessionбаза данных.

4. База файлов cookie

Cookie baseпросто поставьSessionсуществуетCookie, браузер должен сообщить серверу приложенийsessionЧто это, то же самое достигаетсяsessionОтвязка от сервера приложений.

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

Стоит отметить, что:

NginxВ настоящее время поддерживаются следующие алгоритмы балансировки нагрузки:wrr,sh(поддерживает согласованное хеширование),fair(лк). ноNginxВ качестве эквалайзера его также можно использовать вместесервер статических ресурсов.
Keepalived + ipvsadmБолее мощные, поддерживаемые в настоящее время алгоритмы:rr,wrr,lc,wlc,lblc,sh,dh
KeepalivedПоддерживаемые режимы кластера:NAT,DR,TUN
Nginxсам не предоставляетsessionсинхронное решение, в то время какApacheпри условииsessionОбщая поддержка.

После решения вышеуказанных задач структура системы выглядит следующим образом:

Этап 4. Разделение чтения и записи базы данных

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

Но для баз данных все не так просто. Если мы просто разделим базу данных на две части, а затем загрузим запросы к базе данных на машину А и машину Б, это, очевидно, вызовет проблему несогласованности данных в двух базах данных. Итак, для этого случая мы можем сначала рассмотреть возможность использованияразделение чтения-записиирепликация master-slaveПуть.

Структура системы после разделения чтения-записи выглядит следующим образом:

Это структурное изменение также принесет две проблемы:

Синхронизация данных между главной и подчиненной базами данных.
Выбор приложения источника данных.

решение:

использоватьMySQLавтономныйMaster + Slaveспособ достижениярепликация master-slave.
использоватьПромежуточное ПО сторонних баз данных,НапримерMyCat.MyCatОтCobarразработан, иCobarЭто промежуточное программное обеспечение базы данных с открытым исходным кодом Alibaba, разработка которого была прекращена.MyCatЭто тем лучшеMySqlПО промежуточного слоя подтаблицы базы данных с открытым исходным кодом.

Этап 5. Используйте поисковые системы, чтобы снизить нагрузку на чтение библиотек

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

Преимущество поисковой системы: она может значительно повысить скорость запросов и точность поиска.

Ввести накладные расходы поисковой системы

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

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

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

Этап 6. Используйте кеш, чтобы облегчить чтение библиотеки

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

Кэш на уровне приложения и базы данных

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

Кроме того, в некоторых сценариях реляционные базы данных не очень подходят.Например, я хочу сделать функцию "ограничения количества введенных неправильных паролей в день".Идея заключается в том, что при входе пользователя, если логин неправильно, запишите пользователяIPА количество ошибок, так куда эти данные деваются? Если размещать в памяти, то явно будет занимать слишком много контента, если же размещать в реляционной БД, то необходимо создавать таблицу БД и соответствующее резюме.Java bean, также напишитеSQLи Т. Д. И проанализируйте данные, которые мы хотим сохранить, это не более чем аналог{ip:errorNumber}Такойkey:valueданные. Для такого рода данных мы можем использоватьNOSQLбазу данных для замены традиционной реляционной базы данных.

кеш страницы

Помимо кэширования данных, есть еще и кэширование страниц. такие как использованиеHTML5изlocalstroageилиCookie.除了页面缓存带来的性能提升外，对于并发访问且页面置换频率小的页面，应尽量使用页面静态化技术。

Преимущества: уменьшить давление на базу данных, значительно улучшите скорость доступа;
Недостатки: требуется поддержка кэш-сервера, что увеличивает сложность кодирования.

Стоит отметить, что:

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

Структура системы после добавления кеша выглядит следующим образом:

Этап 7, горизонтальное разделение базы данных и вертикальное разделение

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

данные разделены по вертикали

Вертикальное разделение означает разделение различных бизнес-данных в базе данных на разные базы данных.В сочетании с текущим примером это означает разделение данных транзакций, товаров и пользователей.

преимущество:

Решена первоначальная проблема с размещением всего бизнеса в одной базе данных;
Дополнительные оптимизации могут быть сделаны в соответствии с характеристиками бизнеса.

недостаток:

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

проблема:

Оригинальная транзакция по перекрестным бизнесам должна быть рассмотрена;
по базам данныхJoin.

Решение проблемы:

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

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

разделить данные по горизонтали

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

преимущество:

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

проблема:

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

Решение проблемы:

Мы по-прежнему можем решать сторонние промежуточные программы, такие какMyCat.MyCatв состоянии пройтиSQLмодуль синтаксического анализа для нашегоSQLПроанализируйте, а затем перенаправьте запрос в конкретную базу данных в соответствии с нашей конфигурацией. мы можем пройтиUUIDГарантированные уникальные или настраиваемые схемы идентификаторов для разрешения.
MyCatтакже обеспечивает богатыйСхема пейджингового запроса, например, сначала выполнить запрос на подкачку из каждой базы данных, а затем объединить данные для выполнения запроса на подкачку и т. д.

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

Этап 8. Разделение приложения

Разделение приложений по микросервисам

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

Раздельная структура:

проблема:

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

Решать проблему:

Решите проблему частых общедоступных служб, выбрав сервисно-ориентированную SOA.

Выберите путь управления, ориентированного на сервисы SOA

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

Структура системы после принятия услуги:

преимущество:

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

проблема:

Как совершать удаленные вызовы службы?

Решение:

Это можно решить, представив промежуточное программное обеспечение сообщений ниже.

Этап 9. Внедрение промежуточного программного обеспечения сообщений

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

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

Суммировать

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

Добро пожаловать в технический публичный аккаунт: Zero One Technology Stack

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