Comments 11
Смузи то хоть в перерывах пьёте?
Спасибо за статью, интересно. На мой взгляд, главная проблема микросервисов это шина данных. Что произойдёт если сообщение, по тем или иным причинам, не дойдёт от одного сервиса к другому? Как искать виновного, какой сервис не послал сообщение/где оно теряется?
Согласен, если не главная, то одна из них. У нас большая часть взаимодействия между сервисами идет синхронно, с вызовами через GRPC, без участия шины. Это снимает большую часть боли. Через шину у нас идут взаимодействия построенное по событийной модели, передача на исполнение скриптов, разработанных лоукодерами, а так же исполнение бизнес-процессов. В целом на практике это случается не так часто и такие проблемы либо не супер критичны, либо их обрабатываем вручную.
Все четко и понятно, спасибо за труд
не написано, почему выбран typescript для языка low-code разработки.
Да, упустил этот момент. Тут сошлось несколько факторов.
Для начала обозначу, что в системе для разработчика доступы на серверные скрипты, так и клиентские, исполняемые в браузере. Хотелось использовать один язык и для клиентской и серверной стороны, чтобы не заставлять локодеров разбираться в 2 языках, а также сохранить переносимость кода между сервером и клиентом. И тут TypeScript с его совместимостью с JavaScript хорошо ложится.
Для сохранения изоляции между тенантами и безопасности разработки серверные скрипты исполняются в песочнице и тут хорошо подходит для исполнения node.js.
Фронтенд у нас разрабатывается на Angular, который использует как раз TypeScript, поэтому он был нам изначально близок. И статическая типизация, на наш взгляд, немного снижает количество ошибок в рантайме и, как нам кажется, больше подходит непрофессиональным программистам. Но это, конечно, вопрос предпочтений.
Спасибо за такой лонгрид, Алексей, было полезно! С ELMA365 плотно работаем на проектах, внедряем нашим заказчикам. Нравится скорость разработки, функционал и свобода для реализаций всяческого кастома )
"мы не стали выделять отдельные базы под каждый микросервис"
Ясно, понятно.
Это не микросервисы, это SBA или SOA - смотря что у вас там внутри.
Но термин похоже знаете только тот что на слуху
Проще было бы модульный монолит сделать на шарпе
Хочу заметить, что хоть мы и не выделили отдельные базы под каждый сервис, но каждый микросервис ходит в свой набор таблиц, а при необходимости получить данные другого сервиса, обращение идет через API этого сервиса (grpc вызов как правило). Одно исключение у нас получилось - это сервис отчетности, он напрямую в базу ходит к данным разных сервисов. Но основным мотивом не разделять базу у нас было упрощение администрирования.
Но возможно вы правы, и под строгое определение микросервисов мы не подходим и у нас некоторый гибрид получился. Про название архитектуры спорить не буду )
А по поводу монолита, наш прошлый продукт как раз был модульным монолитом, но его архитектура нам не очень подходила для SaaS версии системы, поэтому и решились на переработку архитектуры.
Здорово, что несколько раскрыли подкапотную часть сервиса!
Расскажите, пожалуйста, микросервисы в облаке были с самого начала или перешли на эти Best Practice недавно? Смогли ли вы решить проблемы производительности для клиентов с кастомной логикой и высокой нагрузкой?
Благодарю за оценку )
Если говорить именно про ELMA365, то да, там изначально заложили микросервисную архитектуру, т.к. начиналось она как разработка облачного сервиса. Прошлый наш продукт (ELMA3 и ELMA4), были монолитными решениями.
По поводу производительности, если я правильно понял то вопрос именно про произовдительность в облачной версии. Поправьте меня, если не правильно понял. В облачной версии мы реализовали лимиты, на время выполнения серверных сценариев, объемы выборок данных и прочее. То есть там намеренно ограничена высокая нагрузка, чтобы это не мешало работе нескольких компаний. А при росте числа компаний, есть инструменты горизонтального масштабирования мощностей (добавляются поды сервисов).
Как мы реализовали Low-code на микросервисах