Академический Документы
Профессиональный Документы
Культура Документы
ОРИЕНТИРОВАННАЯ
АРХИТЕКТУРА (SOA)
От знакомства до применения в качестве компонентов
корпоративных систем
Введение в SOA
Каким образом связаны информационные системы внутри предприятия?
Обычный путь для российской компании средних размеров — начинать
внедрение информационных технологий с автоматизации работы бухгалтерии,
отдела кадров и документооборота.
Другие системы также обмениваются данными. И здесь возникает один из
самых трудных вопросов для руководителя — поиск оптимальной степени
интеграции. Большой соблазн иметь абсолютно интегрированную систему, но
такая интеграция чрезвычайно трудоемка, стоит немалых денег. И лучше даже
не говорить, во что обходится сопровождение такой системы. Поэтому нужно
взвесить потребности в интегрированных системах, поставив их на чашу весов
против трудностей и дороговизны крупномасштабной ИС. Не существует
стандартного уровня интеграции или централизации — каждый руководитель
должен самостоятельно решать эту непростую проблему.
Традиционная интеграция
• CSV
• JSON
Бухгалтерия Склад Кадровый учет
• XML
• Web-service JSON
• Web-service WSDL
• COM/DCOM/ActiveX
• CORBA IDL
• WebSockets
Недостатки
• Разные веб-сервисы тяжело интегрировать из-за различий в языках передачи
сообщений. Например, два веб-сервиса, использующих разные JSON-представления
одной и той же концепции.
Интеграция сервисов
Сервис-ориентированная
архитектура
Обязательным условием построения и внедрения архитектуры системы на основе SOA является
использование единой инфраструктуры описания сервисов (репозитория сервисов), разрешенных
протоколов доступа и обмена сообщениями, форматов сообщений.
Упомянутая инфраструктура образует так называемую интеграционную шину (Enterprise Service
Bus — ESB), являющуюся одним из центральных компонентов системы. Она устанавливает единые
правила публикации сервисов, управления и информационного взаимодействия между
приложениями различных систем, входящих в состав интегрированной системы. Это упрощает
управление приложениями и их поддержку, а также снижает риск фрагментации приложений и
процессов.
Сервис-ориентированная
архитектура
Каждая из служб взаимодействует не с остальными службами напрямую, а только с шиной. ИШ
образует однородную среду информационного взаимодействия и является фундаментом для
интеграции информационных систем, функционирующих в различных учреждениях и ведомствах. ИШ
определяет кем, где, каким образом и в каком порядке должны обрабатываться запросы.
Если сервис (информационный ресурс) не поддерживает эти правила, необходимо создавать
промежуточный модуль-адаптер, который предоставляет системе необходимый интерфейс и
обеспечивает взаимодействие с ресурсом.
Изменение и совершенствование бизнес-процессов в компаниях занимает годы. По усредненным
данным Gartner Group: 80 % ИТ-бюджета — это расходы на сопровождение систем, из них 35 % —
затраты на интеграцию приложений, 60 % стоимости внедрения корпоративной ИС составляют
расходы на интеграцию, 50 % ИТ-бюджета потрачено на обеспечение интерфейсов систем.
Использование SOA архитектуры позволяет эффективно организовать оперативную адаптацию ИТ-
систем под требования бизнеса, что дает стратегическое преимущество компании, заключающееся в:
• повышение скорости адаптации бизнеса к быстроменяющимся требованиям рынка (Agility);
• расширении взаимодействия гетерогенных корпоративных информационных систем при
сохранение сделанных в них инвестиций;
• сокращение расходов на ИТ-системы на основе повторного использования их функциональных
компонентов;
• повышение производительности труда клиентов, партнеров и сотрудников (на основе архитектуры
Web 2.0).
Сервисная шина предприятия (ESB)
ESB возникла во времена, когда в компаниях были отдельные
приложения. Например, одно для работы с финансами, другое
для учёта персонала, третье для управления складом, и т. д., и их
нужно было как-то связывать друг с другом, как-то
интегрировать. Но все эти приложения создавались без учёта
интеграции, не было стандартного языка для взаимодействия
приложений (как и сегодня). Поэтому разработчики приложений
предусматривали конечные точки для отправки и приёма данных
в определённом формате. Компании-клиенты потом
интегрировали приложения, налаживая между ними каналы
связи и преобразуя сообщения с одного языка приложения в
другой.
Очередь сообщений может упростить взаимодействие
приложений, но она не способна решить проблему разных
форматов языков. Впрочем, была сделана попытка превратить
очередь сообщений из простого канала связи в посредника,
доставляющего сообщения и преобразующего их в нужные
форматы/языки. ESB стал следующей ступенью в естественной
эволюции простой очереди сообщений.
Сервисная шина предприятия (ESB)
В этой архитектуре используется модульное приложение (composite application), обычно
ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то
операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами,
впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы
ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким
сервисом хотят связаться и где находится сервисная шина.
Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая
преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда
запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и
все остальные системы. То есть ESB — ключевой посредник, очень сложный компонент системы.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным
компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных
брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process
Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать
интегрированная архитектура (federated design): система разделена на бизнес-домены со своими
ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки
отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Сервисная шина предприятия (ESB)
Главные обязанности ESB:
• Отслеживать и маршрутизировать обмен сообщениями между
сервисами
• Преобразовывать сообщения между общающимися сервисными
компонентами
• Управлять развёртыванием и версионированием сервисов
• Управлять использованием избыточных сервисов
• Предоставлять стандартные сервисы обработки событий,
преобразования и сопоставления данных, сервисы очередей
сообщений и событий, сервисы обеспечения безопасности или
обработки исключений, сервисы преобразования протоколов и
обеспечения необходимого качества связи
Сервисная шина предприятия (ESB)
Сервисная шина предприятия (ESB)
Достоинства
• Независимость набора технологий, развёртывания и масштабируемости сервисов
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80)
• Оптимизированный обмен сообщениями
• Стабильная спецификация обмена сообщениями
• Изолированность контекстов домена (Domain contexts)
• Простота подключения и отключения сервисов
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему
• Единая точка для управления версионированием и преобразованием
Недостатки
• Ниже скорость связи, особенно между уже совместимыми сервисами
• Централизованная логика:
Единая точка отказа, способная обрушить системы связи всей компании
Большая сложность конфигурирования и поддержки
Со временем можно прийти к хранению в ESB бизнес-правил
Шина так сложна, что для её управления вам потребуется целая команда
Высокая зависимость сервисов от ESB
Микросервисы
Главное различие микросервисов и шины в том, что ESB была создана в контексте
интеграции отдельных приложений, чтобы получилось единое корпоративное
распределённое приложение. А микросервисная архитектура создавалась в
контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля
создают собственные облачные приложения.
То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат»,
и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью
контролируем приложения (при этом в системе могут использоваться и сторонние
веб-сервисы).
Характер построения/проектирования микросервисов не требует глубокой
интеграции. Микросервисы должны соответствовать бизнес-концепции,
ограниченному контексту. Они должны сохранять своё состояние, быть
независимыми от других микросервисов, и потому они меньше нуждаются в
интеграции. То есть низкая взаимозависимость и высокая связность привели к
замечательному побочному эффекту — уменьшению потребности в интеграции.
Микросервисы
[Микросервисы — это] маленькие автономные сервисы, работающие вместе и
спроектированные вокруг бизнес-домена. — Sam Newman 2015, Principles Of
Microservices
Главным недостатком архитектуры ESB было очень сложное
централизованное приложение, от которого зависели все остальные
приложения. А в микросервисной архитектуре это приложение почти целиком
убрано.
Ещё остались элементы, пронизывающие всю экосистему микросервисов. Но у
них гораздо меньше задач по сравнению с ESB. К примеру, для асинхронной
связи между микросервисами до сих пор применяется очередь сообщений, но
это лишь канал для передачи сообщений, не более того. Или можно вспомнить
шлюз экосистемы микросервисов, через который проходит весь внешний
обмен данными.
Микросервисы
Сэм Ньюман, автор Building Microservices, выделяет восемь принципов микросервисной архитектуры:
• Проектирование сервисов вокруг бизнес-доменов. Это может дать нам стабильные интерфейсы,
высокосвязные и мало зависящие друг от друга модули кода, а также чётко определённые
разграниченные контексты.
• Культура автоматизации. Это даст нам гораздо больше свободы, мы сможем развернуть больше
модулей.
• Скрытие подробностей реализации. Это позволяет сервисам развиваться независимо друг от друга.
• Полная децентрализация. Децентрализуйте принятие решений и архитектурные концепции,
предоставьте командам автономность, чтобы компания сама превратилась в сложную адаптивную
систему, способную быстро приспосабливаться к переменам.
• Независимое развёртывание. Можно развёртывать новую версию сервиса, не меняя ничего другого.
• Сначала потребитель. Сервис должен быть простым в использовании, в том числе другими
сервисами.
• Изолирование сбоев. Если один сервис падает, другие продолжают работать, это делает всю систему
устойчивой к сбоям.
• Удобство мониторинга. В системе много компонентов, поэтому трудно уследить за всем, что в ней
происходит. Нам нужны сложные инструменты мониторинга, позволяющие заглянуть в каждый
уголок системы и отследить любую цепочку событий.
Микросервисы
Сообщество предпочитает другой подход: умные конечные точки
и глупые каналы. Микросервисы, из которых собираются
приложения, должны как можно меньше зависеть друг от друга и
при этом быть очень тесно связанными — они содержат
собственную доменную логику и работают скорее как фильтры с
точки зрения классического Unix: получают запросы, применяют
логику и генерируют ответы. Они оркестрируются с помощью
простых REST-подобных протоколов, а не сложных протоколов
вроде WS-Choreography или BPEL либо какого-то
централизованного инструмента.
— Martin Fowler 2014, Microservices
Микросервисы
Достоинства
• Независимость набора технологий, развёртывания и масштабируемости сервисов.
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов домена (Domain contexts).
• Простота подключения и отключения сервисов.
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
• Синхронность обмена сообщениями помогает управлять производительностью системы.
• Полностью независимые и автономные сервисы.
• Бизнес-логика хранится только в сервисах.
• Позволяют компании превратиться в сложную адаптивную систему, состоящую из нескольких маленьких автономных
частей/команд, способную быстро адаптироваться к переменам.
Недостатки
• Высокая сложность эксплуатации:
Нужно много вложить в сильную DevOps-культуру.
Использование многочисленных технологий и библиотек может выйти из-под контроля.
Нужно аккуратно управлять изменениями входных/выходных API, потому что эти интерфейсы будут использовать многие приложения.
Использование «согласованности в конечном счёте» (eventual consistency) может привести к серьёзным последствиям, которые нужно
учитывать при разработке приложения, от бэкенда до UX.
Тестирование усложняется, потому что изменения в интерфейсе могут непредсказуемо влиять на другие сервисы.
Жизненный цикл сервиса
Жизненный цикл сервиса начинается
в момент его ввода в эксплуатацию
(определения) и заканчивается в
момент его вывода из эксплуатации
или переориентирования. Жизненный
цикл сервиса предполагает
управление сервисом на трех этапах:
этапе формирования требований и
анализа, этапе проектирования и
разработки и этапе эксплуатации в
ИТ-среде.
Жизненный цикл сервиса
Управление жизненным циклом
сервиса
Управление — это процессы, средства и организационная
структура, наличие которых необходимо для успешной
реализации SOA. Эффективное повторное использование сервиса
может быть достигнуто только в случае следования стандартам и
процедурам в течение всего жизненного цикла этого сервиса.
Ввиду совместного использования сервисов приложениями, они
должны проектироваться, разрабатываться и развертываться
сервисы с особой тщательностью, т.к. только так можно избежать
негативного воздействия на уже имеющихся пользователей.
Управление жизненным циклом
сервиса
При использовании сервисов различными организационными единицами
возникает конфликт приоритетов. Эффективное управление позволяет
максимально обеспечить возможность повторного использования сервисов
при минимальных потерях.
Среди основных задач управления SOA можно выделить следующие:
• Публикация стандартов и руководств по SOA
• Определение и реализация процессов, способствующих использованию и
повторному использованию сервисов в рамках проекта
• Контроль всех находящихся в разделяемом доступе сервисов предприятия
или подразделения
• Поощрение создания стандартов и руководств в рамках организации
• Информирование о результатах SOA в рамках организации
• Управление сервисами укрепляет полный жизненный цикл сервисов
Цикл жизни SOA и различные его
этапы
• Этап моделирования
Этапмоделирования включает в себя анализ деятельности и сбор требований, за
которыми следует моделирование и оптимизация бизнес-процесса. Модель
помогает сформировать общее понимание процесса, его целей и результатов. Она
также гарантирует соответствие проекта бизнес-требованиям и обеспечивает
исходные критерии для последующего измерения производительности.
• Этап сборки
На этом этапе существующие активы (например, ERP-система, финансовые системы
и т.д.), которые будут использоваться в моделируемых процессах, инкапсулируются
в сервисы, тогда как отсутствующие нужные функциональности реализуются и
тестируются. Когда все сервисы становятся доступными, можно скоординировать
их для реализации бизнес-процесса.
Цикл жизни SOA и различные его
этапы
• Этап развертывания
На этапе развертывания среда времени исполнения настраивается на необходимый
уровень качества сервиса и на удовлетворение требований безопасности. Среда
может масштабироваться и оптимизироваться для повышения надежности работы
критичных процессов и для обеспечения гибкости, позволяющей динамически
обновлять ее в случае каких-либо изменений.
• Этап управления
На этом этапе выполняется мониторинг ряда аспектов, таких как доступность
сервисов, время реакции, контроль версий сервисов. Важную роль на этом этапе
играет мониторинг ключевых показателей производительности (key performance
indicators - KPI) процесса. Он помогает предотвратить или изолировать и
диагностировать возникающие проблемы в реальном времени, а также обеспечить
обратную связь с целью улучшения производительности бизнес-процесса и
устранения узких мест. Эта обратная связь передается на этап моделирования
(первый этап) с целью усовершенствования процесса.
Система межведомственного
электронного взаимодействия
Система межведомственного электронного взаимодействия (СМЭВ) —
информационная система, которая позволяет федеральным, региональным и местным
органам власти, кредитным организациям (банкам), внебюджетным фондам, и прочим
участникам СМЭВ обмениваться данными, необходимыми для оказания
государственных услуг гражданам и организациям, в электронном виде.
Создана в соответствии с Федеральным законом Российской Федерации от 27 июля
2010 года № 210-ФЗ «Об организации предоставления государственных и
муниципальных услуг».
Положительный эффект
• Граждане избавлены от необходимости собирать документы в различных
государственных органах.
• Теперь гражданин, обращающийся за государственной услугой, должен предоставить
только документы личного хранения (паспорт, свидетельство о рождении и т. д.). Все
остальные справки собирает само ведомство.
• Государственный орган не вправе требовать от граждан или организаций,
обратившихся за госуслугой, сведения, которые уже имеются в распоряжении
другого государственного органа.
Компонентно-ориентированное
программирование
Компонентно-ориентированный подход может применяться во многих языках
программирования с помощью стандартных конструкций (таких как: классы,
интерфейсы, пакеты, модули).
Существуют языки программирования, реализующие на конструктивном уровне
компонентно-ориентированное программирование:
«Оберон» (ограниченно);
«Компонентный Паскаль».
В рамках языка «Java» — компонентно-ориентированное программирование
реализуется посредством компонентов, называемых «JavaBeans», поддержанных в
одной из ранних спецификаций языка;
В платформе «.NET» — реализован компонентно-ориентированный подход,
обеспечивающий создание и повторное использование компонентов для любого языка
программирования, поддерживаемого платформой.
Классический подход к построению
высоконагруженного веб-сервиса
1. Много серверов, поделённых на роли.
2. Часть серверов (роль Frontend) предназначена для отдачи статических ресурсов
(изображений, CSS, JS-файлов) и “распределения” фронта входящего траффика по
нижестоящим узлам. Основной софт, как правило, Nginx.
3. Нижестоящие узлы (роль Backend) занимаются динамическими вычислениями.
Проще говоря, это может быть типичная связка Apache+PHP.
4. Ещё одна группа серверов предназначена для хранения данных. Это MySQL,
Memcache, Redis и так далее.
5. Сам код веб-сервиса (в данном примере – PHP-код) одинаково скопирован на все
узлы, где есть Apache+PHP, и одинаково обрабатывает те запросы, которые
“пришлись” на тот или иной узел.
6. Базы данных “размазываются” по своей группе серверов, и нагрузка на них
балансируется аналогичным образом.
Недостатки классического подхода
Основной тренд – усложнение. С течением времени жизни проекта
“классическая” схема всё более и более усложняется. С добавлением
каждого нового сервера нужно вводить его в схему распределения
траффика. Безусловно, в крупных проектах введение сервера в роль –
“однокнопочное” действие, но тем не менее – это рост инфраструктуры,
которую нужно поддерживать. И тем более – в случае, когда текущих
мощностей под БД уже не хватает, и нужно “по живому” (без остановки
сервиса) переносить или разносить базу данных на новые сервера.
Но самая главная проблема – наращивание кластера распределения
траффика никак не приводит к снижению сложности программного
кода. Вы можете безупречно построить кластер, но код останется таким
же, как был.
Недостатки классического подхода
Деплой не атомарен. Говоря понятными словами, выкладывание новой версии
проекта на боевые сервера занимает какое-то время. Нужно физически загрузить
файлы на N-дцать машин, произвести изменения в БД, сбросить кэши (много
разных кэшей), и единомоментно на всех серверах закончить обработку запросов
“старым кодом” и начать обработку “новым кодом”. Иначе может возникнуть
множество мелких конфликтов, когда часть запроса пользователя обработана по-
старому, часть по-новому, какая-то часть легла в базу данных по “старой схеме”,
часть “по новой”, и так далее.
Поэтому, в идеале все хотят приостанавливать работу сервиса на время
обновления (несколько секунд или десятков секунд), и затем включать снова. В
реальности, при потоке хотя бы в 1000 запросов в секунду, никто так не делает,
предпочитая регулярно исправлять мелкие коллизии “руками”, либо покрывая
защитным программированием, поддерживающим обратную совместимость “до
седьмого колена”. О том, насколько регулярная поддержка обратной
совместимости усложняет жизнь программистам (и удорожает проект в целом) –
сообразительный читатель может задуматься сам.
Недостатки классического подхода
Используется HTTP. Протокол HTTP очевидно устарел морально и
технически, и если вы следите (например) за мобильной
разработкой – вы знаете, что он повсеместно вытесняется более
легковесными протоколами. Но основной недостаток в другом:
протокол HTTP “в браузере” требует завершения петли – требует
ответа в ограниченное время. Это обязывает сервис вычислить и
подготовить ответ строго в тот небольшой таймаут, который ему
позволяет браузер. Если сервис в данный момент перегружен –
запрос будет потерян безвозвратно.
Поэтому в “типичных веб-проектах” прибегают к различным
хитростям типа Long polling или иной форме периодических
запросов, что не только усложняет архитектуру, но и перегружает
сервис излишним “дёрганием впустую”.
Недостатки классического подхода
Инициализация скрипта на каждый запрос. Это следствие
использования HTTP и скриптовых языков вроде PHP, которые по давно
устоявшейся традиции запускаются заново в ответ на каждый запрос.
Да-да, в ответ на каждый из 1000 запросов в секунду PHP-скрипт будет
стартовать заново, инициализовать все переменные заново,
устанавливать соединения с БД заново. На практике бывает так, что на
обработку запроса нужно 0.005 секунды, а скрипт инициализируется
порядка 0.05 секунды – в десять раз дольше!
Иными словами, 90% времени ваши сервера заняты не обработкой
запросов клиентов, а бесполезной инициализацией скриптов.
Попробуйте перевести это в деньги. Поэтому придумана масса
обходных путей вроде OPcode-кэширования, персистентных
коннекшенов к БД, локальных кэшей вроде Memcache или Redis,
предназначенных для того чтобы погасить этот неприятный эффект.
Недостатки классического подхода
Монолитное приложение. Как бы вы ни делили приложение на модули, как
бы ни старались разносить код по сложной структуре каталогов, какой бы
lazy autoloading вы ни использовали – критерий один: если для выкладки
хотя бы одного изменения вам нужно выложить приложение целиком, – у
вас монолитное приложение. Иного не дано.
Недостатки монолитных приложений массово описаны в литературе.
Кратко можно упомянуть один из главных: если вы хотите, чтобы даже
самая мелкая фича была на продакшене не позднее чем через час, вам
нужно уместить всю производственную цепочку в один час. Постановка
задачи, реализация, проверка обратной совместимости, написание тестов,
написание документации, прогон через отдел ручного тестирования,
исправление ошибок – всё в течение часа.
Потому что если вы выкладываете приложение целиком ровно в 00 минут
каждого часа, то к концу каждого часа вы должны приводить всё
приложение в стабильное состояние.
Недостатки классического подхода
Веб-интерфейс отрисовывается бэкэндом. В типичном случае, внешний
вид (и соответственно HTML-код) страниц проекта отрисовывается на
стороне Backend-а, как правило, в ответ на каждый запрос. Это избыточная,
ничем не оправданная затрата ресурсов и денег.
Политическое разделение отделов. Отдел системных администраторов
отвечает за то, чтобы входящий фронт траффика был “размазан” по куче
серверов, на которых крутится PHP-код. Отдел программистов отвечает за
PHP-код. Если PHP-код не успел обработать какой-то конкретный запрос,
то за это отвечает непонятно кто – либо админ, который “пустил” слишком
много траффика на сервак и перегрузил его, либо программист, который
написал неоптимальный скрипт. Если начинает тормозить база данных – то
тоже непонятно кто остаётся крайним: админ, который не сообразил
вовремя её реплицировать или программист, который тоже мог бы
сообразить.
Первые шаги к идеалу
1. Спроектируйте всю систему как SOA (сервисно-ориентированную
архитектуру) с ESB (шиной обмена сообщениями предприятия),
отказавшись от монолитного подхода, чтобы каждую независимую
часть бизнес-логики обрабатывал отдельный “сервис”, а между собой
они бы общались по независимой шине обмена.
2. Откажитесь от синхронности. Например, в синхронной схеме “запрос –
обработка – ответ” это одна петля HTTP, которая не имеет жёсткого
контроля завершённости и легко может прерваться. В асинхронной –
три отдельных процесса: запрос (отправлен и подтверждён), обработка
(с повтором в случае сбоя), доставка ответа (с гарантией).
3. Поделите проект на два приложения – Frontend и Backend. В случае веб-
сервиса, фронтенд – это (как правило) JavaScript-приложение. Суть в
том, чтобы приложения работали асинхронно и развязанно
относительно друг друга, обмениваясь сообщениями по двустороннему
протоколу связи.
Первые шаги к идеалу
4. Откажитесь от HTTP в пользу WebSocket. Протокол WebSocket обладает
фантастическим быстродействием по сравнению с HTTP, не имеет никаких “петель
с таймаутами”, и позволяет передавать в обе стороны любые данные (в том числе
бинарные).
5. Обеспечьте “хранение” протекающих запросов. Как только запрос принят от
клиента, скажите ему “Confirm” и сохраните этот запрос. Как только бэкэнд
освободится от предыдущего цикла обработки – передайте запрос ему. Пока
запрос “идёт” между узлами бэкэнда, сохраняйте его с момента когда он “вошёл” в
узел” и фиксируйте его как только он “вышел” из узла. Таким образом, если какой-
то узел “упадёт”, система не потеряет запрос и тут же направит его снова в
обработку. По окончанию обработки направьте результат клиенту, и храните его до
тех пор, пока клиент не скажет “Confirm”.
6. Обеспечьте параллельность вычислений для тех операций, которые могут
выполняться параллельно с точки зрения бизнес-логики, и последовательность для
тех, которые должны выполняться строго последовательно. Этот пункт написан не с
претензией на “Капитана Очевидность”, а чтобы показать, что не любой бизнес-
процесс можно “вслепую положить” на многопоточный код.
Первые шаги к идеалу
4. Откажитесь от HTTP в пользу WebSocket. Протокол WebSocket обладает
фантастическим быстродействием по сравнению с HTTP, не имеет никаких “петель
с таймаутами”, и позволяет передавать в обе стороны любые данные (в том числе
бинарные).
5. Обеспечьте “хранение” протекающих запросов. Как только запрос принят от
клиента, скажите ему “Confirm” и сохраните этот запрос. Как только бэкэнд
освободится от предыдущего цикла обработки – передайте запрос ему. Пока
запрос “идёт” между узлами бэкэнда, сохраняйте его с момента когда он “вошёл” в
узел” и фиксируйте его как только он “вышел” из узла. Таким образом, если какой-
то узел “упадёт”, система не потеряет запрос и тут же направит его снова в
обработку. По окончанию обработки направьте результат клиенту, и храните его до
тех пор, пока клиент не скажет “Confirm”.
6. Обеспечьте параллельность вычислений для тех операций, которые могут
выполняться параллельно с точки зрения бизнес-логики, и последовательность для
тех, которые должны выполняться строго последовательно. Этот пункт написан не с
претензией на “Капитана Очевидность”, а чтобы показать, что не любой бизнес-
процесс можно “вслепую положить” на многопоточный код.
Четыре проблемы параллельных
вычислений
Синхронизация
Когда несколько модулей одной и той же программы запускаются на разных
процессорах, то возникает необходимость в синхронизации их действий.
Модулю А могут быть необходимы результаты работы модулей В и С, поэтому начать
свое выполнение модуль А может лишь по завершении работы как модуля В, так и
модуля С, которые могут выполняться параллельно, но не известно, какой из них
первым закончит работу. В любом случае запуск модуля А на выполнение должен быть
синхронизирован с окончанием работ модулей В и С.
При распараллеливании по данным один и тот же модуль F может быть запущен на k
процессорах и параллельно выполняться, обрабатывая разные подмножества данных
(X1, X2, …Xk). Результаты работы k процессоров затем объединяются в процессе работы
модуля G. Понятно, что запуск на выполнение модуля G должен быть синхронизирован с
окончанием работы модуля F на всех параллельно работающих k процессорах.
Параллельные вычисления требуют тщательной синхронизации работы модулей
программы, выполняемых разными процессорами.
Четыре проблемы параллельных
вычислений
Гонка данных (Data race)
Так называемая проблема "гонки данных" возникает для мультипроцессорных
компьютеров с общей памятью. Поскольку процессоры работают параллельно, то в
одни и те же моменты времени они могут получать доступ к одним и тем же данным,
хранимым в общей памяти, как для чтения, так и для записи.
Если совместное чтение данных представляется возможным и допустимым, то
одновременная запись двух разных значений в одну и ту же ячейку памяти не
допустима. Запись всегда будет идти по очереди. Конкурирование процессоров за
запись в одно и то же слово памяти и называется "гонкой данных". Интересно, что в
этой гонке выигрывает не тот, кто пришел первый, а тот, кто пришел последний,
поскольку именно его результаты будут сохранены в памяти. Это соответствует
пословице: "хорошо смеется тот, кто смеется последним".
Чтобы справиться с проблемой "гонки данных", существуют разные механизмы
закрытия памяти - одного из видов совместно используемого ресурса. Тот, кто
выигрывает гонку и приходит первым, закрывает ресурс для доступа. Проигравшие
гонку прерывают выполнение и становятся в очередь за обладание ресурсом.
Четыре проблемы параллельных
вычислений
Гонка данных (Data race) - продолжение
Обладатель ресурса спокойно выполняет свою работу, а по ее окончании открывает
ресурс, с которым теперь начинает работать тот, кто первым стоит в очереди.
Гонка данных - это одна из самых серьезных проблем параллельного
программирования, поскольку при некорректно организованной блокировке ресурса
программа может завершаться с некорректными результатами без возникновения
исключительных ситуаций.
Плохо, когда в процессе работы программы происходит отказ и нужные нам
результаты не могут быть получены. Но еще хуже, когда программа завершается,
выдает результаты, но эти результаты ошибочны. Плохо, когда студент на экзамене
говорит: "не знаю", но хуже, когда он говорит "глупости".
Четыре проблемы параллельных
вычислений
Клинч или мертвая блокировка(deadlock)
Чтобы справиться с гонкой данных, приходится включать блокировку, закрывая ресурс для
других конкурентов, которые должны прервать свою работу и томиться в очереди, ожидая
момента освобождения ресурса. Блокировка - полезный механизм, обойтись без которого в
ряде ситуаций просто невозможно. Но блокировка - это и опасный механизм, порождающий
прерывание работы всей программы, когда возникает ситуация, называемая тупиком,
клинчем или смертельным объятием.
Рассмотрим простейшую ситуацию, приводящую к возникновению клинча. Пусть есть два
конкурента А и В, претендующие на два ресурса f и g. Пусть гонку за ресурс f выиграл А и
соответственно закрыл этот ресурс для В. Гонку за ресурс g выиграл В и закрыл ресурс для А.
Но А, чтобы закончить свою работу нужен ресурс g, поэтому он стал в очередь, ожидая
освобождения ресурса g. Симметрично, В томится в очереди, ожидая освобождения ресурса
f. Возникает ситуация клинча, когда ни А, ни В не могут продолжить свою работу.
В боксе, когда два боксера входят в клинч, сцепившись друг с другом, нужен судья, дающий
команду "break", чтобы боксеры могли разойтись и продолжить бой. Так и в параллельных
вычислениях при возникновении клинча, только внешнее воздействие может разрешить
ситуацию.
Четыре проблемы параллельных
вычислений
Послать - Получить (Send - Receive или Map - Reduce)
Для мультикомпьютерных комплексов, где каждый компьютер комплекса имеет
собственную память, проблемы гонки данных и клинча не столь актуальны. Здесь
возникает своя не менее серьезная проблема. Хотя каждый компьютер комплекса
работает со своими данными, но все параллельно работающие компьютеры решают
одну и ту же задачу, поэтому без обмена информацией обойтись невозможно. В
процессе работы компьютеры должны обмениваться данными, посылая друг другу
сообщения. В кластерах (типичном виде мультикомпьютерного комплекса)
компьютеры объединены высокоскоростными линиями связи. Тем не менее, передача
данных является медленной операцией, и время на передачу данных может "съесть"
весь выигрыш, полученный за счет распараллеливания вычислений. Поэтому при
анализе эффективности работы программы, работающей на кластере или другом
мультикомпьютерном комплексе, где параллельно работающие процессоры
обмениваются сообщениями по линиям связи, не имея доступа к общей памяти,
важную роль играют операции п осылки и получения сообщений (send - receive, map -
reduce).
Процессы и потоки
Задача. Обедающие философы.
Пять безмолвных философов сидят вокруг круглого
стола, перед каждым философом стоит тарелка с
роллами (их 10 штук в тарелке). Палочки лежат на
столе между каждой парой ближайших философов.
Каждый философ может либо есть, либо
размышлять. Приём пищи ограничен количеством
оставшихся роллов. Тем не менее, философ может
есть только тогда, когда держит две палочки —
взятую справа и слева.
Каждый философ может взять ближайшую палочку
(если она доступна), или положить — если он уже
держит её. Взятие каждой палочки и возвращение её
на стол являются раздельными действиями, которые
должны выполняться одно за другим.
Суть проблемы заключается в том, чтобы
разработать модель поведения (параллельный
алгоритм), при котором ни один из философов не
будет голодать, то есть они более-менее
равномерно съедят все свои роллы.
Задача. Обедающие философы.
Пять безмолвных философов сидят вокруг круглого
стола, перед каждым философом стоит тарелка с
роллами (их 10 штук в тарелке). Палочки лежат на
столе между каждой парой ближайших философов.
Каждый философ может либо есть, либо
размышлять. Приём пищи ограничен количеством
оставшихся роллов. Тем не менее, философ может
есть только тогда, когда держит две палочки —
взятую справа и слева.
Каждый философ может взять ближайшую палочку
(если она доступна), или положить — если он уже
держит её. Взятие каждой палочки и возвращение её
на стол являются раздельными действиями, которые
должны выполняться одно за другим.
Суть проблемы заключается в том, чтобы
разработать модель поведения (параллельный
алгоритм), при котором ни один из философов не
будет голодать, то есть они более-менее
равномерно съедят все свои роллы.
Функции СМЭВ
• Ведение реестра электронных сервисов
• Ведение политик безопасности, применяемых к зарегистрированным электронным сервисам
• Маршрутизация сообщений к зарегистрированным электронным сервисам при синхронном и
асинхронном взаимодействии
• Протоколирование обращений (входящих и исходящий сообщений) к электронным сервисам
• Гарантированная доставка сообщений, осуществляемая за счет механизма повторных
вызовов электронных сервисов при сбоях
• Обеспечение оповещения Оператора СМЭВ о сбоях в функционировании электронных
сервисов
• Передача информации о событиях на СМЭВ по подписке заинтересованным Пользователям
(информационным системам)
• Формирование динамически создаваемой статистики использования электронных сервисов
• Подписание электронных сообщений электронной подписью
• Форматно-логический контроль входящих сообщений
• Контроль и мониторинг процессов межведомственного обмена с использованием СМЭВ
Техническое описание СМЭВ
СМЭВ состоит из сети защищенных каналов связи между узлами,
расположенными в центрах обработки данных Ростелекома. Каждый
узел СМЭВ — это шина на базе Oracle Enterprise Service Bus. Участники
СМЭВ являются поставщиками и потребителями сведений:
• каждый поставщик сведений публикует и регистрирует в СМЭВ свой
электронный сервис, который предназначен для обработки запросов и
выдачи сведений
• каждый потребитель сведений получает доступ к опубликованным
сервисам в СМЭВ в случае необходимости, реализует адаптер,
который умеет правильно запрашивать сведения и получать ответ.
Оператор СМЭВ — Министерство связи и массовых коммуникаций
Российской Федерации.
Строительством инфраструктуры СМЭВ занимается «Ростелеком».
Технические подробности
взаимодействия
• Взаимодействие информационных систем через СМЭВ осуществляется с
использованием электронных сервисов, реализованных в виде веб-сервисов.
• Для передачи электронных сообщений используется протокол SOAP поверх HTTP.
• Для размещения электронной подписи в сообщениях применяются стандарты
XMLDsig и PKCS #7 (RFC 2318).
• Для электронного документооборота используется формат PDF/A с размещением
реквизитов электронного документа в XML-файле.
• Ограничение доступа реализовано на основании сведений, передаваемых в
сообщении с использованием стандарта WS-Security.
• Форматы и правила разработки электронных сервисов и применения технологии
электронной подписи регламентируются приказом Минкомсвязи РФ N 190 от 27
декабря 2010 года, а также Методическими рекомендациями по разработке
электронных сервисов и применению технологии электронной подписи.
• СМЭВ обладает функциями протоколирования взаимодействия. Также СМЭВ
позволяет установить кто, в каком объёме и на основании каких привилегий
делал запрос информации.
XMLDsig / Подпись XML
Подпись XML (также называемая XMLDSig , XML-DSig , XML-Sig ) определяет
синтаксис XML для цифровых подписей и определяется в рекомендации W3C
XML Signature Syntax and Processing . Функционально это имеет много общего с
PKCS # 7 (RFC 2315) но более расширяемо и ориентировано на подписание
документов XML. Он используется различными веб- технологиями, такими как
SOAP , SAML и другими.
Подписи XML могут использоваться для подписи данных - ресурса - любого
типа , обычно документов XML, но все, что доступно через URL, может быть
подписано. XML-подпись, используемая для подписи ресурса вне его
содержащего XML-документа, называется отдельной сигнатурой ; если он
используется для подписи какой-либо части содержащего его документа, он
называется окутанной подписью; если он содержит подписанные данные
внутри себя, он называется обходящей подписью.
Структура XMLDsig / Подписи XML
<Подпись>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</ Reference>
<Reference /> и т. Д.
</ SignedInfo>
<SignatureValue />
<KeyInfo / >
<Объект />
</ Подпись>
Структура XMLDsig / Подписи XML
• SignedInfoЭлемент содержит или ссылки на подписанные данные и определяет , какие используются
алгоритмы.
SignatureMethodИ CanonicalizationMethodэлементы используются в SignatureValueэлементе и включены в ,
SignedInfoчтобы защитить их от несанкционированного доступа .
Один или несколько Referenceэлементов определяют ресурс, подписанный ссылкой URI; и любые
преобразования, которые должны применяться к ресурсу до его подписания. Преобразование может быть
выражением XPath, которое выбирает определенное подмножество дерева документа.
DigestMethod задает хэш-алгоритм перед применением хэша.
DigestValueсодержит закодированный в Base64 результат применения алгоритма хеширования к
преобразованному ресурсу (ресурсам), определенным в Referenceатрибутах элемента.
• SignatureValueЭлемент содержит Base64 результат кодируются подпись - подпись генерируется с
параметрами , указанными в SignatureMethodэлементе - от SignedInfoэлемента после применения
алгоритма , указанного CanonicalizationMethod.
• KeyInfoэлемент необязательно позволяет подписчику предоставлять получателям ключ, который
проверяет подпись, обычно в виде одного или нескольких цифровых сертификатов X.509 .
Предполагающая сторона должна идентифицировать ключ из контекста, если KeyInfoего нет.
• ObjectЭлемент (необязательно) содержит подписанные данные , если это обволакивающая подпись.
Валидация и соображения
безопасности
При проверке подписи XML выполняется процедура, называемая Core Validation .
1. Проверка ссылок: каждый Referenceдайджест проверяется путем получения
соответствующего ресурса и применения любых преобразований, а затем указанного
метода дайджеста. Результат сравнивается с записанным DigestValue; если они не
совпадают, проверка не выполняется.
2. Проверка подписи:SignedInfo элемент сериализовать с использованием методы
канонизации , указанной в CanonicalizationMethod, ключе данные извлекаются с
помощью KeyInfoили с помощью других средств, а также подпись проверяется с
использованием методы , указанной в SignatureMethod.
Эта процедура устанавливает, действительно ли ресурсы были подписаны предполагаемой
стороной. Однако из-за расширяемости методов канонизации и преобразования
проверяющая сторона также должна убедиться, что то, что фактически было подписано или
переварено, действительно было тем, что было в исходных данных, другими словами, что
используемым там алгоритмам можно доверять не для изменения значения подписанных
данных.
Поскольку структура подписанного документа может быть изменена, что приводит к атакам
«обертывания подписей», процесс проверки должен также охватывать структуру документа
XML. Подписанный элемент и элемент подписи должны выбираться с использованием
абсолютного выражения XPath , а не getElementByNameметодов.
СМЭВ 3: Понятия и правила обмена
информацией
СМЭВ обеспечивает взаимодействие информационных систем (далее – ИС)
федеральных органов исполнительной власти, государственных
внебюджетных фондов, исполнительных органов государственной власти
субъектов Российской Федерации, органов местного самоуправления,
государственных и муниципальных учреждений, многофункциональных
центров, иных органов и организаций (далее - органы и организации),
используемых при предоставлении государственных и муниципальных услуг и
исполнении государственных и муниципальных функций в электронной форме.
Органы и организации выступают в качестве участников взаимодействия.
Участники взаимодействия могут запрашивать сведения или предоставлять их
другим участникам, в зависимости от этого они являются потребителями или
поставщиками сведений, путем обмена данными между ИС участников с
использованием единого электронного сервиса СМЭВ (далее – единый
электронный сервис). Единый электронный сервис реализован в виде веб-
сервиса, предоставляемого СМЭВ.
СМЭВ 3: Понятия и правила обмена
информацией
В рамках информационного взаимодействия ИС поставщика и потребителя
обмениваются сообщениями. ИС, отправляющая сообщение через СМЭВ,
является отправителем сообщения, а ИС, получающая сообщение из СМЭВ, –
получателем.
Упрощенно, процесс обмена сообщениями между ИС потребителя и ИС
поставщика через
СМЭВ включает последовательность следующих шагов:
− передача запроса от ИС потребителя в СМЭВ;
− размещение запроса в СМЭВ в очереди запросов поставщика;
− получение запроса ИС поставщика из СМЭВ;
− подготовка поставщиком ответа на запрос;
− передача подготовленного ответа из ИС поставщика в СМЭВ;
− размещение ответа в СМЭВ в очереди ответов потребителя;
− получение ответа ИС потребителя из СМЭВ.
СМЭВ 3: Обмен информацией
Роль ESB в структуре SOA
Роль ESB в структуре SOA