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