Антон Коренюшкин (Akshell) PaaS за стартиране на JavaScrip на сървъра
Общност от ръководители на ИТ компании, ИТ отдели и сервизни центрове
участниците са служители на IT компании
20% от които са съсобственици на бизнеса
работа в ИТ отдели на други компании
Влез с:
Упълномощаване
Нови потребители
Презентация
Препис
Ще започна най-общо с платформите. Защо всички говорят за платформи? Защо напоследък всички правят платформи? Ще отговоря в следващата тема. представете си, че за да стигнете до тук с кола, първо трябва да съберете тези части. Първо, не много биха се справили с това. Второ, отнема време. И трето, всеки ще трябва да го направи. И в известен смисъл уеб разработката наистина е отчасти такава. Тоест има много инструменти, много софтуер за създаване на уеб приложения. Но програмистите и разработчиците трябва някак да разположат отново всичко това на своите сървъри, да конфигурират, администрират и т.н. Като цяло, ако става дума за мащабиране, тогава, общо взето, всичко става трудно за изрязване. Поради това наскоро бяха предложени много платформи като услуга (PaaS).
Основните предимства на такива неща. Типичните примери включват Google App Engine, Oracle, предназначени за всякакви уеб приложения като цяло. Или платформата Force.com за бизнес приложения. Предимствата на платформите са очевидни. Това е, първо, лекота на използване в сравнение с необходимостта да разположите всичко това на вашия сървър. автоматично мащабиране. Малко хора всъщност си представят какво е това. Тоест вашето приложение описва бизнес логиката икогато прехвърляте вашето бизнес приложение към сървъри, платформата се грижи за това, което значително опростява живота. Естествено, има много по-малко притеснения относно администрирането на приложението. Обикновено клиентът не разполага с всички инструменти, необходими за работа с базата данни, и не е наясно с много повече неща. Всъщност зависи от спецификата на платформата. Ако това е Google App Engine, тогава това е основно нашата база данни, при това много специфична. Ако това е Force.com, тогава това са много бизнес инструменти за създаване на приложение, което автоматизира бизнес процесите. Е, и обикновено, в допълнение към всичко това, платформата предоставя някаква богата среда, в която можете да създавате приложения от тухли. Тоест, това е набор от библиотеки, набор от услуги на платформата и т.н.
Но големият му недостатък е, че бизнес дневниците са написани по такъв начин, че това е просто невъзможно. Кодът се превръща в "спагети" от завръщания и е напълно нечетлив. Тоест, това, което може да се направи в 2 реда на традиционната парадигма, в HMGS се превръща в 20 реда, освен това със сложност от 8 нива. Но има опити, сега предприемаме един от тях, обмисляме го. Говорих със създател на възел на Keyskont и е възможно да се създават леки процеси с помощта на kate. Той има концепцията за така наречения контекст и с помощта на тези контексти можете да създадете няколко стека за изпълнение и всеки стек, те са зависими един от друг, тоест имат някакво общо глобално пространство, но стековете за всеки процес ще бъдат различни и създаването на нови такива стекове е доста евтино. И поради това можете да правите, така да се каже, многозадачност, сякаш strats. Това ще бъде изпълнено по следния начин. В един главен конструктор се изпълнява асинхронен код и визпълнява се допълнителен синхронен код, няма блокиращо извикване и някак си се връщаме към основния, а в основния превключваме ръчно между допълнителни стратове, като по този начин създаваме нов код и се програмира бизнес логиката.
Но тук отново има някои проблеми. Проблеми, по-специално, с бележката и проблеми с този модел. Weeton е създаден за браузъра, а не за сървъра. И това налага известно ограничение. Основното ограничение е, че стартира бавно, създава нишки бавно, така че може да се използва с контексти, както казах, по принцип, ако контекстите се създават бързо. И второто ограничение. Например изобщо не поддържа серия от операционната система, но работи в една серия и когато включи gambridge collusion и се включи, не знае кога, всичко замръзва. Тоест, ако напишете приложение на възел и не се грижите да работи в много процеси, то периодично ще замръзва.
Следващата инициатива е Naurwal. Това дори вече не е платформа, а някакъв вид инициатива за създаване на общ API върху платформата. Сега съществува, но не се използва широко.
Последната е нашата любима платформа Akshion. Просто е създаден за разработване на бизнес приложения. Това е със синхронни API. Това е само част от нашата платформа. Освен това върху него са възможни браузър-базирани разработки. Можете да отидете на нейния уебсайт. Разработките са възможни с едно кликване. Възможно е да пишете код и да съхранявате резултатите в инфраструктурата с едно щракване.
Между другото, забравих да кажа, че за възела има, растат като гъби, услуги, хоствани от възела. Интерфейсът там е прост, без никакво развитие на услугата. Просто напишете код и отидете там. Всъщност целият интерфейс.Освен това има много повече платформа като услуга за възела. Всъщност те се появяват на партиди, но създаването на някаква базова платформа е отделен въпрос. Създаването на нещо наистина мащабируемо и надеждно е, разбира се, по-трудно.
Това всъщност е всичко, което исках да кажа.
От публиката: Има ли значение производителността на платформата?
Паралелно, в смисъл паралелно по тенденциите?
От публиката: Е, да. Е, може би за отделни автомобили.
Е, разбира се, има отделни тенденции за отделните автомобили. Тук е ясно, че чрез определени действия трябва да постигнем, чрез програмиране, изпълнението на някои оптимални действия. Основната разлика, например, в случай на възел от Java е същата, тя се крие в асинхронността. Тоест, как обработвате заявки в традиционна среда, като запитване за нещо от база данни и изчакване да завърши.
Представете си, че пишете IRC сървър. Това е класически пример за възел. Какво се случва в задната част на IRC сървъра? И има дълги нишки на регистъра. Вашият браузър прави заявка към сървъра и сървърът не дава отговор, а по-скоро поддържа тази връзка, тоест за това се създава отделна песен. 200 души са влезли във вашия IRC сървър, ще трябва да запазите 200 песни. Ясно е, че това просто не е мащабируемо, това е неприемливо, особено след като всички тези стракове просто висят. Докато сте в възел, имате нужда само от една нишка, един процес, който ще се обработва асинхронно. Дойде съобщение от някакъв потребител, изпратихте отговори до всички канали, но отговорите се появяват асинхронно. Тоест не закачаш нищо, няма блокиращи повиквания. Това е основната разлика между възел. И предвид някои добавки и приложения на браузъра, актуализации в браузъра, това е идеалната платформа.за бизнес логиката. Ето защо, както казах, ние се опитваме да вземем най-доброто от двата свята и да установим тези бизнес процеси.
Някой използва ли Python? Не? само Java?
От публиката: Ключовият код използван ли е за двигателя?
Появиха се скорошни съобщения, че Facebook ще го използва. Но това е много стара история. Райън не е измислил същата асинхронност. Ако си спомняте, имаше такава услуга Funkle, използва се и до днес. За него те също създадоха Python от страна на сървъра, който всъщност прави същото. Тъй като Python не е толкова удобен, за да не се направи блокиращо извикване върху него, това изисква много усилия, трябва да използвате само обратни API. Съответно са разработени други платформи. Но никой от тях не е спечелил такава слава като Нод. Всъщност емисията с новини във Facebook с помощта на обрат се изпълнява. Поради това можете да получавате данни за актуализацията на него, тоест не чакайте всеки път, а отидете до него и веднага гледайте новинарския канал. Всъщност нестандартното програмиране е предназначено за тези неща.
Защо не. Имате предвид да предоставите API?
Неудобно е да се правят htme шаблони върху него, тоест това е точно бизнес логиката, неудобно е, не е предназначено за това. Добре е да създадете авторски права върху него, защото можете да създавате асинхронни неща, помните ли какво казах? За това е предназначен най-вече. Съвременните уеб приложения... Не че е единственият начин, но много хора го правят. В офиса, когато получите първоначален клиентски код на страницата от сървъра и правите всички други актуализации чрез API. И съответно всичко се актуализира в самия клиент. И сървърът, той не получава такова групиране на връзки.
Е, тук ще дам нашия пример за развитие. Тованапълно едностранично приложение. Тоест, веднъж сте получили testodemade, който, разбира се, е бил кеширан и всичко останало, което сте на тези бутони за отваряне на менюто и т.н. Това вече се случва чрез API на сървъра. Тоест, всъщност става въпрос за една услуга.
За да създавате онлайн магазини, това вероятно не е най-доброто решение. Тук, както казах, бизнес логиката не е приятелска с асинхронността, защото бизнес логиката описва това, което искате. Искам това, искам това, искам това. А не „направи ми това и после ме наричай така и така“. И е необходимо още едно завръщане, за да се върнеш и да го направиш. Но аз съм уверен, че ще можем да вземем най-доброто от двата свята и да създадем платформа, която е универсална.
Има стартъп NauES, той просто създава неща, които се синхронизират, правят външния вид на една среда, в едно и също Google Space и т.н. Ясно е, че един сървър няма да е достатъчен. Освен това с такъв модел много процеси ще се използват едновременно в този сървър. И е необходимо да се поддържат активни среди с помощта на леки съобщения, но това в момента е само в процес на създаване.