Successfully reported this slideshow.

Слоистая архитектура

1

Share

1 of 23
1 of 23

Слоистая архитектура

1

Share

Download to read offline

— Как развивалась инфраструктура веб-проектов в 2ГИС;
— Как не делать один и тот же функционал 5 раз подряд, или слоистая архитектура и выделение общих сервисов;
— Сборка приложений из базовых библиотек;
— Сложность масштабирования цельной системы и легкость распределенной;
— Зоны ответственности групп разработки.

— Как развивалась инфраструктура веб-проектов в 2ГИС;
— Как не делать один и тот же функционал 5 раз подряд, или слоистая архитектура и выделение общих сервисов;
— Сборка приложений из базовых библиотек;
— Сложность масштабирования цельной системы и легкость распределенной;
— Зоны ответственности групп разработки.

More Related Content

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Слоистая архитектура

  1. 1. Слоистая архитектура и Yii Алексей Спиридонов CityPatrol
  2. 2. Этапы развития в 2ГИС От 2х сайтов к 12 сервисам и 3м проектам за 3 года 2012 2009
  3. 3. Инфраструктура Yii Framework в 2ГИС: ● maps.2gis.ru ● flamp.ru ● api.2gis.ru как совокупность сервисов ○ catalog.api ○ ads.api ○ stat.api ○ service.api ○ transport.api ○ partner.api ○ и т.д. ● go.2gis.ru ● и т.д.
  4. 4. Критерии качества системы ● Производительность ● Непрерывное развитие ● Стабильность ● Переиспользование функционала
  5. 5. Что такое слоистая архитектура? ?
  6. 6. Что такое слоистая архитектура?
  7. 7. Что такое слоистая архитектура?
  8. 8. Что такое слоистая архитектура?
  9. 9. Что такое слоистая архитектура? ● Есть четко определенные функциональные зоны ● Зоны образуют вертикальную иерархию ● Каждая зона несет какую то определенную ответственность ● Нижние зоны ничего не знают про верхние Каждая такая зона - это слой архитектуры
  10. 10. Муки выбора подхода VS :( :)
  11. 11. Компоненты фреймворка ● Приложение (CApplication) ● Модуль (CWebModule) ● MVC Контроллер (CController) ● Расширение (CApplicationComponent)
  12. 12. Меняем паттерн приложения M+V+C ● модель ● представление ● контроллер заменяем на E+V+C ● Extension ● представление ● конроллер
  13. 13. Идеальный Extension: ● изолирован, а значит заменим и поддается тестированию ● удобно конфигурируется в main.php ● имеет стабильный зафиксированный интерфейс ● возвращает чистые данные, а не объекты ● реализует некую часть / объект предметной области ● имеем свое собственное хранилище данных
  14. 14. Типичные Extensions Extension 1 : ● Своя база данных ● ActiveRecord Extension 2 : ● враппер вокруг сервиса ○ AMQP ○ GeoIP ○ Thrift сервис Extension 3: ● врапер вокруг библиотеки Extension 4: ● враппер к rest сервису
  15. 15. Изолируем функционал в слоях на всех уровнях: ● классы ● расширения ● сервисы ● приложения
  16. 16. Эволюция функциональных блоков происходит безболезненно Поиск гео-объекта по названию. от 1 класса на PHP к распределенному сервису на C++ без переписывания кода приложения
  17. 17. Простое и легкое управление нагрузкой и надежностью: ● Разделение функционала по серверам становится задачей изменения конфигов. ● Мониторинг нагрузки и поиск проблемных мест. ● Управление требованиями к надежности. Отказ одного функционального блока не затрагивает всю систему.
  18. 18. Масштабирование данных: ● Слабая связанность данных. ● Масштабирование хранища данных за счет разделения данных по разным базам становится элементарным.
  19. 19. Проблемы (Последний слайд) ● Проблема сложности системы ● Проблема изменения интерфейсов ● Как предотвращать восходящие зависимости ● Как разворачивать этот клубок на сервера ● Разделение ответственности за компоненты Если превысим время, просьба ведущему прервать, и вынести обсуждение в курилку...
  20. 20. Алексей Спиридонов, ООО CityPatrol, Москва spiridonov@citypatrol.ru

×