Избор на архитектурен стил (част 3)

Здравей, Хабр. Днес продължавам поредица от публикации, които написах специално за началото на нов поток от курса. "Софтуерен архитект".

въведение

Изборът на архитектурен стил е едно от основните технически решения при изграждане на информационна система. В тази поредица от статии предлагам да анализирам най-популярните архитектурни стилове за изграждане на приложения и да отговоря на въпроса кога кой архитектурен стил е най-предпочитан. В процеса на представяне ще се опитам да начертая логическа верига, която обяснява развитието на архитектурни стилове от монолити до микроуслуги.

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

Сега най-накрая ще дефинираме основните характеристики на архитектурата на микросервизи.

Връзка на архитектурите

Необходимо е да се разбере, че въз основа на определенията, дадени в предишните статии, всяка услуга е компонент, но не всяка услуга е микроуслуга.

Характеристики на микросервизната архитектура

Основните характеристики на архитектурата на микросервизите са:

• Организирани около бизнес възможности
• Продукти, а не проекти
• Интелигентни крайни точки и тъпи тръби
• Децентрализирано управление
• Децентрализирано управление на данни
• Автоматизация на инфраструктурата
• Дизайн за провал
• Архитектура с еволюционно развитие (Evolutionary Design)

Първата точка идва от ориентираната към услугата архитектура, тъй като микроуслугите са специален случай на услуги. Други точки заслужават отделно разглеждане.

Организирани около бизнес възможности

Сега е необходимо да запомните закона на Конуей: организациите, които създават системи, организират своята архитектура, копирайки структурата на взаимодействие в тези организации. Като пример можем да си припомним случая на създаване на компилатор: екип от седем души разработиха компилатор със седем прохода, а екип от петима разработиха компилатор с пет прохода.

Ако говорим за монолити и микроуслуги, тогава ако разработката е организирана от функционални отдели (бекенд, фронтенд, администратори на бази данни), тогава получаваме класически монолит.

За да получат микроуслуги, екипите трябва да бъдат организирани по бизнес възможности (поръчки, пратки, екип по каталог). Тази организация ще позволи на екипите да се съсредоточат върху изграждането на конкретни части от приложението.

Продукти, а не проекти

Проектен подход, при който екип прехвърля разработената функционалност на други екипи, е напълно неподходящ в случай на микросервизна архитектура. Екипът трябва да поддържа системата през целия й жизнен цикъл. Amazon, един от лидерите в внедряването на микроуслуги, заяви: „вие изграждате, вие го управлявате“. Продуктовият подход позволява на екипа да усети нуждите на бизнеса.

Интелигентни крайни точки и тъпи тръби

Архитектурата на SOA обърна голямо внимание на комуникационните канали, по-специално на Enterprise Service Bus. Което често води до Erroneous Spaghetti Box, тоест сложността на монолита се превръща в сложност на връзките между услугите. Архитектурата на микросервизите използва само прости комуникационни методи.

Децентрализирано управление

Ключовите решения относно микроуслугите трябва да се вземат от хората, които действително разработват микроуслугите. Тук ключовите решения означават избор
езици за програмиране, методология за внедряване, договори за публичен интерфейс и др.

Децентрализирано управление на данни

Стандартният подход, при който приложението разчита на една база данни, не може да отчете спецификата на всяка конкретна услуга. MSA включва децентрализирано управление на данни, включително използването на различни технологии.

Автоматизация на инфраструктурата

MSA поддържа непрекъснати процеси на внедряване и доставка. Това може да се постигне само чрез автоматизиране на процесите. В същото време внедряването на голям брой услуги вече не изглежда като нещо страшно. Процесът на внедряване трябва да стане скучен. Вторият аспект е свързан с управлението на услугата в продуктова среда. Без автоматизация управлението на процеси, изпълнявани в различни операционни среди, става невъзможно.

Дизайн за провал

Много услуги на MSA са склонни към провал. В същото време обработката на грешки в разпределена система не е тривиална задача. Архитектурата на приложението трябва да е устойчива на такива повреди. Ребека Парсънс смята, че е много важно вече дори да не използваме комуникация в процеса между услугите; вместо това прибягваме до HTTP за комуникация, която не е толкова надеждна.

Архитектура с еволюционно развитие (Evolutionary Design)

Архитектурата на системата MSA трябва да се развива еволюционно. Препоръчително е да ограничите необходимите промени до границите на една услуга. Трябва да се вземе предвид и въздействието върху други услуги. Традиционният подход е да се опитате да разрешите този проблем с версии, но MSA предлага използването на версии в
в краен случай.

Заключение

След всичко по-горе, можем да формулираме какво представляват микроуслугите. Архитектурата на микросервизите е подход за разработване на едно приложение като колекция от малки услуги, всяка от които работи в свой собствен процес и взаимодейства чрез леки механизми, често API за HTTP ресурс. Тези услуги са изградени на базата на бизнес възможности и могат да бъдат разгърнати независимо, като се използват напълно
механизъм за автоматизирано разгръщане. Има минимално ниво на централизирано управление на тези услуги, които могат да бъдат написани на различни езици за програмиране и да използват различни технологии за съхранение на данни.

Прочетете част 2

Източник: www.habr.com