привет это канал lies in it и сегодня мы слушаем статью отличие со от микро сервисной архитектуры с сайтами crage.ru от автора кирилл ветчинкин спасибо автору за статью и ссылка на статью конечно будет в описании к видео часто на конференциях или формах возникает вопрос в чем отличие микро сервисов от со ответ часто сводится в техническим особенностям реализации со таким как наличие есть б централизация крупные сервисы и тому подобное все это действительно так но сегодня мы хотим дать более развернутый ответ и посмотреть на корневые различия плюсы и минусы этих двух архитектур начнем с a service oriented архитектор
или сервис-ориентированной архитектура в его основе лежат несколько основных идей перри использование сервисов и корпоративная шина разработчики стремятся разбить систему на сервис и таким образом чтобы их можно было использовать повторно взаимодействие маршрутизация осуществляется через корпоративную шину sb типично слова архитектура показано на рисунке на экране давайте посмотрим из каких частей на состоит и какова их роль шина то есть есть b в случае взаимодействия в сложных событий действует как посредник и управляет различными рутинными операциями такими как передача сообщений и координация вызовов инфраструктурные сервиса группы легко перри используемых сервисов такие как аутентификации и авторизации отправкой sms и прочее прикладные
сервисы или applications services не могут быть перри использованы под разные задачи так как ограничены определенным прикладным контекстом но их можно встраивать в более высокоуровневые сервисы сервисы предприятия или enterprise rss эти сервисы отвечают за реализацию крупных частей бизнес-процессов компании и они потребляют более низкоуровневые сервиса и и pr по сути это бэг-энда предоставляющие api для сайтов и мобильных приложений компании они взаимодействуют с юсб и раскрывает функциональность для конечных пользователей как вы могли заметить проектирую архитектуру в данном стиле мы имеем очень большое количество слоев и как следствие команд которыми владеют любой запрос пронизывают все свои системы в большей
степени напоминая монолитную архитектуру но данный тип архитектуры намного сложнее потому что является распределенная уровень теперь mc на красавице сарки керчи микро сервисы в отличие от со наоборот избегают повторного использования применяя философию предпочтительнее дублирования о независимости от других сервисов повторное использование предполагает связанность архитектура микро сердца в значительной степени старается избегать это достигается за счет разбиения системы на сервис ип ограниченным контекстом бизнес отраслям типичная массой архитектура показано на рисунке на экране в отличие от слова каждый сервис обладает всеми необходимыми для функционирования частями имеет свою собственную базы данных и существует как независимый процесс к архитектура делает каждый сервис
физически разделенным самодостаточным что ведет с технической точки зрения к архитектуре без разделения ресурсов сервисы раскрывается ли потребителей также через слой api но его стараются проектировать с полным отсутствием какой-либо логики это фактически просто проксирование api сервиса вовне взаимодействие между сервисами сводятся к обмену данными из польза баркер сообщений именно к обмену данными они вызовы методов из других сервисов как вы могли заметить проектировке текстуры в данном стиле мы имеем небольшое количество слоев но достаточно много сервисов и команд которые ими владеют основной сложностью данной архитектуры является правильное определение ограниченного контекста элиту деление сервисов по командам давайте же сравним со
и м с точки зрения развития и поддержки системы внесение изменений со выполнять изменения в архитектуре со через вы чай на трудно зачастую для внесения 1 изменения требуется изменения сразу в нескольких сервисах так как отдельными сервисами владеют разные команды то внесение элементарных изменений превращается в сущий ад из бесконечных совещаний согласований и документов если две разные команды используют один и тот же сервис то при изменении этого сервиса нужно будет учитывать влияние на сервиса обеих команд когда таких зависимости много развивать сервис становится трудновато так как микро сервисной архитектуре зависимости от других сервисов отсутствуют либо минимальны то необходимость взаимодействию
с другими сервисами и командами пропадает внесение изменений осуществляется командой которая владеет сервисом изменения происходят легче и быстрее перри использование и дублирование со стремится к перри использованию но к сожалению разработчики часто тратят много времени пытаясь интегрировать повторный спа и мы сервиса который как оказывается мало используется повторно в конечном итоге мы приходим к ситуации чем больше у сервиса возможности для повторного применения теме непригодным к применению он становится может возникнуть ситуация когда в 2 разных сервиса использует одну и ту же сущность к примеру кости на микро сервисной архитектуре предпочтительнее использовать дублирование то есть создать в каждом сервисе свою
реализацию каста мир что позволит развивать оба сервиса независимо есть большая вероятность что спустя время в одном из сервисов изменится 2 бизнес-правила или структура объекта кастеры но так как в двух сервисах сущность дублируются то на другой сервис это не окажет никакого влияния оба сервиса все также могут развиваться независимо команда и поддержка большинство команд архитектуры сола разделены так же как и архитектура и требуется колоссальные усилия на координацию для простых изменений в основном это связано с тем что большинство из команд не владеет процессом от начала до конца а лишь развивает сервисы которые являются его частями как следствие они
не понимают и не отвечают за процесс целиком в микро сервисной архитектуре команда кросс функционально то есть она включает в себя всех специалисты в необходимых для развития сервисов так сервис реализует процесс от и дата команды владеть процессом от начала и до конца как следствие они понимают и отвечают за процесс целиком и да за часть фронтэнда в рамках сервиса также отвечает команда взаимодействие в сон взаимодействие осуществляется через корпоративную шину если в ней со временем появляется много логики то она легко становится бутылочным горлышком в микро сервисах каждый сервис обладает всеми частями своего ограниченного контекста и осуществляет связь с
другими ограниченными контекстами с помощью обмена данными используя брокер сообщений просто обмен никакой сложной логики автоматизация и развертывания архитектуру со на основе событий сложно ввести в эксплуатацию эта архитектура состоит из множества развертываемых модулей что затрудняет процесс автоматизации и координации вмс и сервис может быть развернут независимо от других сервисов и другой инфраструктуры что отражает ограниченный контекст возможность для разработчик развертывать один сервис не оказывая влияние на другой является одним из преимуществ архитектура этого типа тестирование тестирование архитектуры со затруднено ни одна из частей архитектуры не явля завершенный все они являются частью более крупного рабочего потока и обычно не предназначенные
для изолированного тестирования провести нтн тестирование такой систему практически нереально вмс и так как каждый сервис имеет хорошо определенную границу и минимум зависимости это позволяет легко тестировать сервис в изоляция других частей системы подготовка тестовых данных и управление ими также облегченная так как они находятся под контролем той же команды что и разрабатывает сам сервис немногочисленные зависимости сервиса базы данных брокер сообщений легко монтируются кстати тестирование у меня есть на примете один очень классный канал телеграме который называется кладовку тестировщик это дайджест интересных материалов для к инженеров и тестировщиков там в канале есть познавательный к теории практические советы по автоматизации
тестирования полезные ресурсы разные находки для q&a обзор инструментов тестирования и разные рассказы жизни по обеспечению качества так что подписывайтесь на канал и ссылка конечно будет описание очень рекомендую подведем итоги архитектуры программного обеспечения создаются не в вакууме а как ответ на окружающую среду учитывая различные ограничения среды 10 лет назад не были так популярны система с открытым исходным кодом не был докера предложения разворачивались на дорогих железных серверах вся инфраструктура была коммерческой лицензионные дорогостоящий со было оптимально для оптимизации и утилизации инфраструктуры отсюда и такая тяга к перри использованию сейчас большая часть программного стыка имеет открытый исходный код и
лицензирование и другие проблемы больше не влияет на архитектуру система непрерывного развертывания и движения devops позволяют легко управлять и создавать соки независимых сервисов важно понимать что различие между двумя подходами не столько технического сколько концептуальная если вы убрали есть б но при этом все еще стремитесь к перед пользование и у вас много зависимости между сервисами то такую архитектуру нельзя назвать микро сервисный под конец я хотел бы вставить один абзац из другой статьи инсайта кадр лес . com сопротив микро сервисов и там очень лаконично расписано основные различия подходов сориентирована на повторное использование сервиса приложений и микро сервисы на
разъединение со приложение созданы для выполнения многочисленных бизнес за микро сервисы для выполнения одной бизнес-задачи что предполагает совместное хранилища данных между службами тогда как микро сервисах каждая служба может иметь независимое хранилище данных со предназначен для совместного использования ресурсов между службами а микро сервисы для размещения служб которые могут функционировать независимо в архитектуре сады maps и непрерывная доставка становятся популярными но еще не стали массовыми в то время как микро сервису уделяет большое внимание devops и непрерывной поставки со это менее масштабируемой архитектуры а микро сервиса наоборот очень масштабируема и ну а на этом всем спасибо что послушали эту статью
надеюсь вам как и мне было интересно спасибо кириллович ангину за то что написал эту статью на сайте micro-atx точка ру но вы обязательно пишите в комментариях что еще хотели бы послушать на нашем канале какие статьи на какую тематику если понравилось это видео ставьте лайк и подписывайтесь на канал чтоб поддержать его но все пока
