Як пояснити архітектуру системи англійською мовою
Додаткові методи і точний англійський словник для чіткого пояснення системної архітектури як технічним, так і нетехнічним аудиторіям у презентаціях і оглядах.
Пояснення системної архітектури є одним з найважливіших комунікаційних навичок в інженерії програмного забезпечення. Якщо це добре зроблено, то це вирівнює команду навколо спільного розуміння, завойовує довіру зацікавлених сторін і рано виявляє ризики проектування. Погано зроблене, це залишає аудиторію збентеженою, породжує недовіру і призводить до рішень, прийнятих на неповній інформації. Виклик полягає в тому, що велике пояснення архітектури повинно працювати одночасно на декількох рівнях: концептуальна ясність, технічна точність і розповідна послідовність.
Основні напрямки діяльності: 1
Одну й ту ж архітектуру треба пояснювати по-різному, залежно від того, хто в кімнаті. Один з колег-архітекторів хоче вивчити гарантії послідовності даних і режими аварій. Менеджер продукту повинен розуміти, як система дозволяє бачити продукт. Виконавець турбується про ризик, вартість і час на виконання.
Просунуті комунікатори можуть плавно перемикатися між цими регістрами, залишаючись точними. Словниковий запас і рамки змінюються; але істина не змінюється.
Складання опису: описовий метод
Найефективніші пояснення архітектури рухаються ззовні всередину, від високорівневої мети до низькорівневої деталі. Це шарування поважає когнітивні обмеження аудиторії і дозволяє людям залучатися до глибини, яка має для них значення.
1-й шар: мета і контекст
Почніть з того, що засноваєте архітектуру на проблемі, яку вона вирішує. Никогда не предполагай, что аудитория разделяет твой контекст.
- «Ця система обробляє всі фінансові транзакції для наших клієнтів у Великій Британії та ЄС — приблизно 140 000 транзакцій на день в пікові дні»
- «Архітектура, яку ми замінюємо, була монолитом, який не міг масштабуватися за межі одного регіону і мав 4-годинний цикл розгортання. Цей дизайн вирішує обидва обмеження»
- «Перед тим, як я пройдусь по компонентах, дозвольте мені пояснити дві непереконливі вимоги, які формували кожне рішення тут: час відповіді менше 100 мс і нульова втрата даних при несправності»
2-й шар: Основні компоненти та їх ролі
Введіть компоненти по одному за раз. Назовите каждое, поясните его обязанности и разъясните его границы.
- “Система має чотири основні компоненти. Дозвольте мені представити кожного з них, перш ніж я поясню, як вони взаємодіють»
- “API Gateway є єдиною точкою входу для всього клієнтського трафіку. Вона обробляє автентифікацію, обмеження швидкості і маршрутизацію запитів»
- “Служба замовлень володіє бізнес-логікою для створення і оновлення замовлень. Вона не має власної оплати — це окремий обмежений контекст»
Шлях 3: Потік даних та взаємодії
Після встановлення компонентів поясніть, як вони взаємодіють.
- «Коли клієнт робить замовлення, запит прибуває до API Gateway, який автентифікує токен і направляє його до Служби замовлень»
- “Служба замовлень публікує подію в чергу повідомлень. Служба інвентаризації і служба попереджень є абонентами — вони реагують на подію незалежно.»
- “Ключева річ тут в тому, що Служба Заказів ніколи не викликає Службу Інвентарізації безпосередньо. Всі зв’ язки є асинхронними через шину подій. Це те, що дає нам роз’єднання»
4-й рівень: зберігання даних
- “Кожна служба має свою базу даних. Немає спільної бази даних. Це було навмисне рішення, щоб забезпечити обмеження послуг і дозволити незалежне масштабування»
- «Служба замовлень використовує PostgreSQL для транзакційних даних. Служба аналітики читає з окремої репліки читання, щоб уникнути впливу на продуктивність запису»
Шар 5: Режими відмови і компроміси
Цей шар відрізняє хороші презентації від чудових. Проактивне надання назв компромісам демонструє архітектурну зрілість і створює довіру.
- «Ця конструкція має компроміс: оскільки комунікація є асинхронною, оновлення інвентаря врешті-решт є послідовним. Есть окно, в котором клиент может теоретически заказать товар, который только что был распродан. Ми прийняли цей компроміс, тому що альтернатива — синхронні виклики — зробить шлях замовлення залежним від доступності послуги інвентаризації»
- “Єдиний API Gateway є потенційною єдиною точкою невдачі. Ми зменшили це, запустивши три екземпляри за балансувальником навантаження з автоматичним відключенням, але це залишається архітектурною проблемою, яку ми моніторимо»
Основні положення для пояснення архітектури
- ** Обмежений контекст ** — чітко визначена межа домена, в межах якої модель є послідовною і самодостатньою
- ** Сервісний кордон ** — межа відповідальності служби; що вона має і що вона делегує
- ** Спільний зв’ язок ** — ступінь залежності одного компонента від іншого; загалом бажано низький ступінь спілкування
- ** Сплоченість ** — наскільки добре відповідальність у межах компонента належить разом; бажана висока сплоченість
- ** Архітектура, керована подією ** — шаблон, за якого компоненти спілкуються за допомогою створення і використання подій
- ** Послідовність можливих оновлень ** — гарантія того, що за достатньо тривалого часу без нових оновлень всі вузли перейдуть до одного стану
- ** Ідемпотентність ** — властивість дії, яку можна виконати декілька разів з таким же результатом, як і при виконанні дії один раз
- ** Прохідність ** — обсяг роботи, який система може виконати за одиницю часу
- ** Затримка ** — часова затримка між запитом і відповіддю на нього
- ** Горизонтальне масштабування ** — додавання більше екземплярів служби для збільшення обсягу
- ** Вертикальний масштаб ** — додавання ресурсів (ЦП, пам’ яті) до існуючих екземплярів
- ** Stateless ** — служба, яка не зберігає стан між запитами; легше масштабувати горизонтально
- ** Ідіоматичний ** — за звичками і найкращими практиками певної технології або шаблону
Корисні фрази переходу
Хороші пояснення архітектури природно переходять від компонента до компонента і від концепції до деталей. Ці переходи допомагають:
- «Тепер, коли ми встановили компоненти високого рівня, дозвольте мені пройти через конкретний поток запитів»
- Це приводить нас до питання про послідовність даних, де дизайн стає цікавим. ”
- «Перед тим, як я піду далі, дозвольте мені відзначити одне припущення, яке ми зробили на початку — воно формує декілька подальших рішень»
- «Я повернуся до режиму невдачі тут, але спочатку дозвольте мені закінчити щасливий шлях»
- «Є два варіанти, які ми розглядали на цій стадії прийняття рішення. Дозвольте мені пояснити, чому ми вибрали саме цей»
- “Це покриває шлях читання. Шлях запису схожий, але з однією важливою відмінністю»
Використовується для виготовлення архітектурних деталей
Старші інженери та архітектори розглянуть ваш проект. Підготуйтеся до типових питань:
** “Чому б не скористатися X замість цього?” ** “Ми розглядали X. Причина, по якій ми відкинули це, була [специфічне обмеження]. Якщо це обмеження зміниться, X варто переглянути»
“Що станеться, якщо Y зазнає невдачі?” «Готове питання — дозвольте мені пройти через режим невдачі. Якщо Y падає, [описати вплив]. Нашими заходами є [описати заходи]. Залишковий ризик становить [описати залишковий ризик].”
“Як це масштабується?” “Вузьке місце в масштабі - це [компонент]. Ми можемо горизонтально масштабувати [сервіси] без змін. Поза [поріг], нам потрібно буде переглянути [компонент або шаблон]»
“Чи розглядали ви наслідки безпеки Z?” “Так - [описати, що було розглянуто]. Остання проблема - це [X], яка знаходиться в нашому списку безпеки. Ми приймаємо цей ризик до [вікового рубежу]»
Архітектурна пам’ятка
Найзапам’ятніші пояснення архітектури розповідають історію. У них є проблема, набір обмежень, ряд рішень і результат. Вони називають те, чим жертвували і що отримували. Вони залишають аудиторію з послідовною ментальною моделлю, а не списком компонентів.
Вправляйтеся у поясненні вашої архітектури вголос — навіть самому собі. Пробели в ясності, які ви помічаєте, коли говорите, є тими ж пробелами, які помітить ваша аудиторія. Заповніть їх перед зустріччю, і ви зможете представити себе з впевненістю, що походить від справжнього розуміння.