В этой статье объясняется, как создать систему телесвязи с помощью облачной платформы Azure.
Архитектура
Скачайте файл Visio для этой архитектуры.
Рабочий процесс
В основе решения лежат четыре аспекта:
- Клиенты
- Компоненты общения.
- API и бизнес-логика.
- Службы служба хранилища и инфраструктуры.
На схеме архитектуры слева клиенты разделены на две группы: медицинский работник и пациент. Медицинский работник использует соответствующее программное обеспечение и клиенты веб-портала для общения со своими пациентами. Пациенты, со своей стороны, используют мобильное приложение, которое связано с медицинским устройством через подключение по Bluetooth. Такое двухстороннее общение достигается с помощью серверных служб:
- Общедоступные API.
- Внутренние микрослужбы, отвечающие за рабочие процессы, такие как видеозвонки через WebRTC или обмен данными между клиентами с использованием Signal. Signal — это программная библиотека для Microsoft ASP.NET, которая позволяет серверному коду отправлять асинхронные уведомления клиентским веб-приложениям.
Состояние этих служб сохраняется в нескольких службах Azure (справа от схемы), таких как База данных Azure для PostgreSQL. Файлы мультимедиа сохраняются в учетных записях хранения Azure. Все журналы всех служб собираются в централизованном решении для ведения журнала, использующего приложение Azure Аналитика. Наконец, асинхронное взаимодействие между клиентами можно достичь с помощью push-уведомлений с помощью Центра уведомлений Azure.
Решение было настроено для решения следующих задач:
Предоставление преимуществ масштабируемости облачных служб, работающих в серверной части.
Повышение автономности команд, разрабатывающих решение. Каждая команда наблюдает за функциональными доменами и управляет развитием их компонентов. Так как функциональные домены не перекрываются, каждая команда может внедрять инновации по своему собственному темпу. Кроме того, так как базы кода служб независимы, конвейер CI/CD для всего решения упрощается.
Создание механизма обмена данными и координации между службами, необходимый для распределения функций между микрослужбами. Решение, описанное в этом документе, использует Кэш Azure для Redis для выполнения этой задачи.
Обеспечение централизованного мониторинга и улучшение возможностей устранения неполадок с решением.
Упрощенное управление секретами, учетными данными, сертификатами и ключами с помощью управляемых удостоверений для защиты обмена данными между службами.
Компоненты
- База данных Azure для PostgreSQL хранит данные о пользователях (пациентах и медицинских работниках) и данные об устройствах. Служба выбрана, так как она стабильная, упрощенная и не имеет привязки к поставщику.
- Служба Azure Kubernetes содержит бизнес-логику приложения и обеспечивает простоту развертывания и гибкость настройки. Служба также абстрагирует решение от реального используемого оборудования.
- Кэш Azure для Redis размещает временные данные, используемые для внутренних данных службы (общие данные). Службу можно создать повторно из базы данных при истечении срока действия данных из кэша.
- Центр уведомлений Azure уведомляет пациента о входящем содержимом: чат, видеозвонки, параметры конфигурации устройства.
- Функции Azure помогают планировать задачи. Например, масштабное общение с большим количеством пользователей, координация работы аналитики в серверной части (агрегации и пр.).
- Azure Application Insights централизует сигналы и события из системы (журналы, данные телеметрии из журналов микрослужб, интерфейсной части и устройств) для устранения неполадок.
- Сеть доставки содержимого Azure (CDN) используется для обслуживания и обновлений (доставки файла скриптов Java) на веб-портале, а также для доставки файлов мультимедиа (видео, изображений) через портал. Все это содержимое сохраняется в учетных записях хранения Azure в фоновом режиме.
- Диспетчер трафика Azure распределяет нагрузку между географическими расположениями.
- Azure SignalR позволяет серверному коду отправлять асинхронные уведомления клиентским веб-приложениям. Устройства пользователей можно настроить как в стандартном, так и в расширенном режимах.
Альтернативные варианты
На стороне базы данных можно использовать любые другие службы базы данных PaaS. При размещении логики приложения вместо использования Служба Azure Kubernetes можно использовать службу приложение Azure.
Подробности сценария
Детали основаны на реальной клиентской реализации, которая объединяет профессиональную организацию, работающую в сфере здравоохранения, и удаленных пациентов. Хотя существуют и другие способы создания такой системы, описанное решение оказалось успешным для обеспечения связи между пациентами и удаленным поставщиком медицинских услуг, а также для удаленной настройки медицинских устройств, которые пациенты носят с собой.
Около 700 миллионов человек страдают от нарушений слуха. Но только 10 % из них используют слуховые аппараты для улучшения качества жизни. В некоторых географических регионах или ситуациях пациенту невозможно получить прямую помощь при необходимости. Например, рассмотрим следующие сценарии:
- Нужна помощь в конкретной ситуации слушания (например, во время прогулки в парке, посещения вечеринки или дома), которая не может быть воспроизведена в офисе специалиста по уходу за слухом.
- У пациента проблемы с передвижением или он проживает на большом расстоянии от специалиста по слуху.
- Пациент проживает в развивающейся стране или регионе с ограниченным числом специалистов по слуху.
Чтобы преодолеть эти трудности, важно иметь возможность предоставлять услуги по уходу за слухом удаленно. В этом случае медицинский работник использует чат или видеосвязь для общения с удаленными пациентами. Люди с нарушениями слуха могут использовать смартфон, чтобы разрешить доступ к слуховому аппарату во время удаленного сеанса. Пациент сразу чувствует улучшение слуха, так как специалист п слуху вносит изменения в конфигурацию слухового аппарата в реальном времени.
Потенциальные варианты использования
Это решение идеально подходит для отрасли здравоохранения. Следующие дополнительные варианты использования имеют схожие шаблоны проектирования:
- С помощью такого решения можно получить доступ к любому устройству с поддержкой Bluetooth и удаленно настроить его.
- Общение (текст, голос, видео) или обмен знаниями (обучение, опросы удовлетворенности) в удаленном расположении или контексте.
- Глобально распределенное управление веб-содержимым.
- Интернет вещей (IoT)
Режимы
Стандартный режим
В стандартном режиме ПО для настройки подготавливает уведомление, содержащее файл конфигурации JSON или содержимое для устройства. Затем уведомление передается в Центр уведомлений Azure, который отправляет уведомление на телефон пользователя.
Расширенный режим
В расширенном режиме специалист по слуху использует ПО для настройки для передачи подробной конфигурации на устройство. Для этого требуется стабильное и надежное подключение между серверной частью и устройством, которое SignalR обеспечивает с помощью веб-сокетов. Телефон пользователя находится на принимающей стороне этого канала. Подключение по Bluetooth с телефона позволяет установить окончательную связь с устройством.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Мы рекомендуем использовать диспетчер трафика перед различными кластерами для оптимизации задержки между регионами и в качестве резервного механизма, если кластеры станут недоступными. Для баз данных мы рекомендуем использовать реплики только для чтения для запросов, требующих загрузки и агрегирования большого объема данных. Мы рекомендуем предоставлять статические веб-файлы (.html, .js, образы и т. д.) глобально с помощью сети доставки содержимого (CDN) для повышения скорости кэширования.
Развертывание
Наиболее важным аспектом, который следует учитывать при развертывании этого сценария, является координация развертываний в облачной серверной и интерфейсной частях (телефоны и устройства). Рассмотрите возможность использования концепции флага функции для достижения этой цели.
Управление
Чтобы лучше выровнять идею о том, что каждый функциональный домен имеет дело с использованием определенной микрослужбы, долгосрочной перспективе, существует возможность разделить базу данных на несколько небольших баз данных. Это обеспечит принципиальную изоляцию и автономию потока, связанного с каждой микрослужбой, в отличие от концентрации данных, связанных со всеми службами, в одной базе данных. Для достижения этой цели потребуется автоматизировать подготовку и управление этими базами данных, что является одной из основных возможностей службы баз данных PaaS в облаке. Этот уровень управления базой данных должен быть интегрирован в решение, а также в унифицированное решение для мониторинга.
Наблюдение
Важно отслеживать каждый из уровней, и каждый аспект мониторинга должен быть федеративн в одном контейнере в облаке. Важно включить корреляцию всех этих журналов и точек данных телеметрии, чтобы обеспечить целостную аналитику между компонентами и слоями.
Сегодня отслеживаемые слои включают:
- Приложение для Windows (ПО для настройки на компьютере специалиста по слуху).
- Логика размещенного приложения.
- Облачные службы
Изменение размера и масштабирование
Обязательно оптимизируйте конфигурацию кластеров Azure Kubernetes, чтобы она соответствовала требованиям масштабирования, которые меняются в зависимости от времени суток и региональных особенностей. Рассмотрите возможность разгрузки рабочих нагрузок чтения (например, агрегирования запросов) с помощью реплик чтения в Базе данных Azure для PostgreSQL.
Использование расширения TimescaleDB для PostgreSQL позволит более эффективно обрабатывать связанные со временем данные, поступающие от медицинских устройств. Рекомендуется использовать горизонтальное масштабирование, например База данных Azure для PostgreSQL — гипермасштабирование (Citus), чтобы достичь глобального масштаба путем подготовки нескольких узлов базы данных.
Безопасность и соответствие требованиям
Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".
Это решение обрабатывает персональную медицинскую информацию и личные данные. Таким образом, важно использовать службы, сертифицированные для медицинских приложений (сертификаты HIPAA, не только для данных, которые остаются в базе данных, но и журналы и данные телеметрии). Дополнительные сведения см. в разделе, посвященном сертификации HIPAA в Центре управления безопасностью Майкрософт.
Управляемое удостоверение должно использоваться во всех службах Azure, поддерживающих эту проверку подлинности без пароля, чтобы упростить управление паролями: AKS, PostgreSQL, Кэш Redis, Центр уведомлений, Azure Key Vault и Функции Azure. Ознакомьтесь со всеми службами, поддерживающими управляемые удостоверения для ресурсов Azure.
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".
Для развертывания в одном регионе ориентировочные цены можно узнать с помощью Калькулятора цен.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Основные авторы:
- Джин-Ив Девант | Главный диспетчер продуктов
Следующие шаги
Чтобы приступить к реализации сравнимой архитектуры для вашего бизнеса, рассмотрите возможность создания навыков по веб-службам, базам данных, таким как База данных Azure для PostgreSQL, и методам разработки мобильных приложений, таким как .NET MAUI.
Документация по продукту:
- Что такое База данных Azure для PostgreSQL?
- Служба Azure Kubernetes
- Учетные записи хранения Azure
- Сведения о Кэш Azure для Redis
- Общие сведения о Функциях Azure
- Azure Application Insights
- Что такое Центры уведомлений Azure?.
Обмен данными в режиме реального времени:
Дополнительные сведения о том, как WebRTC предоставляет возможности для общения в реальном времени для мобильных приложений, см. на сайте проекта WebRTC.
Поворот серверов:
Используйте клиентскую библиотеку, такую как Icelink (загружаемую приложением на телефоне и соответствующим ПО на компьютере специалиста по слуху), для управления серверами TURN* и типами подключения (TCP, UDP, P2P) между двумя клиентами (ПО для настройки и приложение на телефоне). Клиентская библиотека:
- Создает канал потоковой передачи.
- Устанавливает подключения.
- Управляет подключением в случае ошибок, отсутствия пакетов, а также автоматически корректирует потоковую передачу с учетом пропускной способности.
- Кодирует и декодирует вызовы (аудио и видео) во время вызовов.
*Серверы TURN — это сетевые объекты, отвечающие за ретрансляцию мультимедиа в протоколах, связанных с VoIP. В этом решении они размещаются с помощью https://xirsys.com/ в нескольких центрах обработки данных по всему миру. Устанавливает прямое подключение между двумя клиентами в одном сеансе.