Дата зовні, дата всередині, дата танцюй, дата помри

image

У статті «Дані зовні і дані всередині» 2005 року Пет Хелланд розмірковує про даних в сервіс-орієнтованих архітектур. В даний час СОА прийнято вважати «микросервисной архітектурою», що складається з «микросервисов». Хелланд показує, що для інкапсульованих даних і даних, якими обмінюються сервіси, потрібні абсолютно різні підходи. Перехід від монолітної структури до микросервисам більш глибокий, ніж просто рефакторинг коду в зручні, незалежно розгортаються модулі:

Перехід до микросервисам — це перехід від ньютонівської фізики до фізики Ейнштейна. В часи Ньютона теорія дещо розходилася з практикою, що влаштовувало далеко не всіх. До появи микросервисов багато системи для розподілених обчислень виглядали схоже: з RPC, 2PC і так далі. У всесвіту Ейнштейна все відносно і залежить від конкретної точки зору. У микросервисов «справжнє» знаходиться всередині (сервісу), а «минуле» приходить в повідомленнях.

Схоже, нам слід перейменувати рефакторинг «витяг микросервиса» (extract microservice) в «зміна моделі простору-часу» :).

Нещодавно микросервисы залучили багато уваги. Це системи, що складаються з численних сервісів, кожен зі своїм кодом і даними, здатних оперувати незалежно один від одного… В цій роботі відображено ряд основних відмінностей між даними всередині сервісу та даними, відправленими у зовнішній простір, за межі сервісу.

Давайте розберемося.

Сервіси інкапсулюють дані, якими вони володіють. Будь-які зміни, а також операції читання цих даних здійснюються через строго певний інтерфейс. Зміни може вносити тільки довірена логіка програми в рамках сервісу. Зовні сервісу немає ніяких ACID-транзакцій:

Участь у ACID-транзакції передбачає готовність утримувати блокування бази даних до тих пір, поки координатор транзакції не вирішить закоммитить або скасувати транзакцію. Для некоординатора це серйозне обмеження його незалежності...

«Дані всередині» — це інкапсульовані приватні дані, що містяться у рамках сервісу. «Дані зовні» — це інформація, яка передається між незалежними сервісами.

Минуле, сьогодення, майбутнє і «потім»
Всередині сервісу ми можемо використовувати транзакційний доступ до даних, з транзакционной ізоляцією, що створює ілюзію того, що кожна транзакція виконується в строго певний момент часу…

ACID-транзакції існують у «справжньому». У міру перебігу часу і виконання комітів транзакцій кожна нова транзакція отримує вхідні дані транзакцій-попередниць. Логіка виконання сервісів існує з чітким і ясним відчуттям «справжнього».

Надіслані сервісом повідомлення часто можуть містити дані сервісу. Відправник не буде застосовувати блокування даних після надсилання повідомлення. Отже, до того часу, як одержувач обробить повідомлення, вихідні дані всередині відправника можуть змінитися.

Вміст повідомлення завжди приходить з минулого! Воно ніколи не буває у стані «справжнього».

У кожного сервісу — своє власне сприйняття внутрішніх даних, формує уявлення про поточний момент. А зовнішні дані формують уявлення про минуле. Командні повідомлення, дають завдання сервісів, це «надії на майбутнє».

Виходить гримуча суміш минулого, теперішнього і майбутнього:

Операнди можуть існувати або в минулому, або в майбутньому (в залежності від шаблону їх використання). У минулому вони живуть тоді, коли мають копії незаблокированной інформації віддаленого сервісу. А в майбутньому вони живуть тоді, коли містять передбачувані значення, які можуть бути використані при успішному завершенні оператора. Між сервісами все знаходиться в стані «потім»… Як наслідок, дані зовні живуть у світі «потім». Це або минуле, або майбутнє, але не зараз.

Оскільки кожен сервіс живе у власному сьогоденні, то синхронізація цього справжнього з вхідним і вихідним «потім» залежить від логіки сервісу.

Впливу зовнішніх даних
Дані зовні повинні бути незмінними і идентифицируемыми, щоб вони залишалися незмінними незалежно від того, коли і де на них посилаються. В рамках сервісу ви можете посилатися на The New York Times, і завжди буде матися на увазі поточна версія. В даному випадку The New York Times об'єкт, не залежний від версії ідентифікатора. Але коли дані залишають сервіс, то вже недостатньо сказати «The New York Times»; не залежний від версії ідентифікатор повинен стати залежних від версії ідентифікатором. Наприклад, «The New York Times, 4 січня 2005 року, Каліфорнійське видання».

Незмінюваність — недостатня умова для уникнення плутанини. Повинна існувати недвозначна інтерпретація контексту даних. Стабільні дані мають недвозначну і незмінну інтерпретацію протягом «простору і часу»… Є декілька способів створення стабільних даних — використання тимчасових міток і/або версійності або використання унікальних важливих ідентифікаторів.

Повідомлення повинні бути незмінними (наприклад, їх вміст не повинно змінюватися в разі повторення запитів) разом з їх схемою.

Саме тому рекомендується версионировать схеми повідомлень, і кожне повідомлення повинно використовувати залежний від версії ідентифікатор точного визначення формату повідомлення.

(Далі в своїй статті Хелланд обговорює схему, що забезпечує розширюваність.)

При посиланні на інші дані необхідно, щоб ідентифікатор, що використовується для посилання, також був незмінним.

Внутрішні дані
Внутрішні дані — це царство SQL і DDL SQL. SQL і DDL живуть в «справжньому»…

Як і інші операції в SQL, оновлення схеми через DDL виконуються під захистом транзакції і застосовуються атомарно. Зміни схеми можуть вносити суттєві відмінності у способи інтерпретації даних, що зберігаються в базі. Ключове якість DDL полягає в тому, що транзакції, що передують операції DDL, засновані на схемі, що існувала раніше, а транзакції, наступні за операцією DDL, засновані на новій схемі. Іншими словами, зміни в схемі беруть участь в механізмах серіалізації баз даних.

Отримані ззовні дані можуть бути перетворені в зручну для використання сервісом форму. Припустимо, можна зберігати зовнішні дані в «документі» (як приклад у статті наведено XML, найпопулярніший у 2005 році мова). З допомогою цього можна домогтися розширюваності і завдяки ній додати інформацію, не оголошену у вихідній схемі повідомлення.

Розширюваність багато в чому нагадує нотатки на полях. Вона часто дає бажаний результат, але без жодних гарантій.

Другий варіант — «подрібнення» даних: перетворення в реляційну подання.

Цікавий момент — розширюваність конфліктує з «подрібненням». У запланованих таблицях потрібно відобразити незаплановані розширення.

Вибір відповідного подання даних
Стаття завершується розглядом трьох різних представлень даних XML, SQL і інкапсуляції об'єкта. (Зараз ми можемо додати JSON або замінити їм XML. SQL і XML/JSON, по суті, це антиинкапсуляция: вони роблять дані абсолютно доступними. Компоненти та об'єкти, навпаки, підсилюють інкапсуляцію.

Враховуючи все вищесказане, Хелланд пропонує таблицю вимог до внутрішнім і зовнішнім даними:



… Ми розглядаємо інкапсуляцію і розуміємо, що зовнішні дані не захищені кодом. Не існує загальноприйнятого способу переконатися, що тіло коду є посередником при доступі до даним. Більш того, в силу поточної архітектури, ви повинні розуміти внутрішню структуру повідомлення, якщо у вас є доступ до неї. Внутрішні дані завжди є частиною сервісу та логіки програми.

У кожного з трьох вистав свої переваги і недоліки, тому що вони по-різному підходять для внутрішніх і зовнішніх ролей:



Перевага кожної моделі одночасно є її слабкістю! Те, завдяки чому SQL чудово підходить для створення запиту, що робить його жахливим рішенням для незалежного визначення загальних даних. XML чудово підходить для незалежного визначення і створення даних, але не годиться для інкапсуляції. Інкапсуляція — ключова перевага об'єктних систем, але при цьому несумісна з запитами. Ні в одну з цих моделей можна додати можливості, компенсуючі їх слабкості, без втрати переваг!

Так що можна сказати, що у кожної з моделей є своя роль, необхідні всі три:

Якщо усвідомити, що більшість розробників ЗА досить розумні, то цей висновок не повинно вас дивувати. Сьогодні є нормальною практикою використання XML для представлення зовнішніх даних, об'єктів — для реалізації бізнес-логіки сервісів, SQL для зберігання даних всередині. Нам потрібні всі три вистави, і ми повинні вигідно використовувати їх сильні сторони!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.