Благодарю за оценку ) Если говорить именно про ELMA365, то да, там изначально заложили микросервисную архитектуру, т.к. начиналось она как разработка облачного сервиса. Прошлый наш продукт (ELMA3 и ELMA4), были монолитными решениями. По поводу производительности, если я правильно понял то вопрос именно про произовдительность в облачной версии. Поправьте меня, если не правильно понял. В облачной версии мы реализовали лимиты, на время выполнения серверных сценариев, объемы выборок данных и прочее. То есть там намеренно ограничена высокая нагрузка, чтобы это не мешало работе нескольких компаний. А при росте числа компаний, есть инструменты горизонтального масштабирования мощностей (добавляются поды сервисов).
Хочу заметить, что хоть мы и не выделили отдельные базы под каждый сервис, но каждый микросервис ходит в свой набор таблиц, а при необходимости получить данные другого сервиса, обращение идет через API этого сервиса (grpc вызов как правило). Одно исключение у нас получилось - это сервис отчетности, он напрямую в базу ходит к данным разных сервисов. Но основным мотивом не разделять базу у нас было упрощение администрирования. Но возможно вы правы, и под строгое определение микросервисов мы не подходим и у нас некоторый гибрид получился. Про название архитектуры спорить не буду ) А по поводу монолита, наш прошлый продукт как раз был модульным монолитом, но его архитектура нам не очень подходила для SaaS версии системы, поэтому и решились на переработку архитектуры.
Да, упустил этот момент. Тут сошлось несколько факторов.
Для начала обозначу, что в системе для разработчика доступы на серверные скрипты, так и клиентские, исполняемые в браузере. Хотелось использовать один язык и для клиентской и серверной стороны, чтобы не заставлять локодеров разбираться в 2 языках, а также сохранить переносимость кода между сервером и клиентом. И тут TypeScript с его совместимостью с JavaScript хорошо ложится.
Для сохранения изоляции между тенантами и безопасности разработки серверные скрипты исполняются в песочнице и тут хорошо подходит для исполнения node.js.
Фронтенд у нас разрабатывается на Angular, который использует как раз TypeScript, поэтому он был нам изначально близок. И статическая типизация, на наш взгляд, немного снижает количество ошибок в рантайме и, как нам кажется, больше подходит непрофессиональным программистам. Но это, конечно, вопрос предпочтений.
Согласен, если не главная, то одна из них. У нас большая часть взаимодействия между сервисами идет синхронно, с вызовами через GRPC, без участия шины. Это снимает большую часть боли. Через шину у нас идут взаимодействия построенное по событийной модели, передача на исполнение скриптов, разработанных лоукодерами, а так же исполнение бизнес-процессов. В целом на практике это случается не так часто и такие проблемы либо не супер критичны, либо их обрабатываем вручную.
Благодарю за оценку )
Если говорить именно про ELMA365, то да, там изначально заложили микросервисную архитектуру, т.к. начиналось она как разработка облачного сервиса. Прошлый наш продукт (ELMA3 и ELMA4), были монолитными решениями.
По поводу производительности, если я правильно понял то вопрос именно про произовдительность в облачной версии. Поправьте меня, если не правильно понял. В облачной версии мы реализовали лимиты, на время выполнения серверных сценариев, объемы выборок данных и прочее. То есть там намеренно ограничена высокая нагрузка, чтобы это не мешало работе нескольких компаний. А при росте числа компаний, есть инструменты горизонтального масштабирования мощностей (добавляются поды сервисов).
Хочу заметить, что хоть мы и не выделили отдельные базы под каждый сервис, но каждый микросервис ходит в свой набор таблиц, а при необходимости получить данные другого сервиса, обращение идет через API этого сервиса (grpc вызов как правило). Одно исключение у нас получилось - это сервис отчетности, он напрямую в базу ходит к данным разных сервисов. Но основным мотивом не разделять базу у нас было упрощение администрирования.
Но возможно вы правы, и под строгое определение микросервисов мы не подходим и у нас некоторый гибрид получился. Про название архитектуры спорить не буду )
А по поводу монолита, наш прошлый продукт как раз был модульным монолитом, но его архитектура нам не очень подходила для SaaS версии системы, поэтому и решились на переработку архитектуры.
Да, упустил этот момент. Тут сошлось несколько факторов.
Для начала обозначу, что в системе для разработчика доступы на серверные скрипты, так и клиентские, исполняемые в браузере. Хотелось использовать один язык и для клиентской и серверной стороны, чтобы не заставлять локодеров разбираться в 2 языках, а также сохранить переносимость кода между сервером и клиентом. И тут TypeScript с его совместимостью с JavaScript хорошо ложится.
Для сохранения изоляции между тенантами и безопасности разработки серверные скрипты исполняются в песочнице и тут хорошо подходит для исполнения node.js.
Фронтенд у нас разрабатывается на Angular, который использует как раз TypeScript, поэтому он был нам изначально близок. И статическая типизация, на наш взгляд, немного снижает количество ошибок в рантайме и, как нам кажется, больше подходит непрофессиональным программистам. Но это, конечно, вопрос предпочтений.
Согласен, если не главная, то одна из них. У нас большая часть взаимодействия между сервисами идет синхронно, с вызовами через GRPC, без участия шины. Это снимает большую часть боли. Через шину у нас идут взаимодействия построенное по событийной модели, передача на исполнение скриптов, разработанных лоукодерами, а так же исполнение бизнес-процессов. В целом на практике это случается не так часто и такие проблемы либо не супер критичны, либо их обрабатываем вручную.