Микросервисы. Лекция 11

1. Микросервисы Лекция 11

Марина Аншина
Председатель Правления Российского Союза ИТ-Директоров
Член Совета по профессиональным квалификациям в области ИТ (СПК-ИТ)
Доцент Финансового Университета

2. Домашнее задание

• Поправить модели в Archi по замечаниям
• Провести декомпозицию своих приложений и отразить
в модели Archi
• Проанализировать архитектуру ваших приложений по
слайду 25
• Выбрать шаблоны проектирования, которые подходят
для ваших приложений и объяснить, в чем
преимущества их использования
• Сделать диаграмму последовательности и диаграмму
состояний в UML
• Описать бэклог закончившегося спринта и показать
планируемый на следующий спринт бэклог
• Подготовить презентацию с результатами спринта,
планами на будущий спринт и ретроспективой

3. Что было на прошлой лекции

1 Проектирование
архитектуры
2 Принципы SOLID
Ключевые вопросы
3 Декомпозиция
программных
приложений
4 Шаблоны
проектирования
архитектуры ПО
Уровни декомпозиции
Модули

4. О чем будем говорить

1 Шаблоны
проектирования
архитектуры ПО
2 Архитектурные
шаблоны
Классификация шаблонов
проектирования
3 Микросервисы
Определение
Размеры
Свойства
MVC – MVVM - MVP

5. Паттерны (шаблоны) программирования

ПАТТЕРНЫ (ШАБЛОНЫ)
ПРОГРАММИРОВАНИЯ
5

6. История

В 1970-е годы архитектор Кристофер Александр составил набор шаблонов
проектирования разработки ПО.
В 1987 году Кент Бэк (Kent Beck) и Вард Каннингем (Ward Cunningham) взяли
идеи Александра и разработали шаблоны применительно к разработке
графических оболочек на языке Smalltalk.
В 1988 году Эрих Гамма (Erich Gamma) начал писать докторскую диссертацию
при Цюрихском университете об общей переносимости этой методики на
разработку программ.
В 1989—1991 годах Джеймс Коплин (James Coplien) трудился над разработкой
идиом для программирования на C++ и опубликовал в 1991 году книгу
Advanced C++ Idioms.
В этом же году Эрих Гамма заканчивает свою докторскую диссертацию и
переезжает в США, где в сотрудничестве с Ричардом Хелмом (Richard Helm),
Ральфом Джонсоном (Ralph Johnson) и Джоном Влиссидесом (John Vlissides)
публикует книгу Design Patterns — Elements of Reusable Object-Oriented
Software. В этой книге описаны 23 шаблона проектирования. Также команда
авторов этой книги известна общественности под названием «Банда четырёх»
(англ. Gang of Four, часто сокращается до GoF). Именно эта книга стала
причиной роста популярности шаблонов проектирования.

7. Основные шаблоны проектирования

Объект внешне выражает некоторое поведение, но в реальности
Delegation pattern передаёт ответственность за выполнение этого поведения связанному
объекту.
Гарантирует, что каждый модуль компьютерной программы имеет только
Functional design одну обязанность и исполняет её с минимумом побочных эффектов на
другие части программы.
Immutable
Создание неизменяемого объекта.
interface
Общий метод для структурирования компьютерных программ для того,
Interface
чтобы их было проще понять.
В качестве атрибута (как пометки объектной сущности) применяется
наличие или отсутствие реализации интерфейса-маркера. В
Marker interface
современных языках программирования вместо этого могут применяться
атрибуты или аннотации.
Позволяет добавлять дополнительные свойства для класса в контейнер
Property container
(внутри класса), вместо расширения класса новыми свойствами.
Расширяет шаблон Publish/Subscribe, создавая централизованный канал
для событий. Использует объект-представитель для подписки и объектпредставитель для публикации события в канале. Представитель
Event channel
существует отдельно от реального издателя или подписчика. Подписчик
7
может получать опубликованные события от более чем одного объекта,
даже если он зарегистрирован только на одном канале.

8. Порождающие шаблоны

Abstract
factory
Класс, который представляет собой интерфейс для создания компонентов
системы
Builder
Класс, который представляет собой интерфейс для создания сложного
объекта.
Factory
method
Определяет интерфейс для создания объекта, но оставляет подклассам
решение о том, какой класс инстанцировать.
Lazy
Объект, инициализируемый во время первого обращения к нему.
initialization
Multiton
Гарантирует, что класс имеет поименованные экземпляры объекта и
обеспечивает глобальную точку доступа к ним.
Object pool
Класс, который представляет собой интерфейс для работы с набором
инициализированных и готовых к использованию объектов.
Prototype
Определяет интерфейс создания объекта через клонирование другого
объекта вместо создания через конструктор.
Resource
acquisition
Получение некоторого ресурса совмещается с инициализацией, а
is
освобождение — с уничтожением объекта.
initialization
(RAII)
Singleton
Класс, который может иметь только один экземпляр.
8

9. Структурные шаблоны

Adapter /
Wrapper
Bridge
Объект, обеспечивающий взаимодействие двух других объектов, один из
которых использует, а другой предоставляет несовместимый с первым
интерфейс.
Структура, позволяющая изменять интерфейс обращения и интерфейс
реализации класса независимо.
Composite Объект, который объединяет в себе объекты, подобные ему самому.
Класс, расширяющий функциональность другого класса без использования
Decorator
наследования.
Объект, который абстрагирует работу с несколькими классами, объединяя их
Facade
в единое целое.
Обеспечивает унифицированный интерфейс для интерфейсов в
Front
подсистеме. Front Controller определяет высокоуровневый интерфейс,
controller
упрощающий использование подсистемы.
Flyweight
Это объект, представляющий себя как уникальный экземпляр в разных
местах программы, но фактически не являющийся таковым.
Proxy
Объект, который является посредником между двумя другими объектами, и
который реализует/ограничивает доступ к объекту, к которому обращаются
через него.

10. Поведенческие шаблоны

Chain of
responsibilit Предназначен для организации в системе уровней ответственности.
y
Представляет действие. Объект команды заключает в себе само действие и
Command
его параметры.
Interpreter Решает часто встречающуюся, но подверженную изменениям, задачу.
Представляет собой объект, позволяющий получить последовательный
Iterator
доступ к элементам объекта-агрегата без использования описаний каждого
из объектов, входящих в состав агрегации.
Обеспечивает взаимодействие множества объектов, формируя при этом
Mediator
слабую связанность и избавляя объекты от необходимости явно ссылаться
друг на друга.
Позволяет не нарушая инкапсуляцию зафиксировать и сохранить
Memento
внутренние состояния объекта так, чтобы позднее восстановить его в этих
состояниях.
Null Object Предотвращает нулевые указатели, предоставляя объект «по умолчанию».
Определяет зависимость типа «один ко многим» между объектами таким
Observer
образом, что при изменении состояния одного объекта все зависящие от
него оповещаются об этом событии.
Servant
Используется для обеспечения общей функциональности группе классов.
Specificatio
Служит для связывания бизнес-логики.
n
10
Используется в тех случаях, когда во время выполнения программы объект
State
должен менять своё поведение в зависимости от своего состояния.

11. Поведенческие шаблоны

State
Strategy
Template
method
Visitor
Event
listener
Singleserving
visitor
Hierarchical
visitor
Используется в тех случаях, когда во время выполнения программы объект
должен менять своё поведение в зависимости от своего состояния.
Предназначен для определения семейства алгоритмов, инкапсуляции каждого
из них и обеспечения их взаимозаменяемости.
Определяет основу алгоритма и позволяет наследникам переопределять
некоторые шаги алгоритма, не изменяя его структуру в целом.
Описывает операцию, которая выполняется над объектами других классов.
При изменении класса Visitor нет необходимости изменять обслуживаемые
классы.
Предназначен для отслеживания событий
Оптимизирует реализацию шаблона посетитель, который инициализируется,
единожды используется, и затем удаляется.
Предоставляет способ обхода всех вершин иерархической структуры данных
(напр. древовидной).

12. Шаблоны генерации объектов

Singleton
Factory Method
Abstract Factory
Prototype

13. Singleton (одиночка)

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

14. Factory Method

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

15. Abstract Factory

• Предоставляет интерфейс для создания
семейств взаимосвязанных или
взаимозависимых объектов, не
специфицируя их конкретных классов.
Шаблон реализуется созданием абстрактного
класса Factory, который представляет собой
интерфейс для создания компонентов
системы (например, для оконного
интерфейса он может создавать окна и
кнопки). Затем пишутся классы, реализующие
этот интерфейс[2].

16. Шаблоны программирования гибких объектов

• Composite
• Decorator
• Facade

17. Шаблоны выполнения задач

Interpreter
Strategy
Observer
Visitor
Command

18. Шаблоны архитектуры программных приложений

• Model-View-Controller (MVC) Модельпредставление-контроллер.
• Model-View-View-Model
• Model-View-Presenter.
• Presentation-Abstraction-Control.
• Naked objects.
• Hierarchical Model-View-Controller.
• View-Interactor-Presenter-EntityRouting (VIPER).

19. Model-View-Controller (MVC) Модель-представление-контроллер

Model-View-Controller (MVC)
Модель-представлениеконтроллер
• схема разделения данных приложения, пользовательского
интерфейса и управляющей логики на три отдельных
компонента: модель, представление и контроллер — таким
образом, что модификация каждого компонента может
осуществляться независимо.
• Модель (Model) предоставляет данные и реагирует на команды
контроллера, изменяя своё состояние.
• Представление (View) отвечает за отображение данных
модели пользователю, реагируя на изменения модели.
• Контроллер (Controller) интерпретирует действия
пользователя, оповещая модель о необходимости изменений.

20.

20

21.

22. Model-View-View-Model

• Представлен в 2005 году Джоном Госсманом (John
Gossman) как модификация шаблона Presentation
Model. Ориентирован на современные платформы
разработки, такие как Windows Presentation
Foundation, Silverlight от компании Microsoft, ZK
framework.
• Используется для разделения модели и её
представления, что необходимо для их изменения
отдельно друг от друга. Например, разработчик
задаёт логику работы с данными, а дизайнер
работает с пользовательским интерфейсом.

23. Model-View-View-Model

24. Model-View-Presenter

• Основным отличием является класс
Presenter, в который выносится
логика обработки событий,
форматирования данных и
управления View.
• Таким образом разгружаются классы
аналогичные UIViewController от тех
обязанностей, которыми они не
должны заниматься, оставляя
внутри только код инициализации
представлений и анимаций.

25. Сравнение шаблонов

26.

Presentation-AbstractionControl (PAC)
Разделение ПО на три типа компонентов, ответственных за
конкретные аспекты функциональности приложения.
– Компонент абстракции извлекает и обрабатывает данные,
– Компонент представления форматирует визуальное и звуковое представление
данных
– Компонент управления обрабатывает поток управления и связь между двумя
другими компонентами
В отличие от MVC PAC используется как иерархическая структура
агентов, каждый из которых состоит из триады частей представления,
абстракции и управления. Агенты (или триады) взаимодействуют друг
с другом только через управляющую часть каждой триады.
Он также отличается от MVC тем, что внутри каждой триады он
полностью изолирует представление (представление в MVC) и
абстракцию (модель в MVC).
Это предоставляет возможность раздельной многопоточности модели
и представления

27.

Presentation-AbstractionControl

28. Naked objects

• 1. Вся бизнес-логика должна быть инкапсулирована в бизнесобъект domain objects. Данный принцип не является уникальной
особенностью naked objects: это только строгое следование
обязательствам, определенным инкапсуляцией.
• 2. Интерфейс пользователя должен быть прямым представлением
объектов предметной области (domain objects), со всеми
действиями пользователя, явно содержащими создание или
получение объектов предметной области и/или вызовы методов
этих объектов. Данный принцип также не является уникальной
особенностью naked objects: это только частная интерпретация
объектно-ориентированного пользовательского интерфейса objectoriented user interface (OOUI).
• Подлинная идея шаблона Naked objects возникает из комбинации
обеих вышеперечисленных идей в форме третьего принципа:
• 3. Пользовательский интерфейс может быть сформирован
полностью автоматически из определения объектов предметной
области (domain objects).

29. Hierarchical Model-View-Controller

Hierarchical Model-ViewController
• Одно из расширений архитектурного паттерна MVC,
позволяющее решить некоторые проблемы масштабируемости
приложений, имеющих классическую MVC-архитектуру.
• Согласно парадигме HMVC, каждая отдельная MVC триада
используется в качестве слоя в иерархической структуре.
• При этом, каждая триада в этой иерархии независима от других,
и может обратиться к контроллеру другой триады.
• Такой подход существенно облегчает и ускоряет разработку
сложных приложений, облегчает их дальнейшую поддержку и
масштабирование, способствует повторному использованию
кода.

30. Hierarchical Model-View-Controller

Hierarchical Model-ViewController

31. View-Interactor-Presenter-Entity-Routing (VIPER).

View-Interactor-PresenterEntity-Routing (VIPER).
• Interactor, который содержит бизнес-логику, предусмотренную
сценарием.
• Presenter, который содержит логику подготовки содержимого для
отображения (полученного из Interactor) и для реакции на ввод данных
пользователем (запрашивая новые данные от Interactor).
• View, которое отображает, что сообщил Presenter и передает ввод
данных пользователем назад Presenter’у.
• Data Store (например, веб-сервис, база данных) отвечает за
предоставление Entity в Interactor. Поскольку Interactor применяет
свою бизнес-логику, он будет осуществлять выборку Entity из
хранилища данных, управлять Entity и затем возвращать
обновленные Entity назад в хранилище данных. Хранилище данных
управляет персистентностью Entity. Entity не знают о хранилище
данных, таким образом, они не знают, как сохраняться.
• Routing (маршрутизация) обрабатывает навигацию от одного экрана к
другому,

32. Микросервисная архитектура

МИКРОСЕРВИСНАЯ
АРХИТЕКТУРА

33. Что такое микросервисная архитектура

• Вариант сервис-ориентированной
архитектуры программного обеспечения,
направленный на взаимодействие
насколько это возможно небольших,
слабо связанных и легко изменяемых
модулей — микросервисов, получивший
распространение в середине 2010-х годов
в связи с развитием практик гибкой
разработки и DevOps.

34. Что такое микросервисная архитектура

• «Архитектура на основе свободно
сопряжённых сервисов с
ограниченными контекстами. (Loosely
coupled service oriented architecture with
bounded contexts.)»
Эдриан Кокфорт
https://www.youtube.com/watch?v=pwpxq9-uw_0&feature=youtu.be&t=21m25s

35.

36. Ограниченный контекст

• Ограниченный контекст — это понятие
явных границ вокруг какого-то бизнесконтекста.
• Например, в рамках электронной
коммерции мы оперируем понятиями
«темы» (themes), «поставщики
платёжных услуг» (payment providers),
«заказы», «отгрузка», «магазин
приложений». Всё это ограниченные
контексты, а значит — кандидаты в
микросервисы.

37. Что такое микросервис

• «Это небольшие, автономные, совместно
работающие сервисы» Сэм Ньюмен
• «микросервис является самостоятельным
образованием, которое может быть развернуто в
качестве обособленного сервиса на платформе,
предоставляемой в качестве услуги, — Platform as a
Service (PAAS), или может быть процессом своей
собственной операционной системы» Сэм Ньюмен
• «Микросервисы – это некий код, который может быть
переписан за две недели» Джон Ивс

38. Компонентное представление через сервисы

• Компонент — это элемент системы, который
можно независимо заменить,
усовершенствовать (Мартин Фаулер)
и масштабировать (Ребекка Парсонс).
• При разработке ПО мы используем два типа компонентов:
А. Библиотеки: куски кода, применяемые в приложениях,
которые могут дополняться или заменяться другими
библиотеками, желательно без воздействия на остальную
часть приложения. Взаимодействие происходит через
языковые конструкты. Однако если интересующая нас
библиотека написана на другом языке, мы не можем
использовать этот компонент.
Б. Сервисы: части приложений, по факту представляющие
собой маленькие приложения, выполняющиеся в
собственных процессах.

39. Компонентное представление через сервисы

• Взаимодействие выполняется за счёт межпроцессной
связи, вызовов веб-сервисов, очереди сообщений и т.
д. Мы можем использовать сервис, написанный
на другом языке, поскольку он выполняется в
собственном процессе (этот подход
предпочитает Чед Фаулер).
• Независимая масштабируемость — каждый сервис
может быть масштабирован независимо от
остального приложения.

40. Почему плох монолитный код

«При создании дополнительных свойств программы разрастается и база
программного кода. Со временем из-за слишком большого объема этой
базы возникают затруднения при поиске тех мест, куда нужно вносить
изменения. Несмотря на стремление к созданию понятных модульных
монолитных баз кода, довольно часто эти произвольные, находящиеся в
процессе становления границы нарушаются. Код, относящийся к схожим
функциям, попадает в разные места, что усложняет устранение дефектов
или реализацию функций.
Внутри монолитных систем мы стремимся бороться с этой тенденцией,
пытаясь сделать свой код более связанным, зачастую путем создания
абстракций или модулей.
Придание связности означает стремление сгруппировать родственный код.
Эта концепция приобретает особую важность при размышлении о
микросервисах.
Она усиливается определением, данным Робертом С. Мартином (Robert C.
Martin) принципу единственной обязанности — Single Responsibility
Principle, которое гласит: «Собирайте вместе все, что изменяется по одной
и той же причине, и разделяйте все, что изменяется по разным причинам».

41.

42. Монолит vs микросервисы

Преимущества
Монолитная архитектура
Простота
Монолитная архитектура гораздо проще в
реализации, управлении и развёртывании.
Микросервисы требуют тщательного управления,
поскольку они развёртываются на разных
серверах и используют API.
Согласованность (Consistency)
При монолитной архитектуре проще
поддерживать согласованность кода,
обрабатывать ошибки и т. д. Зато микросервисы
могут полностью управляться разными
командами с соблюдением разных стандартов.
Межмодульный рефакторинг
Единая архитектура облегчает работу в
ситуациях, когда несколько модулей должны
взаимодействовать между собой или когда мы
хотим переместить классы из одного модуля в
другой. В случае с микросервисами мы должны
очень чётко определять границы модулей!
Микросервисы
Частичное развёртывание
Микросервисы позволяют по мере
необходимости обновлять приложение по
частям.
При единой архитектуре нам приходится
заново развёртывать приложение целиком,
что влечёт за собой куда больше рисков.
Доступность
У микросервисов доступность выше: даже
если один из них сбоит, это не приводит к
сбою всего приложения.
Сохранение модульности
Сохранять модульность и инкапсуляцию
может быть непросто, несмотря на правила
SOLID. Однако микросервисы позволяют
гарантировать отсутствие общих состояний
(shared state) между модулями.
Мультиплатформенность/гетерогенность
Микросервисы позволяют использовать
разные технологии и языки, в соответствии

43.

Микросервисы
Аппаратные преимущества
Независимая масштабируемость
При размещении модулей на отдельных
серверных узлах мы можем масштабировать
их независимо от других модулей.
Независимый технический стек
Благодаря распределению модулей по
разным серверным узлам и независимому
языку взаимодействия мы можем
использовать совершенно разные языки
программирования, инструменты
взаимодействия, мониторинга и хранения
данных. Это позволяет выбирать лучшие и
наиболее удобные решения, а также
экспериментировать с новыми технологиями.
Программные преимущества
Сохранение модульности
И единая, и микросервисная архитектуры
позволяют сохранять модульность и
инкапсуляцию. Однако это может быть
довольно трудной задачей, на решение
которой уйдут десятилетия, несмотря на
правила SOLID. Зато микросервисы
позволяют обеспечивать логическое
разделение приложения на модули за счёт
явного физического разделения по серверам.
Физическая изолированность защищает от
нарушения пределов ограниченных
контекстов.
Независимая эволюция подсистем
Микросервис может развиваться и ломать
обратную совместимость, не обременяя себя
поддержкой старых версий, так как всегда
можно оставить старую версию микросервиса
работающей необходимое время.

44. Гетерогенность

• Гетерогенность — это возможность построить систему с
использованием разных языков программирования. У подхода есть
ряд преимуществ (Мартин Фаулер), а Чед Фаулер считает, что
системы обязаны быть гетерогенны по умолчанию, то есть
разработчики должны стараться применять новые технологии.
Преимущества гетерогенной системы:
Предотвращает возникновение тесных связей благодаря
использованию разных языков.
• Разработчики могут экспериментировать с технологиями, что
повышает их собственную ценность и позволяет не уходить в другие
компании, чтобы попробовать новинки.
• Правило. При экспериментах с новыми технологиями:
— нужно использовать маленькие элементы кода (code unit),
модули/микросервисы, чтобы снизить риск;
— элементы кода должны быть одноразовыми (disposable).

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

46. Организация человеческих ресурсов в соответствии с возможностями бизнеса

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

47. Организация человеческих ресурсов в соответствии с возможностями бизнеса

• При микросервисном подходе команды должны
организовываться на основе бизнес-возможностей:
например команда заказов, отгрузки, каталога и т. д.
В каждой команде должны быть специалисты по
всем необходимым технологиям (интерфейс,
серверная часть, DBA, QA...).
• Это даст каждой команде достаточный объём
знаний, чтобы сосредоточиться на создании
конкретных частей приложения — микросервисов
(Мартин Фаулер, Эрик Эванс).

48. Закон Конвея

• Подход сочетается с законом Конвея,
который гласит, что если нам нужны
высокосвязные раздельные
микросервисы, то структура организации
должна отражать желаемую
компонентную структуру.
• «Организации, разрабатывающие
системы… создают архитектуры, которые
копируют структуры взаимодействий
внутри этих организаций».
Мелвин Конвей, 1967

49. Продукты, а не проекты

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

50. Децентрализованное управление данными

• При традиционном подходе у приложения
лишь одна база данных, и много разных
компонентов бизнес-логики приложения
«взаимодействуют» в рамках этой БД:
напрямую читают из неё данные,
принадлежащие другим компонентам. Это
также означает, что для всех компонентов
характерна одна и та же степень сохранности
данных, даже если для каких-то из них это не
самая лучшая ситуация (Мартин Фаулер).

51. Децентрализованное управление данными

• При микросервисной архитектуре, когда каждый
бизнес-компонент представляет собой микросервис,
все компоненты обладают собственными базами
данных, которые недоступны другим микросервисам.
• Данные компонента доступны (для чтения и записи)
только через соответствующий интерфейс
компонентов.
• Благодаря этому степень устойчивости данных
варьируется в зависимости от компонента (Мартин
Фаулер, Чед Фаулер).

52. Архитектура с эволюционным развитием

• Архитектура всего приложения не должна быть статичной,
необходима возможность её простого развития в
соответствии с потребностями бизнеса. Например, можно:
Превратить (рефакторить) единое приложение в приложение
микросервисное, изолировав и перенеся наборы бизнес-логики
(ограниченные контексты) в отдельные микросервисы.
• Объединить существующие микросервисы, например когда часто
приходится одновременно изменять разные микросервисы.
• Разделить существующие микросервисы, когда нужно и есть
возможность развивать их по отдельности или когда мы понимаем, что
разделение серьёзно повлияет на бизнес-логику.
• Временно добавить в приложение какую-то возможность, создав
микросервис, который будет работать определённое время.

53. Взаимодействие между микросервисами

• «Обмен данными между самими сервисами ведется через
сетевые вызовы, чтобы упрочить обособленность сервисов и
избежать рисков, сопряженных с тесными связями.
• Этим сервисам необходимо иметь возможность изменяться
независимо друг от друга и развертываться, не требуя никаких
изменений от потребителей. Нам нужно подумать о том, что
именно наши сервисы будут показывать и что им можно будет
скрывать.
• Если объем совместно используемого будет слишком велик,
потребляемые сервисы станут завязываться на внутренние
представления. Это снизит автономность, поскольку при
внесении изменений потребует дополнительного согласования с
потребителями.
• Микросервисы выставляют напоказ программный интерфейс
приложения — Application Programming Interface (API), и
работающие на нас сервисы связываются с нами через эти API.

54. «Нужно подумать и о самой сети»

• «Когда речь идет о распределенном вычислении, самым
распространенным первым заблуждением является
уверенность в надежности сети.
• Сети не могут быть абсолютно надежными. Они могут и будут
отказывать, даже если речь идет о вполне благополучных
клиентах и серверах. Они могут сбоить часто или редко, а могут
и вовсе портить ваши пакеты.
• Всегда нужно предполагать, что сети могут подвергнуться
воздействию недоброжелателей, готовых в любой момент
излить на вас свою злость.
• Поэтому можно ожидать всяческих отказов. Сбой может быть
вызван тем, что удаленный сервер возвратил ошибку, или тем,
что вы составили неверный вызов.
• Можете вы отличить одно от другого, и если да, то можете ли
что-то с этим сделать? А что делать, когда удаленный сервер
просто начинает медленно реагировать на ваши вызовы»

55. Размер микросервисов

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

56. Требования к микросервисам

• По мнению Джеймса Льюиса,
микросервисы должны:
быстро масштабироваться;
дёшево заменяться;
быть устойчивыми к сбоям;
никоим образом не замедлять нашу
работу.

57. Насколько велик микросервис?

• Есть разные мнения о размерах микросервисов. Мартин
Фаулер описывает случаи, когда соотношение количества
сотрудников и сервисов колебалось от 60 к 20 до 4 к 200.
Например, в Amazon используется подход «команда на две
пиццы» (two pizzas team): в команде микросервиса должно
быть столько людей, чтобы их можно было накормить
двумя пиццами.
• Джеймс Льюис утверждает, что сервис должен быть
«настолько большим, чтобы умещаться в руке», то есть
чтобы один человек мог полностью разобраться в его
устройстве и работе.
• Фред Джордж полагает, что микросервис должен быть
«очень-очень маленьким», чтобы его создавал и
сопровождал только один разработчик, как и Джеймс
Льюис.

58. Микросервисная архитектура

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

59. Свойства микросервисной архитектуры

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

60. Архитектура должна:

• «делать продукт гибче и устойчивее к
сбоям
• облегчать понимание, отладку и
изменение кода
• помогать в командной работе.»

61. Философия микросервисов

• Философия микросервисов фактически
копирует философию Unix, согласно которой каждая
программа должна «делать что-то одно, и делать это
хорошо» и взаимодействовать с другими программами
простыми средствами: микросервисы минимальны и
предназначаются для единственной функции.
• Основные изменения в связи с этим налагаются на
организационную культуру, которая должна включать
автоматизацию разработки и тестирования, а также
культуру проектирования, от которой требуется
предусматривать обход прежних ошибок, исключение по
возможности унаследованного кода (микросервисы часто
заменяют целиком, поскольку их функции элементарны).

62. Способ автоматизировать хаос

• Одна из причин использования
микросервисов заключается в том, что
мы хотим иметь возможность быстро
что-то менять, чтобы реагировать на
изменения бизнес-требований,
опережать конкурентов. Или,
выражаясь словами Эрика Эванса, нам
нужно осознавать хаос в компаниях:

63. Эрик Эванс

• «Реальность разработки ПО такова, что вначале мы
никогда не имеем полного понимания задачи.
• Наше понимание углубляется по мере работ, и нам
постоянно приходится рефакторить.
• Так что рефакторинг — это потребность, но в то же время и
опасность, потому что код становится запутанней,
особенно при несоблюдении ограниченности контекстов.
• Микросервисы заставляют соблюдать пределы
ограниченных контекстов, что позволяет сохранять
работоспособность, ясность, изолированность и
инкапсулированность кода в отдельных связных модулях.
• Если модуль/микросервис становится запутанным, то эта
запутанность только в нём и остаётся, а не
распространяется за его пределы.»

64. Мартин Фаулер говорит, что необходимо иметь возможность:

• Быстро вводить в
эксплуатацию: быстро развёртывать
новые машины для разработки,
тестирования, приёмки и работы.
• Быстро развёртывать
приложения: автоматически и быстро
развёртывать наши сервисы.
https://www.youtube.com/watch?v=yPf5MfOZPY0&feature=youtu.be&t=3m17s

65.

• Фред Джордж утверждает то же самое:
есть огромная потребность ускорить
работу, чтобы выдержать конкуренцию!
• Он приводит ретроспективный анализ
времени, необходимого на введение в
эксплуатацию сервера, и отмечает, что
в 1990-х требовалось 6 месяцев, в
2010-м благодаря облачным сервисам
— 30 минут, а в 2015-м Docker позволял
поднять и запустить новый сервер
менее чем за минуту.

66. Среды выполнения микросервисов

• Системы управления контейнеризованными
приложениями (такие как Kubernetes и её
надстройки OpenShift и CloudFoundry, Docker
Swarm, Apache Mesos)
• В этом случае каждый из микросервисов как правило
изолируется в отдельный контейнер или небольшую
группу контейнеров, доступную по сети другим
микросервисам и внешним потребителям, и управляется
средой оркестровки, обеспечивающей
отказоустойчивость и балансировку нагрузки.
• Типовой практикой является включение в контур среды
выполнения системы непрерывной интеграции,
обеспечивающее автоматизацию обновления и
развёртывания микросервисов.

67. Docker

• Программное обеспечение для автоматизации развёртывания и
управления приложениями в среде виртуализации на уровне
операционной системы; позволяет «упаковать» приложение со
всем его окружением и зависимостями в контейнер, а также
предоставляет среду по управлению контейнерами.

68.

69. Усложнившийся мониторинг

• Мониторинг крайне важен (Ребекка
Парсонс), нам необходимо сразу
узнавать о том, что сервер упал, что
какой-то компонент перестал отвечать,
что происходят сбои вызовов, причём
по каждому из микросервисов (Фред
Джордж). Также нам нужны
инструменты для быстрой отладки
(Мартин Фаулер).

70. Сильная devops-культура

• Нужны devops’ы для мониторинга и
управления, при этом между ними и
разработчиками должны быть тесные
отношения и хорошее взаимодействие (Мартин
Фаулер).
• При работе с микросервисами нам приходится
больше развёртывать, усложняется система
мониторинга, сильно разрастается количество
возможных сбоев.
• Поэтому в компании очень важна сильная
devops-культура (Ребекка Парсонс).

71. Опасности

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

72. Роль архитектора

• «У архитекторов весьма важная задача. Они отвечают за
координацию технического представления, помогающего нам дать
клиентам именно ту систему, в которой они нуждаются.
• В одних организациях архитекторам приходится работать с одной
командой, в таком случае роли архитектора и технического лидера
зачастую сливаются в одну.
• В других организациях они могут определять представление о всей
программе работы в целом, координировать взгляды команд,
разбросанных по всему миру или, может быть, действующих под
крышей всего одной организации.
• Но, на каком бы уровне они ни работали, точно определить их роль
весьма трудно, и даже несмотря на то, что в компаниях стать
архитектором считается карьерным ростом для разработчика, эта
роль попадает под огонь критики намного чаще любой другой.
• Архитектор гораздо чаще других может напрямую повлиять на
качество создаваемых систем, условия работы своих коллег и
способность организации реагировать на изменения».

73. Роль архитектора

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

74. Архитектор ПО – Архитектор города

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

75. Зонирование

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

76. Принципы

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

77. Двенадцать принципов Heroku

Это набор конструкторских принципов, сформулированных с
целью помочь в создании приложений, которые смогли бы неплохо
работать на платформе Heroku.
• I. Кодовая база
Одна кодовая база, отслеживаемая в системе контроля версий,
– множество развертываний
II. Зависимости
Явно объявляйте и изолируйте зависимости
III. Конфигурация
Сохраняйте конфигурацию в среде выполнения
IV. Сторонние службы (Backing Services)
Считайте сторонние службы (backing services) подключаемыми
ресурсами

78. Двенадцать принципов Heroku

• V. Сборка, релиз, выполнение
Строго разделяйте стадии сборки и выполнения
VI. Процессы
Запускайте приложение как один или несколько процессов не
сохраняющих внутреннее состояние (stateless)
VII. Привязка портов (port binding)
Экспортируйте сервисы через привязку портов
VIII. Параллелизм
Масштабируйте приложение с помощью процессов
IX. Одноразовость (Disposability)
Максимизируйте надежность с помощью быстрого запуска и
корректного завершения работы

79. Двенадцать принципов Heroku

X. Паритет разработки/работы приложения
Держите окружения разработки, промежуточного развёртывания
(staging) и рабочего развёртывания (production) максимально
похожими
XI. Журналирование (Logs)
Рассматривайте журнал как поток событий
XII. Задачи администрирования
Выполняйте задачи администрирования/управления с помощью
разовых процессов

80. Закон Постела

• Пример клиента, старающегося быть как можно гибче в
использовании сервиса, демонстрирует закон Постела,
известный также как принцип живучести (robustness
principle), который гласит: «Будь требователен к
тому, что отсылаешь, и либерален к тому, что
принимаешь».
• Исходной средой для проявления этой мудрости
служило взаимодействие сетевых устройств, при
котором следует ожидать всевозможных странностей.
• В контексте же взаимодействия в режиме «запрос —
ответ» он может привести к стремлению сделать
сервис приспособленным к изменениям и не требовать
никаких изменений от нас.

81. Технологические принципы

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

82. Инструкции

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

83.

84. Оркестровка и хореография

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

85. Процессы, предназначенные для создания нового клиента

86. Оркестровка

87. Хореография

88. Управление версиями микросервисов

• При семантическом управлении версиями у каждой
версии есть номер, имеющий форму
MAJOR.MINOR.PATCH
(ВАЖНЫЙ.ВТОРОСТЕПЕННЫЙ.ИСПРАВЛЕНИЕ).
• Когда происходит увеличение MAJOR-части номера, это
означает, что были внесены изменения, исключающие
обратную совместимость.
• Когда увеличивается MINOR-часть номера, это означает,
что была добавлена новая функциональная возможность,
которая не должна нарушить обратную совместимость.
• Когда меняется PATCH-часть номера, это означает, что в
существующие функциональные возможности были
внесены исправления, устраняющие какие-либо
недостатки.

89. Использование нескольких параллельных версий сервиса

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

90. Домашнее задание

• Поправить модели в Archi по замечаниям
• Провести декомпозицию своих приложений и отразить
в модели Archi
• Нарисовать сервисную модель ваших приложений с
использованием микросервисов
• Выбрать шаблоны проектирования, которые подходят
для ваших приложений и объяснить, в чем
преимущества их использования
• Сделать диаграмму развертывания в UML
• Описать бэклог закончившегося спринта и показать
планируемый на следующий спринт бэклог
• Подготовить презентацию с результатами спринта,
планами на будущий спринт и ретроспективой

91.

?
ВОПРОСЫ