Зачем использовать микрослужбы для создания приложенийWhy use a microservices approach to building applications

Для разработчиков программного обеспечения разложение приложения на части компонентов не представляет ничего нового.For software developers, factoring an application into component parts is nothing new. Как правило, используется многоуровневый подход с внутренним хранилищем, бизнес-логикой среднего уровня и интерфейсом пользовательского интерфейса.Typically, a tiered approach is used, with a back-end store, middle-tier business logic, and a front-end user interface (UI). Изменения за последние несколько лет заключаются в том , что разработчики создают распределенные приложения для облака.What has changed over the last few years is that developers are building distributed applications for the cloud.

Ниже приведены некоторые изменяющиеся бизнес-потребности.Here are some changing business needs:

  • Служба, которая построена и работает в масштабе для достижения клиентам в новых географических регионах.A service that's built and operated at scale to reach customers in new geographic regions.
  • Более быстрая доставка функций и возможностей для реагирования на запросы клиентов в гибкой методике.Faster delivery of features and capabilities to respond to customer demands in an agile way.
  • Более эффективное использование ресурсов, позволяющее снизить затраты.Improved resource utilization to reduce costs.

Эти бизнес-потребности определяют способ сборки приложений.These business needs are affecting how we build applications.

Дополнительные сведения о подходе Azure к микрослужбам см. в разделе микрослужбы: революция в приложении на базе облака.For more information about the Azure approach to microservices, see Microservices: An application revolution powered by the cloud.

Подход к созданию монолитных и микрослужбMonolithic vs. microservices design approach

По прошествии времени приложения развиваются.Applications evolve over time. Успешные приложения развиваются за счет использования.Successful applications evolve by being useful to people. Неудачные приложения не развиваются и в конечном итоге являются устаревшими.Unsuccessful applications don't evolve and are eventually deprecated. Вот вопрос: сколько вы узнаете о ваших требованиях сегодня и что они будут в будущем?Here's the question: how much do you know about your requirements today and what they'll be in the future? Например, предположим, что вы создаете приложение для создания отчетов для отдела в вашей компании.For example, let's say you're building a reporting application for a department in your company. Вы уверены, что приложение применяется только в пределах организации и что отчеты не будут храниться долго.You're sure the application applies only within the scope of your company and that the reports won't be kept long. Ваш подход будет отличаться от вашего подхода, скажем, создания службы, которая доставляет содержимое видео десяткам миллионов клиентов.Your approach will be different from that of, say, building a service that delivers video content to tens of millions of customers.

В некоторых случаях получение чего-либо в качестве подтверждения концепции является решающим фактором.Sometimes, getting something out the door as a proof of concept is the driving factor. Вы уверены, что приложение может быть переработано позже.You know the application can be redesigned later. При чрезмерном проектировании не используется совсем немного времени.There's little point in over-engineering something that never gets used. С другой стороны, когда компании создаются для облака, ожидание — это рост и использование.On the other hand, when companies build for the cloud, the expectation is growth and usage. Рост и масштабирование являются непредсказуемыми.Growth and scale are unpredictable. Мы хотим быстро создать прототип, а также понять, что мы будем использовать путь, который может справиться с успешным выполнением в будущем.We want to prototype quickly while also knowing that we're on a path that can handle future success. Подход, который применяют небольшие новые компании, включает сборку, измерение, анализ данных и повторение всего цикла.This is the lean startup approach: build, measure, learn, and iterate.

В эпоху клиент/сервер мы, как правило, сосредоточены на создании многоуровневых приложений с использованием конкретных технологий на каждом уровне.During the client/server era, we tended to focus on building tiered applications by using specific technologies in each tier. Для описания этих подходов появилось понятие « монолитное приложение».The term monolithic application has emerged to describe these approaches. Интерфейсы находились как бы между уровнями, а в рамках самого уровня компоненты были более тесно связаны.The interfaces tended to be between the tiers, and a more tightly coupled design was used between components within each tier. Разработчики разработали и собрали классы, которые были скомпилированы в библиотеки и связаны вместе в несколько исполняемых файлов и библиотек DLL.Developers designed and factored classes that were compiled into libraries and linked together into a few executable files and DLLs.

Существует ряд преимуществ для создания монолитных подходов.There are benefits to a monolithic design approach. Монолитные приложения часто проще в проектировании, и вызовы между компонентами выполняются быстрее, поскольку эти вызовы часто передаются через межпроцессный обмен данными (IPC).Monolithic applications are often simpler to design, and calls between components are faster because these calls are often over interprocess communication (IPC). Кроме того, каждый тестирует один продукт, который, как правило, более эффективно использует отдел кадров.Also, everyone tests a single product, which tends to be a more efficient use of human resources. Недостаток состоит в том, что существует тесная связь между многоуровневыми слоями, и вы не можете масштабировать отдельные компоненты.The downside is that there's a tight coupling between tiered layers, and you can't scale individual components. Если необходимо выполнить исправления или обновления, необходимо дождаться завершения тестирования другими пользователями.If you need to do fixes or upgrades, you have to wait for others to finish their testing. Это затрудняет гибкость.It's harder to be agile.

Микрослужбы устраняют эти недостатки и более точно соответствуют предыдущим бизнес-требованиям.Microservices address these downsides and more closely align with the preceding business requirements. Но у них также есть и преимущества, и обязательства.But they also have both benefits and liabilities. Преимущество микрослужб заключается в том, что каждая из них обычно инкапсулирует более простую бизнес-функциональность, которую можно масштабировать, тестировать, развертывать и управлять независимо друг от друга.The benefits of microservices are that each one typically encapsulates simpler business functionality, which you can scale out or in, test, deploy, and manage independently. Одним из важных преимуществ использования микрослужб является то, что группы управляются более бизнес-сценариями, чем технологии.One important benefit of a microservices approach is that teams are driven more by business scenarios than by technology. Небольшие команды разрабатывают микрослужбы на основе пользовательского сценария и используют любые технологии, которые они хотят использовать.Smaller teams develop a microservice based on a customer scenario and use any technologies that they want to use.

Иными словами, организации не нужно стандартизировать технологии для поддержки своих приложений для микрослужб.In other words, the organization doesn’t need to standardize tech to maintain microservice applications. Отдельные команды, владеющие службами, могут делать то, что они считают целесообразным, исходя из собственных знаний или подходящих действий для решения задачи.Individual teams that own services can do what makes sense for them based on team expertise or what’s most appropriate to solve the problem. На практике предпочтительнее использовать ряд рекомендуемых технологий, таких как определенное хранилище NoSQL или платформа веб-приложений.In practice, a set of recommended technologies, like a particular NoSQL store or web application framework, is preferable.

Недостаток микрослужб заключается в том, что необходимо управлять более отдельными сущностями и работать с более сложными развертываниями и версиями.The downside of microservices is that you have to manage more separate entities and deal with more complex deployments and versioning. Сетевой трафик между микрослужбами увеличивается, как и соответствующие задержки сети.Network traffic between the microservices increases, as do the corresponding network latencies. Большое количество бесед, детализированные службы могут вызвать кошмар производительности.Lots of chatty, granular services can cause a performance nightmare. Без средств, помогающих просматривать эти зависимости, трудно увидеть всю систему.Without tools to help you view these dependencies, it's hard to see the whole system.

Стандарты делают работу с микрослужбами, указывая, как обмениваться данными и допускать только те вещи, которые необходимы из службы, а не жесткими контрактами.Standards make the microservices approach work by specifying how to communicate and tolerating only the things you need from a service, rather than rigid contracts. Важно заранее определить эти контракты в структуре, поскольку службы обновляются независимо друг от друга.It's important to define these contracts up front in the design because services update independently of each other. При разработке приложений с использованием микрослужб выделяется еще одна характеристика — мелкомодульная сервисноориентированная архитектура (SOA).Another description coined for designing with a microservices approach is “fine-grained service-oriented architecture (SOA).”

Проще всего подход к проектированию микрослужб — это отделенная Федерация служб с независимыми изменениями в каждом и согласованном стандарте взаимодействия.At its simplest, the microservices design approach is about a decoupled federation of services, with independent changes to each and agreed-upon standards for communication.

По мере создания большего числа облачных приложений пользователи обнаружили, что эта декомпозиция всего приложения на независимые, ориентированные на сценарии службы является лучшим долгосрочным подходом.As more cloud applications are produced, people have discovered that this decomposition of the overall application into independent, scenario-focused services is a better long-term approach.

Сравнение подходов к разработке приложенийComparison between application development approaches

Разработка приложений на платформе Service Fabric

  1. Монолитное приложение содержит функциональные возможности, зависящие от домена, и обычно разделяется на функциональные слои, такие как веб-приложения, бизнес-приложения и данные.A monolithic application contains domain-specific functionality and is normally divided into functional layers like web, business, and data.

  2. Масштабирование монолитного приложения выполняется путем его клонирования на нескольких серверах, виртуальных машинах или контейнерах.You scale a monolithic application by cloning it on multiple servers/virtual machines/containers.

  3. В приложениях, состоящих из микрослужб, функциональные возможности распределены между отдельными службами меньшего размера.A microservice application separates functionality into separate smaller services.

  4. Подход с использованием микрослужб дает возможность масштабировать приложения, развертывая каждую службу независимо от других и создавая экземпляры этих служб на разных серверах и виртуальных машинах и в разных контейнерах.The microservices approach scales out by deploying each service independently, creating instances of these services across servers/virtual machines/containers.

Разработка с использованием микрослужб не подходит для всех проектов, но она более тесно согласована с бизнес-целями, описанными выше.Designing with a microservices approach isn't appropriate for all projects, but it does align more closely with the business objectives described earlier. Начиная с монолитного подхода может иметь смысл, если известно, что вы сможете переработать код позже в проект микрослужб.Starting with a monolithic approach might make sense if you know you'll have the opportunity to rework the code later into a microservices design. Но чаще всего разработчики сначала создают монолитное приложение, а затем медленно и поэтапно разделяют его, начиная с функциональных областей, в которых следует увеличить масштабируемость и гибкость.More commonly, you begin with a monolithic application and slowly break it up in stages, starting with the functional areas that need to be more scalable or agile.

При использовании микрослужб вы объединяете приложение многих небольших служб.When you use a microservices approach, you compose your application of many small services. Эти службы выполняются в контейнерах, развернутых в кластере компьютеров.These services run in containers that are deployed across a cluster of machines. Небольшие команды разрабатывают службу, которая посвящена сценарию и независимо тестирует, версии, развертывать и масштабировать каждую службу, чтобы все приложение можно было развивать.Smaller teams develop a service that focuses on a scenario and independently test, version, deploy, and scale each service so the entire application can evolve.

Что такое микрослужба?What is a microservice?

Существует много определений микрослужб.There are different definitions of microservices. Но большинство этих характеристик микрослужб широко приняты:But most of these characteristics of microservices are widely accepted:

  • Инкапсуляция сценария клиента или бизнес-сценария.Encapsulate a customer or business scenario. Какую проблему вы решаете?What problem are you solving?
  • Разработка небольшими командами разработчиков.Developed by a small engineering team.
  • Написанный на любом языке программирования с использованием любой платформы.Written in any programming language, using any framework.
  • Состоит из кода и, при необходимости, состояния, независимо от версии, развернутой и масштабируемой.Consist of code, and optionally state, both of which are independently versioned, deployed, and scaled.
  • Взаимодействие с другими микрослужбами с помощью четко определенных интерфейсов и протоколов.Interact with other microservices over well-defined interfaces and protocols.
  • Имеют уникальные имена (URL-адреса), которые используются для разрешения их расположения.Have unique names (URLs) that are used to resolve their location.
  • Обеспечение стабильности работы и доступности в случае сбоя.Remain consistent and available in the presence of failures.

Для суммирования:To sum that up:

Приложения, состоящие из микрослужб, формируются из небольших ориентированных на клиента служб с независимым управлением версиями и масштабированием, которые взаимодействуют по стандартным протоколам с применением четко определенных интерфейсов.Microservice applications are composed of small, independently versioned, and scalable customer-focused services that communicate with each other over standard protocols with well-defined interfaces.

Написанный на любом языке программирования с использованием любой платформыWritten in any programming language, using any framework

Как разработчикам, мы хотим бесплатно выбирать язык или платформу в зависимости от наших навыков и потребностей службы, которую мы создаем.As developers, we want to be free to choose a language or framework, depending on our skills and the needs of the service that we're creating. Для некоторых служб вы можете повысить производительность с помощью C++ над любым другим.For some services, you might value the performance benefits of C++ above anything else. В других случаях простота управляемой разработки, получаемой из C# или Java, может быть более важной.For others, the ease of managed development that you get from C# or Java might be more important. В некоторых случаях может потребоваться использовать конкретную библиотеку партнеров, технологию хранения данных или метод для предоставления клиентам доступа к службе.In some cases, you might need to use a specific partner library, data storage technology, or method for exposing the service to clients.

После выбора технологии необходимо учитывать операционные и эксплуатационные этапы управления и масштабирования службы.After you choose a technology, you need to consider the operational or life-cycle management and scaling of the service.

Возможность независимого управления версиями, развертывания и масштабирования кода и состоянияAllows code and state to be independently versioned, deployed, and scaled

Независимо от того, как вы пишете микрослужбы, код и, по желанию, состояние, должны самостоятельно развертывать, обновлять и масштабировать.No matter how you write your microservices, the code, and optionally the state, should independently deploy, upgrade, and scale. Эту проблему трудно решить, поскольку она связана с выбранными технологиями.This problem is hard to solve because it comes down to your choice of technologies. Для масштабирования понимание того, как следует секционировать (или сегментировать) код и состояние, является сложной задачей.For scaling, understanding how to partition (or shard) both the code and the state is challenging. Если в коде и состоянии используются различные технологии, которые сегодня являются общими, сценарии развертывания для микрослужбы должны иметь возможность масштабировать их.When the code and state use different technologies, which is common today, the deployment scripts for your microservice need to be able to scale them both. Это разделение также обеспечивает гибкость и гибкость, поэтому вы можете обновить некоторые микрослужбы, не требуя обновления всех этих микрослужб одновременно.This separation is also about agility and flexibility, so you can upgrade some of the microservices without having to upgrade all of them at once.

Давайте вернемся к нашему сравнению подходов монолитных и микрослужб в течение некоторого времени.Let's return to our comparison of the monolithic and microservices approaches for a moment. На этой схеме показаны различия в подходах к хранению состояния:This diagram shows the differences in the approaches to storing state:

Хранилище состояний для двух подходовState storage for the two approaches

Хранилище состояний платформы Service Fabric

Монолитный подход, слева, содержит одну базу данных и уровни конкретных технологий.The monolithic approach, on the left, has a single database and tiers of specific technologies.

Подход на основе микрослужб справа имеет граф взаимосвязанных микрослужб, где состояние обычно ограничено микрослужбой и используются различные технологии.The microservices approach, on the right, has a graph of interconnected microservices where state is typically scoped to the microservice and various technologies are used.

Монолитное приложение, как правило, использует отдельную базу данных.In a monolithic approach, the application typically uses a single database. Преимущество использования одной базы данных заключается в том, что она находится в одном месте, что упрощает развертывание.The advantage to using one database is that it's in a single location, which makes it easy to deploy. У каждого компонента может быть одна таблица для хранения данных о состоянии.Each component can have a single table to store its state. Сложность состоит в том, что командам разработчиков необходимо строго разграничивать состояния.Teams need to strictly separate state, which is a challenge. Неизбежно, кто-то сможет добавить столбец в существующую таблицу Customer, выполнить соединение таблиц и создать зависимости на уровне хранилища.Inevitably, someone will be tempted to add a column to an existing customer table, do a join between tables, and create dependencies at the storage layer. Однако в таком случае будет невозможно масштабировать отдельные компоненты.After this happens, you can't scale individual components.

При подходе с использованием микрослужб каждая служба управляет собственным состоянием и хранит данные о нем.In the microservices approach, each service manages and stores its own state. Каждая служба отвечает за масштабирование кода и состояния для обеспечения соответствия собственным требованиям.Each service is responsible for scaling both code and state together to meet the demands of the service. Недостаток состоит в том, что при необходимости создания представлений или запросов данных приложения необходимо выполнить запрос к нескольким хранилищам состояний.A downside is that when you need to create views, or queries, of your application’s data, you need to query across multiple state stores. Эта проблема обычно решается отдельной микрослужбой, которая создает представление в коллекции микрослужб.This problem is typically solved by a separate microservice that builds a view across a collection of microservices. Если необходимо выполнить несколько запросов импровизированном к данным, следует рассмотреть возможность записи данных о каждой микрослужбе в службу хранения данных для автономной аналитики.If you need to run multiple impromptu queries on the data, you should consider writing each microservice’s data to a data warehousing service for offline analytics.

Поддерживаются версии микрослужб.Microservices are versioned. Разные версии микрослужбы могут выполняться параллельно.It's possible for different versions of a microservice to run side by side. В процессе обновления может произойти сбой новой версии микрослужбы, и необходимо выполнить откат до более ранней версии.A newer version of a microservice could fail during an upgrade and need to be rolled back to an earlier version. Управление версиями также полезно для тестирования A/B, где разные пользователи испытывают разные версии службы.Versioning is also helpful for A/B testing, where different users experience different versions of the service. Например, вы часто обновляете микрослужбу для определенного набора клиентов, чтобы протестировать новые функции, прежде чем делать это более широко.For example, it's common to upgrade a microservice for a specific set of customers to test new functionality before rolling it out more widely.

Взаимодействие с другими микрослужбами с применением четко определенных интерфейсов и протоколовInteracts with other microservices over well-defined interfaces and protocols

За последние 10 лет были опубликованы подробные сведения о шаблонах связи в архитектурах, ориентированных на службы.Over the past 10 years, extensive information has been published describing communication patterns in service-oriented architectures. Сейчас, как правило, для взаимодействия между службами используется REST, протоколы HTTP и TCP, а также формат сериализации XML или JSON.Generally, service communication uses a REST approach with HTTP and TCP protocols and XML or JSON as the serialization format. С точки зрения интерфейса он состоит в подходе к веб-дизайну.From an interface perspective, it's about taking a web design approach. Но ничто не должно останавливаться на использовании двоичных протоколов или собственных форматов данных.But nothing should stop you from using binary protocols or your own data formats. Просто имейте в виду, что у людей будет труднее использовать микрослужбы, если эти протоколы и форматы недоступны.Just be aware that people will have a harder time using your microservices if these protocols and formats aren't openly available.

Уникальное имя (URL-адрес), используемое для распознавания расположенияHas a unique name (URL) used to resolve its location

Возможность адресации микрослужбы должна существовать независимо от того, где она находится.Your microservice needs to be addressable wherever it's running. Если вы думаете о компьютерах и на каком компьютере выполняется конкретная микрослужба, то они могут быстро оказаться ненужными.If you're thinking about machines and which one is running a particular microservice, things can go bad quickly.

Микрослужба должна иметь уникальное имя, позволяющее обнаружить ее расположение, подобно тому, как DNS разрешает URL-адрес для конкретного компьютера.In the same way that DNS resolves a particular URL to a particular machine, your microservice needs a unique name so that its current location is discoverable. Микрослужбам требуются имена с адресацией, которые не зависят от инфраструктуры, в которой они выполняются.Microservices need addressable names that are independent of the infrastructure they're running on. Это означает наличие связи между развертыванием службы и ее обнаружением, то есть необходим реестр служб.This implies that there's an interaction between how your service is deployed and how it's discovered, because there needs to be a service registry. При сбое компьютера служба реестра должна сообщить, куда была перемещена служба.When a machine fails, the registry service needs to tell you where the service was moved to.

Стабильность работы и доступность в случае сбояRemains consistent and available in the presence of failures

Непредвиденные сбои являются одной из самых сложных для разрешения проблем, особенно в распределенной системе.Dealing with unexpected failures is one of the hardest problems to solve, especially in a distributed system. Большая часть кода, который мы написали для разработчиков, — обработка исключений.Much of the code that we write as developers is for handling exceptions. Во время тестирования мы также тратим максимальное время на обработку исключений.During testing, we also spend the most time on exception handling. Процесс является более сложным, чем написание кода для обработки сбоев.The process is more involved than writing code to handle failures. Что происходит при сбое компьютера, на котором работает микрослужба?What happens when the machine on which the microservice is running fails? Необходимо обнаружить ошибку, которая является жесткой проблемой.You need to detect the failure, which is a hard problem on its own. Но вам также потребуется перезапустить микрослужбу.But you also need to restart your microservice.

Для обеспечения доступности микрослужба должна быть устойчива к сбоям и может быть перезапущена на другом компьютере.For availability, a microservice needs to be resilient to failures and able to restart on another machine. Помимо этих требований к устойчивости, данные не должны быть потеряны, и данные должны оставаться единообразными.In addition to these resiliency requirements, data shouldn't be lost, and data needs to remain consistent.

Устойчивости трудно достичь при возникновении сбоев во время обновления приложения.Resiliency is hard to achieve when failures happen during an application upgrade. Микрослужбе, работающей с системой развертывания, не требуется восстановление.The microservice, working with the deployment system, doesn't need to recover. Необходимо определить, может ли он продолжить переход к более новой версии или откатить до предыдущей версии, чтобы поддерживать целостное состояние.It needs to determine whether it can continue to move forward to the newer version or roll back to a previous version to maintain a consistent state. Необходимо рассмотреть несколько вопросов, например, если доступно достаточное количество компьютеров, чтобы продолжить переход вперед и восстановить предыдущие версии микрослужбы.You need to consider a few questions, like whether enough machines are available to keep moving forward and how to recover previous versions of the microservice. Для принятия этих решений необходимо, чтобы микрослужба выдавала сведения о работоспособности.To make these decisions, you need the microservice to emit health information.

Передача информации о работоспособности и диагностических данныхReports health and diagnostics

Это может показаться очевидным, и часто он не будет рассматриваться, но микрослужба должна сообщить о своей работоспособности и диагностике.It might seem obvious, and it's often overlooked, but a microservice needs to report its health and diagnostics. В противном случае у вас будет немало информации о работоспособности с точки зрения операций.Otherwise, you have little insight into its health from an operations perspective. Сложность заключается не только в выявлении связи между диагностическими событиями для ряда независимых служб, но и в сопоставлении расхождений в показаниях часов компьютера для определения порядка событий.Correlating diagnostic events across a set of independent services, and dealing with machine clock skews to make sense of the event order, is challenging. Как и при взаимодействии с микрослужбами с использованием согласованных протоколов и форматов данных, необходимо стандартизировать способ ведения журнала событий работоспособности и диагностических событий, которые в конечном счете оказываются в хранилище событий, к которому можно обращаться для просмотра данных и создания запросов.In the same way that you interact with a microservice over agreed-upon protocols and data formats, you need to standardize how to log health and diagnostic events that will ultimately end up in an event store for querying and viewing. При подходе к микрослужбам разные команды должны согласовать один формат ведения журнала.With a microservices approach, different teams need to agree on a single logging format. В приложении должен использоваться согласованный подход к просмотру диагностических событий.There needs to be a consistent approach to viewing diagnostic events in the application as a whole.

Работоспособность отличается от диагностики.Health is different from diagnostics. Работоспособность связана с отчетами микрослужбы о своем текущем состоянии для принятия необходимых мер.Health is about the microservice reporting its current state to take appropriate actions. Хороший пример — работа с механизмами обновления и развертывания для поддержания доступности.A good example is working with upgrade and deployment mechanisms to maintain availability. Несмотря на то, что в данный момент служба может быть неработоспособной из-за сбоя процесса или перезагрузки компьютера, служба может продолжать работать.Though a service might be currently unhealthy because of a process crash or machine reboot, the service might still be operational. Последнее, что вам нужно, — это сделать ситуацию хуже, запустив обновление.The last thing you need is to make the situation worse by starting an upgrade. Наилучший подход заключается в том, чтобы сначала исследовать время для восстановления микрослужбы.The best approach is to investigate first or allow time for the microservice to recover. События работоспособности от микрослужбы помогают принимать обоснованные решения и, по сути, создавать самовосстанавливающиеся службы.Health events from a microservice help us make informed decisions and, in effect, help create self-healing services.

Руководство по проектированию микрослужб в AzureGuidance for designing microservices on Azure

Руководство по проектированию и созданию микрослужб в Azureсм. в центре архитектуры Azure.Visit the Azure architecture center for guidance on designing and building microservices on Azure.

Платформа микрослужб Service FabricService Fabric as a microservices platform

Service Fabric Azure появилось, когда корпорация Майкрософт перешла от поставки продуктов в штучной упаковке, которые обычно монолиты для доставки служб.Azure Service Fabric emerged when Microsoft transitioned from delivering boxed products, which were typically monolithic, to delivering services. Возможности создания и эксплуатации больших служб, таких как база данных SQL Azure и Azure Cosmos DB, Service Fabric.The experience of building and operating large services, like Azure SQL Database and Azure Cosmos DB, shaped Service Fabric. Платформа развивалась со временем по мере того, как она была принята службами.The platform evolved over time as more services adopted it. Service Fabric работает не только в среде Azure, но и в автономных развертываниях Windows Server.Service Fabric had to run not only in Azure but also in standalone Windows Server deployments.

Целью Service Fabric является решение проблем, связанных с созданием и запуском службы, а также эффективное использование ресурсов инфраструктуры, благодаря чему команды могут решать бизнес-задачи с помощью подхода к микрослужбам.The aim of Service Fabric is to solve the hard problems of building and running a service and to use infrastructure resources efficiently, so teams can solve business problems by using a microservices approach.

Этот короткий видеоролик содержит общие сведения о Service Fabric и микрослужбах:This short video introduces Service Fabric and microservices:

Service Fabric позволяет создавать приложения в рамках подхода с использованием микрослужб, предоставляя следующее:Service Fabric helps you build applications that use a microservices approach by providing:

  • Платформа, которая предоставляет системные службы для развертывания, обновления, обнаружения и перезапуска служб, в которых произошел сбой, а также обнаружения служб, маршрутизации сообщений, управления состоянием и мониторинга работоспособности.A platform that provides system services to deploy, upgrade, detect, and restart failed services, discover services, route messages, manage state, and monitor health.
  • Возможность развертывания приложений, работающих в контейнерах или в качестве процессов.The ability to deploy applications either running in containers or as processes. Service Fabric — это контейнер и оркестратор процессов.Service Fabric is a container and process orchestrator.
  • Эффективные API-интерфейсы программирования, помогающие создавать приложения в виде микрослужб: ASP.NET Core, Reliable Actors и Reliable Services.Productive programming APIs to help you build applications as microservices: ASP.NET Core, Reliable Actors, and Reliable Services. К примеру, вы можете получать информацию о работоспособности и данные диагностики, а также пользоваться преимуществами встроенных средств, обеспечивающих высокую доступность.For example, you can get health and diagnostics information, or you can take advantage of built-in high availability.

Service Fabric не зависит от того, как вы создаете службу, и можете использовать любую технологию. Но он предоставляет встроенные API-интерфейсы программирования, упрощающие создание микрослужб.Service Fabric is agnostic about how you build your service, and you can use any technology. But it does provide built-in programming APIs that make it easier to build microservices.

Перенос существующих приложений в Service FabricMigrating existing applications to Service Fabric

Service Fabric позволяет повторно использовать существующий код и модернизировать его с новыми микрослужбами.Service Fabric allows you to reuse existing code and modernize it with new microservices. Модернизации приложений состоит из пяти этапов, и вы можете запускать и останавливаться на любом этапе.There are five stages to application modernization, and you can start and stop at any stage. Это следующие этапы.The stages are:

  1. начать с традиционного монолитного приложения.Start with a traditional monolithic application.
  2. Переход.Migrate. Используйте контейнеры или гостевые исполняемые файлы для размещения существующего кода в Service Fabric.Use containers or guest executables to host existing code in Service Fabric.
  3. Модернизировать.Modernize. Добавление новых микрослужб вместе с существующим контейнерным кодом.Add new microservices alongside existing containerized code.
  4. Внедрять инновации.Innovate. Разбейте монолитное приложение на микрослужбы в зависимости от нужды.Break the monolithic application into microservices based on need.
  5. Преобразуйте приложения в микрослужбы.Transform applications into microservices. Преобразуйте существующие монолитные приложения или создайте новые приложения нуля.Transform existing monolithic applications or build new greenfield applications.

Переход на микрослужбы

Помните, что вы можете запускать и останавливаться на любом из этих этапов.Remember, you can start and stop at any of these stages. На следующий этап нет необходимости.You don't have to progress to the next stage.

Рассмотрим примеры для каждого из этих этапов.Let's look at examples for each of these stages.

анализаMigrate
По двум причинам многие компании переносят существующие монолитные приложения в контейнеры:For two reasons, many companies are migrating existing monolithic applications into containers:

  • Снижение затрат из-за консолидации и удаления существующего оборудования или из-за использования приложений с высокой плотностью.Cost reduction, either due to consolidation and removal of existing hardware or due to running applications at higher density.
  • Согласованный контракт развертывания между разработкой и операциями.A consistent deployment contract between development and operations.

Снижение затрат — это просто.Cost reductions are straightforward. В корпорации Майкрософт многие существующие приложения являются контейнерными, что позволяет экономить миллионы долларов.At Microsoft, many existing applications are being containerized, leading to millions of dollars in savings. Последовательное развертывание сложнее оценить, но так же важно.Consistent deployment is harder to evaluate but equally important. Это означает, что разработчики могут выбрать технологии, которые соответствуют им, но операции будут принимать только один метод развертывания приложений и управления ими.It means that developers can choose the technologies that suit them, but operations will accept only a single method for deploying and managing the applications. Она позволяет избежать проблем, связанных с сложностью поддержки различных технологий, не вынуждая разработчиков выбирать только определенные.It alleviates operations from having to deal with the complexity of supporting different technologies without forcing developers to choose only certain ones. По сути, каждое приложение является контейнерным для автономных образов развертывания.Essentially, every application is containerized into self-contained deployment images.

На этом многие организации останавливаются.Many organizations stop here. У них уже есть преимущества контейнеров, и Service Fabric предоставляет полный набор возможностей управления, включая развертывание, обновление, управление версиями, откаты и мониторинг работоспособности.They already have the benefits of containers, and Service Fabric provides the complete management experience, including deployment, upgrades, versioning, rollbacks, and health monitoring.

МодернизацияModernize
Модернизации — это добавление новых служб наряду с существующим контейнерным кодом.Modernization is the addition of new services alongside existing containerized code. Если вы собираетесь написать новый код, лучше проделать небольшие шаги по пути микрослужб.If you're going to write new code, it's best to take small steps down the microservices path. Это может означать добавление новой REST API конечной точки или новой бизнес-логики.This could mean adding a new REST API endpoint or new business logic. Таким образом вы начнете процесс создания новых микрослужб и попрактиковаться в разработке и развертывании.In this way, you start the process of building new microservices and practice developing and deploying them.

ИнновацииInnovate
Подход с использованием микрослужб позволит учесть изменяющиеся требования бизнеса.A microservices approach accommodates changing business needs. На этом этапе необходимо решить, следует ли начать разделение монолитного приложения на службы или внедрять.At this stage, you need to decide whether to start splitting the monolithic application into services, or innovating. Классический пример здесь заключается в том, что база данных, используемая в качестве очереди рабочего процесса, становится узким местом обработки.A classic example here is when a database that you're using as a workflow queue becomes a processing bottleneck. По мере увеличения количества запросов рабочих процессов работа должна распределяться соответственно масштабу.As the number of workflow requests increases, the work needs to be distributed for scale. Пройдите эту конкретную часть приложения, которая не масштабируется или нуждается в обновлении чаще, и разделите ее как микрослужбу и внедрять.Take that particular piece of the application that's not scaling, or that needs to be updated more frequently, and split it out as a microservice and innovate.

Преобразование приложений в микрослужбыTransform applications into microservices
На этом этапе приложение полностью состоит из микрослужб (или разбивается на них).At this stage, your application is fully composed of (or split into) microservices. Чтобы приступать к этому моменту, вы сделали путешествие микрослужб.To reach this point, you've made the microservices journey. Вы можете начать здесь, но для этого не нужно использовать платформу микрослужб, чтобы помочь вам в значительных вложениях.You can start here, but to do so without a microservices platform to help you requires a significant investment.

Подходят ли микрослужбы моему приложению?Are microservices right for my application?

Возможно.Maybe. В корпорации Майкрософт по мере того, как несколько групп начали создавать облачные решения по соображениям бизнеса, многие из них осознали преимущества подхода, схожего с микрослужбами.At Microsoft, as more teams began to build for the cloud for business reasons, many of them realized the benefits of taking a microservice-like approach. Например, Bing использует микрослужбы в течение нескольких лет.Bing, for example, has been using microservices for years. Для других команд этот подход был новым.For other teams, the microservices approach was new. Они столкнулись со сложными проблемами, которые им не удалось решить.Teams found that there were hard problems to solve outside of their core areas of strength. Именно поэтому Service Fabric получили выигрыш в качестве технологии для создания служб.This is why Service Fabric gained traction as the technology for building services.

Цель Service Fabric заключается в том, чтобы уменьшить сложность создания приложений микрослужб, чтобы не нужно было проделать много дорогостоящих реконструирования.The objective of Service Fabric is to reduce the complexities of building microservice applications so that you don't have to go through as many costly redesigns. Принцип использования платформы: создание небольшого приложения, масштабирование по мере необходимости, удаление устаревших служб, добавление новых служб и развитие приложения по мере использования клиентами.Start small, scale when needed, deprecate services, add new ones, and evolve with customer usage. Мы знаем: чтобы сделать микрослужбы более доступными для большинства разработчиков, следует решить еще множество проблем.We also know that there are many other problems yet to be solved to make microservices more approachable for most developers. Контейнеры и модель программирования субъектов — это примеры небольших шагов в этом направлении.Containers and the actor programming model are examples of small steps in that direction. Мы уверены, что для упрощения работы с микрослужбами появились новые нововведения.We're sure more innovations will emerge to make a microservices approach easier.

Дальнейшие действияNext steps