Ресурсы и примеры проектирования SOA на Ruby on Rails

Ответ 1

Является ли SOA правильным дизайном?

Это зависит. Разве вы не ненавидите подобные ответы? Разрушение вашего приложения для слабосвязанных служб с использованием сообщений или вызовов API, по определению, должно было бы реализовать SOA.

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

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

Если вы реализуете асинхронные вызовы, скажем, через ActiveMessaging или аналогично, вам приходится обрабатывать обратные вызовы или какие-то уведомления, чтобы пузыриться до вашего пользователя. Это также подразумевает создание первичных и вторичных брокеров сообщений и, возможно, некоторых JavaScript или индикаторов для проверки статуса. Все это весело!

С чего начать?

Я бы сначала посмотрел, стоит ли это "стоить": в конце концов, SOA классная, но вводит несколько точек отказа, которых у вас нет в настоящее время. Если вы считаете, что ваше сломанное приложение приведет к дискретным службам, которые являются HA и будут обслуживать другие проекты, я бы начал с "druby book" и "service oriented", как вы упомянули.

Каковы некоторые распространенные ошибки, которые я могу избежать?

Я думаю, что наибольшую озабоченность вызывают транзакции через несколько сервисов и возможность отката всей операции, если удаленная служба не работает. Проблемы начинаются, если вы находитесь в какой-либо операции, где вы вызываете A, и он вызывает B и B, вызовы C и C терпят неудачу. Кто знает, что C не удалось? Как вы скажете B и A откинуться назад? Они могут? Сохранят ли они состояние? Жесткие вопросы для предварительного дизайна.

Еще одна проблема заключается в том, что жизнь осложняется, когда вы бросаете рабочий процесс поверх своей SOA: кто хранитель бизнес-процесса? Централизованно или распределено? Все это совсем здорово, но тяжести ползет, нет? Но эта жизнь, если вы должны перейти в SOA.

Что я должен сейчас думать о том, что я могу сделать позже? (т.е. производительность)

Я бы выделил очевидные общие сервисы, которые можно использовать в других приложениях прямо сейчас. Я бы не превысил SOA в своей среде, чтобы не добавлять точки сбоя и не поддерживать SOA в минимуме.

Ответ 2

Это отличный ресурс моего друга, который является техническим директором Crowdtap. Они сделали то же самое, и это действительно помогло им значительно повысить скорость разработки продукта и дать им лучшее покрытие для тестирования. Надеюсь, что это поможет https://www.youtube.com/watch?v=KsiQXAXsQDQ