Цікава, взагалі контора Майкрософт: колись працював над платіжною системою і там теж були актори, але від MS Sercice Fabric. До речі про акторів. Зараз працюю з k8s і зацінив, як же круто у Service Fabric, було мати їх із коробки: по коли вони потрібні украй рідко на проекті, але все ж такі потрібні важко їх завезти і ото починаємо городити distributed locks або іноді разрулюємо fifo очередями. Усьому іншому Service Fabric мало приємно штука і бажаю усім її уникати, але було б круто у k8s з коробки мати якихось акторів для побічних задач
Ти зараз дивишся на приклади, описані людиною, яка дивиться на них крізь призму досвіду і знань. А коли ти з проблемою в перший раз стикаєшся, то однозначно ідентифікувати, що робити, важко. Треба менш експертно дивитися на світ, і тоді таких вражень не буде.
Бачив на гітхабі цікавий репозиторій про реалізацію event sourcing + cqrs від чуваків з уклону. Було б цікаво послухати про мікросервісні патерни які були використані в уклоні, наприклад часто було сказано "хореографія і оркестрація", трохи попахує сагою)
Чому взагалі сервіси називають мікросервіси? В понятті мікросервісної архітектури люди розуміють це про сервіс, а не про архітектуру. Кріс Річардсон: "Periodic reminder: Just because they are called MICROservices it does not mean that you should define lots of little services." Тому люди впершу чергу городять сотні сервісів, які не існують як атомарна одиниця, і це суперечить патерну мікросервісної архітектури. Мікросевісна - це спочатку про архітектуру, а потім про сервіси
З приводу того що в youtube кілька місць де різні counter перглядів, мені виглядає так що це загальна проблема гугла тому що як мінім такаж проблема з google search console та google play console
А що ж ви хлопці робите, коли ваші стейтфул сервіси падають, або ще щось з ними трапляється? Все що було у пам'яті тю-тю? І що робити? Накопичували дані по відповідям від водіїв і впала нода, і все, хана всім даним. Я дуже скептично до Орлінса ставлюся, тому що пацани сову на глобус хотіли натягти. Тільки десь ліворуч-праворуч треба піти і Орлінс не фонтан.
1. Всі наші stateful сервісі будуються на базі partitioned topics (kafka). Відповідно все що було у памʼяті ми відновлюємо з цих топіків на старті компонента. 2. Звичайно, Orleans - це не фреймворк для реалізаціі на ньому всієї системи. В нашому випадку він використовується тільки для 1 задачі - розподілу водіїв між замовленнями (з високим ступенем concurrency) та обробка відповідей від водіїв (які також в окремих бізнес сценаріях сильно конкурентні). І тут він дуже спрощую возню з прімітивами синхронізаціі (lock, etc), distributed locks, рівнями ізоляціі на рівні БД і тд. Також було б цікаво послухати про ваш досвід з "ліворуч-праворуч".
Нажаль будь які незручні коменти, з можливою критикою майбутніх спікерів fwdays, за цей самий stateful й взагалі позицію DBA в EDA - тут просто видаляють. Akka також вже давно не фонтан, але принаймні там було розуміння, що має бути 2 різновиди акторів - окремо ті що зберігають стан у памяті, домішують CRDT до ES для синхронізації... й ті що зберігають стан в БД... Нажаль поки в нас немає конкретних практик як саме потрібно використовувати CDC з вже вбудованими лічильниками транзакцій, разом з розумінням яке то має відношення до EDA та відповідних CRDT лічильників.
@@Stekljannuj Як один з прикладів - для тестування потрібно було зробити маленький кеш на кожній ноді кластера Орлінса, щоб дані підміняти і тестувати, що потрібно. Так от ваявилося, що це взагалі неможливо зробити ніяк. А дані були дуже гарячі і ходити в централізований кеш не хотілося.
@@fwdays ну то у вас надзвичайно велика технічна експертиза, якщо ви можете робити висновки про доцільність критики поточних рішень вагомих інженерних проблем... в будь якому випадку - відсутність зворотнього звязку також багато про що говорить.
Дуже круто, що гість багато років працює над одним проектом, бачить довгострокові наслідки рішень і тепер нам про це розповідає.
Крутий формат 👍 Дякую спікерам за якісний контент 👏
Дуже розумна людина, та дуже поважна (я про автора каналу). Дякую за насичений ефір та змістовну бесіду. Дуже радий що вас знайшов. Підписався.
Дякую, дуже цікаво.
Цікава, взагалі контора Майкрософт: колись працював над платіжною системою і там теж були актори, але від MS Sercice Fabric.
До речі про акторів.
Зараз працюю з k8s і зацінив, як же круто у Service Fabric, було мати їх із коробки: по коли вони потрібні украй рідко на проекті, але все ж такі потрібні важко їх завезти і ото починаємо городити distributed locks або іноді разрулюємо fifo очередями.
Усьому іншому Service Fabric мало приємно штука і бажаю усім її уникати, але було б круто у k8s з коробки мати якихось акторів для побічних задач
Мають бути "коробочні" дистрибутиви до k8s, під конкретний service mesh, observability та autoscaling.
Сподобався ваш тех.формат, чекатиму ще подібних випусків😊
Мене так пропаяли деякі висловлювання, що довелось шукати вас на ютубі
Без образ - але таке враження що приклади які Ви описуєте це "створення проблем на рівному місці і героїчне вирішення їх" 🙂
Ну так воно найчастіше і працює :)
Ти зараз дивишся на приклади, описані людиною, яка дивиться на них крізь призму досвіду і знань. А коли ти з проблемою в перший раз стикаєшся, то однозначно ідентифікувати, що робити, важко.
Треба менш експертно дивитися на світ, і тоді таких вражень не буде.
Оце fwdays піднялися! Вже Бенедикт Кембербетч в гості прийшов 😂
Бачив на гітхабі цікавий репозиторій про реалізацію event sourcing + cqrs від чуваків з уклону. Було б цікаво послухати про мікросервісні патерни які були використані в уклоні, наприклад часто було сказано "хореографія і оркестрація", трохи попахує сагою)
Може залишилось посилання чи хоча б кейворди як знайти ту репу ? Дуже кортить подивитись на код уклоністів)
сага це не хореографія
Чому взагалі сервіси називають мікросервіси?
В понятті мікросервісної архітектури люди розуміють це про сервіс, а не про архітектуру.
Кріс Річардсон:
"Periodic reminder: Just because they are called MICROservices it does not mean that you should define lots of little services."
Тому люди впершу чергу городять сотні сервісів, які не існують як атомарна одиниця, і це суперечить патерну мікросервісної архітектури.
Мікросевісна - це спочатку про архітектуру, а потім про сервіси
З приводу того що в youtube кілька місць де різні counter перглядів, мені виглядає так що це загальна проблема гугла тому що як мінім такаж проблема з google search console та google play console
Це славнозвісна eventual consistency.
1C ? што?
Про дашборди ютуба так орнув) Така жиза!
Давайте ще
Людина, котра радить раст мабудь ніколи не писала на расті :)
👍
А що ж ви хлопці робите, коли ваші стейтфул сервіси падають, або ще щось з ними трапляється? Все що було у пам'яті тю-тю? І що робити? Накопичували дані по відповідям від водіїв і впала нода, і все, хана всім даним.
Я дуже скептично до Орлінса ставлюся, тому що пацани сову на глобус хотіли натягти. Тільки десь ліворуч-праворуч треба піти і Орлінс не фонтан.
1. Всі наші stateful сервісі будуються на базі partitioned topics (kafka). Відповідно все що було у памʼяті ми відновлюємо з цих топіків на старті компонента.
2. Звичайно, Orleans - це не фреймворк для реалізаціі на ньому всієї системи. В нашому випадку він використовується тільки для 1 задачі - розподілу водіїв між замовленнями (з високим ступенем concurrency) та обробка відповідей від водіїв (які також в окремих бізнес сценаріях сильно конкурентні). І тут він дуже спрощую возню з прімітивами синхронізаціі (lock, etc), distributed locks, рівнями ізоляціі на рівні БД і тд.
Також було б цікаво послухати про ваш досвід з "ліворуч-праворуч".
Нажаль будь які незручні коменти, з можливою критикою майбутніх спікерів fwdays, за цей самий stateful й взагалі позицію DBA в EDA - тут просто видаляють. Akka також вже давно не фонтан, але принаймні там було розуміння, що має бути 2 різновиди акторів - окремо ті що зберігають стан у памяті, домішують CRDT до ES для синхронізації... й ті що зберігають стан в БД...
Нажаль поки в нас немає конкретних практик як саме потрібно використовувати CDC з вже вбудованими лічильниками транзакцій, разом з розумінням яке то має відношення до EDA та відповідних CRDT лічильників.
@@Stekljannuj Як один з прикладів - для тестування потрібно було зробити маленький кеш на кожній ноді кластера Орлінса, щоб дані підміняти і тестувати, що потрібно. Так от ваявилося, що це взагалі неможливо зробити ніяк. А дані були дуже гарячі і ходити в централізований кеш не хотілося.
@@YuriyYarosh Ми не видаляємо коменти з критикою якщо вона у коректній формі доноситься.
@@fwdays ну то у вас надзвичайно велика технічна експертиза, якщо ви можете робити висновки про доцільність критики поточних рішень вагомих інженерних проблем... в будь якому випадку - відсутність зворотнього звязку також багато про що говорить.
Я ще такого не чув) надзвичайно розчарований уклоном
Чому?
Ого, розкажи більше, а то не дуже ясно, про що мова?
Местами от переизбытка сленговых слов уши заворачиваются😑