Все зависит от целей и задач, которые вы ставите при описании БП. Можете описать на таком уровне абстракции, что не привязаны, а можете так , что привязаны. И что за система - ее архитектура может влиять на БП, а может быть чисто технической и не влиять. Приведенный кейс актуален для систем организационного управления , где как правило архитектура и БП взаимосвязаны
Вы про микросервисы или про внутреннее устройство БД?
Я про спорность утверждения о единственности таблицы остатков
Ну либо всё же признайте - вам сказано "внедрить", а зачем - не важно.
Признаю : были сформулированы нефункциональные требования и архитектором , как лицом, отвечающим за НФТ, были приняты соответствующие архитектурные решения, которые он согласовал с заинтересованными лицами. Ни ход выполнения проекта, ни результат его выполнения не показал, что принятые архитектурные решения были неверными.
В принципе область эффективности МСА была четко обозначена еще Фаулером, и с того времени , IMHO, по этой теме мало кто чего добавил. Во всяком случае я что-то добавить не готов
Для каждой подсистемы потребуется Архитектурная схема, как ее правильно нарисовать? В UML для этого нет подходящих диаграмм, давайте посмотрим на Archimate:
Почему приведенный пример архитектурной схемы не отрисовывается на UML ? Archimate по сути это такой упрощенный вариант UML, такой архитекторский "суржик" :)
При этом помимо перечисленных ОСНОВНЫХ компонентов при необходимости можно использовать и другие элементы. Например я часто использую на компонентных диаграммах information flow (хотя если нужно, то в EA можно использовать старый добрый DFD), могу отразить отношения композиции (помимо визуальной вложенности компонентов). UML ничем не ограничивает использование дополнительных элементов при условии, что мы обеспечиваем адекватную интерпретацию этой диаграммы
Не пытайтесь рисовать это в Visio, Enterprise Architect или аналогах. Для проектирования баз данных есть много специализированных инструментов, которые заточены под конкретные СУБД, пользуйтесь ими.
При использовании специализированных инструментов нет возможности использовать трассировочные связи с другими видами диаграмм. Ну и не очень понятен смысл специализации скажем в реляционных СУБД. Что в них такого специфического? Типы данных? Это вопрос поддержки инструмента в актуальном состоянии.
При этом универсальные инструменты в том же Sparx EA позволяют достаточно удобные вещи: например автоматическую генерацию DDL не только на создание БД, но и на изменение. Это очень удобно при переносе изменений между средами.
Физически шарды логических таблиц - это как правило разные таблицы, даже если шардирование выполняется средствами СУБД. Просто СУБД "проксирует" запросы. При этом возможен вариант шардирования "снаружи", не системными средствами. Например в том случае, если мы строим распределенную структуру и у каждого подразделения или у каждой товарной группы своя БД. В этом случае можно говорить только об одной сущности, а не об одной таблице
Возможно, вам было бы проще, если бы вы не приводили примеры микросервисов. Просто принято решение - перейти.
Без обьяснения мотивов перехода на МСА на мой взгляд нельзя сформулировать требования к потоку моделирования.
>Всегда останется задача проверки остатков по позициям, что предполагает одну БД и одну таблицу в ней.
На мой взгляд, очень спорное утверждение: обработка информации об остатках совершенно не требует одной базы и одной таблицы. Необходимость централизованной обработки информации об остатках не исключает возможность применения МСА - например можно выделить микросервис "Запас", при этом шардировать таблицу с остатками например по подразделениям (местам хранения) , а то и по типам товара или товарным группам. Таким образом мы сможем масшабировать этот микросервис и разделить нагрузку между экземплярами микросервиса и соответствующими ему шардами.
Если идти дальше, то можно разделить функции чтения и записи информации об остатках : изменять остатки в OLTP , затем через ETL выкладывать срезы остатков на витрины.
Но на самом деле эффект от МСА будет уже тогда, когда мы сможем собрать все бизнес-функции по работе с товарным запасом в одном микросервисе, отделив их от других функций, связанных с продуктами : управлением ассортиментом, управлением ценами и т.д., что в ERP реализуется на связанных таблицах БД монолита
В любом случае целесообразность таких шагов определяется в конкретном проекте
>Второй пункт - вообще никак не связан с микросервисами, поскольку это всего лишь распараллеливание обработки на абсолютно одинаковых обработчиках.
Ну все таки как-то связан :) Запуск многих экземпляров обработчиков, выделенных в отдельный микросервис, управляемых общим оркестровщиком - довольно распространеное решение для паралельной обработки. Хотя согласен, что есть и другие способы ее реализации.
>То есть с самого начала текста ставится ложная задача - перейдём на микросервисы
Не ставилась такая задача. Ну и вообще тема статьи - это не микросервисы vs монолит. Выработка критериев перехода и принятие решения по миграции на МСА - это вообще прерогатива архитекторов. Аналитик работает с уже принятым решением и обеспечивает этог переход
Про шардирование: Шардировать и партиционировать БД безусловно можно и при монолите. Вопрос в том, какая задача в итоге ставиться - горизонтально масштабировать монолит все равно не получиться. Но например чуть повысить производительность за счет уменьшения размера активных таблиц можно. Но при этом делать шардирование и партиционирование механически , не задумываясь о том, как будут проходить транзакции, не будет ли возникать конкуренция за данные, не будет ли падать производительность за счет работы с разными шардами и т.д. не получиться. Все равно нужно будет в какой-то части выполнить работы по изоляции по данным модулей или сервисов , даже, если архитектура останется монолитной
Рост сетевого трафика конечно тоже надо учитывать. Но если все хорошо спроектировано, то он не должен стать критичным: трафик между сервером приложений и сервером БД тоже идет через сеть. Ну и если все микросервисы в одном ЦОДе , то проблема скорости сети как правило не очень критична. А вот если в процессе миграции на МСА идет переход на распределенную систему, то это в большей степени проблема миграции на распределенную систему, чем на МСА. Но все конечно надо считать.
Все зависит от целей и задач, которые вы ставите при описании БП. Можете описать на таком уровне абстракции, что не привязаны, а можете так , что привязаны. И что за система - ее архитектура может влиять на БП, а может быть чисто технической и не влиять.
Приведенный кейс актуален для систем организационного управления , где как правило архитектура и БП взаимосвязаны
Я про спорность утверждения о единственности таблицы остатков
Признаю : были сформулированы нефункциональные требования и архитектором , как лицом, отвечающим за НФТ, были приняты соответствующие архитектурные решения, которые он согласовал с заинтересованными лицами. Ни ход выполнения проекта, ни результат его выполнения не показал, что принятые архитектурные решения были неверными.
В принципе область эффективности МСА была четко обозначена еще Фаулером, и с того времени , IMHO, по этой теме мало кто чего добавил. Во всяком случае я что-то добавить не готов
Почему приведенный пример архитектурной схемы не отрисовывается на UML ? Archimate по сути это такой упрощенный вариант UML, такой архитекторский "суржик" :)
Например компонентная диаграмма:
https://www.uml-diagrams.org/component-diagrams.html
При этом помимо перечисленных ОСНОВНЫХ компонентов при необходимости можно использовать и другие элементы. Например я часто использую на компонентных диаграммах information flow (хотя если нужно, то в EA можно использовать старый добрый DFD), могу отразить отношения композиции (помимо визуальной вложенности компонентов). UML ничем не ограничивает использование дополнительных элементов при условии, что мы обеспечиваем адекватную интерпретацию этой диаграммы
При использовании специализированных инструментов нет возможности использовать трассировочные связи с другими видами диаграмм. Ну и не очень понятен смысл специализации скажем в реляционных СУБД. Что в них такого специфического? Типы данных? Это вопрос поддержки инструмента в актуальном состоянии.
При этом универсальные инструменты в том же Sparx EA позволяют достаточно удобные вещи: например автоматическую генерацию DDL не только на создание БД, но и на изменение. Это очень удобно при переносе изменений между средами.
Согласен. Сейчас еще его плюсом явлется то, что его разработчик базируется в Гонконге. Но на момент этого проекта это было еще неактуально :)
Физически шарды логических таблиц - это как правило разные таблицы, даже если шардирование выполняется средствами СУБД. Просто СУБД "проксирует" запросы. При этом возможен вариант шардирования "снаружи", не системными средствами. Например в том случае, если мы строим распределенную структуру и у каждого подразделения или у каждой товарной группы своя БД. В этом случае можно говорить только об одной сущности, а не об одной таблице
Без обьяснения мотивов перехода на МСА на мой взгляд нельзя сформулировать требования к потоку моделирования.
Именно так
>Всегда останется задача проверки остатков по позициям, что предполагает одну БД и одну таблицу в ней.
На мой взгляд, очень спорное утверждение: обработка информации об остатках совершенно не требует одной базы и одной таблицы. Необходимость централизованной обработки информации об остатках не исключает возможность применения МСА - например можно выделить микросервис "Запас", при этом шардировать таблицу с остатками например по подразделениям (местам хранения) , а то и по типам товара или товарным группам. Таким образом мы сможем масшабировать этот микросервис и разделить нагрузку между экземплярами микросервиса и соответствующими ему шардами.
Если идти дальше, то можно разделить функции чтения и записи информации об остатках : изменять остатки в OLTP , затем через ETL выкладывать срезы остатков на витрины.
Но на самом деле эффект от МСА будет уже тогда, когда мы сможем собрать все бизнес-функции по работе с товарным запасом в одном микросервисе, отделив их от других функций, связанных с продуктами : управлением ассортиментом, управлением ценами и т.д., что в ERP реализуется на связанных таблицах БД монолита
В любом случае целесообразность таких шагов определяется в конкретном проекте
>Второй пункт - вообще никак не связан с микросервисами, поскольку это всего лишь распараллеливание обработки на абсолютно одинаковых обработчиках.
Ну все таки как-то связан :) Запуск многих экземпляров обработчиков, выделенных в отдельный микросервис, управляемых общим оркестровщиком - довольно распространеное решение для паралельной обработки. Хотя согласен, что есть и другие способы ее реализации.
>То есть с самого начала текста ставится ложная задача - перейдём на микросервисы
Не ставилась такая задача. Ну и вообще тема статьи - это не микросервисы vs монолит. Выработка критериев перехода и принятие решения по миграции на МСА - это вообще прерогатива архитекторов. Аналитик работает с уже принятым решением и обеспечивает этог переход
Про шардирование:
Шардировать и партиционировать БД безусловно можно и при монолите. Вопрос в том, какая задача в итоге ставиться - горизонтально масштабировать монолит все равно не получиться. Но например чуть повысить производительность за счет уменьшения размера активных таблиц можно. Но при этом делать шардирование и партиционирование механически , не задумываясь о том, как будут проходить транзакции, не будет ли возникать конкуренция за данные, не будет ли падать производительность за счет работы с разными шардами и т.д. не получиться. Все равно нужно будет в какой-то части выполнить работы по изоляции по данным модулей или сервисов , даже, если архитектура останется монолитной
Рост сетевого трафика конечно тоже надо учитывать. Но если все хорошо спроектировано, то он не должен стать критичным: трафик между сервером приложений и сервером БД тоже идет через сеть. Ну и если все микросервисы в одном ЦОДе , то проблема скорости сети как правило не очень критична. А вот если в процессе миграции на МСА идет переход на распределенную систему, то это в большей степени проблема миграции на распределенную систему, чем на МСА. Но все конечно надо считать.