Microservices - это архитектурный стиль, в котором крупные сложные программные приложения

состоят из одного или нескольких меньших сервисов. Каждый из этих микросервисов

сосредоточен на выполнении одной задачи, которая представляет собой маленькую
функциональность бизнеса. Эти микросервисы могут быть разработаны на любом языке
программирования. Они взаимодействуют друг с другом с использованием нейтральных по языку
протоколов, таких как Presentation State Transfer (REST) или приложений обмена сообщениями,
таких как IBM® MQ Light.

Эта публикация IBM Redbooks® дает широкое понимание этого все более популярного
архитектурного стиля и дает некоторые реальные примеры того, как вы можете разрабатывать
приложения, используя подход микросервисов с IBM Bluemix ™. Исходный код для всех этих
примерных сценариев можно найти на GitHub (https://github.com/).

В книге также представлены некоторые примеры из продуктов IBM. Мы объясняем принятые

архитектурные решения, наш опыт и извлеченные уроки при перепроектировании этих продуктов
с использованием подхода микросервисов.

Специалисты в области информационных технологий (ИТ), заинтересованные в изучении

микросервисов, а также о том, как разработать или переделать приложение в Bluemix с
использованием микросервисов, могут извлечь выгоду из этой книги.

Stay connected to IBM Redbooks

Find us on Facebook: http://www.facebook.com/IBMRedbooks

Follow us on Twitter: http://twitter.com/ibmredbooks

Look for us on LinkedIn: http://www.linkedin.com/groups?home=&gid=2130806

Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks weekly
newsletter: https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm

Stay current on recent Redbooks publications with RSS Feeds: http://www.redbooks.ibm.com/rss.html

Представление архитектурного стиля микросервисов

В этой части мы представляем архитектурный стиль микросервисов и показываем, как можно
разрабатывать приложения, используя этот стиль в IBM Bluemix.

Предоставляя среду платформу как сервис (PaaS) как одну из сред времени выполнения, наряду с
контейнерами и виртуальными машинами (VM), Bluemix использует проект Cloud Foundry как
одну из своих технологий с открытым исходным кодом для методологии ускорения разработки
новых приложений и разработки интегрированных приложений и ИТ-операций (DevOps). Bluemix
позволяет разделять интерфейс, реализацию и развертывание. Вы можете использовать Bluemix
для создания приложений в стиле микросервисов, и в этом разделе показано, как это сделать.

Мотивация для микросервисов

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

1.1, «Что такое микросервисы»

 1.2, «Преимущества микросервисов»

1.3 «Что следует избегать с помощью микросервисов»

1.4, «Как микросервисы отличается от сервис-ориентированной архитектуры?»

1.5, «Варианты использования и наиболее распространенные архитектурные шаблоны»

1.6, «Примеры сценариев с использованием микросервисов»

(Из другого документа: Practical Microservices-

Любая архитектура, демонстрирующая следующие шесть принципов или характеристик, может

быть помещена в зону архитектуры микросервиса:

Система должна состоять из двух или более выполняющихся блоков или компонентов. Эти
компоненты должны раскрывать свою функциональность как услуги. Каждый компонент должен
служить бизнес-цели, а компоненты должны быть слабо связаны. Компоненты должны
взаимодействовать друг с другом через предопределенные протоколы, такие как очереди
сообщений, модели HTTP-запроса / ответа и т. Д.

Системы должны быть языково агностическими. Один компонент может быть разработан на Java,
а другой может быть разработан в .NET. Решение о выборе технологической платформы для
конкретной услуги не должно влиять на архитектуру приложения.

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

Каждый компонент системы должен быть внутренне связанным, независимым и

саморазвертывающимся. Он не должен зависеть от каких-либо других компонентов или ресурсов
для работы или развертывания. Он должен иметь непрерывную интеграцию / непрерывное
развертывание (CI / CD) для более быстрой доставки.

Система должна иметь автоматическое тестирование на месте. Скорость - одна из наиболее

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

Любой отказ компонента / службы должен быть изолирован. Отказ одной службы не должен
сводить все приложение вниз. Если это не удается, оно не должно влиять на другие компоненты /
службы. Должен быть установлен какой-то механизм отката отката. Это означает, что если одна
услуга выходит из строя, ее легко вернуть в более старую рабочую версию.))))))

1.1 What are microservices

Эта книга посвящена микросервисам. Так что же такое микросервисы?

Microservices - это архитектурный стиль, в котором крупные сложные программные приложения

состоят из одной или нескольких служб. Микросервис может быть развернут независимо друг от
друга и слабо связан. Каждый из этих микросервисов фокусируется только на выполнении одной
задачи и делает эту задачу очень хорошо. Во всех случаях эта задача представляет собой
возможность малого бизнеса. На рис. 1-1 показано примерное приложение с использованием
микросервисов.

Figure 1-1 A sample application using microservices

Кроме того, микросервисы могут быть разработаны на любом языке программирования. Они
обмениваются данными друг с другом с помощью интерфейсов прикладного программирования
(API), ориентированных на язык, таких как представление State State Transfer (REST).
Микросервисы также имеют ограниченный контекст. Им не нужно ничего знать о базовой
реализации или архитектуре других микросервисов.

В следующих разделах подробно рассматриваются ключевые аспекты этого определения.

1.1.1 Небольшие и целенаправленные

Микросервисам необходимо сосредоточиться на единице работы, и поэтому они небольшие. Нет

правил о том, насколько небольшой микросервис должен быть. Типичным ориентиром является
правило команды Two-Pizza Team, в котором говорится, что если вы не можете накормить
команду, создающую микросервис двумя пиццами, ваш микросервис слишком велик. Вы хотите
сделать микросервис достаточно маленьким, чтобы вы могли легко переписывать и
поддерживать весь микросервис в команде, если вам нужно.

Сохраняйте интерфейс маленьким: основное внимание должно быть сосредоточено на

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

Хотя владелец продукта может выступать за повторное использование микросервиса, повторное

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

Размер микросервиса также может быть определен на основе потребностей бизнеса.

Отслеживание пакетов, обслуживание котировок автомобилей и прогнозирование погоды - все
это примеры услуг, предоставляемых другими сторонними поставщиками услуг, или
предоставляемые в качестве основного сервиса

Проблема задержки: предоставление услуг слишком большим или требующим слишком

большого количества зависимостей от других микросервисов, может привести к задержке. См.
1.3.5, «Не забудьте следить за потенциальной проблемой латентности» на стр. ХХ.

1.1.2. Слабо связанный

Слабая связь является абсолютно важной характеристикой микросервисов. Вы должны иметь

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

1.1.3 Нечувствительность к языку

Использование правильного инструмента для правильной работы важно. Микросервисы должны

быть построены с использованием языка программирования и технологий, которые имеют
наибольший смысл для этой задачи. Микросервисы составляются вместе, чтобы сформировать
сложное приложение, и их не нужно писать с использованием одного и того же языка
программирования. В некоторых случаях Java может быть правильным языком, а в других может
быть, например, Python.

Связь с микросервисами осуществляется через API-интерфейсы, не зависящие от языка, как

правило, API Hypertext Transfer Protocol (HTTP)-based resource, например REST. Вы должны
стандартизировать интеграцию, а не платформу, используемую микросервисом. Языковая
нейтральность облегчает использование существующих навыков или наиболее оптимального
языка.

1.1.4 Ограниченный контекст (Bounded context)

То, что мы подразумеваем под ограниченным контекстом, состоит в том, что конкретный
микросервис «ничего знает» о лежащей в основе реализации других микросервисов, окружающих
его. Если по какой-либо причине микросервис должен знать что-либо о другом микросервисе
(например, что он делает или как его нужно вызывать), у вас нет ограниченного контекста.)

1.1.5 Comparing microservices and monolithic architectures Table 1-1 compares microservices and
monolithic architectures.
Table 1-1 Comparing monolithic and microservices architectures

Category Monolithic architecture Microservices architecture

Code. A single code base for the entire
application
Understandability Often confusing and hard to
maintain.
Deployment Complex deployments with
maintenance windows and
scheduled downtimes
Language Typically entirely developed in
one programming language
Scaling Requires you to scale the entire
application even though
bottlenecks are localized
Multiple code bases. Each
microservice has its own code
base
Much better readability and
much easier to maintain.
Simple deployment as each
microservice can be deployed
individually, with minimal if not
zero downtime
Each microservice can be
developed in a different
programming language
Enables you to scale bottle-
necked services without scaling
the entire application

1.2 Benefits from microservices

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

Когда не используются микросервисы: Существуют случаи, когда микросервисы не являются

хорошим выбором. Эти случаи описаны в 1.3, «Что следует избегать с помощью микросервисов»
на стр. 10. Знание этих случаев помогает ограничить расходы, связанные с внедрением
инфраструктуры микросервисов, и помогает узнать, когда это оправдано.

1.2.1 Контекст корпоративных решений

Чтобы описать некоторые преимущества архитектуры микросервисов, мы должны взглянуть на

контекст большинства архитектур корпоративной информационной технологии (ИТ) и систем
архитектур для разработки приложений. На протяжении многих лет большинство корпоративных
решений проектировались и разрабатывались как крупные, сложные, монолитные приложения.

Были некоторые разумные подходы к декомпозиции приложений на многоуровневые

архитектуры, такие как model view controller (MVC), как показано на рисунке 1-2. Тем не менее,
приложения по-прежнему неуклюжи в отношении уровня бизнес-функций, за которые отвечает
каждая из приложений, что делает их большими и сложными в управлении.
Figure 1-2 Monolithic applications with a multi-tiered architecture

Что такое монолитное приложение? Монолитное приложение - это приложение, в котором вся
логика выполняется на одинственном сервере приложений. Типичные монолитные приложения
большие и построены несколькими командами, требуют тщательной организации развертывания
для каждого изменения. Мы также рассматриваем приложения монолитным, если, хотя есть
несколько сервисов API, обеспечивающих бизнес-логику, весь уровень представления является
одним большим веб-приложением. В обоих случаях архитектура микросервиса может служить
альтернативой.

1.2.2. Проблемы с монолитной архитектурой

Чтобы лучше понять проблемы с монолитной архитектурой, рассмотрим их с точки зрения

разработчиков, тестеров, владельцев бизнеса и профессионалов по управлению услугами.

1.2.3 Перспектива разработчика

Большие монолитные приложения обычно имеют большуое количество кода приложения,

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

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

Большие базы кода также могут привести к тому, что интегрированная среда разработки
разработчика (IDE) будет работать плохо или в некоторых случаях просто дает сбой. В тех случаях,
когда услуги разрабатываются в облаке, это также означает более длительное время
развертывания. Это может увеличить цикл времени разработки для разработчиков, чтобы
получить обратную связь о выполненных изменениях кода.

Монолитные приложения также могут требовать более длительных обзоров взаимодействующего

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

Приложения Microservice позволяют разработчикам более легко разбивать свою работу на

небольшие независимые команды и интегрировать эту работу по мере ее доставки и интеграции.

Таким образом, микросервисы предоставляют разработчикам следующие преимущества:

Позволяет избежать большой базы кода, упрощая поддержку или добавление функций

Легче использовать существующие навыки или наиболее оптимальный язык

Улучшает время развертывания и время загрузки для IDE

Облегчает отладку

Позволяет командам работать более независимо друг от друга

Упрощает отслеживания зависимостей кода

Позволяет полностью владеть автономной отдельной командой, от определения через

разработку, развертывание, функционирование и завершение

Легче масштабировать узкие места

1.2.4. Tester perspective

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

Существует также проблема единственной точки зависимости, когда несколько тестовых команд
выполняют свои тестовые примеры. Для любого инкрементного изменения компонентов весь
контейнер необходимо перезагрузить или перезапустить независимо от размера и объема
изменений. Аналогичным образом, дефекты имеют больший шанс блокировать больше членов
команды от тестирования по сравнению с микросервисом.

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

1.2.5 Взгляд владельца бизнеса

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

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

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

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

Принимая архитектурный стиль микросервисов, он становится быстро очевидным, когда

происходит дублирование сервисов. Наличие единой платформы для разработки, создания,
эксплуатации и управления вашими микросервисами позволяет вам более легко устранить
дублированные сервисы, сократить расходы на разработку и снизить затраты на управление.

1.2.6 Перспектива управления услугами

Большие монолитные приложения часто имеют большой бизнес-охват и многие точки доступа к
ИТ-инфраструктуре. Любое изменение приложения приводит к многочисленным отзывам и
одобрениям, что приводит к увеличению времени цикла развертывания. Минимальное
централизованное управление означает, что для координации требуется меньшее количество
совещаний.

Принимая архитектурный стиль микросервисов с единой платформой, разработчики услуг могут

легче обслуживать несколько групп продуктов и сервисов. Эффективность может быть
реализована путем автоматизации методов развертывания, ведения журналов и мониторинга в
нескольких проектных группах микросервисов. Клиенты, опрошенные, рассчитывают реализовать
экономию средств от 3 до 1, автоматизируя большую часть инфраструктуры и платформы как
услуги (PaaS).

Когда проблемы возникают в производстве, легче идентифицировать и изолировать проблему.

Определяя меньшие невосприимчивые процессы микросервиса или просматривая файлы
журналов, отмеченные идентификатором команды микросервиса, операции могут быстро
определить, кто из разработчиков должен быть вовлечен в устранение проблемы, все в
автономной команде.

Придожения становятся более устойчивыми, поскольку вы принимаете архитектурный стиль

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

В новой эре разработки существует так много языков и технологий хранения данных, и
разработчики должны иметь гибкость в выборе лучших в зависимости от типа рабочей нагрузки,
которую они пытаются разработать. Использование PaaS предоставляет группам разработчиков
эту гибкость, позволяя командам управления службами последовательно и эффективнее
управлять безопасностью и инфраструктурой во время выполнения.

Figure 1-3 shows a microservices architecture with multiple languages and data store technologies.

Figure 1-3 Microservices architecture with multiple languages and data store technologies

1.3. Чего следует избегать с помощью микросервисов

Архитектуры и подходы обычно превращаются в тенденции, потому что существует достаточное

количество случаев использования, чтобы подтвердить их истинную полезность при решении
конкретной проблемы или класса проблем. В случае микросервисов, прежде чем они были
модными, достаточно компаний построили монолиты, выходящие за рамки их управляемости. У
них была настоящая проблема в их руках, которая была большим приложением, которое в корне
противоречило современным способам масштабирования, управления и развития больших
систем в облаке.

Посредством некоторых проб и ошибок они заново изобрели свои свойства в виде незвязанной
коллекции микросервисов с независимой масштабируемостью, жизненным циклом и
проблемами с данными. Тематические исследования в 1.5, «Практические примеры и наиболее
распространенные архитектурные образцы» на стр. 14 - всего лишь небольшая выборка
компаний, успешно работающих на микросервисах в производстве. Важно помнить об этих
случаях использования, потому что мода микросервисов угрожает заставить разработчиков
попробовать их в тех контекстах, где они не предназначены для использования, что приводит к
сбоям проекта в некоторых случаях. Это плохая новость для практиков, которые извлекают из
пользу этой архитектуры.

В следующем разделе указывается, где микросервисы не являются хорошим выбором. Это

помогает ограничить расходы на внедрение инфраструктуры и практики микросервисов, когда это
оправдано. Это также помогает избежать шумихи на микросервисах и предотвращать некоторые
сбои, которые могли бы рассердить людей против надежного технического подхода.
1.3.1 Не начинайте с микросервисов

При запуске новых приложений не требуйте включения микросервисов в них. Микросервисы

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

Аналогия скалы и камней: есть причина, по которой мы используем слово монолит: это означает,
что камень достаточно большой, чтобы он мог убить вас, если он упадет на вас. Когда вы
начинаете, ваше приложение больше похоже на гальку. Требуетя большее число разработчиков
определенного времени и усилий, чтобы даже приблизиться к монолиту и, следовательно, к
микросервисной территории.

Важно знать, когда вы приближаетесь к статусу монолита и реагировать до того, как это
произошло.

1.3.2 Даже не думайте о микросервисах без DevOps

Микросервисы вызывают взрыв движущихся частей. Нецелесообразно пытаться внедрять

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

Код завершения должен получить ваше приложение, развернутое через крючки фиксации,
которые запускают конвейеры доставки, по крайней мере, для разработки. Вам все еще нужны
ручные проверки и балансы для развертывания в производство. См. «Глава 3,« Микросервисы и
DevOps »на стр. 39, чтобы

Узнайте больше о том, почему DevOps имеет решающее значение для успешного развертывания
микросервисов.

1.3.3. Не управляйте своей собственной инфраструктурой. Микросервисы часто представляют

несколько баз данных, брокеров сообщений, кэши данных и аналогичные службы, которые все
должны поддерживаться, кластеризоваться и храниться в верхнем уровне. Это действительно
поможет, если ваша первая попытка использования микросервисов свободна от таких проблем.
PaaS, такой как IBM Bluemix или Cloud Foundry, позволяет вам функционировать быстрее и с
меньшей головной болью, чем с помощью инфраструктура как услуга (IaaS), при условии, что ваши
микросервисы являются дружественными к PaaS.

1.3.4 Не создавать слишком много микросервисов

Каждый новый микросервис использует ресурсы. Накопительное использование ресурсов может

опрокинуть преимущества архитектуры, если вы превысите количество микросервисов, которые
может обрабатывать ваша организация DevOps, процесс и инструменты. Лучше ошибаться на
стороне более крупных сервисов и разбивать их только, когда они заканчиваются тем, что
содержат части с противоречивыми требованиями масштабирования, жизненного цикла или
данных. Вынуждая их слишком малой сложности передачи от микросервисов и к задаче
интеграции сервисов. Не используйте совместно микросервисы между системами.
1.4. Чем это отличается от сервис-ориентированной архитектуры?
В этом разделе рассматривается сравнение подхода микросервисов и сервис-ориентированной
архитектуре (SOA).

Сравнение непростое и несколько пристрастное, потому что сторонники архитектуры

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

Прежде чем отвечать на прямой вопрос, рассмотрите, что означает SOA:

 Набор услуг и бизнес-ориентированных функций, которые бизнес хочет предоставить

своим клиентам, партнерам или другим областям организации.
 Архитектурный стиль, который запрашивает поставщика услуг, поставщика услуг с
описанием услуги и, возможно, посредника.

Посредничество в SOA: некоторые более зрелые формы SOA могут включать посредничество с
использованием служебной шины предприятия (ESB). Для получения дополнительной
информации см. Модель зрелости SOA:

https://www.opengroup.org/soa/source-book/osimmv2/model.htm

 Набор архитектурных принципов, шаблонов и критериев, которые учитывают

характеристики, такие как модульность, инкапсуляция, слабая связность, разделение
ответственностей, повторное использование и композиционная способность.
 Модель программирования в комплекте со стандартами, инструментами и технологиями,
которые поддерживают веб-сервисы, службы REST или другие виды услуг.
 Решение промежуточного программного обеспечения, оптимизированное для сборки
сервисов, организации, мониторинга и управления.

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

Хотя в обоих случаях мы действительно говорим о наборе услуг, сущности этих услуг разные. SOA
пытается передать эти услуги всем, кто хочет их использовать. Микросервисы, в качестве
альтернативы, создаются с гораздо более целенаправленной и ограниченной целью, которая
действует как часть единой распределенной системы.

Эта распределенная система часто создается путем разрушения большого монолитного

приложения, и предполагается, что набор микросервисов продолжает работать вместе как одно
приложение. Как правило, нет никаких претензий к одновременному использованию нескольких
систем.

В отличие от SOA, микросервисы часто существуют неявно. Они не обнаруживаются во время

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

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

Вы можете назвать это расширение или специализацию SOA, в которой границы функциональных
областей используются для определения моделей доменов и назначения их командам, которые
могут выбирать свои собственные языки разработки, фреймворки и детали развертывания.
Аналогичным образом, сервисная сборка, оркестрация, мониторинг и управление являются
реальной проблемой и требованием системы микросервиса в дополнение к более
традиционным SOA-системам.

В отличие от SOA, бизнес и технические мотивы для микросервисов различны. Возврат

инвестиций (ROI) обусловлен ускоренной реализацией доходов, а не общим преобразованием
бизнесом. Компании с меньшей вероятностью инвестируют в крупные и длительные
трансформационные инициативы. Микросервисы обеспечивают инкрементное преобразование с
использованием локальной оптимизации.

Основываясь на этом анализе, можем ли мы ближе определить различия между архитектурой

SOA и микросервисами? Можно сказать, что ключевыми отличиями являются цель (ambition) и
фокус.

Когда мы говорим об цели, мы подразумеваем множество проблем, которые пытается решить

конкретный подход. По этому критерию, микросервисы намеренно «пытаются» достичь меньше.

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

Information: A good reference for SOA best practices is the following article, Service-oriented modeling
and architecture: http://www.ibm.com/developerworks/library/ws-soa-design1/ You can also go to the
following website for more information on SOA: http://www-01.ibm.com/software/solutions/soa/

В качестве прямого следствия чрезмерного масштаба, стандартов и инструментов, которые SOA

имели в прошлом, архитектура микросервиса намеренно ориентирована на решение одной
проблемы. Основное внимание уделяется постепенному превращению большого монолитного
приложения в распределенную систему микросервисов, которые легче управлять, развивать и
развертывать с использованием методов непрерывной интеграции. Вы не хотите, чтобы какой-
либо из микросервисов, которые принимают участие в системе микросервиса, фактически
использовался другой такой системой.
Хотя много внимания уделяется повторному использованию, это повторное использование не
происходит на уровне обслуживания. Все микросервисы в системе микросервиса в основном
управляются одним основным приложением. Эти микросервисы, если они захотят, могут быть
повторно использованы другими существующими или новыми приложениями для достижения
аналогичных преимуществ, как описано в 1.2 «Преимущества микросервисов» на стр. 6.

Нетрудно понять, как произошло это отличие. SOA была разработана с претензиями для решения
очень сложных проблем архитектуры предприятия с целью облегчения высокого уровня
повторного использования.

Напротив, архитектура микросервисов была принята компаниями, пытающимися

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

Как непосредственное следствие более целенаправленного и ограниченного масштаба, а также

акцент на постепенное развитие от традиционной системы до системы микросервиса,
микросервисы становятся все более привлекательными для предприятий со значительными
инвестициями в инфраструктуру. Подход обещает быть менее дорогостоящим и более
экспериментальным, плата, когда происходит тпнсформация. Напротив, традиционная SOA
обычно требовал гораздо более серьезного финансового и архитектурного вовлечения.

В заключение, как архитектура SOA, так и микросервисов являются видами архитектур

обслуживания, поскольку они связаны с распределенными системами услуг, обменивающимися
по сети.

Тем не менее, практические результаты весьма различны, поскольку основное внимание SOA
уделяется повторному использованию и открытию, когда фокус микросервисов заключается в
замене одного монолитного приложения системой, которой легче управлять и постепенно
развивать.

1.5 Case studies and most common architectural patterns

Несколько компаний приняли архитектурные шаблоны микросервисов для решения бизнес-задач,
особенно для их отраслей. В этом разделе описывается несколько примеров внедрения
микросервисов, наиболее часто используемых шаблонов и наблюдаемых преимуществ. В таблице
1-2 перечислены тематические исследования, которые мы рассмотрим в этом разделе, и
общепринятые архитектурные образцы, используемые в этих тематических исследованиях.

Case Study Patterns Benefits

e-commerce Decompose a monolithic application Agility to respond to customer needs
using Node.js more rapidly
Faster page load times
Financial services Incremental re-platforming Faster delivery
Reduce compute costs
Large brick and Decompose monolithic application Enables mobile app development
mortar retailer using Node.js User perceived performance
improvements
ПРОПУЩЕНО до стр 18. Потом можно вернуться

2. Elements of a microservices architecture

В этой главе мы расскажем о ключевых характеристиках архитектуры микросервисов, которые

делают ее настолько привлекательной для современного приложения (приложения) и разработки
продукта. Мы также рассмотрим подробное описание того, как разрабатывать микросервисы и
интеграцию микросервисов. Наконец, мы задумаемся над тем, каким будет будущее архитектуры
микросервисов.

Эта глава содержит следующие разделы:

2.1, «Характеристики архитектуры микросервисов» на стр. 20

2.2 «Проектирование микросервисов» на стр. 29

2.3, «REST API и обмен сообщениями» на стр. 33

2.4 «Будущее микросервисов» на стр. 38

2.1 Characteristics of microservices architecture

In this section, we describe the characteristics of microservices architecture.

2.1.1 Business-oriented
Поскольку целевая система разбивается на составные службы, существует реальный риск того, что
разложение может быть выполнено по существующим границам внутри организации. Это
означает, что существует вероятность того, что система будет более хрупкой, потому что для
управления ею необходимы более независимые части, а части, которые не интегрируются
хорошо, даже если получаемые сервисы могут взаимодействовать друг с другом.???

Кроме того, если службы, составляющие систему, не проектируются в соответствии с правильной

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

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

Рассмотрим сценарий «старого» стиля обслуживания, показанный на рисунке 2-1

Figure 2-1 “Old” style of service design

В предыдущем сценарии структура коммуникации организации была имитирована в рамках

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

На сервисы, разработанные в предыдущем сценарии, также будут влиять изменения, которые

обычно влияют на организацию, такие как сбой, слияния и поглощения и изменения сетевых
устройств, используемых для предоставления услуг. Было бы неразумно ожидать, что такие
службы будут измеряться каждым отделом, с его собственными показателями ошибок, сбоев и
производительности. Однако система ввода заказов в целом не может служить цели организации.

Подход микросервиса хорошо работает, если разработчики и исполнители каждой части

организации общаются друг с другом, чтобы совместно разработать сервисы для обслуживания
общей бизнес-цели. На рисунке 2-2 показано приложение, измененное с помощью подхода
микросервисов. Обратите внимание, что подобная структура будет также результатом
использования SOA-подхода.
Рисунок 2-2. Применение, переработанное с использованием подхода микросервисов

В предыдущем сценарии кросс-функциональные команды собрались вместе, чтобы создать

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

Более важным, чем фактическая архитектура системы, является тот факт, что дизайн услуг не
имитирует организационные, технологические или коммуникационные границы. Затем службы
могут выдержать изменения в организации (например, новые продукты или услуги, добавляемые
или новые приобретения), а также изменения в штатном расписании. Кроме того, службы
изолированы в поддержку бизнес-функции. Это пример воплощения Закона Конвей.( Conway’s
Law)

пропущено до стр. 27

Синхронный HTTP-асинхронный обмен сообщениями

Существует два основных подхода к межпроцессной коммуникации:

 Синхронные механизмы на основе HTTP, такие как Representational State Transfer (REST),
SOAP или WebSockets, которые позволяют поддерживать канал связи между браузером и
сервером открытым для управляемых событиями запросов / ответов
 Асинхронный обмен сообщениями с помощью брокера сообщений

Синхронный обмен сообщениями - простой и знакомый механизм, который является firewall-

friendly. Недостатком является то, что он не поддерживает другие шаблоны, такие как модель
публикации / подписки. Стиль публикации публикации / подписки более гибкий, чем запрос
точка-точка, потому что он позволяет нескольким приемникам подписываться на поток
сообщений. Это позволяет легко добавлять дополнительные микросервисы в приложение.
Он также не поддерживает очередь запросов, которые могут действовать как своего рода буфер.
Асинхронный обмен сообщениями разъединяет службы друг от друга во времени, позволяя
потоку отправки работать, в то время как система обмена сообщениями несет ответственность за
сообщение, сохраняя их безопасно, пока он не будет доставлен в пункт назначения.

В синхронных приложениях оба клиента и сервер должны быть одновременно доступны, и

клиенты всегда должны знать хост и порт сервера, что не всегда просто, когда службы
автоматически масштабируются при развертывании облаков. В таких сценариях необходим один
из механизмов обнаружения услуг, описанных ранее. (Какой и зде???)

Альтернативно, асинхронный механизм использует брокер сообщений, который отделяет

потребителей сообщений и производителей. Брокер сообщений буферизует сообщения до тех
пор, пока потребитель не сможет их обработать.

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

Есть плюсы и минусы для обоих подходов. В большинстве приложений используется сочетание
двух подходов в соответствии с их потребностями.