Контейнерные микрослужбыContainerized Microservices

Разработка приложений клиент сервер помог сосредоточиться на создании многоуровневых приложений, использования определенных технологий на каждом уровне.Developing client-server applications has resulted in a focus on building tiered applications that use specific technologies in each tier. Такие приложения часто называются монолитных приложений того они упаковываются на оборудовании, предварительно масштабируется для пиковых нагрузок.Such applications are often referred to as monolithic applications, and are packaged onto hardware pre-scaled for peak loads. Основные недостатки этого подхода разработки являются тесную связь между компонентами в пределах каждого уровня, что нельзя легко масштабировать отдельные компоненты и затраты на проверку.The main drawbacks of this development approach are the tight coupling between components within each tier, that individual components can't be easily scaled, and the cost of testing. Простое обновление может иметь непредвиденные последствия на остальных уровня, и поэтому изменение компонент приложения требует его весь уровень повторного тестирования и повторного развертывания.A simple update can have unforeseen effects on the rest of the tier, and so a change to an application component requires its entire tier to be retested and redeployed.

Особенно обсуждение в эпоху облака, что отдельные компоненты не может быть легко масштабируется.Particularly concerning in the age of the cloud, is that individual components can't be easily scaled. Монолитное приложение содержит функциональные возможности доменного и обычно делится на функциональные уровни, такие как внешний интерфейс, бизнес-логики и хранилища данных.A monolithic application contains domain-specific functionality, and is typically divided by functional layers such as front end, business logic, and data storage. Монолитное приложение масштабируется путем клонирования всего приложения на нескольких компьютерах, как показано на рисунке 8-1.A monolithic application is scaled by cloning the entire application onto multiple machines, as illustrated in Figure 8-1.

Рис. 8-1: Масштабный подход монолитного приложенияFigure 8-1: Monolithic application scaling approach

МикрослужбыMicroservices

Микрослужбы предлагают другой подход для разработки и развертывания приложений, подход, который подходит для гибкости, масштабирования и требования к надежности работы современных облачных приложений.Microservices offer a different approach to application development and deployment, an approach that's suited to the agility, scale, and reliability requirements of modern cloud applications. Приложение для микрослужб разлагаются на независимые компоненты, которые вместе работают над достижением общей функциональности приложения.A microservices application is decomposed into independent components that work together to deliver the application's overall functionality. Особое внимание уделяется микрослужбы термин, что должно составлять приложения из службы достаточно небольшим, чтобы отразить независимых проблем, чтобы каждая микрослужба реализует одной функции.The term microservice emphasizes that applications should be composed of services small enough to reflect independent concerns, so that each microservice implements a single function. Кроме того каждая микрослужба имеет четко определенные контракты, чтобы другие микрослужбы могут взаимодействовать и обмениваться данными с ним.In addition, each microservice has well-defined contracts so that other microservices can communicate and share data with it. Типичные примеры микрослужб включают корзин, складских запасах обработки, подсистемами и обработка платежей.Typical examples of microservices include shopping carts, inventory processing, purchase subsystems, and payment processing.

Микрослужбы можно горизонтально масштабировать независимо друг от друга, по сравнению с огромным монолитных приложений, которые масштабируются вместе.Microservices can scale-out independently, as compared to giant monolithic applications that scale together. Это означает, что можно масштабировать конкретной функциональной области, требующий обработки питание или сетевое пропускная способность для поддержки запросу, вместо того чтобы излишне масштабирование других областей приложения.This means that a specific functional area, that requires more processing power or network bandwidth to support demand, can be scaled rather than unnecessarily scaling-out other areas of the application. Рис. 8-2 показан этот подход, где развертываете микрослужбы и масштабировать независимо друг от друга, создавая экземпляры служб между компьютерами.Figure 8-2 illustrates this approach, where microservices are deployed and scaled independently, creating instances of services across machines.

Рис. 8-2: Масштабирование приложения микрослужбFigure 8-2: Microservices application scaling approach

Горизонтальное масштабирование Микрослужб может быть практически мгновенно, что позволяет приложению адаптироваться к изменению загрузок.Microservice scale-out can be nearly instantaneous, allowing an application to adapt to changing loads. Например одна микрослужба в функциональные возможности веб-приложения может быть только микрослужбы в приложении, которое необходимо горизонтальное масштабирование для обработки дополнительных входящего трафика.For example, a single microservice in the web-facing functionality of an application might be the only microservice in the application that needs to scale out to handle additional incoming traffic.

Классическую модель для обеспечения масштабируемости приложения является уровня с балансировкой нагрузки, без отслеживания состояния с общий внешнее хранилище данных для хранения постоянных данных.The classic model for application scalability is to have a load-balanced, stateless tier with a shared external datastore to store persistent data. Микрослужбы с отслеживанием состояния управлять собственные постоянных данных, обычно запоминался локально на серверах, на которых они размещены, чтобы избежать затрат на сетевой доступ и сложности между службами операций.Stateful microservices manage their own persistent data, usually storing it locally on the servers on which they are placed, to avoid the overhead of network access and complexity of cross-service operations. Это обеспечивает быструю обработку возможных данных и позволяет избавиться от необходимости для систем.This enables the fastest possible processing of data and can eliminate the need for caching systems. Кроме того масштабируемых микрослужб с отслеживанием состояния обычно секционирования данных между экземплярами их для управления размером и передачи пропускная способность выходе за которые может поддерживать один сервер.In addition, scalable stateful microservices usually partition data among their instances, to manage data size and transfer throughput beyond which a single server can support.

Микрослужбы также поддерживать независимые обновления.Microservices also support independent updates. Слабая связь между микрослужбами обеспечивает развитие быстрое и надежное приложение.This loose coupling between microservices provides a rapid and reliable application evolution. Своей природе независимые, распределенная поддерживает последовательные обновления, когда будет обновлять только подмножество экземпляров одной микрослужбы в любой момент времени.Their independent, distributed nature supports rolling updates, where only a subset of instances of a single microservice will update at any given time. Таким образом Если обнаруживается проблема, ошибками обновления можно откатить назад, прежде чем обновить все экземпляры с ошибочного кода или конфигурации.Therefore, if a problem is detected, a buggy update can be rolled back, before all instances update with the faulty code or configuration. Аналогичным образом микрослужб обычно используют управление версиями схемы, таким образом, клиенты могут видеть согласованность версий при обновления, независимо от того, какие микрослужба передаваемых экземпляра с.Similarly, microservices typically use schema versioning, so that clients see a consistent version when updates are being applied, regardless of which microservice instance is being communicated with.

Таким образом микрослужба приложения имеют множество преимуществ над монолитных приложений:Therefore, microservice applications have many benefits over monolithic applications:

  • Каждая микрослужба относительно небольшой, легко управлять и развивать.Each microservice is relatively small, easy to manage and evolve.
  • Каждая микрослужба разработки и развертывать независимо от других служб.Each microservice can be developed and deployed independently of other services.
  • Каждая микрослужба может быть масштабирован независимо друг от друга.Each microservice can be scaled-out independently. Например службы каталога или службе корзины для покупок может потребоваться больше, чем служба заказов быть горизонтальным масштабированием.For example, a catalog service or shopping basket service might need to be scaled-out more than an ordering service. Таким образом полученный инфраструктуры более эффективно будет потреблять ресурсы при масштабировании.Therefore, the resulting infrastructure will more efficiently consume resources when scaling out.
  • Каждая микрослужба изолирует все проблемы.Each microservice isolates any issues. Например если имеется проблема в службе он влияет только на эту службу.For example, if there is an issue in a service it only impacts that service. Другие службы могут продолжать обрабатывать запросы.The other services can continue to handle requests.
  • Каждая микрослужба может использовать новейшие технологии.Each microservice can use the latest technologies. Так как микрослужбы являются автономными и выполнения side-by-side, последних технологий и платформ можно использовать, вместо того чтобы использовать на старой платформе, которые могут быть использованы монолитного приложения.Because microservices are autonomous and run side-by-side, the latest technologies and frameworks can be used, rather than being forced to use an older framework that might be used by a monolithic application.

Тем не менее решение на основе микрослужб также имеет потенциальные недостатки:However, a microservice based solution also has potential drawbacks:

  • Выбрать способ разделения приложения на микрослужбы может оказаться сложной задачей, так как каждая микрослужба должна быть полностью автономными, end-to-end, включая ответственность за его источники данных.Choosing how to partition an application into microservices can be challenging, as each microservice has to be completely autonomous, end-to-end, including responsibility for its data sources.
  • Разработчики должны реализовать взаимодействие между службами, который добавляет сложности и задержки в приложения.Developers must implement inter-service communication, which adds complexity and latency to the application.
  • Атомарные транзакции между несколькими микрослужбами обычно невозможны.Atomic transactions between multiple microservices usually aren't possible. Таким образом бизнес-требования должны учитывать итоговую согласованность между микрослужбами.Therefore, business requirements must embrace eventual consistency between microservices.
  • В рабочей среде нет сложности при развертывании и управлении системы включает в себя множество независимых служб.In production, there is an operational complexity in deploying and managing a system compromised of many independent services.
  • Прямое взаимодействие клиента с микрослужбой будет трудно рефакторинга контрактов микрослужб.Direct client-to-microservice communication can make it difficult to refactor the contracts of microservices. Например со временем как разделения системы в службы может потребоваться изменить.For example, over time how the system is partitioned into services might need to change. Одна служба может разбивается на два или несколько служб, а может объединить две службы.A single service might split into two or more services, and two services might merge. Когда клиенты взаимодействуют непосредственно с микрослужбами, эта работа рефакторинга может нарушить совместимость с клиентскими приложениями.When clients communicate directly with microservices, this refactoring work can break compatibility with client apps.

КонтейнеризацияContainerization

Контейнеризация — это подход к разработке программного обеспечения, в котором приложение и его версий набором зависимостей, а также его конфигурации среды, которые абстрагированы как файлы манифеста развертывания, упаковываются вместе в образ контейнера, как единое целое, и развернуть операционную систему узлов.Containerization is an approach to software development in which an application and its versioned set of dependencies, plus its environment configuration abstracted as deployment manifest files, are packaged together as a container image, tested as a unit, and deployed to a host operating system.

Контейнер — изолированной, ресурсов управляемой и переносимой среде, где приложение может работать, не изменяя при этом ресурсы другими контейнерами или узлом.A container is an isolated, resource controlled, and portable operating environment, where an application can run without touching the resources of other containers, or the host. Таким образом контейнер выглядит и работает как недавно установленные физический компьютер или виртуальную машину.Therefore, a container looks and acts like a newly installed physical computer or a virtual machine.

Есть много общего между контейнерами и виртуальные машины, как показано на рисунке 8-3.There are many similarities between containers and virtual machines, as illustrated in Figure 8-3.

Рис. 8-3: Сравнение виртуальных машин и контейнеровFigure 8-3: Comparison of virtual machines and containers

Контейнер с операционной системой, содержит файловую систему и может осуществляться по сети, как если бы он был физической или виртуальной машины.A container runs an operating system, has a file system, and can be accessed over a network as if it were a physical or virtual machine. Тем не менее технологии и основные понятия, используемые контейнерами очень отличаются от виртуальных машин.However, the technology and concepts used by containers are very different from virtual machines. Виртуальные машины оснащены приложения, необходимые зависимости, а также всю операционную систему.Virtual machines include the applications, the required dependencies, and a full guest operating system. Контейнеры включают в себя приложение и его зависимости, но совместно использовать операционную систему с другими контейнерами, как изолированные процессы в операционной системе узла (помимо контейнеры Hyper-V, которые выполняются в специальной виртуальной машине каждого контейнера).Containers include the application and its dependencies, but share the operating system with other containers, running as isolated processes on the host operating system (aside from Hyper-V containers which run inside of a special virtual machine per container). Таким образом контейнеры совместно используют ресурсы и обычно требуют меньше ресурсов, чем виртуальные машины.Therefore, containers share resources and typically require fewer resources than virtual machines.

Контейнер ориентированного подхода разработки и развертывания удобен тем, что оно устраняет большинство проблем, которые возникают из-за настроек несогласованные среды и проблем, которые поставляются с ними.The advantage of a container-oriented development and deployment approach is that it eliminates most of the issues that arise from inconsistent environment setups and the problems that come with them. Кроме того контейнеры позволяют функциональные возможности вертикального масштабирования ускоренного восстановления приложений путем создания экземпляров новых контейнеров при необходимости.In addition, containers permit fast application scale-up functionality by instancing new containers as required.

Ниже приведены основные понятия при создании и работе с контейнерами.The key concepts when creating and working with containers are:

  • Узел контейнера: Физической или виртуальной машине, настроенной для размещения контейнеров.Container Host: The physical or virtual machine configured to host containers. На узле контейнера будет выполняться один или несколько контейнеров.The container host will run one or more containers.
  • Образ контейнера: Изображение состоит из объединения многоуровневой файловые системы, расположены друг над другом и лежит в основе контейнера.Container Image: An image consists of a union of layered filesystems stacked on top of each other, and is the basis of a container. Изображение не имеет состояния, и он никогда не изменяется по мере ее развертывания в разных средах.An image does not have state and it never changes as it's deployed to different environments.
  • Контейнер: Контейнер — это экземпляр среды выполнения изображения.Container: A container is a runtime instance of an image.
  • Образ ОС контейнера: Контейнеры развертываются из образов.Container OS Image: Containers are deployed from images. Образ ОС контейнера — первый уровень в возможного множества слоев образа, составляющих контейнер.The container operating system image is the first layer in potentially many image layers that make up a container. В операционной системе контейнера является неизменяемым и не может быть изменен.A container operating system is immutable, and can't be modified.
  • Репозиторий контейнеров: Каждый раз, когда создается образ контейнера, изображения и его зависимости сохраняются в локальном репозитории.Container Repository: Each time a container image is created, the image and its dependencies are stored in a local repository. Эти образы можно использовать повторно много раз на узле контейнера.These images can be reused many times on the container host. Образы контейнеров также могут храниться в открытом или закрытом реестре, такие как Docker Hub, так что они могут использоваться в различных узлах контейнеров.The container images can also be stored in a public or private registry, such as Docker Hub, so that they can be used across different container hosts.

Предприятия все чаще внедряют контейнеры, при реализации микрослужбы на основе приложений, а Docker стал стандартный контейнер реализацию, которая была принята большинство платформ программного обеспечения и поставщики облачных служб.Enterprises are increasingly adopting containers when implementing microservice based applications, and Docker has become the standard container implementation that has been adopted by most software platforms and cloud vendors.

Для размещения четырех контейнерные микрослужбы серверной части, образце приложения eShopOnContainers используется Docker, как показано на рисунке 8-4.The eShopOnContainers reference application uses Docker to host four containerized back-end microservices, as illustrated in Figure 8-4.

Рис. 8-4: eShopOnContainers ссылаться на внутренние микрослужбы приложенияFigure 8-4: eShopOnContainers reference application back-end microservices

Архитектура служб серверной части в справочное приложение делится на несколько автономных подсистемах в виде совместно работающих микрослужб и контейнеров.The architecture of the back-end services in the reference application is decomposed into multiple autonomous sub-systems in the form of collaborating microservices and containers. Каждая микрослужба предоставляет одну область функций: это служба удостоверений, службы каталога, служба заказов и служба корзины.Each microservice provides a single area of functionality: an identity service, a catalog service, an ordering service, and a basket service.

Каждая микрослужба имеет свою собственную базу данных, позволяя ему быть полностью отделенной от других микрослужб.Each microservice has its own database, allowing it to be fully decoupled from the other microservices. При необходимости согласованность между базами данных разных микрослужб достигается с помощью события уровня приложения.Where necessary, consistency between databases from different microservices is achieved using application-level events. Дополнительные сведения см. в разделе обмен данными между Микрослужбами.For more information, see Communication Between Microservices.

Дополнительные сведения о эталонного приложения, см. в разделе Микрослужбы .NET: архитектура контейнерных приложений .NET.For more information about the reference application, see .NET Microservices: Architecture for Containerized .NET Applications.

Обмен данными между клиентом и МикрослужбCommunication Between Client and Microservices

Мобильное приложение eShopOnContainers взаимодействует с контейнерные микрослужбы серверной части с помощью направить клиента с микрослужбой взаимодействия, как показано на рисунке 8-5.The eShopOnContainers mobile app communicates with the containerized back-end microservices using direct client-to-microservice communication, which is shown in Figure 8-5.

Рис. 8-5: Прямое взаимодействие между клиентом и микрослужбойFigure 8-5: Direct client-to-microservice communication

С прямым взаимодействием клиента с микрослужбой мобильное приложение выполняет запросы к каждой микрослужбе напрямую через общедоступную конечную точку с помощью другого порта TCP каждой микрослужбы.With direct client-to-microservice communication, the mobile app makes requests to each microservice directly through its public endpoint, with a different TCP port per microservice. В рабочей среде конечной точки обычно будут сопоставлены с балансировки нагрузки микрослужб, которая распределяет запросы между доступных экземпляров.In production, the endpoint would typically map to the microservice's load balancer, which distributes requests across the available instances.

Совет

Рассмотрите возможность использования связь шлюза API.Consider using API gateway communication. Прямое взаимодействие клиента с микрослужбой может иметь определенные недостатки, когда создание больших и сложных микрослужб на основе приложения, но это более чем достаточно для небольших приложений.Direct client-to-microservice communication can have drawbacks when building a large and complex microservice based application, but it's more than adequate for a small application. При разработке крупных микрослужбы на основе приложения с десятками микрослужб, рассмотрите возможность использования связь шлюза API.When designing a large microservice based application with tens of microservices, consider using API gateway communication. Дополнительные сведения см. в разделе Микрослужбы .NET: архитектура контейнерных приложений .NET.For more information, see .NET Microservices: Architecture for Containerized .NET Applications.

Взаимодействие между МикрослужбамиCommunication Between Microservices

Приложение для микрослужб на основе является распределенной системой, потенциально работает на нескольких компьютерах.A microservices based application is a distributed system, potentially running on multiple machines. Обычно каждый экземпляр службы — это процесс.Each service instance is typically a process. Таким образом службы должны взаимодействовать, используя протокол межпроцессного взаимодействия, таких как HTTP, TCP, Advanced Message Queuing Protocol (AMQP) или двоичные протоколы, в зависимости от характера каждой службы.Therefore, services must interact using an inter-process communication protocol, such as HTTP, TCP, Advanced Message Queuing Protocol (AMQP), or binary protocols, depending on the nature of each service.

Два обычных подхода к взаимодействие микрослужбы и микрослужбы являются средств связи REST, на основе HTTP, при запросе данных и легкие асинхронные сообщения при обмене данными обновлений в нескольких микрослужбах.The two common approaches for microservice-to-microservice communication are HTTP based REST communication when querying for data, and lightweight asynchronous messaging when communicating updates across multiple microservices.

Асинхронного обмена сообщениями на основе управляемое событиями взаимодействие крайне важен в том случае, если распространение изменений в нескольких микрослужбах.Asynchronous messaging based event-driven communication is critical when propagating changes across multiple microservices. В этом случае микрослужба публикует событие, когда что-либо заметных может произойти, например, при обновлении бизнес-сущность.With this approach, a microservice publishes an event when something notable happens, for example, when it updates a business entity. Другие микрослужбы подписываются на эти события.Other microservices subscribe to these events. Затем когда микрослужба получает событие, он обновляет свой собственный бизнес-сущности, которые в свою очередь может привести к публикации дополнительных событий.Then, when a microservice receives an event, it updates its own business entities, which might in turn lead to more events being published. Это публикация-подписка на функциональные возможности обычно достигается с помощью шины событий.This publish-subscribe functionality is usually achieved with an event bus.

Шина событий позволяет взаимодействие между микрослужбами, не требуя компоненты, которые необходимо явно учитывает друг с другом, как показано на рисунке 8-6 публикации и подписки.An event bus allows publish-subscribe communication between microservices, without requiring the components to be explicitly aware of each other, as shown in Figure 8-6.

Рис. 8-6. Публикации и подписки с помощью шины событийFigure 8-6: Publish-subscribe with an event bus

С точки зрения приложения, шина событий — просто публикация-подписка канала, предоставляемые через интерфейс.From an application perspective, the event bus is simply a publish-subscribe channel exposed via an interface. Тем не менее можно изменять способ реализации шины событий.However, the way the event bus is implemented can vary. Например RabbitMQ, служебная шина Azure или других служебных шин, например NServiceBus, MassTransit использовать реализация шины событий.For example, an event bus implementation could use RabbitMQ, Azure Service Bus, or other service buses such as NServiceBus and MassTransit. Рис. 8-7 показано, как шины событий используется в образце приложения eShopOnContainers.Figure 8-7 shows how an event bus is used in the eShopOnContainers reference application.

Рис. 8-7: Асинхронное взаимодействие, управляемые событиями, в приложении ссылкуFigure 8-7: Asynchronous event-driven communication in the reference application

Шина событий eShopOnContainers, реализованные с помощью RabbitMQ, предоставляет один ко многим асинхронной публикации и подписки функциональные возможности.The eShopOnContainers event bus, implemented using RabbitMQ, provides one-to-many asynchronous publish-subscribe functionality. Это означает, что после публикации события, может существовать несколько подписчиков, прослушивающих того же события.This means that after publishing an event, there can be multiple subscribers listening for the same event. Данная связь показана на рис. 8-9.Figure 8-9 illustrates this relationship.

Рис. 8-9: Один ко многим связиFigure 8-9: One-to-many communication

Этот подход взаимодействия один ко многим использует события для реализации бизнес-транзакций, которые охватывают несколько служб, обеспечивая согласованность между службами.This one-to-many communication approach uses events to implement business transactions that span multiple services, ensuring eventual consistency between the services. Итоговая согласованность транзакций состоит из ряда распределенных действий.An eventual-consistent transaction consists of a series of distributed steps. Таким образом Получив команду UpdateUser, в микрослужбе профиля пользователя обновляет сведения о пользователе в базе данных и публикует событие UserUpdated в шине событий.Therefore, when the user-profile microservice receives the UpdateUser command, it updates the user's details in its database and publishes the UserUpdated event to the event bus. В микрослужбе корзины и микрослужбе оформили подписку для получения этого события и в ответ обновления сведения о своем покупателя в соответствующие базы данных.Both the basket microservice and the ordering microservice have subscribed to receive this event, and in response update their buyer information in their respective databases.

Примечание

Шина событий eShopOnContainers, реализованные с помощью RabbitMQ, предназначен для использования только в качестве подтверждения концепции.The eShopOnContainers event bus, implemented using RabbitMQ, is intended to be used only as a proof of concept. Для производственных систем следует рассматривать реализаций шины альтернативные событий.For production systems, alternative event bus implementations should be considered.

Сведения о реализации шины событий, см. в разделе Микрослужбы .NET: архитектура контейнерных приложений .NET.For information about the event bus implementation, see .NET Microservices: Architecture for Containerized .NET Applications.

СводкаSummary

Микрослужбы открывают подход к разработке приложений и развертывания, в соответствии с требованиями гибкость, масштабируемость и надежность современных облачных приложений.Microservices offer an approach to application development and deployment that's suited to the agility, scale, and reliability requirements of modern cloud applications. Одно из основных преимуществ микрослужб является, что они могут быть масштабируемыми независимо друг от друга, что означает, что определенной функциональной области можно масштабировать, требуются дополнительные обработки или сетевых ресурсов для поддержки требованию, без без необходимости масштабирования области приложение, которое не наблюдается повышение спроса.One of the main advantages of microservices is that they can be scaled-out independently, which means that a specific functional area can be scaled that requires more processing power or network bandwidth to support demand, without unnecessarily scaling areas of the application that are not experiencing increased demand.

Контейнер — изолированной, ресурсов управляемой и переносимой среде, где приложение может работать, не изменяя при этом ресурсы другими контейнерами или узлом.A container is an isolated, resource controlled, and portable operating environment, where an application can run without touching the resources of other containers, or the host. Предприятия все чаще внедряют контейнеры, при реализации микрослужбы на основе приложений, а Docker стал стандартный контейнер реализацию, которая была принята большинство платформ программного обеспечения и поставщики облачных служб.Enterprises are increasingly adopting containers when implementing microservice based applications, and Docker has become the standard container implementation that has been adopted by most software platforms and cloud vendors.