Приготуйтеся вибрати два з трьох

Білл де Ора

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

Знаменитий приклад такого роду – теорема Брюера, яка свідчить, що для розподіленої системи бажаними є три властивості – цілісність (Consistency), доступність (Availability) і стійкість до розділенню (Partitioning tolerance) – і що досягти всіх трьох цілей відразу неможливо Спроби отримати «все відразу» кардинально підвищують витрати на розробку і, як правило, тягнуть за собою зростання складності, не наводячи при цьому до бажаного ефекту і реальному досягненню бізнес-цілі Якщо дані повинні бути розподіленими і постійно доступними, забезпечення цілісності обходиться все дорожче і в кінцевому рахунку стає нереальним Аналогічним чином, якщо система має бути розподіленим і цілісної, забезпечення цілісності веде спочатку до затримок і проблем з продуктивністю і зрештою – до недоступності в той час, коли система зайнята перевіркою даних

Нерідко зустрічаються ситуації, коли одна або кілька властивостей вважаються недоторканними: дані не повинні дублюватися, всі операції запису повинні бути транзакційними, система повинна підтримувати 100-відсоткову доступність, виклики повинні бути асинхронними, в системі не повинно бути єдиних точок відмови, всі складові частини повинні бути розширюваними і так далі Таке фанатичне ставлення до властивостей не тільки наївно, але і заважає нам думати про ті реальні завдання, які стоять перед нами Від обговорення головних принципів проектування ми йдемо в обговорення відхилень архітектури від ідеалу і починаємо плутати догматизм з якісним управлінням Замість цього слід задати питання: Чому ці властивості так необхідні Які переваги вони приносять Коли вони бажані Як розбити систему на частини для досягнення кращого результату У таких випадках завжди проявляйте здоровий скепсис, тому що архітектурні догми здатні зробити поставку продукту проблематичною Прийняти неминучість таких компромісів – одна з найбільш важких завдань в розробці програмного забезпечення, причому не тільки для архітекторів, але також для розробників та інших зацікавлених осіб І все ж це набагато краще, ніж мати безмежну свободу вибору, – неминучі компроміси часто ведуть до творчих, нестандартним результатами

Білл де Ора (Bill de hOra) – провідний архітектор в компанії NewBay Software, де він працює над великомасштабними веб-системами і системами для мобільних пристроїв Є співредактором Atom Publishing Protocol, раніше брав участь у роботі групи W3C RDF Working Group Визнаний експерт в області REST і архітектур на основі передачі повідомлень, а також проектування протоколів

Джерело: Форд Н, Найгард М, де Ора Б, 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>

*

*