Создание микросервисной архитектуры с помощью ASP.NET Core
28 ноября 2022 г.Разговор об архитектуре программного обеспечения обычно сосредоточен на монолитных и микросервисах. п
В прошлом монолитная архитектура использовалась для создания полностью автономной программы, на которую не влияли другие программы. Микросервисная архитектура, по сути, является противоположностью монолита, поскольку она опирается на последовательность различных сервисов, которые можно развернуть в любое время. Пока проект только начинается, управление кодом, когнитивные накладные расходы и развертывание — все это преимущества монолитных систем. Масштабируемость, непрерывное развертывание и обновления могут стать проблемой, когда монолитное приложение становится слишком большим. п
Вместо того, чтобы создавать единое неделимое приложение, микросервисы делят работу на более мелкие и более управляемые фрагменты. Каждая из этих меньших частей вносит свой вклад в общее дело. Децентрализованные и автономно создаваемые сервисы являются строительными блоками приложения. п
Для многих разработчиков хорошим практическим правилом является то, что микросервисы — это естественный переход, когда монолиты становятся слишком большими или сложными. Для крупных потребительских приложений организации все чаще обращаются к микросервисам, а не к монолитной архитектуре, чтобы удовлетворить потребности пользователей, повысить масштабируемость и обеспечить доступность для клиентов. п
В этом блоге основное внимание будет уделено архитектуре микросервисов и тому, как построить эту архитектуру с помощью ASP.NET Core, бесплатной веб-платформы с открытым исходным кодом от Microsoft для веб-приложений. п
Начнем!
Что такое микросервисная архитектура? п
В разработке программного обеспечения есть принцип, который имеет большее значение, когда речь идет о микросервисах, и это принцип KISS, который по сути означает "Не усложняй, глупец". При разработке программного обеспечения принцип KISS в основном относится к тому факту, что программное обеспечение должно быть простым для понимания и использования разработчиками и конечными пользователями. п
Именно здесь в игру вступают микросервисы, но что такое микросервисная архитектура? В архитектуре микрослужб приложения разделены на независимо развертываемые службы, которые взаимодействуют друг с другом через API. Отдельный сервис можно развертывать и масштабировать отдельно, а не как часть всей системы.
Микросервисы предпочитают большие и сложные программы для быстрой и частой доставки. Новые функции и обновления можно добавлять и внедрять быстрее, используя архитектуру микросервисов, а не переписывая значительный объем существующего кода. п
Каждая основная функция или услуга пишется и предоставляется независимо в архитектуре микросервисов при разработке приложений. Микросервисная архитектура означает, что если один компонент выйдет из строя, приложение не пострадает. Контракты API гарантируют, что независимые участники могут общаться друг с другом. Микросервисы позволяют реагировать на постоянно меняющиеся требования бизнеса и быстрее выводить на рынок новые функции.
Преимущества микросервисной архитектуры
Сервисы с различными компонентами n
Отдельные, слабо связанные сервисы-компоненты можно писать, развертывать, использовать, модифицировать и повторно развертывать, не влияя на целостность других сервисов или функциональность приложения с микросервисами. С помощью этого метода можно быстро и легко развернуть функциональные возможности приложения.
Высоко тестируемый и удобный
В случае с микросервисами команды могут экспериментировать с новыми функциями и быстро откатывать их, если они не работают. Благодаря этой функции новые элементы могут быть введены быстрее, что упрощает обновление кода. Это также упрощает поиск и устранение проблем с определенными службами.
Модульный, совместимый и гибкий
Поскольку каждый сервис в программном приложении может быть разобран и реконфигурирован независимо, модульность упрощает понимание, при необходимости изолирует недостатки и тестирует. В дополнение к повышению эффективности и снижению затрат тот факт, что микросервисы можно повторно использовать, теперь является важным аспектом для разработчиков при реализации архитектуры.
Повышение производительности n
Хорошо, значит, микросервисы позволяют разбивать приложения на более мелкие автономные фрагменты, упрощая создание и обслуживание, верно? Ну, из-за самой своей природы каждый сервис может быть создан отдельно, развернут и управляться с использованием различных языков программирования, технологий и программных сред. Модульные компоненты минимизируют размер общей кодовой базы приложения, упрощая выпуск и тестирование новых сервисов, а также позволяя командам разработчиков разделять и распределять связанные задачи. Все это приводит к повышению уровня производительности.
Выделение ошибок n
До тех пор, пока все вышестоящие микрослужбы структурированы для надлежащей обработки ошибок, недоступность отдельной микрослужбы не повлияет на всю программу (например, за счет реализации прерывания цепи).
Небольшие команды владеют микросервисами n
Технологии Agile и DevOps поощряются микросервисами, которые часто создаются небольшими автономными командами. Циклы разработки сокращаются, поскольку командам предлагается работать автономно и быстро.
Микросервисы помогают повысить отказоустойчивость приложений
Вы можете быстро выявлять и решать проблемы с производительностью при использовании архитектуры на основе микрослужб. Более крупные приложения не подвержены влиянию одиночного сбоя благодаря усиленному разделению сбоев, обеспечиваемому отдельными модулями. Вы можете отменить обновления и изменения без повторного развертывания всего приложения, что сводит к минимуму риск простоя.
Микросервисы основаны на возможностях компании
Вы можете организовать услуги в соответствии с потребностями компании в архитектуре микросервисов. Для выполнения конкретной задачи команды должны быть многофункциональными и состоять из участников, обладающих всеми необходимыми знаниями.
Увеличить или уменьшить масштаб по мере необходимости n
Учитывая тот факт, что команды DevOps могут использовать разные стек технологий для каждого модуля, поскольку каждая служба написана на определенном языке или технологии, также можно добавлять новые компоненты в систему без необходимости останавливать и повторно развертывать всю систему. . Влияние более ресурсоемких функций на производительность можно свести к минимуму, развернув службы на нескольких серверах.
Полностью автоматизированная инфраструктура
Подходы к автоматизации инфраструктуры, такие как непрерывная интеграция (CI), непрерывная поставка (CD) и развертывание (также CD), обычно используются группами разработки и обслуживания микросервисов. В результате каждую службу можно разрабатывать и развертывать независимо, не затрагивая другие группы.
Короче говоря, некоторые из основных преимуществ архитектуры микросервисов включают: n
- Приложения состоят из множества независимых компонентов, которые работают вместе как единое целое.
- Функции одного компонента можно легко разработать и понять.
- Микросервисы можно быстро и легко тестировать.
- Компоненты как по отдельности, так и в целом просты в обслуживании.
- Каждой микрослужбой можно управлять как отдельным проектом.
- Модульность системы низкого и среднего размера позволяет разбить систему на более мелкие и более управляемые части.
Как создавать микросервисы в .NET
Начало с монолитной архитектуры – это первый шаг для многих компаний, за которым следует, среди прочего, внедрение шаблонов для устранения сбоев и восстановления после проблем с сетью, управление согласованностью данных и мониторинг спроса на услуги. Это техническая сторона дела, поскольку культура DevOps и реорганизация ваших команд также необходимы. п
Пришло время разбить монолит на микросервисы, что является самым сложным шагом. Рефакторинг схемы монолитной базы данных может быть деликатным. Критически важно определить, какие наборы данных нужны каждой службе, а также любые совпадения. Сбои при выпуске менее вероятны при непрерывной доставке, и ваша команда может свободно работать над созданием и выполнением продукта, а не распространять его. п
Далее мы рассмотрим, как можно создавать микросервисы с помощью .NET.
ASP.NET Core n
Вы можете создать веб-приложение с помощью микросервиса .NET Core благодаря его производительности, многоплатформенной совместимости и лицензии с открытым исходным кодом. п
ASP.NET Core позволяет: n
- Разрабатывайте приложения для Интернета и Интернета вещей, а также мобильные серверные части.
- В Windows, macOS или Linux вы можете использовать инструменты разработки, к которым вы привыкли в предпочитаемой вами операционной системе.
- Развертывание локально или в облаке.
- Поддерживается .NET Core.
Шаблоны проектирования микросервисов .NET n
Вот шаблоны проектирования микросервисов: n
Агрегатор
В компьютерной индустрии агрегатор — это веб-сайт или приложение, которое собирает и представляет связанные фрагменты данных. По этой причине веб-страница агрегатора вызывает другие службы для сбора информации или выполнения желаемой работы даже в рамках микрослужб. п
Совокупный шаблон проектирования следует принципу DRY. Основываясь на этой идее, вы можете абстрагировать логику в составные микрослужбы и объединить эту конкретную бизнес-логику в единую службу. п
Шлюз API
Микросервисы разработаны таким образом, что у каждого сервиса есть свои возможности. Однако разработчик может столкнуться с рядом проблем, когда приложение разделено на небольшие автономные сервисы. Используя шаблон микрослужбы разработки шлюза API, шлюзы API могут преобразовывать запросы протокола из одного типа в другой. Точно так же он может снять с микрослужбы обязанности по проверке подлинности/авторизации.
Связь или цепочка ответственности
Цепочки или шаблоны проектирования цепочки ответственности генерируют один выход из нескольких связанных выходов. п
Асинхронный обмен сообщениями
В соответствии с шаблоном архитектуры микрослужб асинхронного обмена сообщениями все службы могут взаимодействовать друг с другом, но они не обязаны делать это последовательно. п
База данных или общие данные
С каждым приложением связано огромное количество данных. Когда вы перемещаете приложение в архитектуру микрослужб, вы должны убедиться, что каждая микрослужба имеет правильные данные для обработки запросов. Вы можете решить несколько проблем, используя базу данных для каждой службы и общую базу данных для каждой службы. п
**Источники событий
Шаблон проектирования источника событий генерирует события, связанные с изменением состояния приложения. Кроме того, эти события хранятся в виде серии событий, чтобы разработчики могли отслеживать, когда они вносили изменения. п
Филиал
Шаблон проектирования филиала микросервиса — это шаблон проектирования, который позволяет обрабатывать запросы и ответы от двух или более независимых микросервисов одновременно.
Сегрегатор ответственности командных запросов
Каждый дизайн микрослужб использует либо отдельную базу данных для каждой службы, либо общую базу данных. Мы не можем реализовать запрос в базе данных для каждой парадигмы службы, поскольку доступ к данным ограничен одной базой данных. В этой ситуации вы можете использовать сегрегатор ответственности запросов команд (CQRS). Этот шаблон делит программу на команду и запрос. Раздел запросов обрабатывает материализованные представления, а раздел команд обрабатывает запросы CREATE, UPDATE и DELETE. Материализованные представления обновляются с использованием описанного выше шаблона источника событий. п
**Автоматический выключатель
Шаблон проектирования микросервисов Circuit Breaker может остановить процесс запроса и ответа в случае сбоя службы.
**Разложение
Микрослужбы создаются с целью создания небольших служб, каждая из которых имеет свои собственные функции. Но процесс разделения приложения на маленькие автономные компоненты должен быть рациональным. Таким образом, вы можете использовать шаблон декомпозиции, чтобы разбить маленькое или большое приложение на более мелкие службы. Используя этот шаблон, вы можете разложить приложение в зависимости от его бизнес-возможностей или поддоменов. п
Тестирование микросервисов с помощью .NET n
Контроллеры являются важными компонентами каждой службы ASP.NET Core API и веб-приложения ASP.NET MVC. В результате вы должны быть уверены в их пригодности для вашего приложения. Автоматизированное тестирование может обеспечить эту уверенность, выявляя ошибки до того, как они попадут в производство. п
Вы должны проверить, как контроллер реагирует на правильные и неправильные входные данные, а также на результат бизнес-операции, которую выполняет контроллер. Было бы полезно, если бы у вас были следующие типы тестирования для ваших микросервисов: n
Модульное тестирование. Эти тесты подтверждают, что отдельные компоненты приложения работают должным образом. Утверждения оценивают API компонента.
Интеграционное тестирование. Эти тесты гарантируют, что взаимодействие компонентов с внешними объектами, такими как базы данных, работает должным образом. Утверждения можно использовать для тестирования API, пользовательского интерфейса или побочных эффектов таких действий, как ввод-вывод базы данных, ведение журнала и т. д. n
Функциональное тестирование. Каждый микросервис должен пройти доступные тесты. Эти тесты гарантируют, что приложение работает так, как ожидает пользователь.
Сервисное тестирование. Эти тесты обеспечивают проверку сквозных сценариев использования службы, включая одновременное тестирование нескольких служб. Для этой формы тестирования необходимо заранее подготовить настройки. В данном случае это относится к запуску сервисов (например, с помощью docker-compose up)
Запуск приложений микросервисов в Microsoft Azure
Для разработчиков программного обеспечения нет ничего нового в том, чтобы разбивать приложение на составные элементы. Как правило, многоуровневая архитектура состоит из внутреннего хранилища, бизнес-логики среднего уровня и внешнего пользовательского интерфейса (UI). Что изменилось за последние несколько лет, так это то, что разработчики теперь создают облачные распределенные приложения. п
В этом контексте подход к проектированию на основе микросервисов подходит не для всех проектов, но он более точно соответствует бизнес-целям, изложенным ранее. Начать с монолитной системы может иметь смысл, если в будущем вы планируете реорганизовать код в архитектуру микросервисов. Как правило, вы начинаете с монолитной программы и постепенно разбиваете ее на этапы, начиная с функциональных областей, которые должны стать более масштабируемыми или гибкими.
При использовании стратегии микрослужб ваше приложение состоит из множества небольших служб. Эти услуги предоставляются через кластер серверов в контейнерах. Небольшие команды создают сервис, ориентированный на сценарии, и независимо тестируют, верифицируют, развертывают и масштабируют его, чтобы приложение в целом могло адаптироваться.
Microsoft создала Azure Service Fabric, когда переключилась с поставки традиционно монолитных коробочных продуктов на предоставление услуг. В основе Service Fabric лежит опыт разработки и обслуживания крупных сервисов, таких как База данных SQL Azure и Azure Cosmos DB.
Цель Service Fabric — решить сложные проблемы проектирования и эксплуатации службы, а также оптимизировать использование ресурсов инфраструктуры, чтобы команды могли применять подход микрослужб для решения бизнес-задач. Короче говоря, Service Fabric упрощает разработку приложений на основе микрослужб, предлагая следующее:
Платформа, предлагающая системные службы для развертывания, обновления, обнаружения и перезапуска неисправных служб, обнаружения преимуществ, маршрутизации связи, управления состоянием и мониторинга работоспособности.
Возможность развертывания приложений, работающих либо в контейнерах, либо в виде процессов. Service Fabric — это оркестратор и контейнер.
ASP.NET Core, Reliable Actors и Reliable Services — это продуктивные API-интерфейсы программирования для создания приложений на основе микрослужб. Например, вы можете получить информацию о работоспособности и диагностике или использовать встроенную функцию высокой доступности.
Service Fabric не зависит от технологий в отношении того, как устроена служба и какие технологии вы можете использовать. Однако он предоставляет API-интерфейсы для программирования, упрощающие разработку микросервисов. п
Service Fabric помогает повторно использовать и обновлять существующий код с помощью микрослужб. Модернизация приложения состоит из пяти этапов, и вы можете начать и закончить на любом уровне.
Уровни:
- Начните со стандартной архитектуры с одним приложением.
- Миграция. В Service Fabric используйте контейнеры или гостевые исполняемые файлы для размещения существующих программ.
- Модернизация: добавьте новые контейнерные микросервисы в существующий контейнерный код.
- Инновации. В зависимости от требований разделите монолитное приложение на микрослужбы.
- Преобразование. Вы можете преобразовать приложения в микросервисы. Преобразуйте существующие монолитные системы или создайте новые приложения с нуля.
Помните, что вы можете начинать и останавливаться на любом из этих этапов; они не зависят друг от друга при переходе к следующему шагу.
Заключение
Цель микросервисов — уменьшить сложность и зависимость, чтобы избежать дорогостоящих изменений дизайна. Начните с малого, масштабируйте по мере необходимости, отказывайтесь от того, что вам больше не нужно, создавайте новые микросервисы или развивайтесь вместе с вашим клиентом. Поскольку микросервисы становятся все более доступными для разработчиков, приложения становятся очагами инноваций и новых подходов.
Оригинал