[Микросервисы] Архитектура микросервисов: Разрушение монолита (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
01-Июн-2021 21:30

Цитировать

Мы расскажем о том, как можно разбить монолитное приложение на более мелкие части, составляющие модульную систему, и обсудим миграцию в облако.Эта статья подводит итог вебинара "Разрушение монолита", представленного Даниэлем Гутьерресом Сааведрой, старшим инженером-программистом компании Zartis. Вы можете посмотреть полный текст вебинара, который также включает сессию вопросов и ответов, ниже!Извините, данный ресурс не поддреживается. :( Вы работаете с монолитными системами и унаследованными приложениями? Вы ищете способы модернизировать свою архитектуру и перейти на микросервисы? В этой статье мы расскажем о том, как можно разбить монолитное приложение на более мелкие части, которые образуют модульную систему.Почему стоит выбрать микросервисы Микросервисы разрабатываются с использованием бизнес-ориентированных API для инкапсуляции основных бизнес-возможностей. Принцип слабой связи (loose coupling) помогает устранить или минимизировать зависимости между сервисами и их потребителями.Кроме всего прочего, они являются:

Масштабируемыми
Управляемыми
Поставляемыми
Гибкими

В конце концов, архитектуру микросервисов намного проще тестировать и развертывать. Если мы добавим к уравнению подход DevOps, где у нас есть очень маленькие части кода, которые можно тестировать и развертывать небольшими порциями, преимущества станет невозможно игнорировать.Проблемы микросервисовЗдесь важно признать, что архитектура микросервисов действительно сопряжена с некоторыми трудностями. Существует несколько дополнительных уровней сложности, поскольку в системе будет много подвижных частей, и тестирование микросервисов может оказаться сложным.Вот некоторые из основных проблем, которые необходимо учитывать:

Дополнительные уровни сложности.
Если ваше программное обеспечение не меняется часто, оно может ничего не исправить.
Приобретение новых продуктов требует дополнительных затрат.
Как только вы переходите в облако, это позволяет вам выполнять дополнительные действия, такие как ведение журналов, дополнительные меры безопасности и т.д. Ваша команда должна будет самостоятельно обучиться использованию этих инструментов.

Разрушение монолитаЭффективный способ перевода системы на архитектуру микросервисов — начать с определения основных сервисов, а затем провести их рефакторинг и разделение. Давайте подробнее рассмотрим, как можно осуществить эти изменения, и рассмотрим лучшие варианты хранения приложения в облаке.Шаг 1: Определение основных услугЦелесообразно начать миграцию с определения критически важных сервисов, которые могут быть теми, что приносят наибольший доход вашему бизнесу, или часто используются вашей клиентской базой. Эти службы будет труднее всего отделить от монолита. Критичность вашего сервиса определяется только вами. Но первое, что вы должны сделать при переходе к микросервисам, — это их идентифицировать. Когда приходит время нарезать элементы, лучше сделать это горизонтально — просто представьте это с точки зрения слоев; у вас есть бизнес-слой, презентационный слой, слой данных и т.д. Нарезка по вертикали означала бы попытку разделить функциональность, которая охватывает весь спектр слоев в ваших приложениях, что может привести к появлению шаблонов и дублированию бизнес-логики.Для примера возьмем проектирование, управляемое доменом (Domain-Driven Design, DDD). В микросервис-ориентированной системе, возможно, наш домен очень большой, который может охватывать множество микросервисов, и они могут функционировать как поддомены. Таким образом, это весьма схожий подход к проектированию систем, и он прекрасно совместим с такими вещами, как DDD, BDD и т.д.Шаг 2: Разделение и рефакторингИтак, мы увидели, как можно все разделить, но как теперь отделить сервисы от всего остального и рефакторить их, чтобы они стали набором микросервисов?Первое, что нужно знать: чем меньше коммуникаций, тем лучше отношения. Очень легко и заманчиво создать множество сервисов, которые удобно тестировать по отдельности, но в целом ваша система станет сложной и запутанной. Это затрудняет отслеживание в случае появления проблемы, поскольку возникает огромная путаница, и может быть трудно определить, где кроется корень проблемы.Еще одним важным моментом является внесение событий в очередь. Нам много раз говорили, что мы не можем разбить их на отдельные службы, потому что это идеально синхронизировано для событий, которые происходят на следующих этапах. Обычно это не так. Благодаря системам очередей и обмена тематическими сообщениями, которые существуют сегодня, есть множество способов нарушить синхронизацию. Это правда, что вы добавляете дополнительный слой, который может принести некоторые проблемы с задержками, но в конечном итоге возможность нарушить всю синхронность, вероятно, улучшит ваш результат.Шаг 3: API и облакоТеперь, когда мы сделали все нарезки и разделили наш код, куда мы можем поместить все это? В облако!Сегодня у нас есть множество решений, и это лишь малая часть того, что предоставляет нам облако.Если назвать несколько наиболее распространенных, то Google Cloud (GCP), Microsoft Azure и AWS — это три основных претендента, но есть и много других поставщиков. Эти решения обычно предоставляют готовую архитектуру микросервисов, где вам нужно только сделать несколько штрихов и провести небольшое обучение, чтобы все заработало.Кроме того, есть решения, которые необходимы на месте, потому что вы не хотите размещать свои сервисы в облаке. Например, применив сервисы Spring Cloud, можно использовать свои собственные серверы и идеально имитировать структуры публичного облака.Сколько может стоить миграция на микросервисы с использованием облачных решений?Очень легко продолжать создавать микросервисы в облаке, но если у вас нет четкого плана, то возможно потерять контроль над бюджетом проекта. Если вы хотите получить оценку того, сколько вы можете потратить на облачные услуги, то для этого есть несколько способов.Используя калькуляторы, предоставляемые большинством облачных сервисов, которые очень подробны, вы можете получить хорошую оценку, но для этого вам нужно иметь очень четкое представление о том, какова ваша клиентская база, объем транзакций, объем данных, кода и т.д. Если у вас есть все эти параметры, то можно достоверно оценить какими будут ваши затраты в облаке. К сожалению, этот способ расчета не подходит к локальным провайдерам, таким как Spring Cloud services, которые несут различные расходы, связанные с наличием локального сервера.Распространенные стратегии миграцииДавайте рассмотрим наиболее типичные стратегии миграции, существующие на сегодняшний день, которые помогут вам получить более четкое представление о пути, по которому вы, возможно, захотите пойти.Шаблон StranglerОдним из способов миграции может быть использование паттерна strangler — в случае, если ваше приложение очень большое. Таким образом, вы сможете выделить наиболее важные сервисы в архитектуру микросервисов.В приведенном ниже случае было решено извлечь всю клиентскую часть приложения в архитектуру микросервисов и оставить административную часть в монолите, что вполне нормально. Здесь значительно расширили свой код и смогли сделать это, не останавливая разработку. Но это не должно быть окончательным состоянием приложения. В идеале все должно оказаться в правой части изображения. Как вы можете видеть, там есть DBF, то есть DB (база данных) для каждой службы. Это не обязательное требование, но оно помогает.Параллельная разработкаДругой способ выполнить миграцию — использовать подход параллельной разработки. Это больше подходит для небольших проектов или проектов, которые не очень продвинуты в разработке. Таким образом, вы можете параллельно разрабатывать как монолитную архитектуру, так и архитектуру микросервисов.Основной подводный камень этого подхода заключается в том, что он обычно удваивает объем технического обслуживания и дублирования кода, но в конечном итоге все будет в правой части экрана, и если вы хотите сократить риски, этот метод может сильно помочь.ЗаключениеКогда мы находимся в процессе миграции, важно не забегать вперед и пытаться вносить изменения параллельно или проектировать их заранее.Представьте, что вы работаете над параллельной миграцией и решили выполнять миграцию параллельно с разработкой; если появится новая функциональность или возможность, вам придется дублировать этот код и выполнять работу дважды. Если вы попытаетесь спланировать миграцию заранее, одновременно внося изменения в ваше основное приложение, вам будет трудно избежать осложнений.

Перевод статьи подготовлен в рамках курса "Microservice Architecture". Если вам интересно узнать о курсе подробнее, приходите на день открытых дверей онлайн, где преподаватель расскажет о формате и программе обучения.

===========
Источник:
habr.com
===========
===========
Автор оригинала: Adnan Tuccar
===========Похожие новости:

Теги для поиска: #_mikroservisy (Микросервисы), #_arhitektura_po (архитектура по), #_mikroservisy (микросервисы), #_monolit (монолит), #_modulnaja_sistema (модульная система), #_blog_kompanii_otus (
Блог компании OTUS
), #_mikroservisy (
Микросервисы
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 05:22
Часовой пояс: UTC + 5