Приветствую вас, друзья!
Добро пожаловать в мой журнал, где я документирую свой опыт создания гео-распределенного приложения на Java с нуля. В предыдущей статье я разобрал определение геораспределенных приложений. Если вы пропустили эту часть путешествия, переверните «страницу» назад, чтобы наверстать упущенное.
Сегодня я сравню и противопоставлю гео-распределенные приложения с обычными приложениями (такими, которые вы развертываете в пределах одного центра обработки данных или зоны доступности).
Чтобы понять разницу и найти сходства, мне нужно углубиться в строительные блоки (архитектуру) типичного гео-распределенного приложения. Итак, если вы со мной в этом путешествии, то, как говорили пираты, «All Hand Hoy!», что означает «Все на палубу!».
Архитектура гео-распределенного приложения
Каковы основные строительные блоки (архитектура) гео-распределенного приложения? Ответ вас удивит!
В принципе, архитектура такая же, как и у обычных приложений. Гео-распределенное приложение имеет уровни данных и приложений, как и обычное приложение. Оно может иметь выделенный уровень API и состоять из нескольких микросервисов, а также использовать балансировщик нагрузки для лучшей обработки пользовательского трафика. Он может полагаться на некоторое промежуточное программное обеспечение и… список можно продолжать и продолжать!
Так в чем же тогда большая разница? Ключ к правильному ответу кроется в определении геораспределенных приложений:
Гео-распределенное приложение — это приложение, которое охватывает несколько географических точек для обеспечения высокой доступности, отказоустойчивости, соответствия требованиям и производительности.
Все эти строительные блоки и компоненты должны обладать характеристиками, выделенными жирным шрифтом. Для простоты давайте рассмотрим эти характеристики применительно к уровню данных, уровню приложений и балансировщику нагрузки. И некоторые визуальные эффекты также могут помочь!
Пользователи геораспределенного приложения живут по всему миру. В зависимости от приложения, вы можете иметь дело с пользователями, проживающими на одном континенте (или на значительной его части) или буквально в любой точке планеты Земля. В нашем примере (см. выше) у нас есть три пользователя. Назовем их Мисс Синий, Мистер Зеленый и Мистер Красный.
Эти пользователи открывают свои ноутбуки, запускают браузер и выходят в Интернет. Они вводят адрес нашего приложения в окне браузера и ожидают увидеть страницу приложения в течение нескольких секунд, если не сразу. Если страница не загружается в течение 1-3 секунд, они считают приложение медленным (и могут уйти в другое место). Итак, как же справляется с этим геораспределенное приложение?
Глобальный балансировщик нагрузки
Гео-распределенное приложение на нашем рисунке полагается на глобальный балансировщик нагрузки, который получает запросы, определяет местоположение отправителя и направляет запросы на ближайший к пользователю экземпляр приложения.
На рисунке показано, что запрос г-жи Блю направляется к экземпляру приложения, работающему на западе США. Запрос г-на Зеленого — к экземпляру в Европе. А запрос г-на Красного — к экземпляру в Австралии. Чем ближе экземпляр приложения к пользователю, тем быстрее приложение может обработать его запрос. Вот как глобальный балансировщик нагрузки способствует повышению производительности этого геораспределенного приложения.
Но как балансировщик нагрузки помогает обеспечить высокую доступность и надежность?
Представьте, что западный регион США становится недоступным, и балансировщик нагрузки больше не может направлять туда запросы мисс Блю. Балансировщик не будет паниковать. Вместо этого он определит другой ближайший регион для г-жи Блю (это должен быть восточный регион США) и начнет перенаправлять ее трафик туда. Автоматически!
Геораспределенный уровень приложений
Хорошо, давайте перейдем к прикладному уровню архитектуры. Именно сюда глобальный балансировщик нагрузки направляет запрос пользователя.
На рисунке видно, что прикладной уровень охватывает континенты. Приложение может быть монолитом, а может быть разделено на несколько микросервисов. На данный момент это не имеет значения. Самое главное, что несколько экземпляров приложения работают по всему миру. Думаю, уже понятно, почему это делается именно так, поэтому давайте просто подытожим.
Множество экземпляров приложения гарантирует, что геораспределенное приложение сможет выдержать различные сбои в работе облака, включая крупные инциденты. Это делает уровень приложения надежным и высокодоступным. Кроме того, благодаря нескольким экземплярам геораспределенное приложение может обслуживать запросы пользователей с низкой задержкой, независимо от местоположения пользователя. Именно это делает прикладной уровень производительным.
Горизонтально масштабируемый слой данных
Наконец, экземпляр приложения, выбранный для обслуживания пользовательского запроса, должен считывать данные из уровня данных (базы данных) или записывать их в него. В геораспределенных приложениях обычно используется распределенная база данных, которая может масштабироваться горизонтально. Вот почему на рисунке выше несколько узлов базы данных разбросаны по всему миру.
Распределенные базы данных значительно повышают надежность и доступность геораспределенных приложений. Эти базы данных хранят избыточные копии данных, что позволяет приложению оставаться работоспособным во время различных сбоев. Если узел базы данных становится недоступным из-за инцидента в облаке, запросы приложения могут обрабатываться живыми и здоровыми узлами.
С точки зрения производительности, чем ближе пользовательские данные к экземпляру приложения, тем лучше. Вы же не хотите, чтобы экземпляр приложения из Сиднея, обрабатывающий запросы для мистера Реда, обращался к узлу базы данных в Азии или Южной Америке. Верно? Верно! С помощью распределенных баз данных можно расположить данные близко к местоположению пользователя, минимизируя задержки.
Важно отметить, что возможность размещения пользовательских данных в определенных местах также позволяет геораспределенному приложению соответствовать требованиям по сохранению данных. GDPR — серьезная вещь. Итак, когда глобальный балансировщик нагрузки направляет запросы мистера Грина на экземпляр приложения в Европе, этот экземпляр должен считывать персональные данные и записывать их на узел (узлы) базы данных, расположенный в Европейском Союзе.
Вот и все. Как видите, архитектура геораспределенного приложения включает в себя те же компоненты, которые вы используете в обычных приложениях — включая уровень данных, уровень приложений и балансировщик нагрузки. Разница лишь в том, что в случае с геораспределенными приложениями все эти компоненты должны функционировать в нескольких удаленных друг от друга местах.
Все еще запутались? Есть вопросы? Подтолкните меня в комментариях, и мы вместе во всем разберемся!
Что у нас на горизонте?
Итак, в этой статье я закончил обсуждение основных концепций, связанных с гео-распределенными приложениями. Теперь вы знаете, что такое геораспределенное приложение и какие компоненты оно включает.
Что же нас ждет дальше?
Ну, я представлю вам свой первый прототип геораспределенного приложения. Он еще сырой, но это нормально, пока есть основа, на которую можно опираться.
Это веб-приложение на Java, построенное на фреймворке Vaadin и развернутое в Heroku. В качестве базы данных используется YugabyteDB. Прототип функционирует в пределах одного облачного региона, но в нескольких зонах доступности.