Архитектурные решения, стоящие за ядром кошелька и сателлитными системами одного из ведущих электронных кошельков Вьетнама, — и что мы сделали бы иначе.
«Микросервисы» часто понимают как «разделить всё на части». На практике ценность не в количестве сервисов, а в правильно проведённых границах — вокруг бизнес-возможностей, а не вокруг оргструктуры.
Создавая ядро кошелька и сателлитные системы для электронного кошелька национального масштаба, мы обрабатывали миллионы транзакций при жёстких требованиях к консистентности, безопасности и масштабируемости. Вот несколько уроков, которые пережили встречу с production.
1. Границы сервисов следуют за бизнесом
Сервис должен владеть законченной бизнес-возможностью и её данными. Если два сервиса приходится менять вместе при каждом обновлении — это признак неверной границы: им следует быть одним.
2. Событийная модель для того, чему не нужна синхронность
- Движение денег требует строгой консистентности — обрабатывайте его синхронно, с идемпотентностью.
- Уведомления, сверка, аналитика — отправляйте через события и обрабатывайте асинхронно, чтобы не блокировать основной поток.
- Каждое событие — свершившийся факт, а не команда: новых потребителей можно добавлять, не трогая источник.
3. API-first с чёткими контрактами
Определение API-контрактов до написания кода позволяет командам работать параллельно и снижает болезненность интеграции в конце. Каждое изменение контракта версионируется и никогда не ломает существующих потребителей.
Микросервисы не дают скорость бесплатно — они меняют сложность в коде на сложность в эксплуатации. Платите эту цену только тогда, когда масштаб действительно этого требует.
Что мы сделали бы иначе
Начинать с меньшего числа сервисов. Хорошо модуляризованный монолит, который разделяют постепенно по мере роста нагрузки, почти всегда дешевле, чем разделить слишком рано и потом склеивать обратно. Инфраструктура наблюдаемости должна появиться до второго сервиса, а не после десятого.