Автор | Ву Пэн технический эксперт Alibaba

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

В последние два года разработчики все чаще и чаще сообщают о концепции бессерверных технологий, и обмен темами демонстрирует взрывную тенденцию. 20 тем о бессерверных в 2018 году, а в 2019 году их количество увеличится до 35.

На уровне бессерверных продуктов, от самого раннего AWS Lambda до Azure Functions, Goolge Functions, Google CloudRun и отечественного Alibaba Cloud без сервера Kubernetes, бессерверного механизма приложений, функциональных вычислений и т. д., бессерверная облачная инфраструктура, ориентированная на вычисления, становится все более популярной. более обильный.

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

Глядя на Serverless из ежедневной итерации

фигура 1

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

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

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

фигура 2

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

изображение 3

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

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

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

Чтобы ускорить итерацию, части, которые требуют много времени и энергии, должны быть решены по очереди, как показано на рисунке 4:

Рисунок 4

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

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

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

Введение в бессерверные технологии

В Википедии есть более полное руководство по Serverless.определение:

Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

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

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

Serverless computing can simplify the process of deploying code into production. Scaling, capacity planning and maintenance operations may be hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.

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

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

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

Бесплатная эксплуатация и обслуживание (эксплуатация и обслуживание серверов, управление мощностями, эластичное масштабирование и т. д.)
Плата за использование ресурсов

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

Бессерверная модель разработки

Мартина Фаулераэта статьяС точки зрения архитектуры модель разработки без серверов полностью объяснена. Вот краткое изложение. Основное внимание уделяется трем пунктам:

Модель развития, управляемая событиями
Автоматическое эластичное масштабирование
OpenAPI

Внедрение бессерверной разработкиМодель, управляемая событиями, архитектура разработана для создания и реагирования на такие события, как запросы HTTP/HTTPS, время и сообщения. В такой модели ядром является процесс производства и обработки Событий, а весь процесс обслуживания управляется Событием, и внимание сосредоточено на всем процессе обработки. Чем глубже понимание бизнеса, тем больше будет соответствие типа мероприятия и бизнеса, и тем эффективнее будет взаимное продвижение между технологиями и бизнесом.

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

пройти черезстатьяДва изображения могут быть более интуитивно поняты:

Рисунок 5

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

Изображение 6

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

Концептуальное различие между Serverless и PaaS (платформа как услуга) и CaaS (контейнер как услуга) заключается в том,Автоматическое эластичное масштабированиеВ качестве основной функции в начале концепции.

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

С точки зрения разработки, изображения могут использоваться для доставки или упаковки на уровне языка (например, war/jar в Java), а платформа отвечает за работу, связанную с выполнением. Он также может пойти еще дальше, приняв концепцию FaaS, полагаясь на платформу или стандартизированные решения FaaS, предоставляя только функции бизнес-логики, а платформа отвечает за вопросы времени выполнения, такие как ввод запросов, вызов запросов и автоматическое эластичное масштабирование.

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

Бессерверная модель обслуживания

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

Бесплатная эксплуатация и обслуживание (эксплуатация и обслуживание серверов, управление мощностями, эластичное масштабирование и т. д.)
Плата за использование ресурсов

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

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

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

Модель бессерверных услуг должна соответствовать фактическим потребностям.Возвращаясь к рисунку 4, модель бессерверных услуг поставщиков облачных услуг можно разделить на следующие категории:

Платформа экземпляра ресурса
Платформа планирования
Платформа управления приложениями
Платформа управления бизнес-логикой

В совокупности это:

Рисунок 7

Отраслевые бессерверные продукты

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

Рисунок 8

Платформа экземпляра ресурса

Зарубежные AWS Fargate / Azure ACI и отечественные Alibaba Cloud ECI / Huawei CCI имеют большое влияние и предоставляют пользователям услуги группы контейнеров. Группа контейнеров в целом представляет собой концепцию, аналогичную поду в Kubernetes. Пользователи могут напрямую создавать группы контейнеров с помощью вызовов OpenAPI без необходимости покупать и настраивать серверы перед развертыванием служб, а также делегировать управление емкостью, эксплуатацию и обслуживание, связанные с ресурсами. Пользователи могут использовать платформу экземпляров ресурсов в качестве пула ресурсов с достаточной емкостью, выполнять детальное приложение ресурсов на уровне группы контейнеров и выполнять управление емкостью на уровне приложения с динамическим расширением и сокращением.

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

платформа планирования

Kubernetes является стандартом де-факто для контейнерного планирования.С одной стороны зарубежные AWS EKS и отечественные Alibaba Cloud Serverless Kubernetes размещают компоненты Kubernetes Master, а с другой стороны используют сервисы управления ресурсами, такие как VirtualKubelet + AWS Fargate или VirtualKubelet + Alibaba Cloud ECI для предоставления услуг уровня Kubernetes Node.

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

Платформа управления приложениями

Зарубежный Google GAE / CloudRun, отечественный движок приложения Alibaba Cloud Serverless и т. д. Дальнейшая эксплуатация сервиса и работы по техническому обслуживанию, такие как управление выпуском (упаковка / оттенки серого / пакетная обработка / откат / контроль версий и т. д.), журнал / мониторинг / сигнализация, управление трафиком , эластичное масштабирование и т. д., пользователи могут дополнительно сосредоточиться на потребностях бизнеса и низкой стоимости эксплуатации и обслуживания.

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

Платформа управления бизнес-логикой

На основе управления приложениями, такими как зарубежные AWS Lambda / Azure Functions / Google Functions, отечественные облачные вычисления Alibaba Cloud Function Computing / Tencent Cloud Functions / Huawei Function Workflow и т. д., сделать общую логику процесса разработки прозрачной и только для пользователей нужно заботиться о бизнес-логике. Этот процесс можно сравнить с процессом написания юнит-теста в процессе разработки, ввод и вывод общие, а отличия только в логике обработки. Этот тип бессерверного продукта также является наиболее обсуждаемой формой в отрасли, представляя отраслевую абстракцию идеального процесса разработки, которая может еще больше ускорить процесс итерации и сократить время от идеи до запуска. Этот тип бессерверного продукта более тесно интегрирован с другими типами продуктов облачной платформы, чтобыBaaSФорма использует услуги облачной платформы для реализации общей логики, такой как хранение, кэширование и т. д., и имеет определенные неявные требования к богатству продуктов облачной платформы.

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

Выбор

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

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

Соответствует ли текущий этап бизнес-технологий позиционированию облачных продуктов
Будет ли быстрая итерация бизнеса ограничена разработкой самих облачных продуктов?
Насколько стабилен облачный продукт?
Могут ли облачные продукты продолжать приносить бизнесу технологические дивиденды?

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

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

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

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

резюме

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

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

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

References

В Википедии есть более полное определение Serverless.
Serverless Architectures
Модель, управляемая событиями
BaaS
От DevOps к NoOps: как внедрить бессерверную технологию
Экземпляр эластичного контейнера Alibaba Cloud ECI
ACK службы облачных контейнеров Alibaba
Бессерверное облако Alibaba Kubernetes (ASK)
Механизм бессерверных облачных приложений Alibaba (SAE)
Облачные вычисления Alibaba
Облачный бессерверный рабочий процесс Alibaba
Cloud Programming Simplified: A Berkeley View on Serverless Computing

Выбор бессерверной архитектуры: углубленная интерпретация бессерверной архитектуры и выбор платформы