Углерод не любит играть хорошо с другими компонентами. Я никогда не мог успешно использовать Carbon для управления стеком WSO2. Каждый раз, когда я устанавливал/развертывал стек WSO2, я вручную настраивал отдельные файлы конфигурации компонентов. Обычно, сначала начиная с ESB, затем добавляя в CEP, затем BAM.
Вы также должны убедиться, что они начинаются в правильном порядке и что конфигурационные файлы не топают друг на друга (убедитесь, что установлены смещения порта).
Вам не нужно использовать Carbon для запуска любого экземпляра стека WSO2, просто установите его (разархивируйте файл wso2X.zip), затем убедитесь, что служба запускается (звонок wso2X/bin/wso2server.sh start
), и это касается ее общей настройки , после этого вам нужно настроить каждый компонент, чтобы играть хорошо с каждым другим компонентом (это означает, что вам нужно подключить BAM и CEP в ESB и т. д.), нет большого количества «автоматической» конфигурации или обнаружения, поэтому обычно проще перейти на ручной маршрут с помощью WSO2.
Также обратите внимание, что продукты WSO2 являются Java расширения (в основном обертки) вокруг других продуктов Apache (как Tomcat/Synapse), так как правило, если у вас возникли проблемы с WSO2, его, так как основная система (Tomcat/Synapse) не был должным образом (хотя это не ошибка, так как в документации WSO2 не упоминается о том, что базовая система настроена правильно).
Также обратите внимание, что при тестировании продуктов WSO2 они потребляют огромные объемы памяти (не могут работать больше, чем ESB и BAM на одной машине из-за 8GB + памяти, потребляемой каждым), и нужно было поставить билет на неисправность чтобы исправить утечку памяти, обнаруженную в Java-модулях WSO2, не уверен, что это было когда-либо исправлено.
Не пытайтесь отрицать WSO2, но просто предупреждайте, что это не очень хорошо, и вам может быть лучше с другими опциями «облака», если у вас есть выбор.
Редактировать: Мне пришлось тестировать различные «облачные» стеки (с разными типами «плагинов» или веб-сервисов, если хотите) и насколько они совместимы; как оказалось, они довольно интероперабельны, если у вас есть полный контроль над отдельными стеками, иначе самое большое падение любого из стеков, которые я нашел, это просто документация ... Мне все равно, есть ли у программы ошибки или проблемы , если они правильно документированы с возможными обходными способами (если они есть), так что я знаю, что происходит в моем стеке. Поскольку продукты WSO2 были всего лишь оболочкой Java для версий Apache своих предложений (например, ESB == Apache Synapse WSO2), все проблемы, которые возникали там, где обычно решались в документации Apache (что мало у них было для определенных проблем), в то время как документация WSO2 имела много копирование/вставка (если у них была какая-либо документация, кроме версии 1). Обычно проще просто загружать и устанавливать фактические предложения Apache по предложениям WSO2, а затем устанавливать продукты WSO2 и указывать их на правильные конфигурации/установки Apache.
Я провел некоторое тестирование с помощью стека Microsoft с помощью Azure и общих предложений IIS/.NET для эквивалентных служб (эквиваленты IIS/.NET для ESB/CEP/BAM/и т. Д. Для того, что можно было найти). На стороне MS документации было достаточно (и сейчас есть достаточно людей, которые покупают рекламу облака), что я мог бы противостоять большинству услуг полулегким. Я говорю полулегкое из-за неправильного (или моего недоразумения) «удобства использования» услуг «облака». Я также нашел продукт под названием Neuron ESB, который является предложением .NET ESB, хотя я ничего не делал с ним во время тестирования, поэтому я не могу говорить с ним.
Испытание Amazon's offerings оказалось более простым в настройке и настройке; самой большой проблемой с тем, что я тестировал для AWS, была общая латентность в Интернете.
Большая часть этого является личным домыслом, и я настоятельно рекомендую вам оценивать каждого, поскольку пространство «облака» постоянно меняется, и каждая облачная платформа имеет нечто несколько отличающееся.
TLDR: облачное пространство может многое предложить, и нужно действительно подумать о том, чего они пытаются достичь в конечном итоге, а затем оценить предложения каждой платформы, чтобы увидеть, что подходит. При этом документация и совместимость с внутренними поставщиками (т. Е. Способность продуктов поставщика легко связываться друг с другом) определенно помогают коэффициенту «повторного использования» продукта.
Спасибо за понимание - я перестану пытаться изо всех сил, чтобы все это в одном. Там по-прежнему есть выбор платформы - есть ли у вас другие, которые вы бы порекомендовали, чтобы создать стек событий - в идеале - доступную локальную установку, а также облачную платформу. Но можете пересмотреть все ограничения ... – AndyJonesMZ
Я отредактировал свой ответ, чтобы дать больше отзывов об этом влиянии. Надеюсь, поможет – txtechhelp