The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Чатбот (или chatterbot, как говорит Википедия) - это программное обеспечение, которое общается с вами в формате чата. Мы используем чатботов в нескольких (микро)сервисах, и они полностью заменяют пользовательские интерфейсы. Я не думаю, что в этом подходе есть какая-то инновация, но он доказал свою эффективность за последний год примерно. Вот как работает чатбот Rultor для нас и каковы его преимущества.
Давайте сначала приведу пример. Посмотрите на задачу GitHub jcabi/jcabi-http#115:
Давайте посмотрим, что здесь происходит, а затем обсудим, как это организовано внутри. По сути, я общаюсь с чатботом. Имя чатбота - @rultor (я писал об этом в прошлом году). В пункте 1 я прошу чатбота выпустить новую версию библиотеки jcabi-http. В пункте 2 чатбот отвечает, просто подтверждая, что задача понятна и он над ней работает. В пункте 3 бот говорит, что задача выполнена, и ее выполнение заняло девять минут. Наш разговор окончен. Вот и все.
Теперь, что в этом такого особенного?
Одно: нет пользовательского интерфейса. Что ж, нет традиционного веб-интерфейса на основе HTML/CSS. Нет входа, выхода, профиля, меню и тому подобного. Rultor - это веб-сервис, у которого нет веб-интерфейса. Единственный способ общаться с ним - разговаривать с его чатботом.
Что в этом хорошего? Несколько вещей.
Вот как будет выглядеть традиционная архитектура веб-системы:
skinparam componentStyle uml2 Пользователь -> [Сервис] [Сервис] -> [База данных]
Пользователь дает инструкции сервису и получает ответы. Это общение происходит через пользовательский интерфейс (UI) - набор точек входа HTTP, которые получают запросы от браузера и возвращают ответы HTML+CSS. Или, если пользователь находится на другом сервисе, запросы могут содержать некоторые данные, а ответы будут в формате XML или JSON. Вы поняли; пользователь - это клиент, а сервис - сервер.
Как в ресторане - вы говорите, чего хотите, и сервер идет на кухню, ждет там и через несколько минут возвращается с пастой карбонара. Вы - клиент, а эта милая дама - сервер.
В случае с чат-ботом это уже не так. Взгляните на архитектуру:
skinparam componentStyle uml2 Пользователь -вверх-> [GitHub] [Сервис] -вверх-> [GitHub] [База данных] -вверх-> [Сервис]
Сначала пользователь отправляет запрос в GitHub через веб-интерфейс, предоставленный GitHub. Это коммуникационный хаб для нас. Затем сервис подключается к GitHub через его RESTful API и проверяет, есть ли там новые запросы. Если что-то новое найдено, сервис выполняет задание, подготавливает ответ и отправляет его туда. Клиент получает уведомление по электронной почте о новом ответе, только что размещенном в заявке. Затем клиент проверяет GitHub и находит ответ.
Вот как это будет выглядеть в ресторане: будет доска с липкими заметками. Сначала вы пишете заметку «Я бы хотел спагетти карбонара с пармезаном и свежим перцем сверху» (Черт, я просто слишком голоден), и прикрепляете ее к доске под номером 15. Затем вы возвращаетесь к своему столику. Шеф-повар из кухни проверяет эту доску и находит вашу заметку. Он готовит ту самую пасту, добавляет пармезан, свежий перец, немного базилика и оливковое масло… да, он делает все правильно… и ставит рядом с доской. Вы слышите объявление, что заказ номер 15 готов. Вы подходите туда, забираете еду, возвращаетесь к своему столику и наслаждаетесь.
Суть в том, что больше нет милой дамы. Нет сервера. Есть две стороны, общающиеся с доской - вы и кухня. Кухня - наш микросервис, но он больше не является сервером.
Теперь эти две стороны совершенно развязаны. Они никогда не общаются друг с другом. И оба являются клиентами коммуникационного хаба, который является GitHub или доской в ресторане.
Опять же, микросервис больше не является сервером. Вместо этого он является клиентом коммуникационного хаба. И переворот его положения приносит много преимуществ для нас, разработчиков.
Прежде всего, нам не нужно особо беспокоиться о производительности нашего пользовательского интерфейса. Ну, нам совсем не важно, так как у нас и нет пользовательского интерфейса. Мы заботимся о скорости ответов на GitHub? Совсем нет. Когда пользователь отправляет сообщение на GitHub, он или она не ожидает, что наш чат-бот даст немедленный ответ менее чем за 100 миллисекунд. (Я считаю, что это то, что должна гарантировать любая правильно разработанная веб-система.)
Мы оставляем записку на доске и предполагаем, что кухня в данный момент занята чем-то другим. Мы подождем несколько секунд или даже минут. Если, с другой стороны, я дам заказ официантке и она подождет пять секунд, прежде чем ответить, я буду очень удивлен. Если она будет делать это с каждым вопросом, я начну задумываться, все ли с ней в порядке.
Я ожидаю, что пользовательский интерфейс будет мгновенным, тогда как в чате у меня нет проблемы уделить некоторое время для ответа бота. Это происходит естественным образом. Мы привыкли к задержкам в чатах, когда общаемся с реальными людьми. Им нужно некоторое время, чтобы обработать нашу информацию, подумать и что-то набрать в ответ.
Но пользовательский интерфейс не имеет такой роскоши. Он должен быть мгновенным; в противном случае я немедленно испытываю разочарование. То же самое происходит с вами, не так ли?
Еще одним преимуществом этого дизайна без сервера является то, что нет необходимости выглядеть красиво. Здесь нет веб-интерфейса, HTML, CSS, графического дизайна. Возможно, не всем это нравится. Большинство непрофессиональных пользователей могут предпочесть общаться с милым сервером вместо того, чтобы приклеивать к доске бумажные записки. Но если речь идет о профессиональных компьютерных инженерах, они не так требовательны.
Rultor не имеет веб-интерфейса, и его пользователи просто не знают, как он “выглядит”. Он просто разговаривает с вами. Единственное, что вы видите, это его аватар на GitHub.
Это позволяет сэкономить много денег и времени на дизайн-работах, которые обычно стоят очень дорого, если вы стремитесь к высокому качеству. Если ваш веб-сервис выглядит обычно, большинство его пользователей предположат, что он работает также обычно. Множество хороших идей просто умирали, потому что их пользовательский интерфейс не был таким впечатляющим, как привыкли люди благодаря Pinterest и Instagram.
Хорошо выглядящий сервер имеет больше шансов на большие чаевые, верно? Если нет сервера и мы не видим повара, мы судим его только по качеству еды.
То же самое здесь. Избавляясь от пользовательского интерфейса, мы позволяем себе сосредоточиться на качестве предоставляемой услуги. Мы не тратим время и деньги на то, чтобы быть приятными. Мы тратим их на то, чтобы быть полезными.
Если у нас на этой доске слишком много записок, мы просто нанимаем больше поваров или, возможно, строим еще одну кухню, и проблема решается. Мы можем обслужить столько клиентов, сколько необходимо. Хорошо, пока доска достаточно мощная, чтобы справиться с несколькими параллельными пользователями.
GitHub - довольно крупная платформа с сотнями тысяч пользователей и проектов. Если у нас слишком много запросов, мы можем просто добавить больше узлов обработки в Rultor. Помните, мы больше не сервер; мы являемся клиентом GitHub. Мы сами решаем, когда подключаться к GitHub и когда создавать ответы на отправленные запросы.
Намного проще создавать масштабируемого клиента, чем масштабируемый сервер, в основном потому, что никто не ждет от нас быстрого ответа. Загрузку запросов, которые мы получаем, гораздо легче управлять, так как решение о том, когда их обрабатывать, принимается нами.
Когда вы стоите перед клиентом, большинство ваших ошибок не прощаются, преимущественно потому, что они очень заметны. С другой стороны, когда вы готовите что-то на кухне, никто не видит вас и не замечает ваших недочетов. Они заметят их только в том случае, если спагетти пересолены. Другими словами, они будут судить вас по вашим результатам, а не по тому, как вы их получили.
То же самое касается и микросервиса. Когда он работает как сервер, мы ожидаем, чтобы он работал безупречно, реагировал мгновенно и представлял все в структурированном и организованном виде. Если что-то идет не так, все это можно увидеть прямо на веб-странице. Лучший случай - это ошибка 404, а худший - когда вы предоставляете пользователю неправильную информацию. Даже если ошибка не является критической внутри движка микросервиса, пользователь об этом не знает. Пользователь будет судить вас по вашему внешнему виду и не забудет даже маленьких ошибок.
Однако, когда вы оба являетесь клиентами сообщества, вы не видите друг друга. Пользователь общается с GitHub, а микросервис взаимодействует с GitHub. Ошибки менее заметны. Поверьте, у нас было много таких за 18 месяцев, пока Rultor находился в публичном использовании. У нас были периоды простоя, серьезные логические ошибки и повреждение данных. Но эти проблемы очень редко становились видимыми онлайн. Мы просто видели их в журналах нашего сервера. Пользователи их не видели. Ну, почти.
Поскольку между нами есть доска коммуникации, очень легко увидеть всю историю нашего обсуждения, что очень интуитивно. Это похоже на историю чата в Slack. Вы видите, с чего мы начали, кто что сказал и какие выводы были сделаны.
В принципе, вы не можете иметь такую видимость в веб-интерфейсе. Хорошо, вы, вероятно, можете создать специальную страницу с “историей операций”, но кто будет ее проверять? И насколько видимой и простой будет эта информация? И, что самое важное, как эта информация будет соответствовать интерфейсу пользователя?
В журнале вы укажете, что “сборка была запущена”, но что такое сборка и как она была запущена? Как я могу ее запустить снова? С помощью каких кнопок и веб-элементов управления? Это не ясно.
Таким образом, прослеживаемость хронологического чата бесспорна.
Да, думайте о будущем такого подхода. Если есть централизованная доска объявлений, где пользователи общаются с чат-ботом, почему бы другим чат-ботам не общаться друг с другом тоже?
Забудьте о RESTful API. Просто доска объявлений, где чат-боты размещают свои запросы и получают ответы. Они полностью развязаны, заменяемы и очень масштабируемы. Кроме того, их протокол общения виден и легко отслеживается. И они обладают множеством других преимуществ, как было только что объяснено выше. Это намного удобнее для нас, как пользователей, так и программистов, для наблюдения и создания их.
Ну, может быть, это слишком крайний подход, чтобы полностью избавиться от RESTful API, но до некоторой степени этот подход осуществим, я считаю.
Я не зашел слишком далеко с этой идеей, но что-то было сделано. У нас есть платформа обмена сообщениями, которая позволяет нескольким чат-ботам общаться с пользователями. Она называется Netbout. Это очень простая веб-система с изолированными дискуссиями. Проще говоря, любой может создать новую дискуссию, пригласить несколько друзей и размещать сообщения там. Это могут делать и пользователи, и чат-боты.
Так вот, когда новый кандидат хочет присоединиться к Zerocracy, мы просим этого человека заполнить онлайн-форму. Когда кандидат нажимает кнопку “Отправить”, начинается новая дискуссия, и первый чат-бот решает, кто должен провести собеседование с этим человеком. Решение принимается на основе навыков, указанных в форме. Чат-бот приглашает одного из наших лучших программистов для проведения интервью. Когда интервью закончено, другой чат-бот объясняет кандидату, каковы следующие шаги, регистрирует его или ее в нашей базе данных и начинает показывать прогресс работы.
С точки зрения пользователя, это выглядит так, будто он или она общается с несколькими людьми, которые понимают всего несколько простых команд. Это очень интуитивно и легко разработано.
Я думаю, что чат-боты - хороший подход для взаимодействия с микросервисами. Особенно, когда пользователи более или менее профессиональны.
P.S. Иллюстрации от Kristina Wheat.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 09:59
