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

Здравейте, Хабр. Днес продължавам серията публикации, които написах специално за старта на новия поток на курса «Software Architect».

Въведение

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

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

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

Отношение на архитектурите

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

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

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

• Организирани около бизнес възможности (Organized around Business Capabilities)
• Продукти, а не проекти (Products not Projects)
• Умни точки за достъп и глупави канали (Smart endpoints and dumb pipes)
• Децентрализирано управление (Decentralized Governance)
• Децентрализирано управление на данни (Decentralized Data Management)
• Автоматизация на инфраструктурата (Infrastructure Automation)
• Защита от сривове (Design for failure)
• Архитектура с еволюционно развитие (Evolutionary Design)

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

Организирани около бизнес възможности (Organized around Business Capabilities)

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

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

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

Продукти, а не проекти (Products not Projects)

Проектният подход, при който екипът предава разработената функционалност на други екипи в случай на микросервисна архитектура, е напълно неподходящ. Екипът трябва да поддържа системата през целия й жизнен цикъл. Компанията Amazon, един от пионерите в внедряването на микросервиси, заявява: "вие изграждате продукта, и вие го стартирате" ("you build, you run it"). Продуктовият подход позволява на екипа да усети нуждите на бизнеса.

Умни точки за достъп и глупави канали (Smart endpoints and dumb pipes)

SOA архитектурата отдава голямо значение на комуникационните канали, по-специално на Enterprise Service Bus (служебна шина на предприятието). Това често води до Erroneous Spaghetti Box, т.е. сложността на монолита преминава в сложността на връзките между услугите. В микросервисната архитектура се използват само прости средства за взаимодействие.

Децентрализирано управление (Decentralized Governance)

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

Децентрализирано управление на данни (Decentralized Data Management)

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

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

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

Защита от сривове (Design for failure)

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

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

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

Заключение

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

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

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