Как мы создали микросервисную архитектуру, поддерживающую варианты использования в машинном обучении
Идентификация правильного варианта использования
Хорошая реализация микросервиса производственного уровня требует хорошего определения варианта использования. Он должен решать конкретную бизнес-проблему, а использование машинного обучения должно повышать идентифицируемый показатель, такой как производительность.
Обзор архитектуры
Как управлять конечными точками REST API
Служба управления API Azure использовалась для управления политиками, проверкой подлинности и серверными URL-адресами, а также для абстрагирования учетных данных ключа и накладных расходов от потребителей платформы микросервисов.
Управление рабочими нагрузками машинного обучения в разных средах
В нашем контексте у нас были среды, охватывающие Dev, UAT и Production, с идеей, что среды Dev предназначены исключительно для того, чтобы разработчик экспериментировал с различными вариантами использования. UAT был промежуточной средой, используемой для тестирования ошибок, и в этой среде также происходили проникновения в систему безопасности. Производство было последней конечной точкой, доступной конечным пользователям.
Сохранение гибкости
Мы использовали Agile-подход в нашей структуре доставки, что обеспечило регулярные результаты, предоставляемые разработчикам машинного обучения. В конце каждого цикла спринта конечная точка разработки должна была быть готова, и дальнейшие изменения в ней не допускались. Отсюда артефакты, зафиксированные для спринта в среде разработки, будут помещены в среду UAT, а затем выпущены в производство.
