Ласкаво просимо в реальний світ

Грегор Хоп

Технарі люблять точність – особливо програмісти, що живуть у світі нулів і одиниць Вони звикли працювати з двійковими рішеннями: один / нуль, істина / неправда, так / ні Все чітко і послідовно, від несподіванок захищають обмеження зовнішніх ключів, атомарні транзакції і контрольні суми

На жаль, реальний світ не настільки впорядкований Клієнти оформляють замовлення, а через секунду скасовують їх Чеки відхиляються, листи губляться, платежі затримуються, а обіцянки порушуються Помилки введення даних відбуваються частіше, ніж нам хотілося б Користувачі воліють «плоскі» («shallow») інтерфейси, які надають одночасний доступ до багатьох функцій, а не довгий і вузький коридор «процесу» введення даних, який простіше реалізується і здається багатьом розробникам більш «логічним» Ходом виконання програми управляє вже не стек викликів, а користувач

Розподілені системи тільки погіршують становище, тому що в гру вступає сила-силенна нових неузгодженостей Служби бувають недоступні, змінюються без попереднього повідомлення і не надають транзакційних гарантій При виконанні програми на тисячах компютерів питання вже не в тому, чи відбудеться збій, а в тому, коли він відбудеться Такі системи мають слабку повязаністю (loosely coupled), асинхронність і паралелізмом і не відповідають традиційній транзакционной семантиці .. Не бажаєте взяти синю таблетку!

Дивний новий світ компютерних технологій тріщить по швах – так що ж нам робити Як це часто буває, усвідомлення проблеми стає першим важливим кроком до її вирішення

Розпрощайтеся зі старою доброю детермінованою архітектурою стека викликів, в якій ви самі визначали, що, коли і в якому порядку відбувається Замість цього будьте готові реагувати на події в будь час і в будь-якому порядку, відновлюючи стан системи в міру необхідності Видавайте асинхронні запити паралельно замість послідовного виклику методів Щоб уникнути повного хаосу, моделюйте свій додаток, використовуючи керовані подіями ланцюжка процесів або моделі станів Нейтралізуйте помилки через корекції, повторних спроб або тестових операцій

Звучить надто страхітливо Ви на таке не розраховували На щастя, в реальному світі зі схожими проблемами мають справу вже давно: затримки листів, порушені обіцянки, переплутані повідомлення, платежі не на ті рахунки – прикладів не злічити Відповідно люди змушені посилати листи заново, списувати некоректні замовлення і ігнорувати нагадування про вже проведені платежі Не звинувачуйте реальний світ у своїх проблемах – краще використовуйте його, щоб підглянути рішення Зрештою, Starbucks теж не використовує протокол двофазної фіксації[13]

Грегор Хоп (Gregor Hohpe) – архітектор ПЗ в компанії Google, Inc Грегор є загальновизнаним експертом в області асинхронних архітектур для систем обміну повідомленнями і сервіс-орієнтованих архітектур Він є співавтором книги «Enterprise Integration Patterns»[14] (Addison-Wesley Professional), регулярно виступає на технічних конференціях по всьому світу

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*