Ниже приводится обзор и главные выводы этого руководства.
Преимущества использования контейнеров. Решения на основе контейнеров предоставляют важные преимущества с точки зрения сокращения расходов, так как позволяют устранять проблемы, вызванные отсутствием зависимостей в рабочей среде. Контейнеры значительно повышают эффективность 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, являются основной частью важных микрослужб и приложений на основе контейнеров. Это сложные приложения, которые нужно масштабировать и которые постоянно изменяются. В этом руководстве описаны оркестраторы и их значение для решений на базе микрослужб и контейнеров. Если вы раздумываете над переходом к сложным контейнерным приложениям, рекомендуем ознакомиться с дополнительными ресурсами, чтобы больше узнать об оркестраторах.
