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

Август 3, 2022

Главная
Информатика
Микросервисы. Лекция 11

Содержание

2. Домашнее задание Поправить модели в Archi по замечаниям Провести декомпозицию своих приложений и отразить в модели
3. Что было на прошлой лекции
4. О чем будем говорить
5. ПАТТЕРНЫ (ШАБЛОНЫ) ПРОГРАММИРОВАНИЯ
6. История В 1970-е годы архитектор Кристофер Александр составил набор шаблонов проектирования разработки ПО. В 1987 году
7. Основные шаблоны проектирования
8. Порождающие шаблоны
9. Структурные шаблоны
10. Поведенческие шаблоны
11. Поведенческие шаблоны
12. Шаблоны генерации объектов Singleton Factory Method Abstract Factory Prototype
13. Singleton (одиночка) Шаблон, гарантирующий, что в однопоточном приложении будет единственный экземпляр некоторого класса, и предоставляющий глобальную
14. Factory Method Шаблон, предоставляющий подклассам (дочерним классам) интерфейс для создания экземпляров некоторого класса. В момент создания
15. Abstract Factory Предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов.
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-Entity-Routing (VIPER).
19. Model-View-Controller (MVC) Модель-представление-контроллер схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента:
22. Model-View-View-Model Представлен в 2005 году Джоном Госсманом (John Gossman) как модификация шаблона Presentation Model. Ориентирован на
23. Model-View-View-Model
24. Model-View-Presenter Основным отличием является класс Presenter, в который выносится логика обработки событий, форматирования данных и управления
25. Сравнение шаблонов
26. Presentation-Abstraction-Control (PAC) Разделение ПО на три типа компонентов, ответственных за конкретные аспекты функциональности приложения. Компонент абстракции
27. Presentation-Abstraction-Control
28. Naked objects 1. Вся бизнес-логика должна быть инкапсулирована в бизнес-объект domain objects. Данный принцип не является
29. Hierarchical Model-View-Controller Одно из расширений архитектурного паттерна MVC, позволяющее решить некоторые проблемы масштабируемости приложений, имеющих классическую
30. Hierarchical Model-View-Controller
31. View-Interactor-Presenter-Entity-Routing (VIPER). Interactor, который содержит бизнес-логику, предусмотренную сценарием. Presenter, который содержит логику подготовки содержимого для отображения
32. МИКРОСЕРВИСНАЯ АРХИТЕКТУРА
33. Что такое микросервисная архитектура Вариант сервис-ориентированной архитектуры программного обеспечения, направленный на взаимодействие насколько это возможно небольших,
34. Что такое микросервисная архитектура «Архитектура на основе свободно сопряжённых сервисов с ограниченными контекстами. (Loosely coupled service
36. Ограниченный контекст Ограниченный контекст — это понятие явных границ вокруг какого-то бизнес-контекста. Например, в рамках электронной
37. Что такое микросервис «Это небольшие, автономные, совместно работающие сервисы» Сэм Ньюмен «микросервис является самостоятельным образованием, которое
38. Компонентное представление через сервисы Компонент — это элемент системы, который можно независимо заменить, усовершенствовать (Мартин Фаулер)
39. Компонентное представление через сервисы Взаимодействие выполняется за счёт межпроцессной связи, вызовов веб-сервисов, очереди сообщений и т.
40. Почему плох монолитный код «При создании дополнительных свойств программы разрастается и база программного кода. Со временем
42. Монолит vs микросервисы
44. Гетерогенность Гетерогенность — это возможность построить систему с использованием разных языков программирования. У подхода есть ряд
45. Микросервисы позволяют упростить использование разнообразных технологий
46. Организация человеческих ресурсов в соответствии с возможностями бизнеса Когда-то внутри команд разработчиков самоорганизовывались группы на основе
47. Организация человеческих ресурсов в соответствии с возможностями бизнеса При микросервисном подходе команды должны организовываться на основе
48. Закон Конвея Подход сочетается с законом Конвея, который гласит, что если нам нужны высокосвязные раздельные микросервисы,
49. Продукты, а не проекты Раньше был такой подход: команда создаёт какую-то функциональность, а затем передаёт её
50. Децентрализованное управление данными При традиционном подходе у приложения лишь одна база данных, и много разных компонентов
51. Децентрализованное управление данными При микросервисной архитектуре, когда каждый бизнес-компонент представляет собой микросервис, все компоненты обладают собственными
52. Архитектура с эволюционным развитием Архитектура всего приложения не должна быть статичной, необходима возможность её простого развития
53. Взаимодействие между микросервисами «Обмен данными между самими сервисами ведется через сетевые вызовы, чтобы упрочить обособленность сервисов
54. «Нужно подумать и о самой сети» «Когда речь идет о распределенном вычислении, самым распространенным первым заблуждением
55. Размер микросервисов «Когда решается вопрос о достаточности уменьшения объема кода, я предпочитаю размышлять в следующем ключе:
56. Требования к микросервисам По мнению Джеймса Льюиса, микросервисы должны: быстро масштабироваться; дёшево заменяться; быть устойчивыми к
57. Насколько велик микросервис? Есть разные мнения о размерах микросервисов. Мартин Фаулер описывает случаи, когда соотношение количества
58. Микросервисная архитектура Подход к созданию приложения, подразумевающий отказ от единой, монолитной структуры. Вместо того чтобы исполнять
59. Свойства микросервисной архитектуры модули можно легко заменить в любое время: акцент на простоту, независимость развёртывания и
60. Архитектура должна: «делать продукт гибче и устойчивее к сбоям облегчать понимание, отладку и изменение кода помогать
61. Философия микросервисов Философия микросервисов фактически копирует философию Unix, согласно которой каждая программа должна «делать что-то одно,
62. Способ автоматизировать хаос Одна из причин использования микросервисов заключается в том, что мы хотим иметь возможность
63. Эрик Эванс «Реальность разработки ПО такова, что вначале мы никогда не имеем полного понимания задачи. Наше
64. Мартин Фаулер говорит, что необходимо иметь возможность: Быстро вводить в эксплуатацию: быстро развёртывать новые машины для
65. Фред Джордж утверждает то же самое: есть огромная потребность ускорить работу, чтобы выдержать конкуренцию! Он приводит
66. Среды выполнения микросервисов Системы управления контейнеризованными приложениями (такие как Kubernetes и её надстройки OpenShift и CloudFoundry,
67. Docker Программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы;
69. Усложнившийся мониторинг Мониторинг крайне важен (Ребекка Парсонс), нам необходимо сразу узнавать о том, что сервер упал,
70. Сильная devops-культура Нужны devops’ы для мониторинга и управления, при этом между ними и разработчиками должны быть
71. Опасности Нужно управлять гибкостью технологии Не исключено, что обилие технологий и библиотек выйдет из-под контроля. Необходимо
72. Роль архитектора «У архитекторов весьма важная задача. Они отвечают за координацию технического представления, помогающего нам дать
73. Роль архитектора «Требования у нас изменяются куда быстрее, чем у тех, кто проектирует и строит здания,
74. Архитектор ПО – Архитектор города Архитектор здания «Смысл профессии в том, что он вычерчивает подробные планы,
75. Зонирование «Зоны - это границы сервисов или, возможно, собранных в крупные модули групп сервисов. В качестве
76. Принципы Принципы являются правилами, выведенными с целью выверить все, что делается с некой более крупной целью,
77. Двенадцать принципов Heroku Это набор конструкторских принципов, сформулированных с целью помочь в создании приложений, которые смогли
78. Двенадцать принципов Heroku V. Сборка, релиз, выполнение Строго разделяйте стадии сборки и выполнения VI. Процессы Запускайте
79. Двенадцать принципов Heroku X. Паритет разработки/работы приложения Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания
80. Закон Постела Пример клиента, старающегося быть как можно гибче в использовании сервиса, демонстрирует закон Постела, известный
81. Технологические принципы «В пределах отдельно взятого сервиса можно будет вполне смириться с тем, что команда, ответственная
82. Инструкции Инструкции описывают способы соблюдения принципов. Это набор подробных практических предписаний для выполнения задач. Зачастую они
84. Оркестровка и хореография При использовании оркестрового принципа за основу берется центральный интеллект, направляющий процессы и управляющий
85. Процессы, предназначенные для создания нового клиента
86. Оркестровка
87. Хореография
88. Управление версиями микросервисов При семантическом управлении версиями у каждой версии есть номер, имеющий форму MAJOR.MINOR.PATCH (ВАЖНЫЙ.ВТОРОСТЕПЕННЫЙ.ИСПРАВЛЕНИЕ).
89. Использование нескольких параллельных версий сервиса Прежние потребители направляют свой трафик к прежней версии, а новые потребители
90. Домашнее задание Поправить модели в Archi по замечаниям Провести декомпозицию своих приложений и отразить в модели
92. Скачать презентацию

Слайд 2

Домашнее задание
Поправить модели в Archi по замечаниям
Провести декомпозицию своих приложений и

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

Слайд 3

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

Слайд 4

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

Слайд 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

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

Слайд 8

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

Слайд 9

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

Слайд 10

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

Слайд 11

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

Слайд 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-Entity-Routing (VIPER).

Слайд 19

Model-View-Controller (MVC) Модель-представление-контроллер
схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных

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

Слайд 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-Abstraction-Control (PAC)
Разделение ПО на три типа компонентов, ответственных за конкретные аспекты

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

Слайд 27

Presentation-Abstraction-Control

Слайд 28

Naked objects
1. Вся бизнес-логика должна быть инкапсулирована в бизнес-объект domain objects. Данный принцип не является

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

Слайд 29

Hierarchical Model-View-Controller
Одно из расширений архитектурного паттерна MVC, позволяющее решить некоторые проблемы масштабируемости приложений,

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

Слайд 30

Hierarchical Model-View-Controller

Слайд 31

View-Interactor-Presenter-Entity-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 микросервисы

Слайд 43

Слайд 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
Описать бэклог закончившегося спринта и показать планируемый на следующий спринт бэклог
Подготовить презентацию с результатами спринта, планами на будущий спринт и ретроспективой

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

Содержание

Домашнее заданиеПоправить модели в Archi по замечаниямПровести декомпозицию своих приложений и

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

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

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

ИсторияВ 1970-е годы архитектор Кристофер Александр составил набор шаблонов проектирования разработки ПО. В 1987 году Кент Бэк (Kent Beck)

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

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

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

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

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

Шаблоны генерации объектовSingletonFactory MethodAbstract FactoryPrototype

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

Factory Method Шаблон, предоставляющий подклассам (дочерним классам) интерфейс для создания экземпляров некоторого класса. В момент

Abstract FactoryПредоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не

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

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

Model-View-Controller (MVC) Модель-представление-контроллерсхема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных

Model-View-View-ModelПредставлен в 2005 году Джоном Госсманом (John Gossman) как модификация шаблона

Model-View-View-Model

Model-View-PresenterОсновным отличием является класс Presenter, в который выносится логика обработки событий,

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

Presentation-Abstraction-Control (PAC)Разделение ПО на три типа компонентов, ответственных за конкретные аспекты

Presentation-Abstraction-Control

Naked objects1. Вся бизнес-логика должна быть инкапсулирована в бизнес-объект domain objects. Данный принцип не является

Hierarchical Model-View-ControllerОдно из расширений архитектурного паттерна MVC, позволяющее решить некоторые проблемы масштабируемости приложений,

Hierarchical Model-View-Controller

View-Interactor-Presenter-Entity-Routing (VIPER). Interactor, который содержит бизнес-логику, предусмотренную сценарием.Presenter, который содержит логику подготовки содержимого

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

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

Что такое микросервисная архитектура«Архитектура на основе свободно сопряжённых сервисов с ограниченными

Ограниченный контекстОграниченный контекст — это понятие явных границ вокруг какого-то бизнес-контекста.

Что такое микросервис«Это небольшие, автономные, совместно работающие сервисы» Сэм Ньюмен«микросервис является

Компонентное представление через сервисыКомпонент — это элемент системы, который можно независимо заменить,

Компонентное представление через сервисыВзаимодействие выполняется за счёт межпроцессной связи, вызовов веб-сервисов,

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

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

ГетерогенностьГетерогенность — это возможность построить систему с использованием разных языков программирования.

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

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

Организация человеческих ресурсов в соответствии с возможностями бизнесаПри микросервисном подходе команды

Закон КонвеяПодход сочетается с законом Конвея, который гласит, что если нам нужны

Продукты, а не проектыРаньше был такой подход: команда создаёт какую-то функциональность,

Децентрализованное управление даннымиПри традиционном подходе у приложения лишь одна база данных,

Децентрализованное управление даннымиПри микросервисной архитектуре, когда каждый бизнес-компонент представляет собой микросервис,

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

Взаимодействие между микросервисами«Обмен данными между самими сервисами ведется через сетевые вызовы,

«Нужно подумать и о самой сети»«Когда речь идет о распределенном вычислении,

Размер микросервисов«Когда решается вопрос о достаточности уменьшения объема кода, я предпочитаю

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

Насколько велик микросервис?Есть разные мнения о размерах микросервисов. Мартин Фаулер описывает случаи,

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

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

Архитектура должна:«делать продукт гибче и устойчивее к сбоямоблегчать понимание, отладку и

Философия микросервисовФилософия микросервисов фактически копирует философию Unix, согласно которой каждая программа должна

Способ автоматизировать хаосОдна из причин использования микросервисов заключается в том, что

Эрик Эванс«Реальность разработки ПО такова, что вначале мы никогда не имеем

Мартин Фаулер говорит, что необходимо иметь возможность:Быстро вводить в эксплуатацию: быстро развёртывать

Фред Джордж утверждает то же самое: есть огромная потребность ускорить работу,

Среды выполнения микросервисовСистемы управления контейнеризованными приложениями (такие как Kubernetes и её надстройки OpenShift и CloudFoundry, Docker Swarm, Apache

DockerПрограммное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации

Усложнившийся мониторингМониторинг крайне важен (Ребекка Парсонс), нам необходимо сразу узнавать о

Сильная devops-культураНужны devops’ы для мониторинга и управления, при этом между ними

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

Роль архитектора«У архитекторов весьма важная задача. Они отвечают за координацию технического

Роль архитектора«Требования у нас изменяются куда быстрее, чем у тех, кто

Архитектор ПО – Архитектор городаАрхитектор здания«Смысл профессии в том, что он

Зонирование«Зоны - это границы сервисов или, возможно, собранных в крупные модули

Домашнее задание
Поправить модели в Archi по замечаниям
Провести декомпозицию своих приложений и

История
В 1970-е годы архитектор Кристофер Александр составил набор шаблонов проектирования разработки ПО.
В 1987 году Кент Бэк (Kent Beck)

Шаблоны генерации объектов
Singleton
Factory Method
Abstract Factory
Prototype

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

Factory Method
Шаблон, предоставляющий подклассам (дочерним классам) интерфейс для создания экземпляров некоторого класса.
В момент

Abstract Factory
Предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не

Шаблоны программирования гибких объектов
Composite
Decorator
Facade

Шаблоны выполнения задач
Interpreter
Strategy
Observer
Visitor
Command

Model-View-Controller (MVC) Модель-представление-контроллер
схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных

Model-View-View-Model
Представлен в 2005 году Джоном Госсманом (John Gossman) как модификация шаблона

Model-View-Presenter
Основным отличием является класс Presenter, в который выносится логика обработки событий,

Presentation-Abstraction-Control (PAC)
Разделение ПО на три типа компонентов, ответственных за конкретные аспекты

Naked objects
1. Вся бизнес-логика должна быть инкапсулирована в бизнес-объект domain objects. Данный принцип не является

Hierarchical Model-View-Controller
Одно из расширений архитектурного паттерна MVC, позволяющее решить некоторые проблемы масштабируемости приложений,

View-Interactor-Presenter-Entity-Routing (VIPER).
Interactor, который содержит бизнес-логику, предусмотренную сценарием.
Presenter, который содержит логику подготовки содержимого

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

Что такое микросервисная архитектура
«Архитектура на основе свободно сопряжённых сервисов с ограниченными

Ограниченный контекст
Ограниченный контекст — это понятие явных границ вокруг какого-то бизнес-контекста.

Что такое микросервис
«Это небольшие, автономные, совместно работающие сервисы» Сэм Ньюмен
«микросервис является

Компонентное представление через сервисы
Компонент — это элемент системы, который можно независимо заменить,

Компонентное представление через сервисы
Взаимодействие выполняется за счёт межпроцессной связи, вызовов веб-сервисов,

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

Гетерогенность
Гетерогенность — это возможность построить систему с использованием разных языков программирования.

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

Организация человеческих ресурсов в соответствии с возможностями бизнеса
При микросервисном подходе команды

Закон Конвея
Подход сочетается с законом Конвея, который гласит, что если нам нужны

Продукты, а не проекты
Раньше был такой подход: команда создаёт какую-то функциональность,

Децентрализованное управление данными
При традиционном подходе у приложения лишь одна база данных,

Децентрализованное управление данными
При микросервисной архитектуре, когда каждый бизнес-компонент представляет собой микросервис,

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

Взаимодействие между микросервисами
«Обмен данными между самими сервисами ведется через сетевые вызовы,

«Нужно подумать и о самой сети»
«Когда речь идет о распределенном вычислении,

Размер микросервисов
«Когда решается вопрос о достаточности уменьшения объема кода, я предпочитаю

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

Насколько велик микросервис?
Есть разные мнения о размерах микросервисов. Мартин Фаулер описывает случаи,

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

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

Архитектура должна:
«делать продукт гибче и устойчивее к сбоям
облегчать понимание, отладку и

Философия микросервисов
Философия микросервисов фактически копирует философию Unix, согласно которой каждая программа должна

Способ автоматизировать хаос
Одна из причин использования микросервисов заключается в том, что

Эрик Эванс
«Реальность разработки ПО такова, что вначале мы никогда не имеем

Мартин Фаулер говорит, что необходимо иметь возможность:
Быстро вводить в эксплуатацию: быстро развёртывать

Среды выполнения микросервисов
Системы управления контейнеризованными приложениями (такие как Kubernetes и её надстройки OpenShift и CloudFoundry, Docker Swarm, Apache

Docker
Программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации

Усложнившийся мониторинг
Мониторинг крайне важен (Ребекка Парсонс), нам необходимо сразу узнавать о

Сильная devops-культура
Нужны devops’ы для мониторинга и управления, при этом между ними

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

Роль архитектора
«У архитекторов весьма важная задача. Они отвечают за координацию технического

Роль архитектора
«Требования у нас изменяются куда быстрее, чем у тех, кто

Архитектор ПО – Архитектор города
Архитектор здания
«Смысл профессии в том, что он

Зонирование
«Зоны - это границы сервисов или, возможно, собранных в крупные модули