Академический Документы
Профессиональный Документы
Культура Документы
com/IBMRedbooks
Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks weekly
newsletter: https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Предоставляя среду платформу как сервис (PaaS) как одну из сред времени выполнения, наряду с
контейнерами и виртуальными машинами (VM), Bluemix использует проект Cloud Foundry как
одну из своих технологий с открытым исходным кодом для методологии ускорения разработки
новых приложений и разработки интегрированных приложений и ИТ-операций (DevOps). Bluemix
позволяет разделять интерфейс, реализацию и развертывание. Вы можете использовать Bluemix
для создания приложений в стиле микросервисов, и в этом разделе показано, как это сделать.
Система должна состоять из двух или более выполняющихся блоков или компонентов. Эти
компоненты должны раскрывать свою функциональность как услуги. Каждый компонент должен
служить бизнес-цели, а компоненты должны быть слабо связаны. Компоненты должны
взаимодействовать друг с другом через предопределенные протоколы, такие как очереди
сообщений, модели HTTP-запроса / ответа и т. Д.
Системы должны быть языково агностическими. Один компонент может быть разработан на Java,
а другой может быть разработан в .NET. Решение о выборе технологической платформы для
конкретной услуги не должно влиять на архитектуру приложения.
Системы должны иметь децентрализованную базу данных. В идеале каждый компонент или
микросервис должен иметь свою собственную базу данных, с которой взаимодействует только эта
служба. Ни один другой компонент или служба не могут извлекать или изменять данные в этой
базе данных.
Любой отказ компонента / службы должен быть изолирован. Отказ одной службы не должен
сводить все приложение вниз. Если это не удается, оно не должно влиять на другие компоненты /
службы. Должен быть установлен какой-то механизм отката отката. Это означает, что если одна
услуга выходит из строя, ее легко вернуть в более старую рабочую версию.))))))
Кроме того, микросервисы могут быть разработаны на любом языке программирования. Они
обмениваются данными друг с другом с помощью интерфейсов прикладного программирования
(API), ориентированных на язык, таких как представление State State Transfer (REST).
Микросервисы также имеют ограниченный контекст. Им не нужно ничего знать о базовой
реализации или архитектуре других микросервисов.
Микросервис также должен рассматриваться как приложение или продукт. Он должен иметь свой
собственный репозиторий управления исходным кодом и собственный конвейер построения,
сборки и развертывания.
Хотя владелец продукта может выступать за повторное использование микросервиса, повторное
использование не является единственной бизнес-мотивацией для микросервисов. Существуют и
другие, такие как локализованная оптимизация для улучшения пользовательского интерфейса (UI)
и более быстрого реагирование на потребности клиентов.
То, что мы подразумеваем под ограниченным контекстом, состоит в том, что конкретный
микросервис «ничего знает» о лежащей в основе реализации других микросервисов, окружающих
его. Если по какой-либо причине микросервис должен знать что-либо о другом микросервисе
(например, что он делает или как его нужно вызывать), у вас нет ограниченного контекста.)
1.1.5 Comparing microservices and monolithic architectures Table 1-1 compares microservices and
monolithic architectures.
Не всегда интуитивно понятно, какая часть кода приложения нуждается в модификации для
конкретного запроса функции или запроса на изменение. Это приводит к более широкой
траектории обучения для разработчиков приложений, увеличению сроков реализации проекта и
снижению темпов совершенствования и предоставления новых возможностей.
Большие базы кода также могут привести к тому, что интегрированная среда разработки
разработчика (IDE) будет работать плохо или в некоторых случаях просто дает сбой. В тех случаях,
когда услуги разрабатываются в облаке, это также означает более длительное время
развертывания. Это может увеличить цикл времени разработки для разработчиков, чтобы
получить обратную связь о выполненных изменениях кода.
Позволяет избежать большой базы кода, упрощая поддержку или добавление функций
Облегчает отладку
Позволяет командам работать более независимо друг от друга
Время тестирования, как правило, замедляется с большими приложениями, потому что они
запускают неоправданно более длительные периоды времени, что приводит к снижению
производительности тестера. Каждый раз, когда происходит изменение кода, требующего
перезагрузки или перезагрузки контейнера, тестеры становятся менее продуктивными.
Существует также проблема единственной точки зависимости, когда несколько тестовых команд
выполняют свои тестовые примеры. Для любого инкрементного изменения компонентов весь
контейнер необходимо перезагрузить или перезапустить независимо от размера и объема
изменений. Аналогичным образом, дефекты имеют больший шанс блокировать больше членов
команды от тестирования по сравнению с микросервисом.
При использовании монолитных приложений даже небольшое изменение может иметь большой
эффект ряби в отношении регрессионного тестирования. Как правило, для монолитных
приложения требуется накопленная история большого набора регрессионных тестов. Это
добавляет к циклу тестирования времени и добавляет к числу тестировщиков, необходимых для
завершения тестирования. В некоторых случаях существует также риск ложных срабатываний,
возникающих из результатов, не связанных с тестируемыми конкретными изменениями.
Владельцы бизнеса хотят, чтобы их команды могли реагировать на новые потребности клиентов и
рынка. Микросервисы обеспечивают более частую доставку и более быстрое время доставки. Это
позволяет владельцам бизнеса получать более оперативную обратную связь и вносить
коррективы в свои инвестиции.
Владельцы бизнеса хотят иметь возможность разгружать работу сторонних партнеров без риска
потери интеллектуальной собственности. Микросервисы позволяют сегментировать работу для
непрофильных бизнес-функций без раскрытия основных услуг.
Принимая архитектурный стиль микросервисов, он становится быстро очевидным, когда
происходит дублирование сервисов. Наличие единой платформы для разработки, создания,
эксплуатации и управления вашими микросервисами позволяет вам более легко устранить
дублированные сервисы, сократить расходы на разработку и снизить затраты на управление.
Большие монолитные приложения часто имеют большой бизнес-охват и многие точки доступа к
ИТ-инфраструктуре. Любое изменение приложения приводит к многочисленным отзывам и
одобрениям, что приводит к увеличению времени цикла развертывания. Минимальное
централизованное управление означает, что для координации требуется меньшее количество
совещаний.
В новой эре разработки существует так много языков и технологий хранения данных, и
разработчики должны иметь гибкость в выборе лучших в зависимости от типа рабочей нагрузки,
которую они пытаются разработать. Использование 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.5, «Практические примеры и наиболее
распространенные архитектурные образцы» на стр. 14 - всего лишь небольшая выборка
компаний, успешно работающих на микросервисах в производстве. Важно помнить об этих
случаях использования, потому что мода микросервисов угрожает заставить разработчиков
попробовать их в тех контекстах, где они не предназначены для использования, что приводит к
сбоям проекта в некоторых случаях. Это плохая новость для практиков, которые извлекают из
пользу этой архитектуры.
Аналогия скалы и камней: есть причина, по которой мы используем слово монолит: это означает,
что камень достаточно большой, чтобы он мог убить вас, если он упадет на вас. Когда вы
начинаете, ваше приложение больше похоже на гальку. Требуетя большее число разработчиков
определенного времени и усилий, чтобы даже приблизиться к монолиту и, следовательно, к
микросервисной территории.
Важно знать, когда вы приближаетесь к статусу монолита и реагировать до того, как это
произошло.
Код завершения должен получить ваше приложение, развернутое через крючки фиксации,
которые запускают конвейеры доставки, по крайней мере, для разработки. Вам все еще нужны
ручные проверки и балансы для развертывания в производство. См. «Глава 3,« Микросервисы и
DevOps »на стр. 39, чтобы
Узнайте больше о том, почему DevOps имеет решающее значение для успешного развертывания
микросервисов.
Посредничество в SOA: некоторые более зрелые формы SOA могут включать посредничество с
использованием служебной шины предприятия (ESB). Для получения дополнительной
информации см. Модель зрелости SOA:
https://www.opengroup.org/soa/source-book/osimmv2/model.htm
Когда это определено таким образом, очевидно, что SOA имеет всеобъемлющий и далеко идущий
набор целей и задач, которые он пытается решить. Это также позволяет нам начинать замечать
различия между SOA и архитектурой микросервиса.
Хотя в обоих случаях мы действительно говорим о наборе услуг, сущности этих услуг разные. SOA
пытается передать эти услуги всем, кто хочет их использовать. Микросервисы, в качестве
альтернативы, создаются с гораздо более целенаправленной и ограниченной целью, которая
действует как часть единой распределенной системы.
Вы можете назвать это расширение или специализацию SOA, в которой границы функциональных
областей используются для определения моделей доменов и назначения их командам, которые
могут выбирать свои собственные языки разработки, фреймворки и детали развертывания.
Аналогичным образом, сервисная сборка, оркестрация, мониторинг и управление являются
реальной проблемой и требованием системы микросервиса в дополнение к более
традиционным SOA-системам.
Для этого есть веская причина. Некоторые из систем 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
уделяется повторному использованию и открытию, когда фокус микросервисов заключается в
замене одного монолитного приложения системой, которой легче управлять и постепенно
развивать.
2.1.1 Business-oriented
Поскольку целевая система разбивается на составные службы, существует реальный риск того, что
разложение может быть выполнено по существующим границам внутри организации. Это
означает, что существует вероятность того, что система будет более хрупкой, потому что для
управления ею необходимы более независимые части, а части, которые не интегрируются
хорошо, даже если получаемые сервисы могут взаимодействовать друг с другом.???
Крайне важно разработать микросервисы с конечной целью бизнеса. Это может потребовать,
чтобы команды в рамках границ организаций собирались вместе и совместно разрабатывали
сервисы, а не использовали микросервисы для маршрутизации вызовов между командами.
Более важным, чем фактическая архитектура системы, является тот факт, что дизайн услуг не
имитирует организационные, технологические или коммуникационные границы. Затем службы
могут выдержать изменения в организации (например, новые продукты или услуги, добавляемые
или новые приобретения), а также изменения в штатном расписании. Кроме того, службы
изолированы в поддержку бизнес-функции. Это пример воплощения Закона Конвей.( Conway’s
Law)
пропущено до стр. 27
Синхронные механизмы на основе HTTP, такие как Representational State Transfer (REST),
SOAP или WebSockets, которые позволяют поддерживать канал связи между браузером и
сервером открытым для управляемых событиями запросов / ответов
Асинхронный обмен сообщениями с помощью брокера сообщений
Он также не поддерживает очередь запросов, которые могут действовать как своего рода буфер.
Асинхронный обмен сообщениями разъединяет службы друг от друга во времени, позволяя
потоку отправки работать, в то время как система обмена сообщениями несет ответственность за
сообщение, сохраняя их безопасно, пока он не будет доставлен в пункт назначения.
Еще одним преимуществом обмена сообщениями является то, что вспомогательные приложения,
стоящие за очередью, могут распределять рабочую нагрузку среди нескольких клиентов. Этот тип
сценария разгрузки рабочих станций позволяет разработчикам создавать масштабируемые,
реагирующие приложения. Внедрение одного или нескольких экземпляров рабочего приложения
рабочего стола позволяет приложению продолжить свою работу без необходимости ждать
серверному приложению завершения работы .
Есть плюсы и минусы для обоих подходов. В большинстве приложений используется сочетание
двух подходов в соответствии с их потребностями.