Существует проект сбора данных Интернета вещей и проект обработки данных Интернета вещей. Они разрабатываются и поддерживаются отдельно. Однако было бы полезно разделить общее зерно между ними в бункере Орлеана (или кластере бункеров). Как будет выглядеть архитектура в сценарии с самостоятельным размещением — монолитный бункер со ссылками на оба проекта для связи внутри хранилища или два отдельных хранилища, сообщающихся извне? Если в одном бункере, может ли бункер динамически обнаруживать зерна .dll?
Орлеанский архитектурный дизайн - совмещенные или отдельные проекты бункеров?
comment
Обратите внимание, что если вы используете монолитный бункер, развертывание новых версий любого из проектов становится нетривиальным. Проекты, которые должны были быть разделены, но, поскольку они выполняются в одном и том же бункере, вы не можете развернуть новую версию одного проекта, не влияя на другой (в противном случае вы можете получить две гранулы, ссылающиеся на один и тот же объект)
- person shay__ schedule 16.08.2015
comment
Спасибо, Шей, для меня это тоже имеет смысл. Я все еще пытаюсь понять, как работают разрозненные хосты, но развязка кажется правильным путем по всем обычным причинам.
- person Doug L. schedule 16.08.2015
comment
ознакомьтесь с функцией № 685 — github.com/dotnet/orleans/issues/685 , все будет проще :)
- person shay__ schedule 17.08.2015
Ответы (1)
Вероятно, будут лучшие ответы, но до тех пор:
Есть некоторые компромиссы. С точки зрения производительности лучше распределить все зерна (всех сервисов) по кластеру. Таким образом, каждое зерно взаимодействует с другими зернами через инфраструктуру Орлеана (я думаю, это двоичные сериализованные сообщения через tcp) без каких-либо дополнительных накладных расходов. Но когда у каждой службы (или проекта) есть собственный бункер, вам понадобится шлюз — возможно, прослушиватель HTTP — в дополнение к Orleans. Однако в первом примере ваши услуги становятся связанными. Вы не можете развернуть новую версию службы, пока существует хранилище, на котором работает ее более старая версия (в противном случае может быть 2 фрагмента одной и той же сущности). Но если вы отключите этот бункер, вы закроете остальные сервисы. Это очень нетривиальный вопрос.
Если в одном бункере, может ли бункер динамически обнаруживать зерна .dll?
Не уверен, что вы имеете в виду. Когда бункер загружается, он рекурсивно ищет dll внутри своей папки и, если находит зерна, загружает их.
person
shay__
schedule
16.08.2015
Спасибо - думаю, это то, что я ищу. Ссылки на реализации зернистости и интерфейсы в примерах проектов подтолкнули меня к этому. Так что я предполагаю, что они там только для того, чтобы поместить .dll в каталог bin?
- person Doug L.; 19.08.2015
В ранних версиях примеров проектов они использовали сценарий пост-сборки в проекте зерна для копирования всех dll из каталога бункера зерна в каталог бункера. Таким образом, проект по хранению зерна был полностью отделен от проекта по хранению зерна. Я не знаю о более новых версиях примеров проектов, но я думаю, что имеет смысл использовать ссылку на проект вместо сценария после сборки.
- person shay__; 19.08.2015
