SOA / ESB Дилемма
Извините за очень сложный вопрос, но это то, что я изучал некоторое время, и это действительно расстраивает меня. Я чувствую, что в наше время у нас есть миллион, и один из способов реализовать сервисы кросс-платформенный (SOAP) и простой в создании (благодаря.NET, java и другим фреймворкам). Тем не менее, эти технологии были в сообществе в течение 5-10 лет, но мы (или, по крайней мере, я) постоянно сталкиваемся с одними и теми же проблемами:
- Идентификация (Услуги слежения) - UDDI; например, пришлось напомнить коллеге три раза в этом месяце, где находится служба, несмотря на то, что есть вики, в которой обсуждается служба, и PDF-версия той же документации, которая находится в хранилище, где мы храним наши сервисные документы,
- Масштабируемость - кластеризация из коробки; Как организации, мы тратим много денег на оплату нашим администраторам только для того, чтобы следить за использованием наших сервисов и принимать решения, такие как: нужен ли этот сервис больше оперативной памяти, больше процессора, больше интерфейсов? Как мне это сбалансировать?
- Мониторинг - регистрация ошибок и т.д.; Я не могу сосчитать, сколько раз мне нужно настроить трассировку для служб, чтобы понять, почему происходит ошибка, которая, по-видимому, затрагивает только одного клиента, или приходится кодировать логику в службе, чтобы сериализовать исключения, регистрировать исключения в dbs, терпеть неудачу изящно и т. д.
- Развертывание - простота развертывания; ни один из этих развертываний DLL на 5 серверов с балансировкой нагрузки
Каждая из этих проблем требует определенного типа индивидуального решения, внедренного организацией. Документация и UDDI для #1. Аппаратное и программное обеспечение для виртуализации и балансировки нагрузки для #2. Отслеживание, запись исключений в базы данных / журналы и т. Д. Для #3. Пользовательское программное обеспечение для развертывания #4. Я работаю в организации среднего размера. Я даже не представляю, как компания размером с Sun, Google или Microsoft справится с этими дилеммами.
Может быть, мое видение нереально, но я мечтаю о том, чтобы иметь Framework как таковой, который живет поверх кластера серверов, который управляет всем вышеперечисленным. Я был в восторге от прочтения о Microsoft AppFabric, поскольку она действительно расширяет некоторые возможности BizTalk для разработчиков служб WCF: кэширование, хостинг, мониторинг и т. Д. Однако из того, что я видел, я до сих пор не чувствую, что он живет вплоть до моей мечты о решении "все в одном", которое помогает разработчику и организации в написании сервисов, которые легко масштабируются по кластерам, легко внедряются в кластер и могут быть идентифицированы, возможно, даже в зависимости от версии.
Итак, я не имею в виду этот пост о моей мечте. У меня действительно есть вопрос. Для начала, моя мечта / желание совершенно нереально? Кроме того, какие существуют решения, которые пытаются решить эти проблемы, не ограничивая нас новым и более запатентованным способом (BizTalk) разработки сервисов? И наконец, что касается комплексного решения SOA / ESB, где мы видим наибольший потенциал на рынке сейчас или в будущем?
3 ответа
Я думаю, что вы говорите о различных проблемах здесь.
1). Разработчики, которые не читают документацию. Это эндемическая проблема, не ограничивающаяся SOA - просто взгляните на некоторые вопросы по Stackru. По крайней мере, разработчик спрашивает вас, есть ли сервис, а не просто дублирует логику в собственном коде. Я не вижу никакого технического решения таких проблем, вы уже предоставили хорошие реестры и документацию, но некоторые разработчики предпочитают общаться с людьми. Может быть, даже на самом деле это хорошая вещь - человеческое взаимодействие имеет ценность выше технического содержания взаимодействия. Или, может быть, вы слишком милы: "Нет, я не буду отвечать на этот вопрос, посмотрите его".
2). Scaling. Есть технологии для решения этой проблемы. (Отказ от ответственности Я работаю на IBM, которая продает некоторые из них, поэтому я буду ссылаться на них - я не собираюсь подразумевать, что IBM - единственный поставщик, имеющий решения в этой области.) Существуют такие продукты, как эта, которые могут предоставить новую машину установите программный стек и добавьте его в кластер, чтобы учесть изменения рабочей нагрузки. Тогда на более тонком уровне контроля в мире Java EE Сервер приложений может динамически формировать трафик и настраивать кластеры. См. WebSphere Virtual Enterprise
3). Мониторинг. Я не понимаю, что вы ожидаете здесь. По всей вероятности, такие хитрые ошибки потребуют трассировки уровня приложения. Для некоторых проблем, таких как обнаружение утечек памяти и узких мест производительности, существуют очень хорошие инструменты, по крайней мере, в мире Java EE.
4). Я не могу говорить с миром.Net, но я бы сказал, что серверы приложений Java EE выполняют разумную работу по плавному развертыванию приложений в кластерах, и в тех случаях, когда мы используем JNI и нам нужно развертывание DLL, мы можем использовать продукты например, стек Tivoli, о котором я упомянул для управления этим.
Итак, в целом, я думаю, что поставщики пытаются решить эти проблемы. И я не думаю, что ваша жизнь была бы проще без SOA. Представьте себе, что одни и те же проблемы применяются к множеству независимых приложений.
Вот мои два цента.
Я был разработчиком в компании, которая неправильно использовала SOA. Худшее решение, которое они реализовали, - это проверка на уровне поля элементов формы в настольном приложении с использованием SOA. Для выполнения приемлемо это требует очень низкой задержки. Ожидание 2-4 секунды для перехода на новое поле быстро устареет. Служба работала по сети на сервере biztalk. Все ненавидели это.
Если вы собираетесь это сделать, вам действительно нужно потратить много времени на решение проблем с задержкой в сети, сбоями в обслуживании, временем и временем ожидания.
Не увлекайтесь и думайте, что SOA - решение любой проблемы. Используемый на высоком уровне, он великолепен, а на низком уровне делает ваши приложения хрупкими, медленными и невозможными для отладки.
Если вы поговорите с IBM или одним из крупных поставщиков SOA, у них есть продукты, которые соответствуют каждому сценарию.
Identification (Tracking services) - UDDI; e.g., had to remind a co-worker the 3 times this month where a service is at, despite the fact there is a wiki that discusses the service and a PDF version of the same documentation that lives in a repository where we keep our service docs.
Сервер реестра и репозитория. Приятно то, что он управляет (продвижение, понижение в должности, управление версиями, утверждение), и ваш ESB обычно выполняет "поиск" последних и самых лучших по сравнению с сервером регистрации.
Scalability - Out of the box clustering; As organizations, we spend a lot of money on paying our admins just to watch the utilization of our services and make decisions like, does this service need more RAM, more CPU, more interfaces? How do I load balance this?
Программное обеспечение для мониторинга транзакций, такое как IBM Tivoli Composite Application Manager для SOA. По сути, он отслеживает вещи с горизонтальной точки зрения и позволяет увидеть, есть ли сбой в обслуживании с точки зрения конечного пользователя / конечного приложения.
Что касается вашей кластеризации.... вы должны выбрать хорошее промежуточное ПО и архитектуру. Лично говоря, получите материал, который готов к работе в "облаке". Серверы приложений с NoSQL, соединенные MOM.
Monitoring - error logging, etc; I can't count how many times I have to set up tracing on services in order to see why a bug is happening that only seems to affect one customer, or have to code logic into the service to serialize exceptions, log exceptions to dbs, fail gracefully, etc.
Корпоративные стандарты для ваших разработчиков и поставщиков. Интеграция всех деловых и системных событий в единую панель управления. (Большинство компаний разлили их). Это делается уже в большинстве корпоративных магазинов.
Deployment - easy to deploy; none of this deploying DLLs to 5 load balanced servers
Ааа... Microsoft IIS Web Deployment Tool 2.0. Вы можете синхронизировать 100 серверов MS, просто обновив мастер. Это действительно легко.