SOA: библиотеки против сервисов: может ли библиотека быть лучшим вариантом?

Question

Я работаю с WCF 4.0 и хорошо представляю, как создавать сервисы с технической точки зрения. Я работаю с WCF уже 3 года.

Несмотря на это, я и другие, с кем я общаюсь, имеют разные представления о том, какой должна быть единица программного обеспечения, составляющего услугу, а что нет. Многие люди, с которыми я общаюсь, считают, что услуги должны быть гранулярными. Действительно, моя предыдущая компания провела много времени, превращая некоторые из своих сборок в службы (так мне сказали).

Во многих случаях я не вижу, как услуга лучше ... и, возможно, это не всегда должно быть. Я приведу вам пример: в нашей системе есть большой сервис, который действительно вырос для выполнения двух разных независимых работ. Я собираюсь разделить его на две службы по двум причинам: производительность и изоляция ошибок (мы размещаемся в службе Windows, а не IIS). Дело в том, что, несмотря на обслуживание двух независимых бизнес-процессов (один сервис может быть недоступен, не влияя на другой), оба имеют значительную часть общей бизнес-логики.

Теперь некоторые советуют мне, чтобы эта общая логика была разделена на 3-й сервис в соответствии с принципами SOA и использовался двумя недавно разделенными сервисами. На мой взгляд, это лишь частично сводит на нет преимущество разделения большого сервиса в первую очередь: мы ввели узкое место в производительности и единую точку отказа. Если процесс хоста 3-го сервиса не работает, 1 и 2 больше не могут выполнять свою работу. Это происходит с нами сейчас, когда у нас есть «глубокая» структура многих услуг. Один выходит, и любые зависимые службы увеличивают время ожидания цепочки, поскольку на их звонки никогда не отвечают.

Теперь, если общая логика была просто библиотекой, а не службой, мы получаем преимущество повторного использования кода, отсутствие узких мест в производительности и изоляции отказов, поскольку каждая служба выполняет свою собственную копию сборки в своей собственной памяти. Также нет затрат на сериализацию.

Что думают люди по этому поводу? Есть ли правило или общее руководство, когда дело доходит до решения, когда что-то должно быть службой или библиотекой? Любой другой совет?

Спасибо Michael

Answer 1

Это справедливый аргумент против использования сервисов, но правильный подход, вероятно, заключается в использовании сервисной шины.

Затем вы можете запустить несколько сервисов для выполнения ваших «основных» функций. Вы получаете избыточность и надежность (вы можете даже направить ваши процессы 1 и 2 на отдельные экземпляры, если вам нужно, но предпочитаете балансировку нагрузки), но вы получаете слабую связь и удобство обслуживания отдельных сервисов.

Я считаю, что SOA - это отличный принцип, но он использует очень осторожную архитектуру и очень легко ошибиться. И если вы все сделаете неправильно, последствия могут быть ужасными.

Answer 2

Вероятно, для меня есть два ключевых соображения, чтобы понять, может ли библиотека или служба быть лучшим подходом к данной проблеме.

Во-первых, потенциальные потребители: если они будут полностью под вашим контролем, и для них будет целесообразно разместить их в процессе, тогда библиотека будет законным подходом. Если нет возможности внешнего потребления, то это, вероятно, лучший выбор, потому что усилия по проектированию, разработке и тестированию, вероятно, будут значительно меньше, чем эквивалентное обслуживание.

Вторым является «гранулярность» API. Сервисы должны быть спроектированы так, чтобы уменьшить «болтливость» - хороший сервис, как правило, имеет мощные операции, поведение которых меняется в зависимости от содержимого сообщения. Например. Addorder (msg) против CreateHeader (h), GetCustomer (c), AddOrderCustomer (h, c), AddOrderLine (p, 1) и т. Д. Первое - это то, что я ожидаю от операции службы, тогда как последнее будет более типичным библиотеки. Если проблема не связана с этим стилем API, или вы не можете приложить необходимые усилия, чтобы сделать этот дизайн правильным, тогда библиотека была бы более подходящей.