Автор | Ли Ципэн

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

Очередь доисторических сообщений с открытым исходным кодом

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

Vivek Ranadiv[2]

В 1985 году Вивек получил начальное финансирование от Teknekron Corp, и родилась Teknekron Software Systems Inc. (TSS), сосредоточившаяся на коммерциализации TIB. TIB в основном обслуживает финансовую отрасль и решает проблемы обмена данными между программным обеспечением для торговли ценными бумагами. В 1980-х годах индустрия финансовой торговли в США процветала, поэтому TIB получил широкое распространение и имел большой успех. Teknekron была приобретена Reuters Group в 1993 году[3]. В 1997 году Reuters основала TIBCO Software[4] для независимой эксплуатации программных решений TIB. В 2014 году TIBCO Software официально стала частной в результате приобретения Vista Equity Partners за 4,3 миллиарда долларов [5].

Успех TIB привлек внимание голубого гиганта IBM, поскольку клиенты IBM также в основном представляют финансовую отрасль. IBM начала разработку очередей сообщений в 1990 году, а три года спустя был запущен продукт IBM WebSphere MQ [6,7]. После непрерывного развития IBM MQ стала очень конкурентоспособной системой обмена бизнес-сообщениями в мире [8,9]. Согласно отчету Gartner [10], IBM MQ по-прежнему будет приносить почти 1 миллиард долларов США годового глобального дохода в 2020 году, что составляет почти треть мировой доли рынка промежуточного программного обеспечения для обмена сообщениями.

Эпоха открытого исходного кода

Успех коммерческого MQ позволил ему занять рынок прикладных коммуникаций крупных предприятий. Однако высокая цена отпугнула малые и средние предприятия. В то же время, чтобы сохранить свои конкурентные барьеры, коммерческие поставщики MQ создали закрытую экосистему продуктов и не взаимодействуют с другими MQ. В результате многие крупные предприятия одновременно используют продукты нескольких поставщиков MQ, но не могут связаться друг с другом. Например, если приложение подписано на сообщения TIBCO MQ и ему необходимо получать сообщения от IBM MQ, реализовать его будет очень сложно. Эти продукты используют разные API, разные протоколы и, конечно же, не могут быть объединены в одну шину. Для решения этой проблемы в 1998 году была создана служба сообщений Java (JMS) [11,12].

JMS для MQ является тем же, чем JDBC для баз данных. Он пытается решить проблемы совместимости, преодолевая барьеры, предоставляя общедоступный API Java и скрывая реальные интерфейсы, предоставляемые отдельными поставщиками продуктов MQ. С технической точки зрения, Java-приложение необходимо только запрограммировать с использованием JMS API, выбрать соответствующий драйвер MQ, а JMS позаботится обо всем остальном. JMS в определенной степени решает проблему совместимости между MQ, но когда нижний уровень взаимодействия приложений адаптируется к различным MQ, требуется код для объединения множества различных интерфейсов MQ, что делает приложения JMS очень хрупкими и снижает удобство использования. Очевидно, что рынок остро нуждается в MQ, который изначально поддерживает протокол JMS.

На этом фоне в 2003 году родился ActiveMQ [13]. Это первый продукт с открытым исходным кодом, который изначально поддерживает протокол JMS. ActiveMQ полностью реализует JMS. Появление ActiveMQ решает проблему адаптации к стабильности JMS и поддерживается многими предприятиями. Более того, ActiveMQ является продуктом с открытым исходным кодом. Учитывая высокую цену коммерческой версии MQ, ActiveMQ пользуется большим спросом у малых и средних предприятий. В 2005 году Дамарилло и др. основали компанию LogicBlaze на основе проекта ActiveMQ [14], которая была приобретена IONA 2 года спустя [15].

У JMS есть серьезный недостаток: он подходит только для Java-приложений. Программы, разработанные на других языках, не могут использовать JMS для осуществления обмена информацией. В этом контексте настоящим спасителем является AMQP. AMQP[16] (расширенный протокол очереди сообщений) был предложен Джоном О'Хара в 2003 году. JPMorgan Chase взял на себя инициативу и объединил усилия с Cisco, IONA, Red Hat, iMatix и т. д., чтобы создать рабочую группу AMQP для решения проблем. между различными платформами в финансовой сфере, вопросы взаимодействия сообщений. AMQP — это протокол, точнее, двоичный протокол проводного уровня. В этом существенное отличие от JMS, AMQP не ограничивает его на уровне API, а напрямую определяет формат данных для сетевого обмена. Это делает поставщика, реализующего AMQP, естественным образом кроссплатформенным. Это означает, что мы можем использовать Java AMQP Provider и в то же время использовать Python Producer и Ruby Consumer. С этой точки зрения AMQP можно сравнить с HTTP. Он не заботится о языке реализации. Пока все отправляют запросы сообщений в соответствии с соответствующим форматом данных, клиенты на разных языках могут подключаться к серверам на разных языках. языки. AMQP имеет более широкую область применения, чем JMS.

На рынке явно существует потребность в продукте для очереди сообщений, который полностью реализует протокол AMQP. Компания Rabbit Technologies, сооснователями которой являются Алексис и Маттиас, была основана в 2007 году [17]. В том же году компания запустила RabbitMQ, первый продукт для очереди сообщений, полностью реализовавший протокол AMQP. Компания была приобретена VMware. 2010 г. [18]. RabbitMQ разработан на языке Erlang и имеет очень хорошую производительность с задержкой на уровне микросекунд. Благодаря полной поддержке AMQP он более открыт и может поддерживать больше интеграций доступа к приложениям, чем коммерческие продукты, такие как IBM MQ и ActiveMQ, реализующие JMS. Более того, по сравнению с другими современными продуктами реализации AMQP, такими как Apache Qpid[19], его многоязычный клиент и техническая документация более стандартизированы и полны, а сообщество открытого исходного кода более активно[20][21]. Благодаря этому RabbitMQ постепенно становится идеальным выбором для обмена сообщениями малых и средних предприятий и даже крупных предприятий. Фактически, RabbitMQ остается одной из самых успешных очередей сообщений с открытым исходным кодом в мире.

Схема архитектуры RabbitMQ [22]

Конечно, RabbitMQ не идеален. Именно из-за идеальной поддержки протокола AMQP реализация слишком сложна. Это также приводит к его низкой пропускной способности.

эпоха больших данных

Рождение Интернета заставило предприятия генерировать все больше и больше данных. Появление мобильного Интернета в 2010 году полностью взорвало суперпортал Интернета. В 2010 году в мире насчитывалось 1,97 миллиарда пользователей Интернета, что составляло 28,7% мирового населения [23]. Поэтому интернет-компаниям необходимо обрабатывать все больше и больше данных. LinkedIn, как глобальная социальная сеть, в 2010 году насчитывала более 90 миллионов участников [24]. Ему необходимо ежедневно анализировать поведение пользователей Интернета с помощью большого количества журналов для оптимизации продукта и рекламы. Базовая парадигма анализа больших данных, Lamdba [25, 26], собирает данные из многих систем с помощью компонентов сбора данных, а затем агрегирует их в платформы больших данных, такие как Spark или Hadoop. Данные журнала поведения пользователей получаются с помощью программ распределенного сбора. Hadoop может осуществлять пакетный анализ больших объемов данных. Ключевой проблемой стала передача больших объемов данных журналов в Hadoop [27]. В сценарии интеграции данных первоначальным решением LinkedIn является передача журналов через ActiveMQ. Однако в сценарии интеграции больших данных, несомненно, обнаруживаются проблемы с производительностью ActiveMQ. Несмотря на то, что он имеет полный механизм обмена сообщениями, гибкие методы настройки и гарантии безопасной доставки сообщений, он бесполезен для сценария LinkedIn по передаче больших объемов данных [28]. Сценарии интеграции больших данных требуют быстрой передачи больших объемов данных журналов на платформу больших данных. Не требуется сложная конфигурация и поддержка протокола AMQP. Больше всего необходим продукт с высокой пропускной способностью, который ActiveMQ не может обеспечить.

На этом фоне в конце 2009 года LinkedIn планировала разработать новое поколение продукта обмена сообщениями Kafka[29,30] для решения проблемы передачи массовых событий отслеживания активности веб-сайтов, показателей мониторинга приложений[31], баз данных и других данных в платформа анализа больших данных. По словам основателя Kafka Джея Крепса, первоначальный дизайн Kafka имел три основных требования [32]: пропускная способность сотен мегабайт данных в секунду на узел, все данные должны сохраняться и данные должны храниться распределенным образом. Самой большой проблемой является требование как высокой пропускной способности, так и устойчивости сообщений. Это дилемма, поскольку обычно, если требуется высокая пропускная способность, программа обычно помещает данные непосредственно в память, а не на диск, поскольку память может считываться быстрее. Если требуется постоянство данных, они обычно хранятся на диске, но скорость чтения с диска будет очень низкой. Что касается этой проблемы, после изучения специального режима хранения и передачи данных в очереди сообщений на основе глубокого и уникального анализа журнала [33] и полного использования характеристик программного и аппаратного обеспечения операционной системы Джей Крепс Команда придумала очень умную схему конструкции [34], которая последовательно записывает данные на диск в виде журналов и последовательно считывает данные журналов. Благодаря особой структуре жесткого диска, последовательная запись на диск может достигать скорости записи более 100 МБ/с, что даже выше, чем случайная запись в память. Kafka также считывает данные последовательно, а благодаря механизму Page Cache операционной системы последовательное чтение с диска также может достичь производительности, близкой к производительности чтения памяти. Таким образом, хотя Kafka записывает сообщения на диск, он достигает скорости чтения и записи, близкой к скорости памяти. В этом секрет высокой пропускной способности Kafka. Конечно, Kafka также использует три технологии: пакетную отправку, сжатие данных и нулевое копирование [35]. Эти технологии значительно улучшают пропускную способность Kafka и обеспечивают сохранение сообщений. Конкретный анализ высокопроизводительного чтения и письма Кафки можно найти здесь [36]. Метод хранения данных Kafka показан ниже. Он делит тему на несколько разделов. При отправке данных производитель записывает данные в разделы в определенном порядке в соответствии с определенными правилами. В Kafka не реализованы некоторые функции сообщений, такие как сообщения о транзакциях, отложенные сообщения, очереди недоставленных писем и т. д.

Модель хранения Кафки[37]

Kafka, разработанный на основе вышеизложенных концепций, обеспечивает очень высокую пропускную способность и в то же время может обеспечить сохранение данных на диске. На рисунке ниже показано сравнение производительности kafka и самых популярных в то время очередей сообщений ActiveMQ и RabbitMQ, проведенное командой Джея Крепса после запуска kafka в LinkedIn [38]. Как видно из рисунка ниже, Kafka имеет более чем в 4 раза преимущество перед двумя другими системами обмена сообщениями в создании и потреблении сообщений.

Kafka был открыт с открытым исходным кодом в конце 2010 года и передан в дар Фонду Apache от LinkedIn в июле 2011 года [39]. 23 октября 2012 года Kafka окончил Apache и стал ведущим проектом с открытым исходным кодом. Kafka использовал свой уникальный метод проектирования для решения распространенных и критических проблем в сценариях интеграции больших данных. После открытия исходного кода он был быстро использован в сценариях анализа больших данных такими интернет-компаниями Кремниевой долины, как Twitter, Netflix и Uber [40].

1 ноября 2014 года члены команды основателей Kafka объявили о своем выходе из LinkedIn и основали компанию Confluent[41], сосредоточив внимание на открытом исходном коде и коммерциализации продуктов Kafka. Benchmark, LinkedIn и др. инвестировали в компанию 6,9 миллиона долларов США. После создания Confluent, чтобы более комплексно решать проблемы анализа больших данных, Kafka последовательно запустила два экологических компонента, Kafka Connect [42] и KsqlDB, в 2016 и 2017 годах, закрепив позицию Kafka как фактического стандарта для передачи данных в область больших данных. Kafka Connect в основном используется для лучшей интеграции Kafka с окружающими продуктами. Например, с помощью MySQL Source Connector пользователи могут лучше извлекать данные об изменениях MySQL в систему Kafka. С помощью Hadoop Sink Connector пользователи могут более удобно записывать данные из Kafka в Hadoop. Kafka KsqlDB предназначена для обработки данных, передаваемых Kafka, в режиме реального времени. Например, процесс передачи больших данных обычно требует операций ETL, таких как фильтрация данных и дедупликация. Эти задачи можно лучше выполнить с помощью KsqlDB Kafka. На рисунке ниже представлена ​​диаграмма экологической архитектуры Кафки после добавления двух компонентов больших данных. Подробный анализ можно найти здесь [43].

Эпоха микросервисов

По мере развития Интернета все больше и больше пользователей сети привлекают демократические способы получения информации и удобный образ жизни. Продолжающийся приход пользователей сети означает дальнейший быстрый рост производительности и волну за волной волн фондового рынка для интернет-компаний. В 2011 году рыночная капитализация Google составляла 180 миллиардов долларов США, а общее количество сотрудников составляло более 24 000 человек[44]. В 2021 году рыночная стоимость Google приблизится к $2 трлн [45], что в 10 раз больше, чем в 2010 году, а количество сотрудников превысит 150 000 человек. Однако прикладное программное обеспечение сталкивается с растущими проблемами. Чтобы справиться с доступом сотен миллионов пользователей Интернета, прикладное программное обеспечение должно подвергнуться структурной перестройке, чтобы обеспечить более беспрепятственный доступ к веб-сайту все большему количеству пользователей.

В этом общем контексте микросервисы вошли в поле зрения многих разработчиков. Любая технология замечается не тогда, когда она изобретена, а тогда, когда она необходима. Микросервисы являются такой технологией. Хотя микросервисы [46] были предложены в 2005 году, они фактически не использовались до 2014 года для реконструкции внутренней системы веб-сайта, чтобы справиться с все большим количеством одновременных обращений. RocketMQ родился из этой необходимости. Чтобы справиться с огромным количеством пользователей, посещающих Double Eleven, веб-сайты Alibaba, такие как Taobao и Tmall, последовательно претерпели микросервисную трансформацию. Раньше система электронной коммерции состояла только из нескольких крупных серверных сервисных программ. Чтобы улучшить возможности одновременной работы всего веб-сайта, серверные службы были реструктурированы в сотни микросервисов. До 2010 года связь с веб-сайтом Taobao осуществлялась через Napoli, платформу обмена сообщениями, созданную на основе ActiveMQ, которая сохраняла сообщения в базе данных [47].

Поскольку система электронной коммерции Alibaba завершает преобразование микросервисов, ключевой проблемой стало обеспечение возможностей асинхронной связи для сотен или тысяч микросервисов. Поскольку Napoli необходимо хранить данные в базе данных, ее пропускная способность очень ограничена и не может поддерживать асинхронную связь в крупномасштабных микросервисных кластерах. После того, как Kafka стал открытым, Alibaba переписала основную логику Kafka на Java и назвала ее MetaQ, надеясь решить проблему асинхронного взаимодействия крупномасштабных микросервисов. Хотя Kafka обладает очень высокой пропускной способностью и возможностями сохранения, он по-прежнему не способен поддерживать крупномасштабные сценарии микросервисов [48]. Существует три основные проблемы: 1. Этот сценарий требует лучшей поддержки функций сообщений, таких как сообщения о транзакциях и отложенные сообщения. Например, пользователи обычно платят после отправки заказа. Если они не платят в течение длительного времени после отправки заказа, заказ будет отменен. В этом сценарии используется возможность задержки сообщений. Kafka не поддерживает эту функцию обмена сообщениями. 2. В сценарии микросервиса требования к качеству отдельного сообщения очень высоки. Если какое-либо сообщение потеряно, это означает, что данные заказа потеряны. Такая ситуация невыносима для бизнеса, и время от времени происходит потеря сообщений Kafka. Изначально Kafka был разработан для повышения пропускной способности сообщений и использовал метод пакетной отправки сообщений, который не способствует безопасности сообщений. Сценарии с большими данными могут допустить потерю одного сообщения, поскольку одно сообщение обычно не влияет на общий вывод анализа больших данных. 3 Когда Kafka создает несколько тем, это очень нестабильно, что серьезно влияет на пропускную способность всей системы. Это во многом связано с разработкой модели системы Kafka.

Учитывая вышеописанную ситуацию, Alibaba самостоятельно разработала продукт для очереди сообщений, который может соответствовать крупномасштабным сценариям микросервисов, и назвала его RocketMQ. RocketMQ можно просто понимать как объединенную версию Kafka и RabbitMQ. RocketMQ реализует такие функции сообщений, как сообщения транзакций, отложенные сообщения и очереди недоставленных писем. Чтобы обеспечить высокую пропускную способность, RocketMQ в целом использует модель хранения Kafka, а также решение последовательного чтения и записи. Однако в целях улучшения качества сообщений RocketMQ не использует метод пакетной отправки и получения сообщений, а отправляет и получает сообщения индивидуально. Кроме того, чтобы решить проблему нестабильной работы модели Kafka в большом количестве сценариев Topic, RocketMQ улучшил механизм хранения данных Kafka. Дизайн Kafka заключается в том, что каждая тема включает в себя несколько разделов, и каждый раздел одновременно записывает только один файл хранилища. Когда файл хранилища заполнен (например, 1 ГБ), запишите следующий файл хранилища. Каталог хранения Kafka показан на рисунке ниже [49].

Такой механизм хранения не вызовет проблем при относительно небольшом количестве тем. В сценариях с большими данными обычно нет необходимости задавать слишком много тем. При использовании в крупномасштабных сценариях микросервисов из-за потребностей бизнеса необходимо настроить множество тем, обычно сотни или даже тысячи. Когда Kafka настраивает сотни топиков, благодаря своей уникальной модели хранения каждый узел Broker будет создавать сотни файлов, а когда будет прочитано много файлов, часть данных будет загружена в Page Cache операционной системы, используя тоже. большое количество Page Cache сделает систему крайне нестабильной. Это также причина того, что производительность Kafka очень низкая при наличии нескольких тем. RocketMQ улучшает это. RocketMQ сохраняет данные во всех разделах одного и того же брокера (называемого очередью сообщений в RocketMQ) в файл журнала. Хотя это будет немного сложнее при чтении, это может решить проблему производительности нескольких тем.

Поскольку RocketMQ решает проблему применения очередей сообщений в крупномасштабных сценариях микросервисов, он привлек большое внимание интернет-компаний после того, как стал открытым исходным кодом. В 2019 году RocketMQ занял первое место в рейтинге «Самое популярное программное обеспечение с открытым исходным кодом в Китае» [50]. До этого многие интернет-компании, такие как Didi, WeBank, Tongcheng-Elong и Kuaishou, использовали Kafka в сценариях анализа больших данных и крупномасштабных сценариях взаимодействия микросервисов. После того, как RocketMQ стал открытым исходным кодом, крупные компании последовательно использовали Kafka в крупных проектах. масштабные сценарии микросервисов. Заменено RocketMQ[51]. На рисунке ниже показан сравнительный тест Didi RocketMQ и Kafka с использованием разных размеров сообщений и разного количества тем [52].

Из теста мы видим, что первый набор данных вверху использует Kafka для начала потребления, а размер каждого сообщения составляет 2048 байт. Количество тем продолжает увеличиваться, и когда оно достигает 256 тем, его пропускная способность резко падает. Вторая группа — RocketMQ, и влияние увеличения темы очень мало. Третья и четвертая группы — это ситуации, когда потребление двух вышеуказанных групп отключено. Выводы в основном аналогичны двум вышеуказанным группам, а общая пропускная способность будет немного выше.

От облачных вычислений к облачным технологиям

Вклад Интернета человечеству – это, конечно, не только демократизация информации, но и рождение для нас технологии облачных вычислений. В 2000 году Amazon, известная платформа онлайн-покупок в США, запустила сервис электронной коммерции под названием Merchant.com[53], чтобы помочь сторонним торговцам создавать веб-сайты онлайн-покупок на основе механизма электронной коммерции Amazon. Чтобы беспрепятственно продвигать проект Merchant.com, Энди Ясси побудил людей полностью реконструировать внутреннюю систему Amazon с помощью API, чтобы обеспечить беспрепятственную интеграцию как внутренних команд, так и сторонних продавцов с механизмом электронной коммерции Amazon. В 2003 году Энди Ясси[54] предложил идею создания операционной системы Интернета, надеясь предоставить большему количеству компаний онлайн-вычисления, хранилища и другую программную инфраструктуру, а также помочь пользователям легче создавать программные системы. В 2004 году AWS запустила свой первый инфраструктурный сервис: Simple Queue Service (SQS) [55]. В 2006 году были последовательно запущены S3 и EC2. К этому моменту базовая структура Amazon для онлайн-веб-сервисов была в основном сформирована, создавая таким образом мировой суперрынок с оборотом более сотен миллиардов долларов [56] - эпоху. началось внедрение облачных вычислений.

Облачные вычисления предоставляют очень хорошие возможности для предприятий, которым необходимо создавать программные системы. С одной стороны, платформы облачных вычислений, такие как AWS, предоставляют виртуальные компьютеры. Им не нужно покупать компьютеры для создания программных систем на платформе AWS. арендовать виртуальные компьютеры AWS. С другой стороны, AWS также предоставляет общие компоненты, такие как очереди сообщений, базы данных и хранилища, что делает создание программных систем очень удобным для пользователей. После 2010 года интернет-компании стали быстро развиваться, а спрос на облачные вычисления становился все сильнее и сильнее. Все интернет-компании являются компаниями-разработчиками программного обеспечения и имеют потребность в создании программных систем. Интернет-компаниям требуется более высокая оперативность и больше внимания к затратам. Облачные вычисления, несомненно, являются лучшим выбором для интернет-компаний. Это видно из финансового отчета AWS. В 2006 году доход AWS составил всего 21 миллион долларов США. С развитием Интернета и ростом энтузиазма глобальных предприятий в отношении цифровой трансформации доходы AWS резко возросли. Глобальный доход в 2021 году превысит 150 миллиардов долларов США, а самая высокая рыночная стоимость Amazon приближается к 2 триллионам долларов США.

NAVIGATING THE REVENUE STREAMS AND PROFIT POOLS OF AWS[57]

В результате углубленного внедрения облачных вычислений на различных предприятиях выявилось множество проблем, среди которых наиболее важным является вопрос стоимости. Многие интернет-компании создают программное обеспечение на основе облачных сервисов от поставщиков облачных услуг и обнаруживают, что их стоимость намного выше, чем покупка серверов раньше. Вам нужно заплатить только один раз за приобретение серверного оборудования, а создание на основе облачных сервисов требует постепенной оплаты. Например, цена покупки 8-ядерного аппаратного сервера 16G на рынке обычно составляет около 17 000 юаней [58]. При покупке 8-ядерного облачного сервера 16G у поставщика облачных компьютеров стоимость годовой аренды составляет 18 000 юаней [59], что эквивалентно цене приобретения аппаратного сервера. Чтобы решить проблему стоимости использования облачных вычислений и позволить предприятиям лучше получать дивиденды от облачных вычислений, в этом контексте была создана технология Cloud Native. Cloud Native — это не только тип технологии, но и концепция. Есть надежда, что предприятия будут использовать собственные методы облачных вычислений для создания программных систем. Каков естественный подход к облачным вычислениям? Во-первых, приложения эластичны и запускаются по требованию. Согласно концепции облачных вычислений, программное обеспечение, созданное в облаке, должно запускаться только тогда, когда это необходимо. Например, если веб-сайт не посещают пользователи, лучше не запускать его. Если его посещает больше пользователей, можно запустить более крупный кластер для поддержки массового посещения пользователей. Поскольку виртуальные машины оплачиваются по мере использования, если веб-сайт, созданный на основе виртуальной машины, запускается при отсутствии доступа, вам все равно придется платить. Поэтому для предприятий лучший способ — иметь такую ​​технологию, которая позволит им создавать программное обеспечение, работающее в зависимости от условий доступа. Бессерверная технология — это такая технология. Бессерверная технология предоставляет корпоративным пользователям ключевую возможность использовать облачные вычисления в исходном виде, то есть программное обеспечение будет запускаться только при необходимости.

Термин «бессерверные» был предложен компанией Iron Company в 2012 году [60]. Как и облачные вычисления, бессерверные продукты уже существуют. В 2008 году Google запустил бессерверный продукт Google App Engine[61]. Как уже говорилось ранее, любую технологию замечают не тогда, когда она изобретена, а тогда, когда она нужна. Это справедливо как для микросервисов, так и для бессерверных сервисов. После того, как AWS запустила бессерверный продукт Lamdba в 2014 году, Lamdba стала внедряться все большим количеством компаний из-за высокого спроса на снижение затрат со стороны интернет-компаний, использующих облачные вычисления. Впоследствии основные поставщики облачных вычислений, такие как Azure и GCP, также запустили соответствующие бессерверные продукты. Университет Беркли, который когда-то успешно предсказал эпоху облачных вычислений, в 2019 году снова написал статью «Упрощенное облачное программирование: взгляд Беркли на бессерверные вычисления» [62], предсказав, что бессерверные технологии станут направлением развития облачных вычислений в следующее десятилетие. В документе также дается определение бессерверных вычислений. Проще говоря, это бессерверные вычисления, которые состоят из FaaS + BaaS (Backend as a Service) для формирования бессерверной архитектуры программного обеспечения. Особенностью является то, что он может быть гибким и платить по требованию. В 2020 году половина пользователей AWS использовали Lamdba для создания своих бизнес-систем. Согласно отчету опроса Datadog, количество вызовов Lamdba в 2021 году выросло на 350% по сравнению с двумя годами ранее.

Бессерверная эра

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

1 EDA заменит SOA и станет типичной парадигмой будущей архитектуры программного обеспечения.

Архитектура, управляемая событиями (EDA) [63] не является новой технологией, но, как уже говорилось выше, любая технология замечается не тогда, когда она изобретена, а тогда, когда она необходима. Нет эпохи, которая бы так нуждалась в технологии EDA, как эпоха бессерверных технологий. Благодаря уникальной функции бессерверного запуска по требованию, запуск бессерверных программ через EDA станет самым популярным режимом. В истории развития архитектуры программного обеспечения шаблон проектирования, основанный на сервис-ориентированной архитектуре (SOA) [64], всегда был главным героем, а RPC всегда был режимом по умолчанию для программного обеспечения с архитектурой SOA, поэтому большинство методов связи между программами раньше были синхронные коммуникации. С появлением бессерверных технологий асинхронная связь может стать главным героем. Рисунок ниже взят из отчета Datadog о бессерверных технологиях[65] за 2022 год.

Среди четырех основных методов запуска Lamdba, помимо API GATEWAY, SQS, EVENTBRIDGE и SNS, используются асинхронные методы. Можно предвидеть, что система обмена сообщениями станет основным источником бессерверных технологий в будущем, и для предприятий станет новой нормой создавать программные системы, управляемые событиями.

2 Serverless соединит все в облаке на основе событий.

Режим синхронной связи RPC сильно отличается от режима асинхронной передачи сообщений. Общение программ через RPC похоже на телефонный звонок, требующий двусторонней связи. После того как одна сторона инициирует запрос, другая сторона должна ответить. Если она не ответит, связь прервется. Более того, программа может одновременно отвечать только на один RPC, а другие программы могут быть только заняты. Асинхронное общение больше похоже на отправку сообщения другому абоненту в Facebook. Независимо от того, находится ли собеседник в сети или нет, на общение не влияет, и вы можете общаться с несколькими людьми одновременно. Бессерверная технология дает огромные преимущества, поскольку использует асинхронную связь, а стоимость интеграции программного обеспечения значительно снижается. Согласно предыдущей концепции проектирования программного обеспечения на основе SOA, максимальное количество микросервисов, включенных в систему, исчислялось сотнями. Слишком большое количество сервисов сделает систему очень сложной, и доступность резко снизится. Системы, построенные с помощью процессов, управляемых событиями, могут поддерживать тысячи бессерверных программ и менее подвержены географическому влиянию. Поскольку связь между службами раньше основывалась на RPC, если две службы пересекают облака или центры обработки данных, связь может прерваться из-за тайм-аутов, сбоев сети и т. д. Эта ситуация значительно упрощается при асинхронной связи.

Благодаря преимуществам асинхронной связи можно строить крупномасштабные бизнес-системы на базе Serverless в облаках и регионах. Это откроет больше возможностей для будущих цифровых предприятий по созданию крупномасштабного искусственного интеллекта, Интернета вещей, автономного вождения и других систем. Например, будущая система IoT должна быть построена на облаке, периферии и терминалах. Облако отвечает за анализ больших данных, периферия отвечает за агрегацию данных и анализ в реальном времени, а терминал отвечает за отчетность и управление данными. исполнение. В то же время этот метод связи дает предприятиям больше возможностей для построения бизнес-систем. В прошлом пользовательские бизнес-системы в основном строились в одном облаке, но бизнес-системы, построенные на нескольких облаках, позволят пользователям избежать привязки к поставщику, снизить затраты и стать более конкурентоспособными. Представьте себе сценарий, в котором пользователям необходимо создать сценарий обработки изображений на основе бессерверной технологии. AWS S3 очень удобен и недорог для хранения изображений, но сервис обработки изображений Google Cloud является более точным и быстрым. Лучшим решением в этом случае является построение связи обработки изображений между облаками на основе событий. Изображение сохраняется в S3 AWS. Всякий раз, когда изображение сохраняется, запускается событие, которое запускает бессерверную программу Google Cloud для вызова службы изображений для завершения обработки изображения.

3 CloudEvents станет новым стандартом де-факто для будущих коммуникаций приложений.

Новая эра требует новых стандартов. Бизнес-системы, созданные пользователями в эпоху бессерверных технологий, характеризуются более масштабными, более широкими возможностями и более диверсифицированными услугами. Первые две характеристики были объяснены выше. Для традиционных систем архитектуры SOA они в основном состоят из ряда разрабатываемых пользователем сервисов, которые относительно просты по составу. Бизнес-системы в эпоху бессерверных технологий включают в себя большое количество бессерверных сервисов, большое количество облачных сервисов (возможно, от разных поставщиков облачных вычислений) и даже устройств Интернета вещей. Требуется частая связь между большим количеством гетерогенных систем в нескольких облаках, что требует унифицированных стандартов данных. С текущей точки зрения CloudEvents, несомненно, является лучшим выбором. CloudEvents — это стандарт, инициированный CNCF для обеспечения переносимости функций и совместимости обработки потока событий между поставщиками облачных услуг. По своей природе он очень хорошо подходит для бессерверных технологий и поддерживается многими бессерверными продуктами, такими как Knative, OpenFaaS, Serverless.com[66] и IBM Cloud Code Engine. В настоящее время на рынке нет продукта для обмена сообщениями, который полностью поддерживает протокол CloudEvents.

При создании программных систем на базе EDA в бессерверную эпоху система обмена сообщениями, несомненно, станет основным базовым компонентом. Однако в настоящее время MQ очень сложно поддерживать отправку и получение событий в бессерверных сценариях. Большая часть нынешнего основного MQ родилась примерно в 2010 году. В то время он в основном разрабатывался для решения больших данных и крупномасштабных сценариев микросервисов. В то время о Serverless почти ничего не знали. Таким образом, если посмотреть на это с точки зрения бессерверной архитектуры, то нынешняя основная архитектура MQ поддерживает прикладное программное обеспечение, созданное на основе бессерверной технологии, что может привести к возникновению множества проблем.

В основном проявляется в четырех аспектах: Первая проблема заключается в том, что традиционный MQ не может напрямую запускать работу бессерверных продуктов, таких как Lamdba. Основная причина заключается в том, что нынешняя прямая связь между потребителями и службами MQ в основном основана на протоколе TCP, будь то Kafka или RabbitMQ. TCP — это протокол, ориентированный на соединение. Перед обменом данными обеим сторонам необходимо установить соединение, и это соединение необходимо поддерживать постоянно. Для бессерверной работы требуется модель связи без установления соединения, поскольку ключевой особенностью бессерверной технологии является запуск по требованию, поэтому TCP-связь использовать нельзя. Таким образом, все текущие основные облачные функции в отрасли, такие как AWS Lambda, Knative, OpenFaaS и т. д., используют для связи протокол Http. Более того, большинство текущих очередей сообщений используют модель потребления Pull, тогда как все текущие основные очереди используют модель Push. Gartner также дальновидно указала на эту проблему в своем отчете за 2020 год о том, как выбрать правильный брокер событий [67].

Вторая проблема заключается в том, что текущая система обмена сообщениями сильно ограничивает гибкость бессерверных приложений. На примере Kafka, согласно модели хранения, каждая тема разделена на несколько разделов. Поскольку в каждом разделе может быть только одно сообщение-потребитель, это означает, что размер кластера нижестоящей системы Kafka, использующей одну тему, не может превышать количество разделов тем. Это не проблема в традиционных сценариях больших данных. Но если нижестоящее приложение Kafka представляет собой бессерверный кластер, проблема будет более серьезной. Потому что даже если в соответствии со стратегией масштабирования в бессерверном режиме появляется много экземпляров потребителей, потребители с более чем разделом могут только простаивать и не иметь возможности потреблять данные [68]. Конечно, разработчики могут вручную изменять и расширять количество разделов, но это не может реагировать на быстро меняющийся бизнес. А когда потребительский кластер на какое-то время сжимается, слишком большое количество разделов будет пустой тратой системных ресурсов.

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

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

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

· Встроенная поддержка HTTP Протокол, сообщение принимается с использованием push режим, нажать режим может отправлять сообщения непосредственно на Serverless Запускается событие завершения работы системы.

· Встроенная поддержка CloudEvents[69] Стандартная отправка событий, CloudEvents Это совершенно новый стандарт взаимодействия с событиями в эпоху облачных вычислений. В настоящее время он получил такую ​​поддержку. Knative、OpenFaaS Подождите, пока появится мейнстрим с открытым исходным кодом. Serverless Поддержка платформы.

· Встроенная поддержка CloudEvents Стандарт может доставлять события непосредственно в Serverless платформа, более удобная.

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

В настоящее время существует относительно мало продуктов для обмена сообщениями, которые могут хорошо поддерживать бессерверные сценарии. Поставщики облачных вычислений, такие как AWS и Azure, могут предоставлять EventBridge, который может быть опцией. EventBridge предоставляет возможность отправлять события для прямого запуска бессерверных программ, а также предоставляет определенные возможности. фильтрация событий и другие возможности. Однако общая проблема с EventBridge, предоставляемым поставщиками облачных услуг, заключается в том, что он позволяет облачным продуктам их собственной компании лучше осуществлять взаимодействие с событиями, но имеет слабую поддержку облачных продуктов и продуктов с открытым исходным кодом, предоставляемых другими компаниями. В результате предприятия используют EventBrigde для завершения передачи сообщений между приложениями, но они попадают в ловушку EventBrigde. История всегда удивительно похожа, что очень похоже на сцену до появления протокола AMQP. Конечно, новые продукты и технологии появятся на свет только тогда, когда будет спрос. Вот несколько очередей сообщений, которые появились за последние два года и больше подходят для бессерверных сценариев.

MQ в эпоху бессерверных технологий

1  Vanus   vanus.ai

Vanus(vanus.ai) Это бессерверная платформа потоковой передачи событий с открытым исходным кодом и встроенными возможностями обработки событий. Он может подключаться к облачным функциям, SaaS, облачные сервисы и базы данных, помогающие пользователям создавать управляемые событиями приложения нового поколения. Ванус Раздельные хранилища и вычислительные ресурсы, Встроенная поддержка CloudEvents стандарт. В то же время он предоставляет универсальные и гибкие возможности фильтрации и преобразования с помощью встроенных функций, которые могут помочь разработчикам обрабатывать события без кода.

Vanus изначально разработан на основе Kubertenes и обладает полными возможностями эластичности. Кластеры можно автоматически масштабировать в зависимости от трафика событий. Vanus очень легкий, его можно развернуть одним щелчком мыши и установить за десятки секунд. Более того, он легко интегрирует бессерверные технологии и может беспрепятственно доставлять события в облачные функции и платформы FaaS, такие как AWS Lambda и Knative.

2 Redpanda  redpanda.com

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

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

3 KubeMQ   kubemq.io

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

KubeMQ построен как набор микросервисов, которые можно развернуть в виде контейнеров в кластере Kubernetes. Он включает в себя такие функции, как организация очереди сообщений, обмен сообщениями публикации/подписки, обмен сообщениями запроса/ответа и обмен сообщениями, управляемыми событиями. Одним из основных преимуществ KubeMQ является то, что он обеспечивает высокую доступность и отказоустойчивость. Он включает в себя такие функции, как автоматическое сегментирование, репликация данных, а также резервное копирование и восстановление данных, которые помогают обеспечить надежную доставку сообщений даже в случае сбоя узла или сбоя сети.

4 memphis  memphis.dev

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

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

Одним из главных преимуществ Мемфиса является его простота и удобство использования. Он предоставляет простой и интуитивно понятный API, который можно использовать с различными языками программирования, включая Rust, Python и Java. Кроме того, он включает в себя веб-консоль управления, которая позволяет пользователям отслеживать трафик сообщений, просматривать статистику и управлять инфраструктурой обмена сообщениями.

Об авторе

Ли Ципенг,vanus.ai Генеральный директор, энтузиаст открытого исходного кода, степень магистра Пекинского университета. Работал в Alibaba Cloud, Apache. RocketMQ PMC , Долгосрочное внимание к проектированию и разработке облачной инфраструктуры и архитектуры промежуточного программного обеспечения.

Ссылки

1. TIBCO Staff.A Look Back: Vivek Ranadivé and TIBCO.TIBCO Blog.January 25, 2013. https://www.tibco.com/blog/2013/01/25/a-look-back-vivek-ranadive-and-tibco/
2. Vivek Ranadivé.Wikipedia. https://en.wikipedia.org/wiki/Vivek_Ranadiv%C3%A9
3. Lawrence M. Fisher.Reuters Is Buying Teknekron.The New York Times.December 18, 1993. https://www.nytimes.com/1993/12/18/business/company-news-reuters-is-buying-teknekron.html
4. TIBCO Software. Wikipedia.https://en.wikipedia.org/wiki/TIBCO_Software
5. LAURA LORENZETT.TIBCO Software goes private with $4.3 billion Vista Equity purchase,FORTURN.September 30, 2014. https://fortune.com/2014/09/29/tibco-software-goes-private-with-4-3-billion-vista-equity-purchase/
6. Introduction to IBM WebSphere MQ. IBM Website. May 27,2022. https://www.ibm.com/docs/en/ibm-mq/7.5?topic=mq-introduction-websphere
7. IBM MQ.Wikipedia.https://en.wikipedia.org/wiki/IBM_MQ
8. Compare Amazon MQ. Apache Kafka, Google Cloud Pub/Sub, and IBM MQ. g2.com.https://www.g2.com/compare/amazon-mq-vs-apache-kafka-vs-google-cloud-pub-sub-vs-ibm-mq
9. IBM MQ. IBM Product Website.https://www.ibm.com/products/mq
10. Application Infrastructure and Middleware Market Share WorldWide 2019-2020.Gartner.2021.
11. Jakarta Messaging. Wikipedia. https://en.wikipedia.org/wiki/Jakarta_Messaging#cite_note-jms-101-spec-4
12. Mark Hapner,Rich Burridge,Rahul Sharma.Java Message Service,October5,1998.https://web.archive.org/web/20001010161718/http://www.java.sun.com/products/jms/jms-101-spec.pdf
13. Apache ActiveMQ. Wikipedia. https://en.wikipedia.org/wiki/Apache_ActiveMQ#cite_note-support-16
14. Martin LaMonica.Investors to commercialize open source.CNET.May 20, 2005. https://www.cnet.com/tech/tech-industry/investors-to-commercialize-open-source/
15. Stefan Tilkov,Floyd Marinescu.IONA acquires LogicBlaze, supporters of ActiveMQ and ServiceMix ESB.InfoQ.APR 10, 2007. https://www.infoq.com/news/2007/04/iona-buys-logicblaze/
16. Advanced Message Queuing Protocol.Wikipedia. https://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
17. RabbitMQ.Wikipedia. https://en.wikipedia.org/wiki/RabbitMQ
18. Acquisitions.VMware Website. https://www.vmware.com/company/acquisitions.html
19. Apache Qpid.Qpid Website.https://qpid.apache.org
20. RabbitMQ VS Apache Qpid.libhunt.https://www.libhunt.com/compare-rabbitmq-server-vs-qpid
21. Rabbit MQ vs Apache QPID - picking your AMQP broker. batey.info. http://www.batey.info/
22. LOVISA JOHANSSON(September 23, 2019),Part 1: RabbitMQ for beginners - What is RabbitMQ? ,CloudAMQP Blog. https://www.cloudamqp.com/blog/part1-rabbitmq-for-beginners-what-is-rabbitmq.html
23. INTERNET GROWTH STATISTICS.internetworldstats.com. https://www.internetworldstats.com/emarketing.htm
24. Numbers of LinkedIn members from 1st quarter 2009 to 3rd quarter 2016. statista.com . October 2016.https://www.statista.com/statistics/274050/quarterly-numbers-of-linkedin-members/
25. Big data architecture style. microsoft.com. https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/big-data
26. Lambda architecture. Wikipedia.https://en.wikipedia.org/wiki/Lambda_architecture
27. Jay Kreps.The Evolution of Apache Kafka: From In-House Infrastructure to Managed Cloud Service.YouTube.Feb 25,2022. https://www.youtube.com/watch?v=SQX6nGS5RcA
28. Tanvir Ahmed.Kafka's origin story at LinkedIn.Linkedin.Oct 20,2019. https://www.linkedin.com/pulse/kafkas-origin-story-linkedin-tanvir-ahmed/ .
29. Daniel Gutierrez .A Brief History of Kafka, LinkedIn’s Messaging Platform .insidebigdata.com.April 28, 2016.https://insidebigdata.com/2016/04/28/a-brief-history-of-kafka-linkedins-messaging-platform/
30. Jay Kreps on the Last 10 Years of Apache Kafka and Event Streaming.confluent website.
31. Apache Kafka.hadoopadmin.co. http://www.hadoopadmin.co.in/hadoop-developer/kafka/https://www.youtube.com/watch?v=aJuo_bLSW6s
32. Jay Kreps. Apache Kafka and Real-Time Data Integration.YouTobe.June26, 2016. https://www.youtube.com/watch?v=aJuo_bLSW6s
33. Jay Kreps.The Log: What every software engineer should know about real-time data's unifying abstraction.Linkedin.December 16. 2013. https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
34. Ken Goodhope, Joel Koshy, Jay Kreps, Neha Narkhede, Richard Park, Jun Rao, Victor Yang Ye.Building LinkedIn’s Real-time Activity Data Pipeline.Computer Science.2012. http://sites.computer.org/debull/A12june/pipeline.pdf
35. Zero-copy. Wikipedia. https://en.wikipedia.org/wiki/Zero-copy
36. Talk about Kafka: why is Kafka so fast? developpaper.com . Oct 10, 2021. https://developpaper.com/talk-about-kafka-why-is-kafka-so-fast/
37. Kafka 3.2 Documentation.Kafka Website.https://kafka.apache.org/documentation/#introduction.
38. Jay Kreps, Neha Narkhede, and Jun Rao. Kafka: a distributed messaging system for log processing. ACM SIGMOD Workshop on Networking Meets Databases, page 6, 2011. https://engineering.linkedin.com/content/engineering/en-us/blog/authors/j/jay-kreps
39. Neha Narkhede.First Apache release for Kafka is out!.Linkedin Engineering.January 6, 2012. https://engineering.linkedin.com/kafka/first-apache-release-kafka-out
40. Jun Rao,Jay Kreps.Apache Kafka Users.Apache Kafka website.July 25,2106. https://cwiki.apache.org/confluence/display/KAFKA/Powered+By
41. Jay Kreps.Announcing Confluent, a Company for Apache Kafka and Realtime Data.Confluent Blog.NOV 1, 2014. https://www.confluent.io/blog/announcing-confluent-a-company-for-apache-kafka-and-real-time-data/
42. Open Source Kafka Connect Adds More than a Dozen Connectors. Confluent Blog.April 22, 2016. https://www.confluent.io/press-release/open-source-kafka-connect-adds-more-than-a-dozen-connectors/
43. Navdeep Sharma.Understanding the EcoSystem of Apache Kafka.medium.Aug 9, 2019. https://medium.com/@navdeepsharma/the-ecosystem-of-apache-kafka-6087b621d16f
44. Alphabet: Number of Employees 2010-2022 | GOOG.macrotrends.2022. https://www.macrotrends.net/stocks/charts/GOOG/alphabet/number-of-employees
45. Market cap history of Alphabet (Google) from 2014 to 2022.companiesmarketcap.June 2022. https://zh.m.wikipedia.org/wiki/Google
46. Microservices.Wikipedia. https://www.infoq.cn/article/79tlsolfsktqsg9obwwd
47. Von Gosling,Wang Xiaorui.Apache RocketMQ - Trillion Messaging in Practice.YouTobe.May 22,2017. https://www.youtube.com/watch?v=H9HGE9VOimY .
48. Фэн Цзя с нетерпением жду Apache RocketMQ5.0 Рассказываем о прошлом, настоящем и будущем RocketMQ.Likes.2018 https://www.likecs.com/show-204717665.html.
49. https://img-blog.csdnimg.cn/785b9ba8492e45d9841193de2960c784.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5py65pm65YW1,size_20,color_FFFFFF,t_70,g_se,x_16
50. Самое популярное китайское ПО с открытым исходным кодом в 2019.2019.Ощина https://www.oschina.net/project/top_cn_2019.
51. Apache RocketMQ. https://rocketmq.apache.org/users/
52. Цзян Хайтинг. Диди Чусин создает очередь корпоративного уровня на базе RocketMQ. сообщений Служитьизупражняться.CSDN. November 6, 2018. https://blog.csdn.net/b6ecl1k7BS8O/article/details/83805620
53. Ron Miller.How AWS came to be.TechCrunch.July 2, 2016.       https://techcrunch.com/2016/07/02/andy-jassys-brief-history-of-the-genesis-of-aws/
54. Kevin McLaughlin.Andy Jassy: Amazon's $6 Billion Man.CRN.August 04, 2015. https://www.crn.com/news/cloud/300077657/andy-jassy-amazons-6-billion-man.htm
55. Jeff Barr.The AWS Blog: The First Five Years.09 NOV 2009.AWS Website https://aws.amazon.com/cn/blogs/aws/aws-blog-the-first-five-years/
56. Гоцян Ян.IDC: В 2021 году мировой рынок облачных вычислений превысит 90 миллиардов долларов США, а рыночная доля Alibaba Cloud займет третье место в мире, STCN, 28 апреля 2022 года. https://www.stcn.com/company/gsdt/. 202204/t20220428_4466952.html
57. Timothy Prickett Morgan.NAVIGATING THE REVENUE STREAMS AND PROFIT POOLS OF AWS.The Next Platform.February 5, 2018. https://www.nextplatform.com/2018/02/05/navigating-revenue-streams-profit-pools-aws/
58. Параметры стоечного сервера Dell PowerEdge R750xs, Pconline https://product.pconline.com.cn/server/dell/1453647_detail.html.
59. Облачный сервер CVM, Tencent Cloud.https://buy.cloud.tencent.com/price/cvm/calculator?devPayMode=hourly®ionId=33&zoneId=330001&instanceType=S6.2XLARGE16&imageType=linux&systemDiskType=CLOUD_PREMIUM&systemDiskSize=50&bandwidthType=TRAFFIC_POSTPAID_BY_HOUR&bandwidth=5&timeSpan=12&hourlyValue=12
60. Луо Хао. Узнайте о происхождении, разработке и внедрении бессерверной технологии в одной статье. 18 января 2022 г. https://blog.csdn.net/yunqiinsight/article/details/122565912.
61. Serverless computing.Wikipedia.https://en.wikipedia.org/wiki/Serverless_computing
62. University of California at Berkeley.Cloud Programming Simplified: A Berkeley View on Serverless Computing.February 10, 2019. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf
63. Event-driven architecture.Wikipedia.https://en.wikipedia.org/wiki/Event-driven_architecture
64. Service-oriented architecture,Wikipedia. https://en.wikipedia.org/wiki/Service-oriented_architecture
65. The state of Serverless.Datadog.June, 2022.https://www.datadoghq.com/state-of-serverless/
66. Serverless.com.https://www.serverless.com/
67. Gary Olliffe.Choosing Event Brokers: The Foundation of Your Event-Driven Architecture. Gartner. June 22,2020.page 12.
68. Best message queue for HPA on kubernetes.Reddit.2022.https://www.reddit.com/r/kubernetes/comments/uk8pj5/best_message_queue_for_hpa_on_kubernetes/
69. Why CloudEvents?.CloudEvents. https://cloudevents.io/