1. История развития распределенной архитектуры
В 1946 году в Университете Пенсильвании в Соединенных Штатах родился первый в мире электронный компьютер.Его имя: ENICAC.Этот компьютер много весит, а скорость вычислений невысокая, но он олицетворяет приход компьютерной эры, и затем Интернет в будущем.Существует также фундаментальное значение в развитии
Состав компьютера состоит из пяти частей, а именно: устройство ввода, устройство вывода, память, память состоит из оператора и контроллера, есть модель фон Неймана очень яркий объект Состав компьютера описаны, но компьютеры также имеют поток данных, поток инструкций и поток управления для выполнения вычислений и нормальной работы. Как показано на рисунке:
После ENIAC электронные компьютеры вступили в эпоху мейнфреймов, в которых доминировала IBM.В 1946 году появился первый мэйнфрейм IBM SYSTEM/360, благодаря которому IBM доминировала во всей индустрии мейнфреймов в 1950-х и 1960-х годах.В эту эпоху компьютерная архитектура развивалась в два направления CISC (компьютерный набор инструкций, выполняемый микропроцессором) ЦП — это дешевый персональный ПК, а RISC (компьютер с сокращенным набором команд) — небольшой сервер UNIX с высокой ценой.
Появление мейнфреймов с их вычислительной мощностью и вычислительной мощностью, высокой стабильностью и безопасностью привело к развитию вычислительной области в течение длительного периода времени. Однако централизованная компьютерная система принесла некоторые проблемы, и она все больше не может удовлетворить потребности пользователей, такие как:
1. Крупномасштабные хосты очень дороги и не могут использоваться обычным малым бизнесом.
2. Мейнфрейм более сложен, а стоимость обучения талантов относительно высока.
3. Одноточечные проблемы, такие как отказ мейнфрейма, вся система зависает и не может работать, что делает потери предприятия очень большими.
4. С развитием технологий производительность персональных ПК становится все выше и выше, а стоимость все ниже и ниже.
Alibaba запустила кампанию по переходу на «IOE» в 2009 году.
IOE относится к миникомпьютеру IBM, базе данных Oracle и высокопроизводительным устройствам хранения данных EMC, переходу к IOE в 2009 году и последнему миникомпьютеру Alipay от IBM в 2003 году.
Зачем идти в ИО
В прошлом Alibaba использовала Oracle для баз данных, а также использовала мини-компьютеры и высокопроизводительные устройства хранения для предоставления высокопроизводительных услуг по обработке и хранению данных. С увеличением объема бизнеса компании и постоянным увеличением масштаба пользователей традиционная централизованная архитектура базы данных Oracle столкнулась с узкими местами при расширении. Для традиционного Oracle DB2 в основном централизована, а недостатком является отсутствие масштабируемости.Централизованное расширение в основном использует расширение вверх, а не горизонтальное расширение.Системное узкое место.
1. Общие концепции распределенной архитектуры
кластер
В маленьком ресторане раньше был повар, который нарезал овощи, мыл овощи, готовил и готовил все овощи. Позже было слишком много гостей, один повар на кухне был слишком занят, и был нанят другой повар.Оба повара могли готовить одни и те же блюда.Отношения между двумя поварами были кластером.
распределенный
Чтобы позволить шеф-повару сосредоточиться на приготовлении пищи и приготовить блюда по максимуму, был нанят сторонний повар, который отвечал за нарезку, приготовление и приготовление овощей.Отношения между поваром и второстепенным поваром распределены, и даже Шеф-повар не может быть занят Я нанял шеф-повара, и отношения между двумя шеф-поварами представляют собой кластер. Следовательно, в распределенной архитектуре могут быть кластеры, но кластеры не равны распределению.
узел
Узел относится к отдельной программе, которая может независимо выполнять набор логики в соответствии с распределенным протоколом. В конкретном проекте узел представляет собой процесс в операционной системе.
копировальный механизм
Реплика относится к обеспечению избыточности данных или служб в распределенной системе.
Реплика данных относится к сохранению одних и тех же данных на разных узлах.Когда данные узла потеряны, данные могут быть прочитаны из реплики. Реплики данных являются единственным средством последовательной потери данных в распределенной системе.
Реплика службы означает, что несколько узлов предоставляют одну и ту же услугу, а схема высокой доступности службы реализуется через отношение ведущий-ведомый.
промежуточное ПО
Помимо услуг, предоставляемых битом промежуточного программного обеспечения и операционной системой, он не принадлежит к приложению.Это своего рода программное обеспечение, которое обрабатывает связь, ввод и вывод между битом и приложением и системным уровнем для удобства Это позволяет пользователям заботиться о своих собственных приложениях.
Процесс разработки архитектуры
Зрелая крупномасштабная системная архитектура веб-сайта не предназначена для того, чтобы быть идеальной с самого начала, и она не обладает такими функциями, как высокая производительность, высокая доступность и безопасность с самого начала, но по мере увеличения числа пользователей бизнес-функции расширяются медленно. Отлично эволюционировал. В этом процессе разработки режим разработки, техническая архитектура и т. д. претерпят большие изменения.
Если система имеет следующие функции:
Пользовательский модуль: Регистрация и управление пользователями
Товарный модуль: отображение и управление товарами
Модуль транзакций: создание транзакции и расчет платежа
Фаза 1: Архитектура единого приложения
Первичный уровень системы заключается в том, что и приложения, и базы данных размещаются на одном сервере.
Фаза 2: Разделение сервера приложений и сервера базы данных
По мере увеличения количества пользователей веб-сайта и увеличения трафика для сервера приложений и сервера базы данных развертываются отдельные машины, что позволяет повысить производительность системы, повысить эффективность доступа, а также повысить нагрузочную способность и устойчивость к сбоям единая машина.
Этап 3: Кластер сервера приложений — оповещение о загрузке сервера приложений
С увеличением доступа и трафика, при условии, что база данных не сталкивается с узкими местами, кластер серверов приложений используется для разгрузки запросов для повышения производительности программы. Существующие проблемы: кто перенаправляет запрос пользователя и как управлять сеансом.
Этап 4. Увеличение нагрузки на базу данных — разделение операций чтения и записи в базе данных.
Если разделить чтение-запись, то последующие запросы и запросы запроса могут читать данные из библиотеки, а записанные данные могут отправляться в основную библиотеку, но это принесет несколько проблем:
1. Синхронизация данных между базами данных master-slave: репликация master-slave может быть достигнута с помощью метода master-slave, который поставляется с mysql.
2. Выбор соответствующего источника данных: используйте промежуточное программное обеспечение сторонней базы данных, например: mycat
Этап 5. Используйте поисковые системы, чтобы облегчить задачу чтения библиотек.
Если база данных используется в качестве библиотеки для чтения, производительность нечетких запросов часто не очень хороша, особенно для крупных интернет-компаний, модуль, который вы хотите найти, является относительно основным.Это поисковая система, которую можно использовать, хотя она может значительно улучшить запрос, скорость, но это также принесет некоторые проблемы, такие как построение индекса.
Этап 6. Внедрение механизма кэширования для снижения нагрузки на базу данных.
Для некоторых горячих данных в качестве кеша на прикладном уровне можно использовать Redis и memcache, кроме того, в некоторых сценариях вместо реляционной базы данных для хранения можно использовать mongodb.
Этап 7: Горизонтальное/вертикальное разделение баз данных
Вертикальное разделение: разделите различные бизнес-данные в базе данных на разные базы данных.
Горизонтальное разделение: разделение данных в одной таблице на две или более баз данных. Причина горизонтального разделения заключается в том, что некоторые большие объемы бизнес-данных достигли узкого места в одной базе данных. Таблицы разбиты на несколько баз данных.
Этап 8: Разделение приложения
С развитием бизнеса появляется все больше и больше предприятий, и давление приложений увеличивается. Масштабы проекта также становятся все больше и больше. В настоящее время мы можем рассмотреть возможность разделения приложения и разделения наших пользователей, товаров и транзакций на подсистемы в соответствии с моделью предметной области.
После этого разделения могут быть некоторые идентичные коды, такие как пользовательские операции, запросы товарных транзакций, и все они приведут к пользовательским запросам и операциям, связанным с доступом, в каждой системе. Эти же коды и модули должны быть абстрагированы. Это облегчает техническое обслуживание и управление.
После того, как служба разделена, связь между службами может осуществляться через технологию RPC, наиболее типичными из них являются: веб-служба, hession, http, RMI и т. д.