В настоящее время облачные решения день за днем набирают популярность среди гигантских компаний, которые когда-то полагались на локальные инфраструктуры и высокопроизводительные компьютерные архитектуры, также известные как системы на основе мэйнфреймов. Эта тенденция была впервые поддержана крупными технологическими компаниями, особенно теми, которые определены как компании FAAMG. Имея это в виду, я решил создать статью, в которой исследуются некоторые из основных преимуществ распределенных систем на основе событий, использующих Kafka в качестве основного брокера сообщений по сравнению с классическими монолитными приложениями и системами мэйнфреймов.
Для этого поста я создал краткое руководство с использованием двух микросервисов Java Spring Boot, Docker, Schema Registry и Kafka. Я также включил немного истории компьютерных систем.
Почему крупные компании переключают свой стек на облачные вычисления?
Мэйнфрейм, без сомнения, одна из самых надежных, производительных и экономичных машин, когда-либо созданных людьми. Независимо от ваших аргументов против этого, мы должны признать его важность, особенно в период с 1980-х до начала XXI века.
Однако с развитием технологий в последние годы эта мощь была превзойдена многими суперкомпьютерами, использующими параллельные системы, и новыми распределенными решениями, использующими несколько реплик данной услуги с возможностью масштабирования.
Компании с огромной рыночной капитализацией и неограниченными техническими бюджетами в прошлом были привержены созданию своих систем с использованием мэйнфреймов, особенно когда мы говорим о финансовой отрасли. В конце концов, огромная первоначальная стоимость вовсе не была проблемой. Возьмем, к примеру, крупнейшие финансовые учреждения. Подавляющее большинство из них были учреждениями, работающими на мэйнфреймах до начала 2000-х годов.
Этот сценарий кардинально изменился только после запуска в 2006 году таких компаний, как Amazon Web Services. С тех пор большинство банков, правительственных учреждений, авиакомпаний и многих других хотят оседлать эту волну облачных вычислений. Ни одна компания не хочет пропустить эту лодку современных программных архитектур.
Когда дело доходит до различных облачных архитектур, которые у нас есть сегодня, асинхронная архитектура выделяется как одна из будущих замен традиционных разработок программного обеспечения. Некоторые из причин, по которым это будет будущее крупномасштабных систем, указаны ниже.
1 - Стоимость
Несомненно, облачные решения дешевле для начинающих и средних компаний, чем программное обеспечение для мэйнфреймов. Итак, как насчет более 100 000 сотрудников корпораций, таких как банки? А компании, у которых уже есть прочные и надежные системы мэйнфреймов? Чтобы ответить на эти вопросы, мы должны увидеть здесь общую картину. Конечно, в конечном итоге стоимость распределенных систем ниже, чем плата за MIPS (миллионы инструкций в секунду) в архитектуре мэйнфрейма.
С другой стороны, первоначальные затраты на создание самой платформы и инфраструктуры, необходимой для поддержки бизнес-сервисов, могут быть довольно дорогими. Несмотря на то, что это долгий путь, как только они это сделают, стоимость со временем резко снизится. В целом стоимость этих систем ниже, чем у мэйнфреймов.
Когда мы говорим о монолитных системах, есть много общего с платформами для мэйнфреймов. Сравнивая это с микросервисами, мы видим обратную сторону стоимости. Другими словами, долгосрочная стоимость намного выше, чем создание и развертывание нескольких микросервисов. Это верно, потому что мы можем разделить функции таким образом, чтобы бизнес-ценность постоянно внедрялась в производственную среду с помощью микросервисов. Этого нельзя достичь, если разработчики тратят месяцы на выпуск одного приложения, что верно для монолитного программного обеспечения, поскольку для их разработки требуется гораздо больше времени.
2 - Труда
Теперь мы переходим к интересной теме. Еще в 1990-х COBOL был настоящим. Колледжи и университеты по всей планете включили этот компонент в свои учебные программы, поскольку в то время он пользовался большим спросом на рынке. Этот сценарий изменился к началу 2000-х годов, когда новые языки программирования появились на замену системам мэйнфреймов. В настоящее время тысячи и тысячи новых выпускников ежегодно выходят на рынок с хорошо обученными навыками разработки программного обеспечения и облачных вычислений.
Тем компаниям, которые когда-то полагались на разработчиков COBOL, пришлось адаптироваться к этой новой норме. Таким образом, во всем мире профессионалов в области облачных вычислений намного больше, чем специалистов по мэйнфреймам. К тому же, многие из сегодняшних программистов COBOL уходят на пенсию, и ожидается, что в ближайшем будущем мы столкнемся с нехваткой этих профессионалов.
3 - Ловкость
Это, пожалуй, одно из основных преимуществ распределенной архитектуры на основе микросервисов с асинхронной связью. Причина этого в том, что разработка и развертывание небольших функций на платформе микросервисов происходит быстрее, чем разработка новой подпрограммы или процедуры на мэйнфрейме. В завершенных автоматизированных облачных системах гибкие команды могут внедрять функции в производственную среду в считанные часы, если не минуты.
4 - Независимость
Ни одна компания не хочет, чтобы в цепочке поставок был только один поставщик, особенно когда это касается основной услуги этой компании: программного обеспечения. Так обстоит дело с большинством компаний, которые полагаются на мэйнфреймы. IBM доминирует на этом рынке, на ее долю приходится более 90% всех мэйнфреймов в мире. Поставщики общедоступных облаков, напротив, конкурируют друг с другом здоровым образом, что приводит к значительному падению цен за последние пять лет или около того.
Даже если компания решит иметь свой собственный центр обработки данных, что иногда случается, у нее не будет никаких связей с конкретным поставщиком, поскольку рынок в этой области диверсифицирован.
5 - Сложность
Наконец, когда крупные компании переносят свою внутреннюю инфраструктуру в облако с помощью распределенных систем, они могут своевременно разрабатывать сложные серверные службы. Я имею в виду, что многие операции, выполняемые интерфейсными службами, теперь могут быть полностью закодированы в серверной части. Это верно, потому что в большинстве случаев, когда они используют только мэйнфреймы, они не могут выполнять такие операции, как анализ изображений, с использованием искусственного интеллекта, например, внутри архитектуры мэйнфрейма.
Как следствие, большую часть времени компании используют интерфейс для выполнения этих операций или даже конкретные сервисы для их обеспечения. Напротив, если выбрана микросервисная архитектура, эта операция может быть выполнена без каких-либо серьезных технических препятствий.
Кафка
Теперь, когда мы говорили о важности наличия полностью распределенной платформы, давайте поговорим о типах решений с открытым исходным кодом, доступных для поддержки такого дизайна. Apache Kafka - один из самых популярных компонентов брокера сообщений, используемых для управления и оркестровки сообщений. За последние 10 лет существования Kafka стал ключевым компонентом практически во всех крупномасштабных и облачных архитектурах.
Короче говоря, Kafka используется в качестве обмена сообщениями между микросервисами, службами или сторонними приложениями, такими как Hadoop, для анализа данных.
Реестр схем
Целостность и контроль данных, которые производятся и потребляются через Kafka, осуществляются Реестром схем. Все управление, правила и структура определены в файле Avro, а реестр схем гарантирует, что в Kafka разрешены только сообщения, соответствующие этим стандартам.
Докер
Большинство поставщиков общедоступных облаков предлагают вариант KaaS (Kafka As A Service), например EKS, и есть такие компании, как Confluent, которые также обеспечивают поддержку клиентов для локальных центров обработки данных.
При разработке микросервисов с использованием Kafka и Schema Registry большую часть времени нам необходимо запускать эти компоненты локально для тестирования нашего программного обеспечения. Это одна из основных причин, почему мы используем Докер (конечно, одну из многих). С Docker Compose мы можем запускать несколько контейнеров на нашем персональном компьютере, что позволяет нам одновременно запускать Kafka и Schema Registry.
Для этого нам нужно создать файл с именем Dockfile со следующими изображениями:
FROM confluentinc/cp-kafka-connect:5.1.2 ENV CONNECT_PLUGIN_PATH="/usr/share/java,/usr/share/confluent-hub-components" RUN confluent-hub install --no-prompt confluentinc/kafka-connect-datagen:latest
Затем мы создадим наш файл компоновки докеров с именем docker-compose.yml.
Наконец, давайте запустим наши контейнеры локально.
$ docker-compose upКогда мы выполняем команду docker ps -a, мы видим, что наши контейнеры работают.
Если хотите, я включил этот код в свой GitHub.
Кроме того, вы также можете запустить Kafka и Schema Registry, встроенный с помощью этого замечательного компонента Java, разработанного Маркосом Валлимом.
Микросервисы Spring Boot
Пришло время создать наши микросервисы. Идея состоит в том, чтобы создать два микросервиса на Java. Тот, который называется kafka-holder, будет содержать конечную точку API, которая выполняет платеж. Как только он получит этот HTTP-запрос, он отправит событие Avro в Kafka и будет ждать ответа.
Затем служба kafka-service получит это сообщение от Kafka, обработает платеж и создаст новое событие, в котором будет указано, был ли платеж обработан или нет.
Событие Avro для платежного запроса определено ниже.
Созданная здесь архитектура использует Kafka и Schema Registry для организации сообщений.
Обратите внимание, что оба приложения одновременно являются потребителями и производителями. Применяя этот подход, мы можем индивидуально масштабировать наши микросервисы. Это гарантия того, что мы не тратим зря ресурсы, и мы используем наши деньги там, где это действительно необходимо.
Еще одно преимущество этой архитектуры заключается в том, что сообщение не теряется в случае простоя данного микросервиса. Это означает, что у нас будет DLQ (очереди мертвых писем) и хорошее решение для обеспечения устойчивости в нашем проекте.
В случае, если нам нужно узнать, что произошло с данной транзакцией, мы также можем проверить брокера Kafka и найти это конкретное событие там.
В этом посте представлен общий обзор истории развития компьютеров и программного обеспечения за последние десятилетия. Он также показал некоторые ключевые преимущества использования распределенных решений при работе с большим количеством сервисов и данных.
Я надеюсь, что эта статья помогла вам понять, почему эта тенденция к облачным вычислениям и системам, основанным на событиях, осталась неизменной и почему она заменит большинство древних систем мэйнфреймов в долгосрочной перспективе.
Если у вас есть какие-либо вопросы, пожалуйста, оставьте комментарий.
Спасибо, что прочитали!
