Файл: Понятие прикладных протоколов и серверы приложений.pdf

Первый шаг - проанализировать приложение и понять ключевые бизнес-функции и способы их реализации. Хорошее понимание ключевых бизнес-функций может помочь нам переупаковать его в микросервисы, следуя подходу «один микросервис на функциональность». Мы должны помнить руководящие принципы микросервисов при оценке приложения [10, с. 131]. Некоторые из ключевых руководящих принципов:

1.Микросервисы должны быть достаточно маленькими, чтобы ими могла владеть гибкая команда разработчиков (так называемое «правило 2 пиццерий»).

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

3.Микросервисы должны быть без гражданства. Приложение без состояния обрабатывает каждый запрос с информацией, содержащейся только в нем.

4.Микросервисы должны быть предназначены только для одной цели, но делать это правильно.

Лучшее понимание приложения, как с точки зрения функциональности, так и с технической точки зрения позволяет нам лучше реорганизовать приложение в микросервисы с минимальными изменениями кода, сохраняя при этом функциональность приложения. В зависимости от характера приложения мы можем применить любой из стандартных шаблонов, таких как Backend for Frontend (BFF), Service Pattern, Adapter Pattern и т. д. [7, с. 80].

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

В то время как одностраничное приложение хорошо работает с одноканальным пользовательским интерфейсом, этот шаблон обеспечивает плохие результаты для пользователей по различным каналам, иногда перегружая браузер, управляя взаимодействием со многими асинхронными сервисами поддержки на основе REST [10, с. 167].

Был разработан паттерн Backend for Frontend (BFF), в котором бэкэнд-агрегаторная служба уменьшает общее количество вызовов из браузера и, в свою очередь, обрабатывает большую часть обмена данными между внешними сервисами поддержки, наконец, возвращая более легко управляемый одиночный запрос в браузер. Шаблон позволяет внешним командам разрабатывать и развертывать собственную службу агрегатора бэкэнда (BFF) для обработки всего количества вызовов внешних служб, необходимых для их конкретного взаимодействия с пользователем - часто созданного для определенного браузера, мобильной платформы или устройства IoT. Одна и та же команда создает как пользовательский интерфейс, так и BFF, часто на одном языке, что приводит как к повышению общей производительности приложений, так и к их доставке. При создании приложения на основе микросервисов наши клиенты придерживаются стандартного подхода:

Современные многоканальные интерфейсы должны быть реализованы в виде одностраничных приложений (SPA) с HTML / CSS / JavaScript [7, с. 148].

Эти пользовательские интерфейсы загружаются со статического веб-сервера (либо реализованного с использованием NGINX, либо просто с помощью простого веб-сервера Node.js.) [11, с. 160].

Затем JavaScript в клиенте может выполнять вызовы REST в набор BFF (или напрямую в Business Microservices) для заполнения данных в компонентах SPA (например, заполнение содержимого для пунктов меню GUI или раскрывающихся меню или других элементов GUI). [10, с. 160].

Микросервисы не генерируют элементы GUI в HTML - это полностью делается с помощью JavaScript и статического HTML / CSS. Вместо этого Microservices возвращают бизнес-ориентированные данные JSON только в ответ на запросы REST [7, с. 120].

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

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

Вывод по главе.

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

ЗАКЛЮЧЕНИЕ

Исследовав цели и задачи, поставленные в начале работы, было выяснено, что Стандарт STEP разделен на множество прикладных протоколов, принадлежащих к семейству стандартов ISO 10303. Каждый протокол определяет стандарт обмена данными для определенного семейства продуктов на определенной стадии его жизненного цикла. Наиболее популярными прикладными протоколами для САПР являются AP-203, также известный как ISO 10303-203, и AP-214, также известный как ISO 10303-214. Протокол применения STEP-NC имеет номер ISO 10303-238 или AP-238. Другие прикладные протоколы определяют стандарты обмена данными для специализированных продуктов, таких как корабли (AP-216) и печатные платы (AP-210), и для различных этапов жизненного цикла продукта, таких как планирование процесса (AP-240) и контроль координатной измерительной машины (AP-219)

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

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

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

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

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

Сервер приложений - это виртуальная машина Java ™ (JVM), на которой выполняются пользовательские приложения. Сервер приложений взаимодействует с веб-сервером для возврата динамического настраиваемого ответа на запрос клиента. Запрос клиента может состоять из сервлетов, файлов JavaServer Pages (JSP), корпоративных компонентов и их вспомогательных классов.

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

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