Комментарии 19
Интересная статья, но про архитектуру не совсем ясно. В моем понимании с точки зрения арихитектора технологический стек выглядит как-то так:
- Orchestration Systems: Kubernetes, OpenShift, Nomad, Docker Swarm, Rancher, Apache Mesos, Cloudify...
- Load Balancers / Edge Routers: Nginx, HAProxy, Envoy, Traefik, ALB...
- Messaging Systems: NATS, RabbitMQ, Apache Kafka, Synapse, NSQ, Pulsar...
- Database Management: MS SQL Server, Oracle, MySQL, MariaDB, Postgress, Cassandra, Scylla, MongoDB, Redis, Amazon DynamoDB...
- Monitoring: Zabbix, Grafana, Prometheus, Graphite...
- Logging: Zipkin, Logstash, Splunk, Graylog...
Из того, что перечислено в статье, понятно, что Вы используете RabbitMQ в качестве Messaging System. Интересно было бы узнать типы остальных элементов системы и как они соединены...
Все приложения упаковываются в docker образы, но до инструментов оркестрации ещё не дошли, активно изучаем и смотрим в сторону Kubernetes, OpenShift. Так же есть не совсем удачный опыт работы с docker swarm в нашей команде(ошибки по которым тикеты долго не закрываются, проблемы с настройкой нетворков, итд)
Балансировщиком выступает Nginx, коллеги использует HAProxy для банк апи.
Messaging Systems: RabbitMQ
Database: Активно используем Postgres для реляционных баз, коллеги в ряде проектов успешно использовали MongoDB(чатботы, сервисные приложения)
Monitoring: Zabbix(healthcheck, наличие ресурсов на машине) с уведомлениями на рабочую группу
Logging: Используем Graylog для анализа логов, в ней консолидируются сообщения от всех сервисов, настраиваются алерты. Так же смотрим в сторону Grafana
но до инструментов оркестрации ещё не дошли, активно изучаем и смотрим в сторону Kubernetes
А почему не дошли еще, интересно, нехватка ресурсов или нет надобности?
Как в вашей архитектуре обеспечивается отказоустойчивость? Допустим, некий сервис считает остатки по товару и весь сервер, где этот сервис работает, выходит из строя. Кто подхватывает упавшее знамя?
Насчет инструментов оркестрации: на текущий момент поддерживаем не такое большое количество сервисов/серверов. Но с их планируемым ростом и тиражированием, непременно будут увеличиваться и время/затраты на их развертку/поддержку.
А как выполняются задачи по расписанию? Если выделен какой-то сервер, то что происходит, если он выходит из строя?
Круть, воды как в диссертации о научном коммунизме.
Вот этим списком можно было начать и закончить.
Spring Framework — фреймворк для создания веб-приложений;
RabbitMQ — для межсистемного взаимодействия;
Camunda BPM — платформа для автоматизации бизнес-процессов.
И про какой МСБ Вы говорите? Пивной бар? Кофейня? Розничный магазин? Производство окон? Пошив одежды, обуви? Дизайнеры? Строители?
Далее устанавливаем реализованные задачи на тестовый стенд, разработчики проводят демо-показ и, если все хорошо, ставим на бой.
Я правильно понял — разработчики проводят демо-показ и это считается проведенным тестированием, достаточным для внедрения?
Крайний раз, когда такое было, потом на бою случился краевой сценарий, о котором ни разработчик, ни технолог, ни тем более бизнес-заказчик не подумали. Недовольство клиентов, перерасчеты и всё такое.
Заведите уже нормальных тестировщиков. Хоть это и не по скраму, но это работает.
— CI/DI
— демостенды (которые позволяют выполнять проверенную приёмку заказчиком)
— разделение на микросервисы
— замена Legacy монолита на адаптацию Spring+Comunda
С точки зрения реальности, в использовании данных технологий нет ничего нового и есть проекты 2014 года, в которых уже замечательно реализуются микросервисы, то есть потенциал уже давно обоснован, как и с другими технологиями.
Вы выполнили рациональные внедрения и получили ожидаемый результат. Сами по себе идеи не новы. Поздравляю вас. Хорошо было бы узнать как вы сдавали релизы заказчику без демостанедов ранее и как ваша жизнь изменилась после.
И интересно узнать более подробно, как вам удалось обосновать подобные внедрения? Ведь контакт менеджера с клиентом можно было бы реализовать в виде набора костылей на скорую руку, как это чаще всего происходит в российском ИТ :)
К тому же, значительную часть доработок занимает автоматизация взаимодействия с партнерами/агентами банка, работа с «сетью», это опять же, большое количество информационных потоков, которыми необходимо управлять, анализировать, выстраивать их правильно, с точки зрения архитектуры с возможностью её тиражирования.
Реализация в виде набора костылей на скорую руку, скорее всего, уже через год скажутся на качестве работы и будут вылезать разные болячки в виде проблем масштабирования, изолированности, сложности анализа, и итд.
Я увидел, что разработчики участвуют в проработке требований? они у вас бизнес-ориентированные универсалы, получается? просто обычно этим занимаются или бизнес-аналитики, или системные аналитики. Пусть даже в паре с разработчиком/архитектором.
И еще просьба — могли бы вы в следующий раз показать реализованную архитектуру «на картинках»? хотя бы в укрупненном презентативном виде? было бы полезно очень.
Еще раз спасибо!
Разработчики, как правило, работают с функциональными требованиями(включает состав доработок: описание форм, интеграция, бизнес-правила, требования к аудиту, итд), которые составляют системные аналитики на основе бизнес-требований от заказчиков.
Так, я бы выделил две активности, которые мы проводим:
1. Заказчики могут обратиться с конкретной «болью»/юзерстори к нам, мы собираемся вместе с аналитиками/разработчиками, проводим «мозговой штурм», продумываем варианты решения с точки зрения пользовательского опыта, затрагиваемого скоупа доработок, возможные сценарии, которые нужно предусмотреть.
2. Верификация/ревизия требований со стороны разработчиков/архитекторов. Перед тем, как взять в план задачу, разработчики проводят оценку требований: возможность тестирования, осуществимости функционирования и сопровождения, соответствие архитектуре.
В целом, стремимся к тому, чтобы быть как можно ближе к предметной области заказчика. Можно сказать, что практикуем принципы Domain-driven design(DDD).
Насчет просьбы, полностью за! Изображения всегда нагляднее и интереснее)
а есть у вас такое решение которое позволит автоматически взимать платежи, свои%, переводить юридическим лицам и физическим их доли, и управлять всем этим без бумажек?
Это мода такая сейчас: все банки взялись на хабре писать, как они запилили платформу для бизнеса?
Обслуживание (клиентов) тем временем у всех как было не совсем чтобы клиентоориентированным, так и остаётся. Потому что банк — это не ИТ, это банкиры, и любви к людям у них немного.
Таких постов на подобные темы в проплаченных блогах много, что означает, что кто-то в банке решил, что можно зацепить еще и айтишников, не как клиентов, так на работу, правда? Ну и что банку нечем похвастать, вот и придумывают «ит-темы». Напишите серию постов о работе банкоматов, броневиков инкасации, да даже службы охраны, и в стиле старых постов билайна — это будет получше, это привлечет внимание, ит-ники же любопытны!
А что у вас платформа хорошая или нет — дело-то десятое, увы. «Не банк для ит, а ит для банка», как ни крути.
А вот баннер на хабое для этого поста страшный — видно, что падающий мост задавит стоящих снизу (это ИТ банка, я так понимаю).
Символично получается, словно говорит, что ИТ-инфрастурктура не особо надежная, но бизнес работает, стараясь не обращать внимание, что под ногами трещит, и до ремонта не снисходит:
Ремонтные работы или IT-трансформация? Как мы разработали архитектуру с нуля и создали платформу для малого и среднего бизнеса