През изминалата седмица се впуснах в софтуерната разработка, като изследвах концепцията за виртуални актьори. В крайна сметка разгледах две различни рамки: Dapr и Orleans.
И двата проекта са много кратки и с много интересни случаи. И двете използват идеята за "виртуални" актьори. Виртуален актьор е състояние и логическа единица, която:
- Тя може да бъде уникално идентифицирана чрез ID
- Тя е еднонишкова
- Може да бъде в паметта или постоянен – жизненият му цикъл се управлява от рамката
Много ми харесва идеята за виртуални актьори и ги намирам за много полезни в изследването ми на изграждането на мащабируеми и надеждни инструменти за справяне със сложни работни процеси. Ако всяка задача е виртуален участник с една нишка, проблемът със състезателното състояние изчезва.
Тъй като Orleans и Dapr са проекти на Microsoft, си представям ден в сблъсък в стил Western Story в столовата на Microsoft.
Орлеан
Започнах с Orleans, защото от известно време ми е на радара след като гледах няколко видеа за него в YouTube. Започна много зле, защото мислех, че ще използвам 4.x версията на всичките им NuGet пакети. Въпреки това, абсолютно нито една от техните документи не работи с 4.x пакета. В крайна сметка използвах версия 3.6.2.
Зърна / Състояние / Таймери
Създаването на зърно, което проследява собственото си състояние и извършва действия, е много просто. Дори успях да следвам документацията за устойчивост на зърната и да създам собствена CosmosDB (SQL API) имплементация на IGrainStorage.
Напомняния
Напомнянията също са лесни за настройване. Докато не опитах да конфигурирам реалната устойчивост за тях. В момента се опитвам да поддържам всичко подредено и да съхранявам всичко в ComsosDB. За съжаление, изобщо не мога да накарам пакета за напомняне за устойчивост на Orleans. В крайна сметка трябваше да премина към пакета AzureStorage. Сега данните ми са наполовина в SQL API акаунта, а наполовина в акаунта на таблицата.
Потоци
Там не се получих добре. В Орлеан потоците се идентифицират чрез GUID и опционално пространство от имена. Сигурен съм, че има добра причина стриймовете да се идентифицират с GUID, но уау, това е непрактично.
Много съм разочарован от стриймовете, защото успях лесно да ги създам, но щом спра и рестартирам проекта си и задействам ново събитие, всичко се срива.
След това идва много ценна информация, тъй като ми отне 8 часа да разбера кода на Орлеан, за да го разбера:
Когато grain е абонат на поток, grain трябва да извика ResumeAsync на дескриптора за абонамент в метода си OnActivateAsync, иначе ще се срине с неразпозната грешка.
Имах и проблем със дублирането на същия абонамент, затова използвах кода, за да изтрия всички абонаменти за зърното и после го създадох отново:
Други орлеански готчи / съвети
Streams работи добре с Azure Event Hubs (чрез AddEventHubStreams).
Не използвайте / или други специални символи в името Grain на CosmosDB SQL API!
Орлеанско заключение
Харесвам Орлеан и мисля, че има потенциал. Въпреки това, има много стръмна крива на обучение. Поради дългата ми борба със стрийминга, нямам време да изучавам как работят клъстерите/внедряванията.
Dapr
Открих Dapr, като търсех алтернативи на Орлеан. Малко е странно, че това е и проект, спонсориран от Microsoft. Може би са тук, за да възприемат подхода "оцеляват най-силният". Ако да, мисля, че Dapr ще бъде оцелял.
Първо, REST/gRPC-базираният дизайн на Dapr позволява актьорите да бъдат реализирани с използване на всеки програмен език. Също така ми се стори тривиално да пусна всичко (участници, статуси, таймери, напомняния, събития) на един Redis инстанс. Освен това ми отне само около една трета от времето, за да започна да използвам Dapr. Толкова бързо стартиране се дължи на отличната документация на Dapr.
Актьори / Таймери / Напомняния
Току-що казах ли, че документацията на Dapr е страхотна? Е, той е навсякъде, освен примерите с JavaScript. Прекарвам по-голямата част от времето си на Dapr, опитвайки се да разбера как да извикам методи на актьорите. Кодът за Dapr Javascript примера е следният:
Това е очевидно остаряло. Трябваше да отделя много време, за да прокарвам тези три реда през тестовото/изследването на пробния код на Dapr
Примерите с код за получаване/настройка на състояние имат подобни проблеми, затова създадох проблем в GitHub за тях.
Освен тези дребни проблеми, подреждането на актьори е лесна работа.
Настройването на таймери и напомняния за моя гипс също е много лесно.
Държава
Успях много лесно да конфигурирам Dapr да запазва с Postgres.
Едно нещо, което забелязах, е че може да има проблеми с мащабируемостта при съхранението на напомнянията. Dapr съхранява всички известия за определен тип участник в един JSON масив. Какво се случва, ако някой има много напомняния?
Други Dapr Gotcha / Съвети
Едно нещо, което забелязах, докато разглеждах кода за JavaScript SDK, е че в кода почти няма коментари. Това прави почти невъзможно да се разбере нещо. Например, в метода addOrUpdateState на мениджъра на състоянието има трети параметър, наречен updateValueFactory. Ако няма коментари в кода, почти е невъзможно да се разбере за какво е обратният call.
Също така не съм сигурен колко харесвам командата "dapr init", която се опитва да настрои и пусне redis контейнер за мен. Ами ако вече имам redis контейнер? Ами ако искам да използвам postgres вместо това? Не мога да намеря документи, обясняващи как да се промени функцията за init на DAP.
Бележка към всеки, който има затруднения с използването на pubsub. Трябва да използвате "dapr run", за да управлявате както издателя, така и абоната:
За актьори и pubsub имай предвид, че е важно да използваш параметъра --app-port, за да уведомиш dapr на кой порт работи твоята услуга. pubsub събитията и актьорските повиквания се изпращат към вашата услуга от страничната кола на Dapr чрез http calls, така че трябва да знае къде да ги изпраща:
Тествах малък Dapr самостоятелно хостван "клъстер", като стартирах моя pubsub абонат инстанс на два различни компютъра в домашната си мрежа. Просто проработи!
Заключение на Dapr
Ако искате да научите повече идеи за разпределени приложения или виртуални актьори, препоръчвам да започнете с Dapr. Orleans беше оригиналният пионер, докато Dapr беше рестарт, който издигна нещата на следващо ниво.
Оригинален линк:Входът към хиперлинк е видим.
|
Публикувано в 29.12.2022 г. 14:24:52 ч.
|
|
|
|
Хазяин|
Публикувано в 29.12.2022 г. 14:25:28 ч.
|
