Enterprise symfony architecture
- 2. О докладчике Лисаченко Александр • Руководитель отдела проектирования ПО в Alpari • Идеолог Symfony2: почти вся инфраструктура на Symfony2, в т.ч. и основной сайт alpari.ru (миллионы хитов в день, BigData при анализе, высокая сложность логики) Twitter: @lisachenko Github: https://github.com/lisachenko 2
- 6. Основные идеи архитектуры Ускорение/удешевление достижения бизнес-цели. Cнижение сложности системы путем абстракции и разграничения полномочий. Достижение производительности, отказоустойчивости и масштабируемости. 6
- 8. Уровни архитектуры Микро Стиль кода (SOLID) Ограничения (хуки, ветки) Макро Компоненты (LDAP, MQ) Модули Сервисы (SOA) Приложения 8
- 9. Микро-архитектура. SOLID А ты используешь принципы SOLID? 9
- 10. Микро-архитектура. SOLID (S)Ingle Responsibility • Принцип единственной ответственности. Каждый метод и класс делает свое дело (O)pen-Closed principle • Класс должен быть открыт для расширения, но закрыт для изменения (L)iskov Substitution • Методы должны работать с подтипами, ничего не зная о них заранее (I)nterface Segregation • Лучше много конкретных интерфейсов, чем один гигантский. (D)ependency Inversion Principle • Абстракции не должны зависеть от конкретных реализаций. Не проси – тебе дадут 10
- 12. Symfony2 - это не MVC! View Controller Model??? 12
- 13. Слои в Symfony2 View Controller Service Data Access 13
- 14. Корпоративная архитектура SF2 Только данные! Никаких методов в сущностях. (AR) Репозитории только для методов поиска/конвертации данных. Получают только аргументы и возвращают только примитивные типы: скаляры, DTO. Реализуют бизнес- логику. Обеспечивает только распаковку запроса/упаковку ответа, а также вызов одного сервиса Контроллер Сервисы Источники данных 14
- 15. Пример правильного контроллера в коде Получить запрос • Request Разобрать параметры • $login • $pass Вызвать сервис • UserService -> login() Вернуть данные • $isSuccess 15
- 16. Толстый тупой уродливый контроллер (ТТУК) 16
- 17. Компоненты Аутенти- фикация Модуль авториза- ции Шина событий (MQ) Сервисная шина (SOA) Failover 17
- 18. Корпоративная аутентификация – LDAP/x.509 LDAP App1 App2 Service1Service2 Admin 18
- 19. Сервисная шина (SOA) (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения. Превращаем сервисы SF2 в полноценные веб-сервисы и используем в других приложениях. Следуем принципу SRP для сервисов! SOA Service1 Service2 Service3 Service4 Service5 Service6 19
- 20. Плюсы и минусы SOA 20
- 21. За и против SOA Преимущества • Независимая разработка • Контроль доступа к коду • Проще управлять • Единственная ответственность • Проще масштабировать Недостатки • Новые точки отказа • Сложный мониторинг • Сложнее отладка взаимодействия • Управление версиями • Круговые зависимости (!) • Медленная работа конечных приложений 21
- 23. Failover Virtual Host HAProxy (DC1) TCP Service 1 TCP Service 2 HAProxy (DC2) TCP Service 1 TCP Service 2 23
- 24. Асинхронный процессинг Быстрый ответ на запрос Выполнение работы в фоновом режиме Результаты в реальном времени Масштабирование нагрузки Уведомление других приложений о событиях 24
- 25. Асинхронный процессинг Request Response Event Push Event Subscribe Push Result Push Async Result 25