Comments 15
А где SOA-то? Как сделана маршрутизация, как сделаны service descriptions/service discovery? Где проходит граница автономности сервисов? Как вы решаете проблемы версионирования контрактов? Есть ли оркестровка, и если да, то на базе чего?
Где проходит граница автономности сервисов?
На данный момент лишь сделан этап разделения бизнес логики на слои/службы с заранее оговоренным api, доступным либо внутри группы через механизм компонентов в Yii (эту задачу в частности выполняет backend), либо для всех смежных групп через rest (shared). Дальнейшим шагом развития и перехода к soa я вижу в организации реестра служб, над этой задачей в частности и работает наш межсистемный архитектор. Мы же со своей стороны постарались уйти от монолитного приложения к службам с заранее очерченными границами, выполняющими конкретную задачу бизнеса.
Как вы решаете проблемы версионирования контрактов?
В нашем отделе службы только на начальном этапе и проблемы обратной совместимости апи еще не возникало.
Если же говорить о практике смежных отделов, то при разработке новых методов/доработке старых архитектор каждой группы анализирует возможные подводные камни, подключая при этом архитекторов или разработчиков из смежных групп. Если возникают моменты когда требуется кардинальная переработка существующего метода, например, требуется изменить сигнатуру, то добавляется новый метод. Какого либо версионирования помимо версии debian-пакета на данный момент нет. Все новые пакеты проходят интеграционное тестирование во всех остальных группах разработки.
К сожалению я не погружен во все тонкости данной парадигмы и возможно не до конца понял ваш вопрос.
Если же говорить о практике смежных отделов, то при разработке новых методов/доработке старых архитектор каждой группы анализирует возможные подводные камни, подключая при этом архитекторов или разработчиков из смежных групп. Если возникают моменты когда требуется кардинальная переработка существующего метода, например, требуется изменить сигнатуру, то добавляется новый метод. Какого либо версионирования помимо версии debian-пакета на данный момент нет. Все новые пакеты проходят интеграционное тестирование во всех остальных группах разработки.
К сожалению я не погружен во все тонкости данной парадигмы и возможно не до конца понял ваш вопрос.
Как вы решаете проблемы консистентности бизнес-состояния между двумя службами? Предположим, за информацию о кредите покупателя отвечает один сервис, за информацию о наличии товара на складе — другой. Как вы решаете проблему того, что товар на складе резервируется только в случае достаточности кредитного лимита, но лимит уменьшается только в том случае, когда товар есть на складе?
Как решаются проблемы отказоустойчивости и временной недоступности сервисов?
Как решаются проблемы отказоустойчивости и временной недоступности сервисов?
Как вы решаете проблемы консистентности бизнес-операций между двумя службами?
В компании активно развивается направление BPM, в частности на базе продукта Activiti реализуются некоторые процессы связанные с подключением услуг. Внедрение BPM показало рентабельность данного решения и на него переводится все больше БП. Но у Activiti есть один недостаток. Т.к. это по сути движок БП, то нормального интерфейса для работы с экземплярами процесса нет. Ранее в компании для автоматизации БП использовался workflow engine jira3
Как решаются проблемы отказоустойчивости и временной недоступности сервисов?
насколько мне известно данный вопрос решается лишь на уровне SLA + холодный резерв. Возможно для критически важных для бизнеса служб используется другая схема отказоустойчивости, например, в биллинге.
Прошу прощения, что написал новым комментарием, а не ответом на предыдущий.
В компании активно развивается направление BPM, в частности на базе продукта Activiti реализуются некоторые процессы связанные с подключением услуг. Внедрение BPM показало рентабельность данного решения и на него переводится все больше БП. Но у Activiti есть один недостаток. Т.к. это по сути движок БП, то нормального интерфейса для работы с экземплярами процесса нет. Ранее в компании для автоматизации БП использовался workflow engine jira3
Это ответ вообще на другой вопрос.
насколько мне известно данный вопрос решается лишь на уровне SLA + холодный резерв. Возможно для критически важных для бизнеса служб используется другая схема отказоустойчивости, например, в биллинге.
То есть на уровне вашей архитектуры — никак.
Собственно, я изначально по вашей статье так и подумал — собственно с SOA-то вы еще столкнуться не успели. Декомпоновка на автономные сервисы — это еще не SOA. Так что писать о «переходе» архитектур вам рановато. Деплой компонентов — да.
Это ответ вообще на другой вопрос.
Возможно я не до конца понял вопрос, но в одном из реализованных процессов есть похожий с вашим пример. Например, абоненту нужно активировать точку доступа лишь когда он пополнит баланс на необходимую сумму, а баланс клиент может пополнить лишь при созданном лицевом счете и выделенной точке доступа. В данном случае идет взаимодействие между несколькими службами
Собственно, я изначально по вашей статье так и подумал — собственно с SOA-то вы еще столкнуться не успели. Декомпоновка на автономные сервисы — это еще не SOA. Так что писать о «переходе» архитектур вам рановато. Деплой компонентов — да.
Тут вы правы, о полноценной реализации soa говорить рано. Основной задачей было начать процесс перехода, который естественно включает в себя много этапов. В частности благодаря вашим вопросам я узнал новые аспекты, на которые следует обратить внимание. Целью статьи было показать как можно организовать структуру приложений в случае реализации служб, плюс возможно затронуть некоторые аспекты деплоя через deb-пакеты.
Например, абоненту нужно активировать точку доступа лишь когда он пополнит баланс на необходимую сумму, а баланс клиент может пополнить лишь при созданном лицевом счете и выделенной точке доступа. В данном случае идет взаимодействие между несколькими службами
Как решается вопрос консистентности данных?
как можно организовать структуру приложений в случае реализации служб
Вы понимаете, что после решения озвученных выше проблем эта организация скорее всего изменится?
Как решается вопрос консистентности данных?
данную задачу решает BPM, собственно это его основная задача. Например, сначала создается лицевой счет, если удалось то процесс переходит на следующий шаг, если нет, то выполняет заданное в процессе действие. Например, система может повторить попытку выделения заданное кол-во раз, а затем в случае очередной неудачи выслать уведомление администратору. Безусловно процесс на некоторых его шагах требует принятия решений человеком, так называемое взаимодействие система — человек.
Если же требуется выполнить 2 связанных элементарных операции вне процесса, то данная логика реализуется в esb службе, в которой уже заложена логика в зависимости от результата выполнения каждой операции. Конкретная реализация зависит от конкретной задачи. Общего алгоритма на все случаи жизни нет.
Вы понимаете, что после решения озвученных выше проблем эта организация скорее всего изменится?
Безусловно что-то придется допиливать, без необходимого опыта сделать все идеально с первого раза нельзя. Но имея базис и некий опыт работы с данной структурой гораздо проще спланировать дальнейшее развитие системы. В голову приходят строки «Москва не сразу строилась»
данную задачу решает BPM, собственно это его основная задача. Например, сначала создается лицевой счет, если удалось то процесс переходит на следующий шаг, если нет, то выполняет заданное в процессе действие.
Похоже, я плохо озвучил задачу. Речь идет о наличии двух сервисов, имеющих взаимные требования. В монолитной системе это решается транзакцией, при которой либо будет изменено состояние обеих систем, либо не будет изменено ничего. А в вашей распределенной?
Но имея базис и некий опыт работы с данной структурой гораздо проще спланировать дальнейшее развитие системы.
К сожалению, некоторые вещи в систему нужно закладывать изначально, иначе развитие будет сопоставимо по сложности (а то и превышать, учитывая требования обратной совместимости) с разработкой с нуля.
К сожалению, некоторые вещи в систему нужно закладывать изначально, иначе развитие будет сопоставимо по сложности (а то и превышать, учитывая требования обратной совместимости) с разработкой с нуля.
Буду благодарен если дадите наводку на что стоит сразу обращать внимание, потому что сложилось ощущение, что есть явные огрехи и их желательно сразу устранить, потому пока еще все не зашло далеко.
В монолитной системе это решается транзакцией, при которой либо будет изменено состояние обеих систем, либо не будет изменено ничего. А в вашей распределенной?
На самом деле за время работы в данной компании не припомню задачи, в которой бы была нужна транзакционность при интеграции нескольких служб. Возможно на стороне смежных групп это решается проще ибо написаны они на java и взаимодействие между ними требует меньше накладных ресурсов. Я не готов ответить более детально на данный вопрос. В специфике задач решаемых отделом ВА подобных задач не было.
Буду благодарен если дадите наводку на что стоит сразу обращать внимание, потому что сложилось ощущение, что есть явные огрехи и их желательно сразу устранить, потому пока еще все не зашло далеко.
Да я, в общем, основное, что помню, уже перечислил. Стабильность контракта, версионирование, маршрутизация, отказоустойчивость, обеспечение консистентности. У Эрла наверняка еще перечислено, но зачем же книжку пересказывать?
На самом деле за время работы в данной компании не припомню задачи, в которой бы была нужна транзакционность при интеграции нескольких служб.
Искренне завидую.
Возможно на стороне смежных групп это решается проще ибо написаны они на java и взаимодействие между ними требует меньше накладных ресурсов.
А вот это как раз показывает, что вы не до конца грокнули SOA. Одна из основных прелестей SOA — это интероперабельность, для честной SO-архитектуры не важно, на чем написан каждый конкретный сервис (добавьте интероперабельность в список выше).
Искренне завидую.
Думаю не стоит быть столь категоричным. Было немало не менее интересных и увлекательных задач, но это уже за рамками данной темы.
А вот это как раз показывает, что вы не до конца грокнули SOA
Да вы правы и я это выше отметил. Понимание данной парадигмы один из шагов в моем развитии как профессионала, я думаю многие разработчики проходят через это рано или поздно.
Собственно данная статья была написана еще и с целью получения фидбека и комментариев от людей, ранее столкнувшихся с soa и наступивших на свои грабли.
Собственно роль дирижера в нашем случае выполняет либо Activiti, если это бизнес процесс с оговоренными границами, либо ESB служба, реализующая часть бизнес логики.
Sign up to leave a comment.
Переход от 2-х звенки к архитектуре служб в парадигме SOA