Облаците трябва да бъдат ефективни, за да осигурят полезна толерантност към грешки и мащабируемост, но също така трябва да са лесни за използване.

колко струва един терминал на bloomberg на месец

CloudI (произнася се „cloud-e“ / klaʊdi /) е платформа за изчислителни облаци с отворен код, изградена в Erlang, която е най- тясно свързани към Платформа като услуга (PaaS) облаци. CloudI се различава по няколко ключови начина, най-важното: разработчиците на софтуер не са принудени да използват специфични рамки, бавно хардуерна виртуализация или конкретна операционна система. Като позволява внедряването на облак да се случва без виртуализация, CloudI оставя процеса на разработка и изпълнението по време безпрепятствено, докато качеството на услугата може да се контролира с ясна отчетност.

Какво прави облака облак?

Думата „облак“ стана вездесъщ през последните няколко години. И истинският му смисъл донякъде се е загубил. В най-основния технологичен смисъл това са свойствата, които платформата за изчислителни облаци трябва да притежава:

• Толерантност към повреди
• Мащабируемост

И това са свойствата, които бихме искали като облак да има:

• Лесна интеграция
• Лесно внедряване

Моята цел в изграждането на CloudI трябваше да обедини тези четири атрибута.

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

Започнах с разглеждане на Програмиране на Erlang език (върху който е изграден CloudI). Виртуалната машина Erlang осигурява характеристики на толерантност към повреди и а силно мащабируема архитектура докато езикът за програмиране Erlang поддържа необходимия изходен код малък и лесен за следване.

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

Какво е толерантност към неизправности в облачните изчисления?

Толерантността към грешки е устойчивост към грешки. Тоест системите, устойчиви на повреди, могат да продължат да работят сравнително нормално дори в случай на (надяваме се изолирани) грешки.

Тук виждаме услуга C, изпращаща заявки към услуги A и B. Въпреки че услуга B временно се срива, останалата част от системата продължава, относително безпрепятствено.

Урок за Erlang за начинаещи

Erlang е известен с постиженията си 9x9s надеждност (99,9999999% ъптайм, така че по-малко от 31,536 милисекунди престой на година) с реални производствени системи (в рамките на телекомуникационната индустрия). Нормалните техники за уеб разработка само постигат Надеждност 5x9s (99,999% ъптайм, така че около 5,256 минути престой на година), ако имат късмет, поради бавни процедури за актуализация и пълни системни откази. Как Erlang осигурява това предимство?

Виртуалната машина Erlang прилага това, което се нарича „ Актьорски модел ”, Математически модел за едновременно изчисление. В рамките на модела на актьора, леките процеси на Erlang са едновременно примитив на самия език. Тоест, в рамките на Erlang предполагаме, че всичко е актьор . По дефиниция актьорите извършват своите действия едновременно; така че ако всичко е актьор, ние получаваме присъщо съвпадение. (За повече информация относно модела на актьора на Erlang има по-дълга дискусия тук .)

В резултат на това софтуерът Erlang е изграден с много леки процеси които държат състоянието на процеса изолирано, като същевременно осигуряват изключителна мащабируемост. Когато процесът Erlang се нуждае от външно състояние, съобщението обикновено се изпраща до друг процес, така че опашката на съобщенията може да осигури на процесите Erlang ефективно планиране. За да запази състоянието на процеса Erlang изолирано, виртуалната машина Erlang прави събиране на боклука за всеки процес поотделно, така че другите процеси на Erlang да продължат да се изпълняват едновременно, без да бъдат прекъсвани.

c корпорация срещу s корпорация

The Събиране на боклук от виртуална машина Erlang е важна разлика в сравнение с събирането на боклук от виртуална машина Java, защото Java зависи от една купчина , в което липсва изолираното състояние, осигурено от Erlang. Разликата между събирането на боклука Erlang и събирането на боклук Java означава, че Java не е в състояние да предостави основни гаранции за устойчивост на грешки само поради събирането на боклука на виртуалната машина, дори ако библиотеките или езиковата поддръжка са разработени върху Java виртуалната машина. Имало опити за разработване на функции за устойчивост на грешки в Java и други езици, базирани на Java виртуална машина, но те продължават да бъдат неуспешни поради събирането на боклука на Java виртуална машина.

По принцип изграждането на поддръжка на толерантност в реално време върху JVM по дефиниция е невъзможно, тъй като самата JVM не е устойчива на грешки.

Ерланг процеси

На ниско ниво, какво се случва, когато получим грешка в процес на Erlang? Самият език използва предаване на съобщение между процесите, за да се гарантира, че грешките имат обхват, ограничен от едновременен процес. Това работи, като съхранява типове данни като неизменяеми обекти; тези обекти се копират, за да се ограничи обхватът на състоянието на процеса (големите двоични файлове са специално изключение, тъй като те се отчитат, за да се запази паметта).

В основни термини това означава, че ако искаме да изпратим променлива X към друг процес P, трябва да копираме над X като собствена неизменяема променлива X ’. Не можем да модифицираме X ’от текущия ни процес и затова дори ако задействаме някаква грешка, вторият ни процес P ще бъде изолиран от неговите ефекти. Крайният резултат е контрол на ниско ниво върху обхвата на всякакви грешки, дължащи се на изолирането на състоянието в процесите на Erlang. Ако искахме да станем още по-технически, бихме споменали, че липсата на променливост на Erlang го дава референтна прозрачност за разлика от, да речем, Java.

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

Планирането на процесите на Erlang осигурява изключително мащабируемост за минимален изходен код, което прави системата по-опростена и по-лесна за поддръжка. Макар да е вярно, че други езици за програмиране са успели да имитират мащабируемост открити в Erlang чрез предоставяне на библиотеки с нишки на ниво потребител (евентуално комбинирани с нишки на ниво ядро) и обмен на данни (подобно на предаването на съобщения) за внедряване на техния собствен модел на Actor за едновременно изчисление, усилията не са в състояние да повторят грешката толеранс, осигурен във виртуалната машина Erlang.

шаблон за срочен лист за придобиване

Това оставя Erlang сам сред програмните езици като едновременно мащабируема и устойчив на повреди , което го прави идеална платформа за разработка на облак.

Възползвайки се от Erlang

Така че, с всичко казано, мога да заявя, че CloudI носи устойчивостта и мащабируемостта на Erlang на различни други езици за програмиране (в момента C ++ / C, Erlang (разбира се), Java, Python и Ruby), внедрявайки услуги в рамките на Архитектура, ориентирана към услуги (SOA).

Тази простота прави CloudI гъвкава рамка за разработване на софтуер за полиглот, предоставяйки силните страни на Erlang, без да изисква от програмиста да напише или дори да разбере ред от Erlang код.

Всяка услуга, изпълнена в CloudI, взаимодейства с API на CloudI . Всички услуги за езици за програмиране, различни от Erlang, се обработват с помощта на същия вътрешен код на CloudI Erlang. Тъй като същият минимален Erlang изходен код се използва за всички езици за програмиране, които не са Erlang, друга поддръжка на език за програмиране може лесно да бъде добавена с внедряване на външен програмен език на API на CloudI. Вътрешно API на CloudI прави само основна сериализация за заявки и отговори. Тази простота прави CloudI гъвкава рамка за разработване на софтуер за полиглот, предоставяйки силните страни на Erlang, без да изисква от програмиста да напише или дори да разбере ред от Erlang код.

Конфигурацията на услугата определя параметри за стартиране и ограничения на толерантността, така че грешките в услугата могат да възникнат по контролиран и изолиран начин. Параметрите за стартиране ясно определят изпълнимия файл и всички необходими аргументи, заедно с изчакванията по подразбиране, използвани за заявки за услуги, методът за намиране на услуга (наречен „метод за опресняване на местоназначението“), както позволите, така и откажете списък за контрол на достъпа (ACL) за блокиране на изходящи заявки за услуги и незадължителни параметри, които да повлияят на начина, по който се обработват заявките за услуги. Ограниченията за толерантност към грешки са просто две цели числа (MaxR: максимално рестартиране и MaxT: максимален период от време в секунди), които контролират услугата по същия начин, както поведението на надзора на Erlang (модел на дизайн на Erlang) контролира процесите на Erlang. Конфигурацията на услугата предоставя изрични ограничения за живота на услугата, което помага да се направи изпълнението на услугата лесно за разбиране, дори когато възникнат грешки.

За да се запази паметта на услугата изолирана по време на изпълнение, се използват отделни процеси на операционната система за всяка услуга, която не е Erlang (наричана „външна“ услуга), и асоцииран процес Erlang (за всяка не-Erlang нишка на изпълнение), която е планирана от Erlang VM. API на Erlang CloudI създава „вътрешни“ услуги, които също са свързани с процес на Erlang, така че както „външните“ услуги, така и „вътрешните“ услуги се обработват по един и същи начин в Erlang VM.

При изчисленията в облак е важно също така вашата толерантност да надхвърля един-единствен компютър (т.е. разпределена системна устойчивост на грешки). CloudI използва разпределена Erlang комуникация за обмен на информация за регистрация на услуги, така че услугите да могат да се използват прозрачно за всеки екземпляр на CloudI, като посочва едно име на услуга за заявка, направена с API на CloudI. Всички заявки за услуги са балансирани на натоварване от изпращащата услуга и всяка заявка за услуга е разпределена транзакция, така че една и съща услуга с отделни екземпляри на отделни компютри е в състояние да осигури устойчивост на грешки в системата в CloudI. Ако е необходимо, CloudI може да бъде внедрен в рамките на виртуализирана операционна система, за да осигури същата устойчивост на грешки в системата, като същевременно улесни стабилна рамка за развитие.

уроци по кодиране на c++

Например, ако HTTP заявка трябва да съхранява някои данни за акаунта в база данни, тя може да бъде направена до конфигурираната HTTP услуга (предоставена от CloudI), която ще изпрати заявката до услуга за данни за акаунт за обработка (въз основа на HTTP URL адреса, който е използва се като име на услугата) и данните за акаунта след това ще се съхраняват в база данни. Всяка заявка за услуга получава a Универсално уникален идентификатор (UUID) при създаване, което може да се използва за проследяване на завършването на заявката за услуга, като всяка заявка за услуга в CloudI е разпределена транзакция. И така, в примера за услуга за данни за акаунти е възможно да се правят други заявки за услуги или синхронно, или асинхронно и да се използват UUID на заявката за услуга, за да се обработят данните за отговор, преди да се използва базата данни. Наличието на изрично проследяване на всяка отделна заявка за услуга помага да се гарантира, че заявките за услуги се доставят в рамките на периода на изчакване на заявката, а също така предоставя начин за еднозначно идентифициране на данните за отговор (UUID на заявката за услуга са уникални сред всички свързани CloudI възли).

С типично внедряване всеки CloudI възел може да съдържа конфигуриран екземпляр на услугата за данни на акаунта (който може да използва множество процеси на операционна система с множество нишки, всеки от които има обект на API на CloudI) и екземпляр на HTTP услугата. Външен балансиращ товар лесно би разделил HTTP заявките между възлите на CloudI и HTTP услугата ще насочи всяка заявка като заявка за услуга в CloudI, така че услугата за данни на акаунта може лесно да се мащабира в CloudI.

CloudI в действие

CloudI ви позволява да вземете нескалируем наследен изходен код, да го обгърнете с тънка услуга CloudI и след това да изпълните наследения изходен код с явни ограничения на толерантността към грешки. Този конкретен работен процес за разработка е важен за пълното използване на многоядрени машини, като същевременно осигурява разпределена система, която е устойчива на грешки по време на обработката на заявките в реално време. Създаването на „външна“ услуга в CloudI просто създава екземпляр на обекта на API на CloudI във всички нишки, които са конфигурирани в конфигурацията на услугата, така че всяка нишка да може да обработва едновременно заявките на CloudI. Един прост пример за услуга може да използва единичната основна нишка за създаване на един обект на API на CloudI, като следния изходен код на Python:

import sys sys.path.append('/usr/local/lib/cloudi-1.2.3/api/python/') from cloudi_c import API class Task(object): def __init__(self): self.__api = API(0) # first/only thread == 0 def run(self): self.__api.subscribe('hello_world_python/get', self.__hello_world) self.__api.poll() def __hello_world(self, command, name, pattern, request_info, request, timeout, priority, trans_id, pid): return 'Hello World!' if __name__ == '__main__': assert API.thread_count() == 1 # simple example, without threads task = Task() task.run()

Примерната услуга просто връща „Hello World!“ към HTTP GET заявка, като първо се абонирате с име на услуга и функция за обратно повикване. Когато услугата започне да обработва входящи заявки за шина на услугата CloudI в рамките на функцията за анкета на CloudI API, входящите заявки от „вътрешната“ услуга, която предоставя HTTP сървър, се насочват към примерната услуга въз основа на името на услугата, поради абонамента. Услугата също може да върне никакви данни като отговор, ако заявката трябва да бъде подобна на съобщение за публикуване в типичен API за разпределени съобщения, който предоставя функционалност за публикуване / абониране. Примерната услуга иска да предостави отговор, така че HTTP сървърът да може да отговори на HTTP клиента, така че заявката е типична транзакция за заявка / отговор. И с двата възможни отговора от услуга, или данни, или данни, функцията за обратно извикване на услугата контролира използваната парадигма за съобщения, вместо услугата за извикване, така че заявката може да се насочи през толкова услуги, колкото е необходимо, за да предостави отговор, когато е необходимо, в рамките на времето за изчакване, за да се получи заявката в рамките на. Времената за изчакване са много важни за обработката на събития в реално време, така че всяка заявка определя цяло число изчакване, което следва заявката, докато маршрутизира през произволен брой услуги. Крайният резултат е, че ограниченията в реално време се налагат заедно с ограниченията за толерантност, за да се осигури надеждна услуга при наличие на произволен брой софтуерни грешки.

Наличието на грешки в изходния код във всеки софтуер трябва да се разбира като ясен факт, който се смекчава само с ограничения за толерантност към неизправности. Разработката на софтуер може да намали присъствието на грешки, тъй като софтуерът се поддържа, но може и да добавя грешки, когато се добавят софтуерни функции. CloudI предоставя изчислителни облаци, които могат да отговорят на тези важни проблеми, свързани с толерантността към грешки в рамките на разработването на софтуер за разпределени системи в реално време. Както демонстрирах в този урок за CloudI и Erlang, облачните изчисления, които CloudI предоставя, са минимални, така че ефективността да не се жертва за предимствата на облачните изчисления.