Преимущества безсерверных
В процессе разработки приложений AWS Serverless с использованием Serverless Framework самое удобное то, что первое развертывание ничем не отличается от второго и третьего развертывания. просто выполнитьserverless deploy, и через несколько минут наш код запускается онлайн. Если это традиционное приложение AWS, мне нужно подключиться к моему серверу по SSH для развертывания, чтобы я мог написать свой сценарий автоматического развертывания. Кроме того, мне также нужно беспокоиться о том, какие пользователи используют в этом процессе.
Кроме того, я думаю, что развертывание удобно, а цена разумна. У меня есть свой блог и несколько других сетей, работающих на моем экземпляре AWS EC2. Однако мой блог с PV всего около 500 проводит большую часть времени в режиме ожидания. Это кажется немного расточительным, но Serverless, который взимает плату только за работу, не будет иметь такой проблемы. Позволяет мне смело пользоваться этими услугами. Конечно, есть и другие весомые преимущества.
Сокращение затрат на запуск
Когда мы разрабатываем веб-приложение как компания, нам нужен сервер управления версиями, сервер непрерывной интеграции, тестовый сервер, репозиторий управления версиями приложений и другие основные службы во время разработки. При работе в сети, чтобы справиться с большим количеством запросов, нам нужен хороший сервер базы данных. Когда наше приложение предназначено для обычных пользователей, нам необходимо:
- Почтовый сервис для отправки напоминаний, регистрации и других сервисов
- Служба SMS (в соответствии с национальными правилами использования реальных имен), используемая для операций авторизации пользователя, таких как регистрация и вход в систему.
Для крупных компаний это готовая инфраструктура. Но для новых стартапов это все стартовые затраты.
Сокращение эксплуатационных расходов
Что касается стартапов, то у них нет ни инфраструктуры, ни финансовых ресурсов, и, вероятно, у них нет возможности построить инфраструктуру. Переход на облачные сервисы часто является лучшим вариантом и может сэкономить много денег. Они могут сосредоточиться на: создании продуктов, которые ценны для пользователей. Если стартап использует облачные сервисы вместо создания собственных серверов. Тогда у него будетбольше времениВместо того, чтобы сосредотачиваться на них, развивайте бизнес-функции. Платите только за программное обеспечение во время его выполнения.
с использованиемфункциональные вычисленияСамая большая разница между бессерверным и облачным сервером заключается в следующем:Облачные серверы должны работать постоянно, а функциональные вычисления — это вычисления по запросу.. Вычисления по требованию означают, что функции запускаются только при поступлении запроса. Когда нет запроса, нет денег.
На ранней стадии проекта количество пользователей имеет тенденцию к медленному росту, и когда мы выбираем сервер, мы часто оцениваем на основе возможных пользователей. В это время некоторые ненужные затраты часто тратятся впустую. Однако бессерверные приложения легко справляются даже с внезапным всплеском пользователей. Нужно только изменить конфигурацию базы данных, а затем повторно развернуть копию.
Сокращение затрат на разработку
Успешный поставщик бессерверных услуг должен быть в состоянии предоставить рядВспомогательные услуги. Это означает, что вам нужно только написать имя таблицы этой базы данных в файле конфигурации, тогда наши данные будут храниться в соответствующей базе данных. Даже если поставщик услуг предоставляет серию шаблонов расчета функций, нам нужно только написать нашу конфигурацию. Эта серия вещей может быть сделана автоматически и эффективно.
при этих обстоятельствах,Использование определенного облачного сервиса так же просто, как вызов API, который поставляется с определенной системой..
Конечно, разработка приложения без сохранения состояния может быть проблемой для ранних систем. Кроме того, такая огромная система, как AWS, не может быть легко освоена начинающими программистами.
Реализуй быстро онлайн
Для веб-проекта запуск проекта требует серии привет, мир. Когда мы создаем среду локально, это привет, мир, а когда мы развертываем программу в среде разработки, это также привет, мир, связанный с развертыванием. Выглядит немного иначе, но в целом работает!
Преимущества бессерверного развертывания облегчают вам выход в Интернет.
Более быстрый конвейер развертывания
На самом деле бессерверные приложения имеют преимущество при развертывании, поскольку они эквивалентныВстроенное автоматическое развертывание- По мере разработки наших приложений мы постоянно совершенствовали возможности развертывания.
В нашей повседневной разработке, чтобы добиться автоматического развертывания, нам нужно сначала выполнить развертывание вручную, чтобы разработать соответствующую и безошибочную конфигурацию развертывания, такую как Dockerfile от Docker или playbook от Ansible. Кроме того, нам также необходимо разработать функции сине-зеленого выпуска и так далее.
В функциональных вычислениях и бессерверных приложениях все эти функции предоставляются поставщиком. Каждый раз, когда мы заканчиваем писать код, нам просто нужно запустить:sls deployБудет достаточно. В функциях вычислений, таких как AWS Lambda, функции обычно готовы к вызову в течение нескольких секунд после загрузки.
Это означает, что, как и каждый день, мы используем шаблон для разработки нашего приложения. Мы смогли завершить первое развертывание в течение нескольких минут после того, как Clone закончил код.
Единственная трудность может заключаться в том, какой тип конфигурации службы выбрать, например, какой уровень пропускной способности DynamoDB выбрать и какой объем памяти использовать для лямбда-вычислений.
более высокая скорость разработки
В качестве поставщика бессерверных услуг был подготовлен ряд основных услуг. Как разработчики, нам нужно сосредоточиться только на том, как лучше реализовать бизнес, а не на каких-то технических ограничениях.
Поставщик услуг подготовил и протестировал для нас эту серию услуг. Они в основном стабильны, надежны и не сталкиваются с какими-либо серьезными проблемами. На самом деле, когда у нас есть достаточно сильный код, например, использование тестов для обеспечения надежности в сочетании с непрерывной интеграцией, мы можем развертывать его непосредственно в рабочей среде при отправке кода. Конечно, это может быть не так хлопотно, нам нужно только добавить хук predeploy и сделать автоматическое тестирование в этом хуке, а затем мы можем напрямую выпустить новую версию локально.
В этом процессе нам не нужно слишком много думать о публикации.
Безопасность системы выше
Судя по моему опыту ведения моего блога, поддерживать постоянную работу сервера — непростая задача. Непреднамеренно взломщики всегда будут атаковать ваш сайт. Нам нужно защищаться от различных типов атак, например, хакеры всегда пытаются войти с паролем на мой сервер, но серверу моего блога для входа нужен ключ. После магической попытки входа в систему мой демон SSH рухнул. Это означает, что я могу перезапустить сервер только из фона EC2.
С Serverless мне больше не нужно беспокоиться о том, что кто-то попытается войти в систему, потому что я даже не знаю, как войти на сервер.
Мне больше не нужно учитывать основные проблемы безопасности системы.Каждый раз, когда я вхожу в AWS EC2, мне всегда нужно обновлять программное обеспечение; всякий раз, когда я вижу уязвимость в программном обеспечении, такую как предыдущая версия версию и обновить ее программное обеспечение. На самом деле ТМ отнимает много времени и сил, а пользы никакой.
Единственное, о чем стоит беспокоиться, это о том, что кто-то запустит DDOS-атаку. и согласноCould Zombie Toasters DDoS My Serverless Deployment?Расчет на миллион запросов примерно 0,2 доллара, а в час 360 000 000 запросов, что составляет 72 доллара.
Адаптация к микросервисной архитектуре
Как мы видели за последние несколько лет, микросервисы в значительной степени не заменили монолиты — в конце концов, замена старых систем новыми архитектурами имеет небольшую ценность для бизнеса. Поэтому для многих предприятий нет такого сильного спроса и срочности. Жить - более насущный вопрос.
А бессерверность по своей сути связана с микросервисной архитектурой.дополняют друг другаиз. Бессерверное приложение имеет собственный шлюз, базу данных, интерфейс, и вы можете разрабатывать сервисы на своем любимом языке (в зависимости от поставщика услуг). Другими словами, Serverless может быть идеальным экземпляром микрослужбы в этой ситуации.
В ближайшие год или два Serverless заменит некоторые компоненты и службы в некоторых системах.
Возможность автоматического расширения
За Serverless стоит FaaS (функция как услуга), такая как AWS Lambda.
Для традиционных приложений способ справиться с большим количеством запросов — развернуть больше экземпляров. Однако на этот раз часто бывает слишком поздно. Для FaaS этого делать не нужно, FaaS автоматически расширится. Он запускает столько реплик экземпляров, сколько необходимо, без длительных задержек развертывания и настройки.
Это зависит от того, что наш сервис не имеет состояния, поэтому мы можем бессовестно запускать новые экземпляры.
Проблемы с бессерверным доступом
Как приложение, которое запускается только во время выполнения, Serverless также имеет необходимые нам проблемы.
Не подходит для долго работающих приложений
Serverless запускается только при поступлении запроса. Это означает, что когда приложение не запущено, оно будет переходить в «состояние сна», а в следующий раз, когда придет запрос, приложению потребуется время запуска, т.е.Холодный запуск. В это время вы можете использовать CRON или CloudWatch для периодического пробуждения приложения.
Если ваше приложение должно работать непрерывно в течение длительного времени и обрабатывать большое количество запросов, возможно, бессерверная архитектура вам не подходит. В этом случае лучше использовать облачный сервер, такой как EC2. Потому что EC2 дешевле по цене.
ЦитироватьLu Zouсуществует "Потратив 1000G, я наконец понял, что такое бессерверная архитектура (выше): что такое бессерверная архитектура?"Комментарии на:
EC2 эквивалентен покупке автомобиля, а Lambda эквивалентен аренде автомобиля.
Долгосрочная аренда, безусловно, дороже, чем покупка автомобиля, но вы сэкономите часть затрат на техническое обслуживание. Поэтому эта задача на самом деле является проблемой, заслуживающей глубоких расчетов.
Полная зависимость от сторонних сервисов
Да, когда вы решите использовать облачный сервис, это означает, что вы можете оказаться в тупике. В этом случае на Serverless можно размещать только неважные API.
Serverless — это не очень хорошо для вас, когда у вас уже есть большая инфраструктура. Когда мы внедряем бессерверную архитектуру, мы привязываемся к конкретному поставщику услуг. Мы используем сервисы AWS, поэтому нам не так просто перенести наши сервисы в Google Cloud.
Нам нужно изменить ряд базовых кодов, и решение, которое мы можем принять, — установить уровень изоляции. Это означает, что при разработке приложения необходимо:
- Изолированный шлюз API
- Изолируйте уровень базы данных, учитывая, что на рынке нет зрелого инструмента ORM, позволяющего поддерживать как Firebase, так и DynamoDB.
- и т.д
Это также принесет нам некоторые дополнительные расходы, возможноЭто вызовет больше проблем, чем решит.
время холодного старта
Как упоминалось выше, у бессерверных приложений есть проблема со временем холодного запуска.
Согласно официальному блогу New Relic "Понимание производительности AWS Lambda — насколько важен холодный запуск?", время холодного запуска AWS Lambda.
Или время ответа на запрос, которое я посчитал раньше:
Хотя это время холодного запуска в большинстве случаев может быть в пределах 50 мс. Хотя это относится к приложениям Node.js, Java и C# с виртуальными машинами могут быть менее удачливыми.
Отсутствие инструментов отладки и разработки
Когда я использовал Serverless Framework, я столкнулся с такой проблемой: нехватка средств отладки и разработки. Позже, после того, как я обнаружил ряд плагинов, таких как serverless-offline, dynamodb-local и т. д., проблема была решена.
Тем не менее, это остается серьезной проблемой для систем регистрации.
Каждый раз, когда вы отлаживаете, вам нужно снова и снова загружать код. И каждый раз, когда вы загружаете, вы как будто развертываете сервер. И, черт возьми, я не всегда могу быстро определить проблему. Итак, я изменил код и добавил строкуconsole.log, а затем снова развернул код. Проблема решена, хорошо, удалилconsole.log, а затем снова развернул код.
Позже я научился быть хорошим и нашел библиотеку Node.js, такую как log4j, которая может записывать журналы на разных уровнях.winston. Он может поддерживать шесть различных уровней журналов: ошибка, предупреждение, информация, подробный, отладочный и автоматический.
построить комплекс
Бессерверные решения дешевы, но это не значит, что они просты.
Ранее, узнав об AWS Lambda, мне захотелось что-нибудь попробовать. Но CloudForamtion кажется мне слишком сложным, его конфигурация настолько сложна и трудна для чтения и записи (в формате JSON).
Учитывая сложность CloudForamtion, я обрел некоторую уверенность только после знакомства с Serverless Framework.
Конфигурация Serverless Framework проще и представлена в формате YAML. Во время развертывания Serverless Framework создаст конфигурацию CloudForamtion на основе нашей конфигурации.
в этом "Kinesis Firehose сохраняет данные в S3«Размышляя над статьей о статистике данных, мы представили конфигурацию фреймворка Serverless. По сравнению с общей конфигурацией Lambda здесь конфигурация немного сложнее. Однако на самом деле это не производственная конфигурация. Я имею в виду, что реальные сценарии приложений намного сложнее.
языковая версия позади
Когда вышла Node.js 6, AWS Lambda поддерживала только Node.js 4.3.2, когда вышла Node.js 9.0, AWS Lambda поддерживала 6.10.3.
AWS Lambda поддерживает следующие версии среды выполнения:
- Node.js — версии 4.3.2 и 6.10.3
- Java - Java 8
- Python — Python 3.6 и 2.7
- .NET Core — .NET Core 1.0.1 (C#)
Для Java и Python наверное достаточно их версий, как C# не знаю. Но версия Node.js явно старовата, но это все Node.js 9.2.0. Однако, другими словами, это может иметь какое-то отношение к волне внешних версий, принесенной версией Emperor Chrome.
Выдержка из "Руководство по разработке приложений для бессерверной архитектуры》