После двух десятилетий в качестве разработчика, я хотел бы обобщить свои мысли о теме, которая несколько раз пересекала мой путь: SOA . Высокоуровневое определение SOA — это разработка и объединение сервисов в нечто большее. Надеемся, что эта комбинация полезна в качестве продукта, тогда как каждая услуга должна быть независимой и многократно использоваться самостоятельно.
SOA, как умное слово, интенсивно использовался в технических статьях, и многие разработчики, вероятно, думали: «Эй, это будет хорошо смотреться в моем резюме / резюме». В других случаях было принято решение руководства о внедрении SOA, так как его легко бросить эти 3 буквы против любой проблемы. В конце концов, нас всех учили «Разделяй и властвуй», верно?
Прежде чем продолжить чтение, я, вероятно, должен предупредить вас: я думаю, что во многих случаях SOA — это неправильный подход. Я работал во многих компаниях, использующих SOA, и видел, как многие проекты проваливались или боролись. Недавно у меня было небольшое прозрение, и я должен сказать: мне действительно нравится идея иметь монолитные веб-приложения. Я, наверное, должен объяснить …
развитие
Обычно разработчик работает и запускает свое приложение на своей локальной машине. Для разработчика Rails все, что вам нужно сделать, — это запустить rails server Когда вы выделяете один сервис из своего приложения, вам нужно будет запустить этот сервис отдельно, прежде чем вы сможете начать свою работу. Когда что-то не работает, вам придется просматривать журналы вашего приложения и вашего сервиса.
Конечно, это будет работать и не похоже на большие накладные расходы, но подумайте о том, чтобы задействовать пять или, может быть, даже 10 услуг. Теперь вы должны запустить их все, найти журналы, если что-то пошло не так и так далее. Позже вы попробуете автоматизировать вещи, возможно, воспользуетесь некоторыми инструментами управления конфигурацией для автоматической установки всех сервисов и даже представите какой-нибудь централизованный инструмент управления журналами. Суть в следующем: вам потребуется больше времени, чтобы сделать то же самое по сравнению с монолитным приложением.
тестирование
Давайте обсудим тестирование на секунду. Вы хотите протестировать свое приложение с помощью автоматических интеграционных тестов , верно? Один из вариантов — использовать существующую службу, работающую в системе интеграции, и протестировать ее. Мы делали это много раз, и часто мы забывали проверить, какая версия сервиса была там запущена. Уверяю вас, это отличный способ убить несколько часов.
Тем не менее, вы можете издеваться над всем. Это в основном удваивает вашу работу по тестированию, потому что при изменении поведения службы вам теперь также нужно изменить свои макеты. Возможно, вы решите запустить новые экземпляры каждого сервиса при запуске интеграционных тестов. Это, вероятно, самый безопасный способ, но для его реализации требуется время и время для каждого теста.
развертывание
Вы должны развернуть эти службы и ваше веб-приложение. Необходимы некоторые усилия по управлению, чтобы знать, что развертывать и какие побочные эффекты возможны. Если вы выполняете непрерывное развертывание, и каждый коммит с зелеными тестами может быть запущен, то вы можете быть в порядке в большинстве случаев. Тем не менее, если вы будете развертывать один раз в неделю, это определенно станет сложнее. Многие люди думают, что развертывание службы проще, чем развертывание всего приложения.
Я не понимаю этого. Когда у вас есть кластер веб-серверов Rails за балансировщиком нагрузки, вы можете развертывать их один за другим без какого-либо влияния на пользователя. Вообще говоря: развертывание службы в рабочей среде обычно также означает наличие кластера именно этой службы, чтобы обеспечить развертывание без влияния пользователя. Поэтому вам, вероятно, потребуется балансировщик нагрузки для каждой настроенной службы. Это может стать ужасным в спешке.
пересчет
В монолитном приложении масштабирование довольно просто. Если ваше приложение работает медленно, вы добавите несколько серверов для масштабирования или купите более крупные машины. Возможно, вы разбили БД и имеете больше серверов БД ( шардинг ). Наличие пары услуг означает, что вам придется масштабировать каждую из этих услуг. Что делать, если один сервис довольно занят? Теперь эта служба нуждается в другой машине, и вам придется отслеживать, какие службы работают медленно по отдельности.
операции
В операциях вы хотите некоторый мониторинг работоспособности систем. Вы можете использовать Munin для отображения времени отклика или Nagios, чтобы увидеть, что все серверы работают. С SOA у вас обычно есть дюжина сервисов для мониторинга.
Производительность и надежность
Установление HTTP-соединения с вашим сервисом намного медленнее, чем просто вызов библиотеки / гема или некоторого кода внутри вашего приложения. Вы должны помнить, как устроены ваши сервисные звонки. Интерфейс должен быть довольно сложным, поскольку цель должна состоять в том, чтобы вызывать службу только один раз на запрос пользователя, чтобы поддерживать низкую задержку. Помните, что каждый звонок в ваш сервис займет пару миллисекунд. Это вполне приемлемо, если вы вызываете его один раз, но если вы вызываете его сто раз для обслуживания одного запроса пользователя, у вас большие проблемы.
Если вы думаете, что ваше сокетное соединение с сервисом так же надежно, как и вызов метода внутри вашего приложения, вы будете удивлены. Соединение с сокетом обрабатывается как открытый файл в Linux. Если один из ваших сервисов работает медленно (возможно, отсутствует индекс ), каждый вызов службы выполняется в течение тайм-аута. Поскольку ваши клиенты все еще отправляют запросы, количество сокетов увеличивается. В конце концов, вы столкнетесь с лимитом сокетов, чтобы выяснить, какая служба отвечает за аварию. Тем временем ваше приложение закрыто, и вы наслаждаетесь расслабляющими мелодиями всех сирен и мигающими красными огнями.
Параметры
Это все, что говорится … каковы ваши варианты?
Одним из вариантов может быть разрезать вашу систему вертикально, а не горизонтально. То есть вместо того, чтобы помещать ваши вещи низкого уровня в службы, попробуйте разделить ваше приложение на разные домены, возможно, одно приложение Rails для управления профилями пользователей, другое для взаимодействия с другими и так далее. Эти приложения могут совместно использовать базу данных или иметь разные базы данных и при необходимости обмениваться данными через службы REST .
Когда услуги адекватны?
В крупных компаниях у каждого отдела есть свой набор приложений. Они могут даже использовать несколько языков программирования или каркасов. Если им нужно связаться со службой, которая нужна многим приложениям, например, для предотвращения мошенничества, я не верю, что есть какой-то способ обойти SOA.
Резюме
На мой взгляд, важно, чтобы каждый разработчик и архитектор задумался о последствиях предоставления услуг. Мы не должны делать это, потому что это круто, а не просто потому, что это делают другие компании, так как это может привести к будущим неприятностям. Помните, что при извлечении кода в службу у нас есть еще одно приложение для развертывания, обслуживания и мониторинга. Кроме того, у нас есть дополнительное сетевое взаимодействие, которое может дать сбой и будет значительно медленнее, чем вызов функций или библиотек на одном компьютере.
Проще говоря: если вещи становятся слишком большими и уродливыми, у нас есть другие методы, такие как разделение нашего приложения по горизонтали или создание библиотек / гемов.
Каковы ваши мнения или опыт в отношении SOA?