Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Go на Google App Engine
Similar to Go на Google App Engine (20)
Go на Google App Engine
- 1. Go на Google App Engine Сергей Лалов - @SergeyLerg spiralcodestudio.com
- 2. Кто я вообще такой? • C -> PHP -> Python -> Lua + Go • Corona SDK • Google App Engine • Зачем?
- 3. Краткий экскурс • RBaaS - Rusty Bucket as a Setup • IaaS - Infrastructure as a Service • PaaS - Platform as a Service • SaaS - Software as a Service • (M)BaaS - (Mobile) Backend as a Service
- 6. PaaS • AWS Elastic • Heroku • Google App Engine • Великая грусть сисадмина
- 7. Google App Engine • Распределенность • Масштабируемость • Высокая надежность • Удобство работы • Низкая стоимость • Бесплатные квоты
- 8. Google App Engine • Python, Java, Go, PHP • Sandbox • Datastore • Blobstore • CloudSQL
- 9. Services • Channel • Log • Mail • OAuth • Search • Sockets • Users • XMPP • ...
- 10. Why Go? Go is Awesome
- 11. Why Go? Go is AWESOME!!11
- 12. Why Go? • 2007, 2009, 2011 • Компилируемый • Статическая типизация • Конкурентный (pun intended) • GC • Fun
- 13. Go на Google App Engine • Самый ресурсо эффективный • Легко использовать • Соответствует идеологии масштабируемых систем • goapp serve • goapp deploy • my-app-id.appspot.com • HTTPS бесплатно
- 14. Go • Go Lite IDE • Export • Interface • OOP • go fmt • Ниже вероятность ошибок
- 15. Hello, Engine package hello12345 import ( "fmt" "net/http" ) func init() { http.HandleFunc("/", handler) } func handler(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "Hello, Engine!") }
- 16. app.yaml application: hello12345 version: 1 runtime: go api_version: go1 handlers: - url: /.* script: _go_app
- 17. Модульность application: penguin-daycare-simulator module: default version: 1 runtime: go api_version: go1 automatic_scaling: max_concurrent_requests: 500 handlers: - url: /.* script: _go_app
- 21. Penguin Daycare Simulator • Go (Google App Engine) + Lua (Corona SDK) • http://habrahabr.ru/post/220031/
- 22. Спасибо за внимание! • @SergeyLerg • http://github.com/Lerg
Editor's Notes
- Здравствуйте, Меня зовут Сергей и это доклад Go на Google App Engine. Начнем
- Логичный вопрос, а кто же собственно перед вами. Я начал профессионально заниматься программированием с языком С. Кстати, профессионально означает, что мне за это платили деньги, за Pascal и Delphi мне, к сожалению, никто ничего не платил. На С это была работа с видеопотоками, система видеонаблюдения, обработка изображений. Моя первая статья на хабре была про определение расстояния до машины на дороге с высоко расположенной камеры. В перемешку с этим я еще работал веб разработчиком на PHP/JS и прочих сопутствующих вещах. После прочтения нескольких комиксов на сайте XKCD.com влюбился в Python, но широко и часто его использовать мне не удалось так как за код на PHP платили больше. А потом я все бросил и стал делать мобильные игры на языке Lua с помощью Corona SDK. Примерно в это же время (2011 год) я познакомился с языком Go и я был в восторге от него. И когда стала необходима разработка бэкендов для моих приложений, то очевидно это был Go. Сначала на VPS, потом на Google App Engine. Зачем я это все рассказал, чтобы дать вам понять, что перед знакомством с Go у меня уже был некий багаж опыта разработки с другими языками и мне было с чем сравнивать.
- И так. Мы уже подходим к самой проблеме. Теперь небольшой экскурс в терминологию, сейчас я объясню все эти страшные аббревиатуры. Rusty Bucket as a Set up - ржавое ведро - это все, что у вас есть. Пожалуйста, используйте этот термин, я его вчера придумал. У вас есть какой-то компьютер и вы полностью обслуживаете его сами. Интернет, питание, настройка, апдейты - все лежит на вас самих. Это с одной стороны и хорошо, полный контроль. Однако непредвиденные обстоятельства не подконтрольны. Например, жесткий диск умер, а последний бэкап был месяц назад и хранился на том же самом диске. Даже если есть свежий бэкап, то восстановление может занять уйму времени. Как решить эту проблему? Больше абстракций! Нам по сути не важно на каком железе у нас работает операционная система, лишь бы работала и работала стабильно. Это называется Infrastructure as a Service. Virtual Private Server, Amazon, Linode - это все IaaS. Обслуживание железа мы исключили, но осталось обслуживание системы, в сети все еще очень много систем подверженных багу в SSL - heartbleed, все потому, что либо их некому обслуживать, либо им просто лень - человеческий фактор опасная штука. Да и вообще поддерживать весь зоопарк различного софта в системе часто задача нетривиальная. Как решить эту проблему? Больше абстракций! Нам по сути не важно какая у нас операционная система, главное чтобы все компоненты были защищены от подобных багов и вовремя обновлялись. У нас есть код и нам нужно, чтобы он работал. Это Platform as a Service. Такой как Google App Engine. Небольшой парадокс - наряду с тем как PHP веб хостинг за $5 в месяц внезапно стал облаком, он также внезапно стал PaaS системой, вот только ни для кого не секрет, что такие облака и Google App Engine это борцы совсем разных весовых категорий. Еще одна абстракция - это Software as a Service, когда нам не нужно выполнять код, но нужно исполнять другие операции, самый очевидный пример это MySQL и другие базы данных как сервис. У Google App Engine это Datastore (NoSQL), Memcached и CloudSQL. У Google App Engine есть еще много других сервисов, которые вы можете использовать без особых усилий в настройке. Последний тип MBaaS это что-то между PaaS и SaaS. Мы можем исполнять свой код, мы можем пользоваться различными сервисами, но все заточено на использование в качестве бэкенда для мобильных приложений. Такие сервисы часто предоставляют готовые решения для хранения аккаунтов пользователей, таблицы рекордов, мультиплеер и отправка push уведомлений. Большую часть этого рынка забрал себе parse.com
- Но можно глубже. Можно взять IaaS, развернуть там PaaS и построить на ее основе MBaaS. Например можно будет запускать специальную версию Google App Engine на вашем инстансе Google Compute Engine.
- Типичные представители PaaS систем. Все достаточно сильно отличаются друг от друга по многим параметрам. Go можно запускать на Google App Engine и на Heroku через неоффициальный buildpack. Но мой выбор - это конечно Google App Engine, это же Google! Стоит сказать, что подобного рода сервисы и платформы это подрыв карьеры сисадмина, они просто на просто не будут нужны в этой области. В прочем обилие таких систем все же может породить новые вакансии для сисадминов, нужно только назваться Cloud Sysadmin as a Service и давать консультации по выбору и особенностям работы всех этих систем.
- Каковы же ключевые особенности хороших PaaS систем и Google App Engine в частности. Так как ваше приложение распределено по дата центрам, то такая операция как запись локального файла не имеет смысла. Читать локальные файлы можно, но модифицировать нельзя. Для этого есть сервис Blobstore. Бесплатные квоты. Причем если подключить возможность оплаты в вашем аккаунте, то некоторые бесплатные квоты возрастают в то время как вы все еще можете ничего не платить
- Изначально Google App Engine разрабатывался для Python, затем появилась поддержка Java, в 2011 году стал поддерживаться Go и сравнительно недавно добавили поддержку PHP.
- В последние годы появилось много новых языков программирования. Google - Go, Mozilla - Rust, JetBrains - Kotlin, Apple - Swift. Крупные компании понимают, что новые языки крайне нужны сообществу разработчиков. И все эти языки займут свое место под солнцем, так как каждый из них решает немного разные задачи.
- Go сам по себе является многопоточным языком, но вместо явных потоков он использует горутины и сам распоряжается сколько потоков создать, сам распределяет горутины по потокам и сам эффективно переключает их внутри каждого потока. В Go можно указать что какая-то конкретная горутина должна занимать собой весь поток целиком. Но так как на Google App Engine все работает в песочнице и обязательным условием является целостность памяти, то Go приходится запускать в один поток. Но не спешите расстраиваться, вы все еще можете использовать горутины и ваш код будет конкурентным, просто физически все они выполняются на одном ядре конкретного процессора. В добавок для увеличения производительности Google App Engine автоматически запускает нужное количество инстансов вашего приложения и балансирует нагрузку между ними. И они уже могут работать одновременно на разных процессорах. И не стоит думать о многопоточности как о средстве нацеленным сугубо на увеличение производительности, горутины и канала в Go это инструмент написания более грамотного и красивого кода. Без них код может превратится в кашу и стать очень сложным для понимания. В отличии от других языков на Google App Engine, в Go контекст вызова передается явно, через него происходит общение с внешней средой. Он включает в себя например коды авторизации и информацию для статистики и биллинга. В других языках этот контекст скрыт от глаз, Python и PHP работают в однопоточном режиме, у них контекс хранится где-то в глобальном скопе. А в Java он находится в локальном хранилище потока. Не в курсе как обстоит дело с многопоточным режимом работы Python. Так как запросы обрабатываются одновременно, то и контекстов должно быть несколько. Такой подход существенно упростил интеграцию Go с Google App Engine. Для питона пришлось написать много дополнительного кода, отвечающего за многопоточность, в то время как в Go нужно ее было просто включить. Каждое приложение - один большой бинарник, статическое линкование библиотек. Это нормально, google не использует дискеты в дата центрах, у них есть место.
- Всем нужна IDE для работы с языком. У Go есть LiteIDE и плагин к Sublime. Export с большой буквы. Сначала это жутко не привычно, но потом привыкаешь и получаешь удовольствие. Читать чужой код становится проще. Интерфейсы - вынос мозга. Не надо писать что-то implements что-то. ООП в Go похоже на OOP на Lua. Нет классов, но есть ассоциативные массивы в Lua и Struct в Go.