CloudEvents SQL Expression Language 1.0, або CESQL, задає переносну SQL-подібну мову для обчислення умов над context attributes і extensions CloudEvent. Мова є чистою та total: оцінювання завжди повертає значення, а проблеми додатково повертаються як набір помилок. Поліморфне поле data версія 1.0 навмисно не обробляє.
Фільтр є частиною контракту
У розподіленій системі producer не повинен знати кожного consumer. Підписник описує потрібні події за type, source, subject або extension attributes, а інфраструктура відкидає решту. Спільна семантика зменшує ситуації, коли та сама умова по-різному працює в broker і локальній бібліотеці.
Типи й помилки визначені явно
CESQL 1.0 має String, Integer і Boolean, а також правила приведення типів. Звернення до відсутнього атрибута повертає нульове значення очікуваного типу та MissingAttributeError. Якщо CESQL використовується як filter predicate, результат має бути Boolean, а подія з будь-якою помилкою не повинна пройти фільтр.
Context attributes — навмисна межа версії 1.0
Вираз може звертатися до стандартних атрибутів і extensions, але не до поля data через його поліморфну природу та складність. Для умов над payload потрібен інший механізм. Це обмеження не варто обходити перетворенням усього data на випадковий extension: контракт події має залишатися зрозумілим.
Переносність потрібно перевірити
Реалізації можуть підтримувати різні версії або підмножини мови. Перед міграцією готують conformance-набір із граничними значеннями, Unicode, числами, null та missing. Той самий набір запускають у локальному evaluator і хмарному event service.
Складний вираз впливає на експлуатацію
Фільтр має бути спостережуваним: оператор повинен бачити версію, кількість прийнятих і відхилених подій та помилки оцінювання. Надто складну бізнес-логіку краще виконувати в consumer, де є тести й журнал рішень. Інфраструктурний фільтр залишають коротким, детермінованим і дешевим.
Експлуатаційний контроль
Після впровадження варто вимірювати accepted і rejected events, MissingAttributeError, cast та math errors і затримку фільтрації. Метрики пов’язують із конкретною версією конфігурації та доповнюють журналом рішень: сам графік без контексту не пояснює, чи зміна є нормальною, помилковою або наслідком атаки. Власник системи визначає пороги, канал сповіщення і безпечну дію після їх перевищення. Рішення та набір тестів переглядають, коли змінюється schema події, версія мови, event service або набір context attributes. Такий перегляд потрібно планувати заздалегідь, а не відкладати до інциденту.
Практичний чекліст
- стандартизувати type, source, subject і extensions
- підготувати тести для missing attributes, cast і math errors
- не очікувати доступу CESQL 1.0 до поля data
- перевірити підтриману версію в кожному сервісі
- моніторити відхилені події та помилки виразу
Висновок
Технологія дає користь лише тоді, коли її властивості пов’язані з конкретною моделлю загроз, операційними обмеженнями та перевірними тестами. Починати варто з малого пілота, зберігати версії конфігурації й доказів, а рішення про розширення приймати за виміряними результатами.
Першоджерела: CloudEvents SQL v1.0.
Коментарі
Щоб залишити коментар, увійдіть через Google.