Вкратце: я ищу лучший способ, чтобы распределенные бизнес-процессы передавали информацию трассировки, которая позволяла бы мне реконструировать асинхронный процесс с несколькими приложениями, сохраняя при этом иерархию и бизнес-порядок этого процесса без изменений, не требуя от пользователя этогоданные для глубокого знания процесса или для каждого приложения знание того, что они являются частью более крупного процесса.
У нас есть несколько бизнес-процессов, которые асинхронно работают в нескольких распределенных приложениях.Мы хотим, чтобы каждое приложение отправляло данные трассировки / журналирования приложения в стандартном формате, который позволит восстанавливать любой конкретный экземпляр любого из этих процессов в правильном порядке, даже если некоторые части этих процессов асинхронны и / или происходят параллельноклиентом, имеющим доступ к необработанным данным, но не имеющим смысла в реальных шагах процесса, что, конечно, со временем изменится.
У нас уже есть приложение типа служебной шины, которое может собирать и передавать эти данные,Я просто пытаюсь найти хороший способ «скрутить» эти события, чтобы собрать все части вместе в правильном порядке.
Так, например, допустим, что это Process # 1
- Приложение 1 - вызывает приложение 2
- Приложение 2 - вызывает приложение 3 асинхронно , затем сразу вызывает приложение 5
- Приложение 3 - вызывает приложение 4
- Приложение 4 - занимает очень много времени, поэтому оно заканчивается последний
- Приложение 5 - я последний!
Такесли каждое приложение отправило событие со своим номером приложения, просто упорядочив эти события по отметке времени или идентификатору последовательности, можно отобразить шаги как
При этом теряется иерархия и создается впечатление, что 5 наступает раньше, чем 4, что верно на часах, но неправильнобизнес.Что я действительно хочу, так это след, который выглядит следующим образом:
Дополнительные требования:
- Потребители этих данных не должны знать, что они пытаются очертить трассировкуреконструировать.Они должны иметь возможность строить эту трассировку самостоятельно, включая иерархию, только на основе данных, скажем, из идентификатора сеанса, который является общим для всех этапов трассировки.Если приложение 3 начинает звонить в приложение 3А, только приложение 3 должно знать об этом изменении.Все остальные должны просто увидеть это в данных. Потребитель этих данных должен быть свободно связан с деталями процесса, на который он смотрит.
- Приложение 3 может быть частью 13 различных процессов.Он не может предполагать, что его шаги - дети Приложения 2.Это должно просто добавить к иерархии, которой это вручают, или создать новую, если ни одна не дана ему. Каждое приложение не должно ничего знать о других приложениях
Я думаю, что у меня есть работоспособное решение, но мне хотелось получить обратную связь и / или посмотреть, является ли это решенной проблемой.м отсутствует.Моя идея состоит в том, чтобы каждое из этих приложений получило новый необязательный заголовок «X-Trace-Hierarchy» (все они являются пользовательскими веб-приложениями и почти все RESTful), представляющие список целых чисел, разделенных точками, как показано на схеме.Если приложение получает этот заголовок, оно добавляет к нему свою собственную иерархию, выполняя свою работу, включая вызов дочерних приложений.Шаги в приложении добавляются в иерархию как братья и сестры, увеличиваясь на 1 каждый раз, а вызовы внешних служб добавляются как дочерние.В результате входящий заголовок X-Trace-Hierarchy для вышеуказанного процесса выглядит следующим образом:
- Приложение 1 -
X-Trace-Hierarchy: (not sent, will default to 1) - Приложение 2 -
X-Trace-Hierarchy: 2 - Приложение 3 -
X-Trace-Hierarchy: 2.1 - Приложение 4 -
X-Trace-Hierarchy: 2.1.1
- Приложение 5 -
X-Trace-Hierarchy: 3
Теперь, если я получу кучу шагов трассировки для данного сеанса, я могу однозначно восстановить логический порядок, независимо от фактической последовательности времени, в которой они происходят, и не имея никаких ожиданий или знаний о том, что это порядок должен быть. Фактически, вызов приложения 3, который не является частью этого процесса, приведет к:
- Приложение 3 -
X-Trace-Hierarchy: (not sent, will default to 1)
- Приложение 4 -
X-Trace-Hierarchy: 1.1
поэтому иерархия, создаваемая каждый раз, всегда будет вытекать из конкретных шагов, предпринятых этим экземпляром процесса, и может каждый раз отличаться, но это позволит относительно «тупому» клиенту реконструировать любой произвольный процесс из этих данных.
Да, для этого требуется, чтобы каждое приложение обновлялось для использования X-Trace-Hierarchy, и это предполагает гарантированную доставку отправленных событий, но я в порядке. В противном случае я не могу думать ни о проблемах с этим подходом, ни о лучшем способе сделать это. Но если вы можете, интернет, пожалуйста, дайте мне знать.