Архитектура микрослужб .NET: главные выводы

Ниже приводится обзор и главные выводы этого руководства.

Преимущества использования контейнеров. Решения на основе контейнеров предоставляют важные преимущества с точки зрения сокращения расходов, так как позволяют устранять проблемы, вызванные отсутствием зависимостей в рабочей среде. Контейнеры значительно повышают эффективность DevOps и производственных операций.

Контейнеры будут распространены повсеместно. Контейнеры на базе Docker становятся фактическим стандартом в этой области и поддерживаются большинством поставщиков в экосистеме Windows и Linux, такими как Майкрософт, Amazon AWS, Google и IBM. Очень скоро Docker, вероятно, будет широко использоваться как в облачных, так и локальных центрах обработки данных.

Контейнеры как единица развертывания. Контейнер Docker превращается в стандартную единицу развертывания любого серверного приложения или службы.

Микрослужбы. Использование архитектуры микрослужб становится предпочтительным подходом для распределенных и крупных или сложных критически важных приложений, основанных на множестве независимых подсистем в виде автономных служб. Этот подход предполагает создание приложения на базе коллекции служб, которые разрабатываются, тестируются, поддерживают управление версиями, развертываются и обновляются независимо друг от друга. В каждой службе может использоваться несколько связанных автономных баз данных.

Проблемно-ориентированное проектирование и сервисноориентированная архитектура. Шаблоны архитектуры микрослужб созданы сервисноориентированной архитектурой (SOA) и проблемно-ориентированным проектированием (DDD). Когда вы проектируете и разрабатываете микрослужбы для сред с растущими бизнес-потребностями и правилами, важно учитывать подходы и шаблоны проблемно-ориентированного проектирования.

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

Контейнеры для любого приложения. Контейнеры Windows удобно использовать не только для микрослужб, но и для монолитных приложений на основе традиционной платформы .NET Framework. Использование Docker предоставляет преимущества для приложений самых разных типов, например, позволяя решать проблемы при переходе от развертывания в производство и обеспечивая современные среды разработки и тестирования.

Интерфейс командной строки и интегрированная среда разработки. С помощью инструментов Майкрософт вы можете разрабатывать приложения .NET в контейнерах, используя выбранный вами подход. Вы можете разрабатывать приложения с помощью интерфейса командной строки и среды на базе редактора, используя Docker CLI и Visual Studio Code. Или вы можете использовать интегрированную среду разработки с Visual Studio, которая включает специальные возможности для работы с Docker, включая отладку приложений с несколькими контейнерами.

Устойчивые облачные приложения. Как правило, в облачных и распределенных системах всегда существует риск частичного сбоя. Поскольку клиенты и службы являются отдельными процессами (контейнерами), служба может не ответить вовремя на запрос клиента. Например, служба может не работать в связи с обслуживанием ли частичным сбоем. Служба может быть перегружена, медленно отвечать на запросы или быть недоступна некоторое время из-за проблем в сети. При разработке облачных приложений необходимо учитывать возможность подобных сбоев и реализовывать стратегии реагирования на них. Эти стратегии могут включать политики повтора (повторная отправка сообщений или запросов) и реализацию шаблонов размыкателя цепи, чтобы избежать возрастания нагрузки при повторяющихся запросах. По сути, облачные приложения должны обладать механизмами устойчивости на основе облачной инфраструктуры или пользовательских решений, включая высокоуровневые платформы, предоставляемые оркестраторами или служебными шинами.

Безопасность. Современный мир контейнеров и микрослужб может иметь новые уязвимости. Базовая безопасность приложения обеспечивается несколькими способами на основе проверки подлинности и авторизации. Но система безопасности контейнеров должна учитывать дополнительные ключевые компоненты, которые повышают безопасность приложений. Важнейший элемент при создании более безопасных приложений — это защищенный способ связи с другими приложениями и системами на основе учетных данных, токенов и паролей — то, что обычно называется секретами приложения. Для любого защищенного решения нужно учитывать рекомендации по обеспечению безопасности, включая шифрование секретов при передаче и хранении, а также предотвращение утечки секретов при использовании в конечном приложении. Эти секреты нужно хранить в безопасном расположении, например в Azure Key Vault.

Оркестраторы. Оркестраторы на основе контейнеров, такие как Службы Azure Kubernetes и Azure Service Fabric, являются основной частью важных микрослужб и приложений на основе контейнеров. Это сложные приложения, которые нужно масштабировать и которые постоянно изменяются. В этом руководстве описаны оркестраторы и их значение для решений на базе микрослужб и контейнеров. Если вы раздумываете над переходом к сложным контейнерным приложениям, рекомендуем ознакомиться с дополнительными ресурсами, чтобы больше узнать об оркестраторах.