Углерод не любит хорошо сочетаться с другими компонентами. Мне никогда не удавалось успешно использовать 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 на одной машине из-за того, что каждый из них потреблял более 8 ГБ памяти), и для устранения проблемы необходимо было отправить заявку на устранение неисправности. утечка памяти обнаружена в модулях Java WSO2, не уверен, что это когда-либо было исправлено.
Не пытаюсь отрицать WSO2, но просто имейте в виду, что это не очень приятное мероприятие, и вы можете добиться большего успеха с другими «облачными» вариантами, если у вас есть выбор.
изменить: мне пришлось протестировать различные «облачные» стеки (с разными типами «плагинов» или веб-сервисов, если хотите) и насколько они совместимы; как оказалось, они довольно совместимы, если у ВАС есть полный контроль над отдельными стеками, в противном случае самым большим падением любого из стеков, которые я обнаружил, была просто документация... Меня не волнует, есть ли в программе ошибки или проблемы. , если они должным образом задокументированы с возможными обходными путями (если таковые имеются), чтобы я знал, что происходит в моем стеке. Поскольку продукты WSO2 были просто Java-оболочками для версий Apache своих предложений (т. е. WSO2 ESB == Apache Synapse), любые проблемы, которые возникали, обычно решались в документации Apache (то немногое, что у них было для определенных проблем), в то время как в документации WSO2 было много информации. проблемы с копированием/вставкой (если у них была какая-либо документация после версии 1). Обычно было проще просто загрузить и установить фактические предложения Apache по сравнению с предложениями WSO2, а затем установить продукты WSO2 и указать им действительные конфигурации/установки Apache.
Я провел некоторое тестирование со стеком Microsoft с Azure и общими предложениями эквивалентных услуг IIS/.NET. (Эквиваленты IIS/.NET ESB/CEP/BAM/и т. д. для того, что можно было найти). Что касается MS, документации было достаточно (и сейчас достаточно людей покупаются на ажиотаж вокруг облака), чтобы я мог легко поддерживать большинство сервисов. Я говорю «полупростой» из-за неправильного названия (или моего непонимания) «простоты использования» «облачных» сервисов. Я также нашел продукт под названием Neuron ESB, который представляет собой предложение .NET ESB, хотя я ничего не делал. с ним во время моего тестирования, поэтому я не могу говорить с ним.
Тестирование предложений Amazon оказалось одним из самых простых в установке и настройке; Самая большая проблема с тем, что я тестировал для AWS, заключалась в общей задержке в Интернете.
Большая часть этого является личным предположением, и я настоятельно рекомендую вам оценить каждое из них, поскольку «облачное» пространство постоянно меняется, и каждая облачная платформа может предложить что-то немного другое.
TLDR: облачное пространство может многое предложить, и нужно действительно подумать, чего они пытаются достичь в долгосрочной перспективе, а затем оценить предложения каждой платформы, чтобы увидеть, какие из них подходят. При этом документация и внутренняя интероперабельность поставщиков (т. е. способность продуктов поставщиков легко взаимодействовать друг с другом) определенно помогают фактору «повторного использования» продукта.
person
txtechhelp
schedule
17.12.2013
