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

Текст｜Ма Чжэньцзюнь (название цветка: древнее и современное)

Лет работы в сфере инфраструктуры

В настоящее время в команде промежуточного программного обеспечения Ant Group

Отвечает за разработку таких проектов, как MOSN и Layotto.

Вычитка｜Чжо Юй, Ци Тянь

Эта статья 9053 слов прочитана 18 минут

| Предисловие |

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

Однако сервисная сетка — это не серебряная пуля, и после масштабного внедрения она также сталкивается с новыми проблемами.

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

Рассматривая весь процесс эволюции Ant Group от микросервисной архитектуры до Service Mesh и распределенной среды выполнения приложений, в этом документе делается попытка обсудить облачную среду выполнения в следующие пять лет, объединив различные проблемы и мысли, возникающие в процессе производства и внедрения. направления развития.

ЧАСТЬ 1. От Service Mesh к среде выполнения приложений

В 2018 году Ant Group вложила значительные средства в это направление, когда Service Mesh впервые стала популярной, и вот уже более трех лет. Sevice Mesh уже широко внедрена в компании, поддерживая ежедневную работу сотен тысяч контейнеров в производственной среде.

Во второй половине 2019 года проект Dapr был официально открыт и продолжал пользоваться популярностью.Концепция среды выполнения приложений привлекла внимание людей, и Ant Group также встала на путь эволюции от Service Mesh к среде выполнения приложений.

A. Преимущества и остающиеся проблемы практики Ant Service Mesh

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

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

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

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

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

Увидев огромный потенциал концепции Service Mesh, Ant Group быстро вложила значительные средства в это направление.Как показано на рисунке выше, первым из них является использование языка Go для разработки плоскости данных, которая может выполнять бенчмаркинг envoy. Затем различные возможности управления RPC переносятся в MOSN, так что SDK RPC становится «облегченным», в то время как SDK других инфраструктур по-прежнему сохраняет статус-кво.

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

Б. Исследование предварительной пан-Сети муравьев

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

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

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

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

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

Аналогично вышеперечисленным проблемам, после трансформации pan-Mesh низкая стоимость разработки «легкого» SDK позволяет различным разнородным языкам иметь возможность доступа ко всей инфраструктурной системе и получать дивиденды от многолетнего строительства инфраструктуры.

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

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

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

ЧАСТЬ 2 Переопределение границ инфраструктуры

А. Как посмотреть дапр

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

На приведенном выше рисунке представлена схема архитектуры, официально предоставленная Dapr.Подобно архитектуре Service Mesh, Dapr использует модель sidecar для развертывания между приложениями и инфраструктурой. Но разница в том, что Dapr предоставляет приложениям набор семантически четких, ориентированных на возможности API-интерфейсов, основанных на стандартных протоколах, таких как HTTP/gRPC, так что приложения могут больше не заботиться о деталях реализации инфраструктуры, а только сосредоточиться на том, какие возможности сам бизнес зависит от.

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

В дополнение к возможностям официальные лица Dapr также указали сходства и различия между Dapr и Service Mesh, как показано на рисунке выше.

Хоть и есть некоторые пересечения, но суть в другом, Service Mesh делает акцент на прозрачном сетевом агенте, ему плевать на сами данные, а DAPR делает упор на возможность предоставления возможности, и верно думать о том, как сократить приложение , стоимость.

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

В то же время взаимодействие между Dapr и инфраструктурой не может быть отделено от сети, поэтому существует ли решение, которое может объединить среду выполнения приложения с Service Mesh, чтобы снизить затраты на разработку приложений, сохранив при этом широкие возможности управления сетью?

B. Layotto: Комбинация Swords Servcie Mesh и Application Runtime

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

Кроме того, основываясь на опыте внутренней производственной эксплуатации и обслуживания Ant Group, Layotto также абстрагировала набор API-интерфейсов для PaaS. Основная цель — показать рабочее состояние приложения и самого Layotto платформе PaaS, чтобы SRE мог быстро понять текущее состояние приложения.Уменьшить расходы на ежедневную эксплуатацию и техническое обслуживание.

C. Стандартизация API: инструмент для кроссплатформенного развертывания

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

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

D. Почему бы не решить все в одной коляске?

Самый большой вывод из проекта Dapr заключается в том, что он определяет границы между приложениями и инфраструктурой, но приложениям нужно нечто большее. Dapr дает нам хорошую идею и является хорошим началом, но он не может полностью охватить то, что мы хотим Мы надеемся полностью определить границу между приложениями и зависимыми ресурсами и может охватывать системные ресурсы, инфраструктуру, ограничения ресурсов и т. д. Чтобы быть «настоящей» средой выполнения приложения, приложению не нужно сосредотачиваться на каких-либо других ресурсах, кроме бизнес-логики.

Судя по текущей реализации идеи Sidecar, будь то Dapr, MOSN или Envoy, он решает проблему применения к инфраструктуре. Для системных вызовов ограничения ресурсов и другие аспекты по-прежнему выполняются самим приложением.Эта часть операции не должна проходить через какие-либо промежуточные звенья, и ею трудно управлять единообразно, если она не перенята. сетевой трафик, если нет единого входа и выхода, естественно будет управляться. В то же время, если системные ресурсы, доступные приложению, нельзя точно контролировать, всегда будут существовать риски безопасности.

E. Единая граница: амбиции Лайотто

В то время как начальная фаза Layotto аналогична Dapr, присутствует как форма приложения во время выполнения.

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

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

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

Хотя цель была ясна, какую форму существования примет Лайотто для достижения этой цели — это первый вопрос, с которым мы сталкиваемся.

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

ЧАСТЬ 3 Следующие пять лет: будет ли функциональность следующей остановкой?

А. Лайотто и функциональное будущее муравьев

Я полагаю, что все знакомы с вычислением функций, но есть ли лучший способ попробовать саму функцию, кроме как запустить ее как независимый процесс? Чтобы ответить на этот вопрос, сначала рассмотрим развитие технологии виртуализации.

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

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

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

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

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

Окончательная функциональная модель, которую мы ожидаем, показана на рисунке выше:

Подниматься:

1. Сама функция может быть разработана на любом языке, чтобы лучше соответствовать все более разнообразным требованиям бизнеса.

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

Спускаться:

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

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

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

C. WebAssembly (wasm) на пороге

WebAssembly, или сокращенно wasm.

Хотя изначально предполагалось, что язык программирования на стороне сервера будет работать в браузере для решения проблем с производительностью JavaScript, из-за различных превосходных функций этой технологии люди очень надеются, что ее можно будет использовать в среде, отличной от браузера. Так же, как Node.js позволяет запускать JavaScript на сервере, сообщество WebAssembly также предоставляет различные среды выполнения для поддержки запуска файлов *.wasm на сервере.

У WebAssembly, как у любимой технологии, есть неотъемлемые преимущества, которые не могут заменить другие технологии:

1. Независимый от языка, кроссплатформенный

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

2. Безопасность, небольшой размер

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

3. Среда исполнения «песочница»

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

Несмотря на то, что эта технология имеет огромный потенциал развития, в настоящее время все еще существует много недостатков для фактической реализации в фоновой производственной среде:

1. Многоязычная поддержка

Целью WebAssembly является поддержка компиляции с разных языков, но в настоящее время различные основные языки поддерживают его в разной степени.Поддерживаемые языки — c/c++/rust и другие компилируемые языки.К сожалению, эти языки не подходит для разработки общих С точки зрения бизнес-логики, стоимость начала работы является большой проблемой. Для основных сценариев Java и Go в бизнес-сценариях их поддержка WebAssembly очень ограничена, чего недостаточно для поддержки реализации этой технологии в производственной среде.

2. Экологическое строительство

В реальной производственной среде проблема позиционирования в сети — это то, с чем мы сталкиваемся каждый день. В Java есть различные команды и сторонние инструменты, такие как arthas. Pprof Go также является отличным инструментом анализа производительности, но как выполнить wasm в работе? Устранение неполадок, таких как элегантная печать стека ошибок или отладка, все еще находится на ранних стадиях.

3. Различные возможности среды выполнения неравномерны

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

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

D. Будущее функциональных приложений Layotto и Ant

Если в будущем функции будут использоваться как еще одна базовая модель НИОКР с тем же статусом, что и текущая микросервисная архитектура, нам необходимо рассмотреть экологическую конструкцию всей функциональной модели, и эта конструкция фактически построена вокруг предельной итерационной эффективности, включая, но не ограничивается следующими пунктами:

1. Базовая структура

Благодаря поддержке технологии WebAssembly сама функция может быть разработана на множестве основных языков, но для того, чтобы лучше управлять каждой функцией, студентам, изучающим бизнес, по-прежнему необходимо следовать определенным шаблонам в процессе разработки, например, когда функция загружена, будет выполнен метод start(), который может выполнить некоторую работу по инициализации, и метод destroy() будет выполнен при выгрузке, который может выполнить некоторую работу по очистке.

2. Разработка и отладка

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

3. Развертывание пакета

В настоящее время основные приложения упаковываются в war, jar или напрямую компилируются в исполняемые файлы целевой операционной системы при развертывании.В системе функций приложения компилируются в файлы *.wasm, которые по умолчанию могут работать в различных операционных системах.

4. Управление жизненным циклом + планирование ресурсов

Теперь, когда K8s стал стандартом де-факто для планирования управления контейнерами, то, как интегрировать планирование функций в экосистему K8s, также является основным направлением нашего исследования.

Что касается рабочей модели, как показано на рисунке выше, помимо поддержки режима Sidecar, Layotto использует технологию WebAssembly, позволяющую запускать функции в форме wasm непосредственно в Layotto. В этом режиме взаимодействие между функциями и Layotto использует локальные вызовы Мы называем этот уровень API Runtime ABI, который эволюционировал из Runtime API.Например, если функция хочет запросить ключ из кеша, ей достаточно вызвать локальный метод proxy_get_state.

Что касается планирования, K8s теперь стал стандартом де-факто, поэтому необходимо решить, как функция в форме wasm интегрируется в экосистему K8s. Здесь мы должны сосредоточиться на двух вопросах:

1. Какая связь между wasm и зеркалированием?

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

2. Как разрешить K8s управлять и развертывать wasm?

Единицей планирования K8s является модуль Pod.Как изящно соединить модуль планирования с модулем планирования wasm и позволить нескольким функциям wasm выполняться в одном процессе, также является сложной проблемой.

Изучив некоторые исследовательские решения от сообщества, мы разработали набор собственных решений для реализации. В целом, K8s поддерживает разработчиков для расширения среды выполнения контейнера на основе спецификации OCI Containerd.В настоящее время существуют хорошо известные решения для реализации контейнеров безопасности, такие как Kata и gVisor, основанные на этой спецификации.Поэтому в Layotto мы также используем Containerd-based Расширения реализуют сценарии выполнения контейнеров. В общем плане есть два ключевых момента:

1. Этап создания образа

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

2. Запланируйте этап развертывания

Мы внедрили подключаемый модуль containerd-shim-layotto-v2.После того, как K8s получит запрос на планирование Pod, он передаст реальную логику обработки в Kubelet, а затем передаст ее нашему пользовательскому подключаемому модулю через Containerd. Файл *.wasm будет извлечен из целевого образа для загрузки и запуска Layotto. В настоящее время Layotto интегрирует wasmer в качестве среды выполнения wasm.

Конечный эффект использования всей схемы расписания показан на рисунке выше.Для разрабатываемой функции сначала скомпилируйте ее в файл *.wasm, а затем встройте в образ.В процессе развертывания вам нужно только указать runtimeClassName в файле yaml как Layotto Вот и все. Последующие операции, такие как создание контейнеров, просмотр состояния контейнеров и удаление контейнеров, сохраняют семантику K8s, что не требует дополнительных затрат на обучение для студентов SRE.

В настоящее время весь процесс находится в открытом доступе в сообществе Layotto.Заинтересованные студенты могут обратиться к нашему документу QuickStart [1] для получения опыта.

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

Что касается инструментов разработки, в дополнение к локальным IDE, все больше и больше людей могут выбирать облачные IDE для разработки, что значительно повысит эффективность совместной работы разработчиков. Затем наступает этап развертывания.Для некоторых облегченных бизнес-сценариев развертывание может выполняться по функциональной модели, для традиционного бизнеса может быть сохранена модель BaaS.В то же время, при повышенных требованиях к безопасности, возможное решение заключается в развертывании бизнеса Deployed в безопасном контейнере, таком как Kata.

Благодаря зрелости технологии Unikernel все больше и больше людей могут попробовать себя в этом направлении, например, поместить Layotto в ядро, а затем скомпилировать и развернуть его вместе с приложением.

Что еще более важно, независимо от того, какая модель развертывания будет использоваться в будущем, исходя из присущей Layotto мобильности, операционный и обслуживающий персонал может развертывать приложения на любой платформе по своему желанию, и это переключение полностью прозрачно для разработчиков!

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

ЧАСТЬ 4 Открытый исходный код и беспроигрышный вариант

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

A. Сообщество Dapr: стандартизация API

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

B. Сообщество WebAssembly: экологическая конструкция

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

1. Многоязычная поддержка

Как упоминалось ранее, языки, которые лучше поддерживают WebAssembly, дороже для разработки бизнес-логики, поэтому мы надеемся, что с развитием сообщества мы сможем лучше поддерживать распространенные языки разработки бизнеса, такие как Java, Go и JS.

2.WASM ABI

Это в основном для определения API, используемого для взаимодействия между функцией wasm и Layotto. В сообществе были предприняты некоторые попытки, и мы надеемся добавить определение Runtime ABI на этой основе, чтобы функции могли более удобно вызывать инфраструктуру.

3. Экологическое строительство

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

C. Сообщество Layotto: изучение микросервисов и функций

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

1. Модель коляски

В этой модели приложение взаимодействует с Layotto через Runtime API на основе протокола gRPC, что также является самой простой моделью для реализации в настоящее время.

2. Модель FaaS

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

｜Послесловие｜

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

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

"Ссылаться на"

【1】QuickStart