Эта статья была впервые опубликована на ZenOfCoding и переиздана здесь с разрешения автора.
Простой вопрос побудил меня сесть и написать это продолжение моей статьи около года назад .
Q: Есть мысли о том, где сегодня вещи? (2/24/2017)
A: «Я бы сказал, что это в значительной степени зависит от Laravel и Symfony; когда дело доходит до фреймворков PHP. Я не чувствую особой ценности использования CakePHP, Zend, CodeIgniter, Yii и т. Д., Если вы начинаете новый проект.
Только если вы уже знаете эти фреймворки или у вас есть разработчики, которые привыкли работать с ними, я смогу найти причину их использования.
Когда начинается настоящая разработка, вы должны быть в состоянии найти инструменты, плагины, ответы на распространенные проблемы. А с сообществами Laravel и Symfony и постоянной разработкой новых «модулей» или функций вы никогда не почувствуете, что остаетесь позади. Ларакасты в одиночку (даже если вы не разрабатываете в Laravel) просто фантастические.
Будь то интеграция со службами, такими как iron.io или другими SaaS-провайдерами, поддержка широкого спектра источников данных, локальная разработка, например, Homestead , эти платформы и поддерживающие модули гораздо более продвинуты.
Компонент Lumen, разработанный для быстрой разработки API, действительно великолепен как отличный подход к быстрой разработке приложений и созданию прототипов в наши дни. Нельзя сказать, что он как-то ограничен [когда дело доходит до создания] более крупных приложений.
В целом, однако, мы определенно наблюдаем сдвиг в сторону контейнерной архитектуры, где MVC играет гораздо меньшую роль. Все дело в микросервисах, оркестровке и создании приложений как «функций» (т. Е. AWS Lambda и аналогичных сервисов). Возможно, пришло время освежить свои навыки в Node / JS и GoLang 🙂 »
Хотя я был в целом доволен этим ответом, я не мог не подумать, что было бы неплохо подробно остановиться на некоторых из этих моментов и по-новому взглянуть на положение вещей.
Прежде чем перейти к странным темам, таким как «GoLang», давайте сделаем шаг назад и взглянем на тенденции 2017 года в мире фреймворков PHP MVC.
Я бы сказал, что наблюдаемые нами в прошлом тенденции сохраняются. Laravel все еще продвигается вперед, в то время как большинство остальных отстают. Популярность Symfony немного увеличилась, вероятно, из-за долгожданного выпуска Symfony 3.
(Я пробовал более конкретные поиски для сравнения, такие как «CakePHP 3» или «ZF2», однако они не дали статистически значимых тенденций).
В этом году я включил CodeIgniter, потому что он очень популярен, как видно. Я получил ряд вопросов о CodeIgniter и своих мыслях о том, где он находится в сообществе PHP MVC…
Короче говоря, CI все еще вне конкуренции, потому что это не настоящая платформа MVC. Я не знаю, как это назвать, кроме организованной коллекции ПОПО …
Давайте просто возьмем эту цитату прямо из их руководства:
CodeIgniter имеет довольно свободный подход к MVC, поскольку модели не требуются. Если вам не нужно дополнительное разделение или вы обнаружите, что поддержка моделей требует большей сложности, чем вы хотите, вы можете их игнорировать и минимально создавать свое приложение, используя Controllers и Views.
Когда дело доходит до построения структуры, я просто не согласен с таким подходом. Возможно, это достойный образец, отсюда и популярность CodeIgniter, однако в рамках этой платформы должна соблюдаться некоторая дисциплина, в противном случае конечный продукт превращается в беспорядок кода для спагетти, заключенного в некий «шаблон».
Двигаясь дальше, Symfony 3 принес нам несколько приличных улучшений в опыте разработчиков, внедрении зависимостей и ряде других функций. Как и многие аналоги PHP, теперь он предлагает микро-фреймворк. Сравнительно, ZF3 предоставил ряд улучшений, таких как поддержка PHP7 (наконец-то) и даже собственный микро-фреймворк … но, как говорится в их руководстве:
Для пользователей Zend Framework 2 MVC различия незначительны…
Я действительно надеялся, что они скажут, что различия драматичны, что произошло значительное архитектурное улучшение, замечательные новые модули, которые помогут вам разрабатывать вещи современным способом. Увы, по большей части ZF3 остается довольно похожим на ZF2.
Короче
Вот как я вижу мир PHP-фреймворков сегодня:
- Symfony или Laravel, в зависимости от ваших потребностей
- Остальные
Руки вниз, Laravel украл шоу. Объем доступной информации, Laracasts, талантливые разработчики по всему миру, простые реализации шаблонов, интегрированные наборы инструментов для тестирования, активная реализация записей в форме Eloquent, облегченная версия в Lumen, локальная разработка с использованием Homestead (Vagrant) делают эту платформу действительно выдающейся для новых и опытные разработчики.
Однако модели Eloquent могут стать неуправляемыми и довольно большими по размеру, может быть создано слишком много сервисов Laravel (не путать с микросервисами), и люди начинают задумываться о реализации шаблона репозитория там, где он не принадлежит . Так рождается монолит.
Если вам не нравится активный шаблон записи и вам нужна дополнительная гибкость репозиториев или, возможно, вы видите слишком много анонимных функций на свой вкус, используйте Symfony + Doctrine.
Считаю ли я Symfony шлюзом для монолитных приложений? В какой-то степени да. Тем не менее, это, вероятно, самый элегантный.
В целом, я бы не назвал это резким изменением по сравнению с прошлым годом. Тем не менее, нам нужно взглянуть на картину в целом: правильно разработанное приложение выходит за рамки только MVC; речь идет об инфраструктуре, конвейере развертывания, отделенной архитектуре. Все это может быть достигнуто в стеке MVC, но нужно быть очень внимательным, чтобы избежать монолита.
Появление микросервисов
Ранее я упоминал о росте количества микросервисов и необходимости усовершенствовать навыки GoLang или Node.
В самом деле, даже в статье PHP MVC было бы глупо не упомянуть о явном движении к архитектуре, ориентированной на микросервис (MOA); и он набирает обороты, как будто вы не поверите.
Хотя эти два понятия не являются взаимоисключающими, нет причин пытаться найти параллели между ними, поскольку они действительно представляют разные, хотя и пересекающиеся, философии.
Например , размещение вашего приложения MVC в одном контейнере, а MySQL в другом и последующее их связывание не обязательно представляет собой правильный MOA.
Это, безусловно, лучший подход, на самом деле гораздо лучше, чем пытаться установить MAMP, XAMPP или любой другой беспорядок, который вам нужен, чтобы ваша локальная машина обслуживала приложение.
Кроме того, это может решить некоторые проблемы, такие как простота запуска локальной среды на разных платформах (разработчиков) и, возможно, стратегия развертывания, в некоторых случаях, но вы застряли с монолитом MVC в своем слое / контейнере приложения.
Уничтожение Монолита
Это «разрушение» — вот что такое микросервисы.
В то время как MVC обращается к вашей структуре кода и организации, предоставляя надежный подход к разделению проблем, эта концепция еще более расширяется с помощью контейнеров / сервисов / MOA.
Вместо того, чтобы просто отделять ваши представления от ваших моделей, вы теперь разделяете каждый «чанк» или логическую единицу вашего приложения на отдельный сервис, предназначенный для надлежащего выполнения своих собственных обязанностей.
Если ваше MVC-приложение имеет контроллер «Поиск», действие и соответствующие методы Model, то у нас уже есть пример монолитного приложения.
Напротив, используя подход MOA, у нас будет сервис для каждого из этих процессоров. В качестве примера:
- Маршрутизатор Сервис
- Запросить услугу
- Сервис запросов
- Служба источника данных
- Служба реагирования
Подождите, но не все эти «сервисы» являются лишь частью стека MVC. Ну да, именно так. Они являются строительными блоками нашего Монолита.
С MOA каждый сервис работает в своей среде, и как разработчики, но в большей степени как архитекторы, мы можем разработать лучший подход для решения конкретной задачи.
Например, если бы я писал Сервис обработки изображений в среде Laravel, я бы, вероятно, использовал что-то вроде расширения PHP-GD2, которое, возможно, не самый эффективный способ обработки изображений. Служба C ++, которая обрабатывает мои потребности в обработке изображений, может быть намного быстрее и определенно более надежной в масштабе. Чтобы уточнить еще больше, мы можем теперь взять выходные данные службы обработки изображений и отправить их в службу хранилища данных, службу CloudStorage и службу очереди электронной почты.
Решение этой же проблемы с помощью нескольких заданий cron и, возможно, нескольких отдельных приложений MVC и пользовательских сценариев — это то, как мы работали раньше (то есть 2 года назад). Время двигаться вперед.
Масштабируемость
Это где проблемы начинаются (или заканчиваются, в зависимости от того, куда вы направляетесь). С одной стороны, трудно масштабировать Monolith, если вы встраиваете все больше и больше логики в один и тот же стек MVC, вы застрянете, возможно, в хорошо структурированном приложении ужасной сложности.
С другой стороны, если вы создаете тысячу микросервисов на разных языках, как вы справляетесь с этим беспорядком?
Сообщалось о более чем одной катастрофе .
Существуют различные инструменты оркестровки контейнеров (например, Kubernetes, Swarm, Mesos), службы развертывания контейнеров (например, GKE и AWS ECS), однако лишь немногие предприятия используют архитектуру Docker. Определенно есть успешные примеры построения инфраструктуры с использованием Docker или других контейнерных технологий (например, GKE). Большинство этих историй приходят от компаний, которые могут позволить себе тратить ресурсы на архитекторов, разработчиков, администраторов баз данных и инженеров. Тем не менее, в настоящее время ведутся бесчисленные дебаты о том, как развернуть хорошо организованную и элегантную MOA. Один размер определенно не подходит всем в этом случае, и существует множество способов решить вашу проблему.
В любом случае, вы не решите эту проблему в одиночку (DevOps FTW!), И только после того, как вы достигнете относительно больших масштабов, эта проблема действительно нуждается в решении. Может быть, сейчас не время перегружать инженером.
Счастливой серединой для сегодняшнего дня (и для тех, кто имеет дело с приложениями меньшей сложности или требованиями к трафику) является передача многих типичных услуг сторонним поставщикам. Почти все доступно как услуга сейчас. Фоновые задания, обработка изображений, аутентификация, анализ данных, ведение журналов, отправка электронной почты, системы очередей не должны быть встроены в один и тот же стек MVC, а архитектор должен подумать о том, что может быть выгружено в систему SaaS за небольшую ежемесячную плату (т. Е. Поиск Algolia) или, возможно, специально созданная докерская служба, работающая в некотором облачном пространстве, которая обрабатывает эту раздражающую обработку изображений.
Я предполагаю, что суть в том, что вы не должны сначала прыгать в голову проекта по ре-архитектуре, не сбрасывать все, что у вас есть сегодня, и выпускать рой докеров везде, где только можно вообразить. Существуют способы постепенного развертывания улучшенной основы путем отделения того, что возможно, изучения узких мест в системе и применения понятия разделения проблем к этим проблемным областям.
Вывод
2017 год принесет нам больше разговоров и производственных развертываний на основе контейнеров и MOA. Мои замечания и разговоры о Docker, использующем GoLang или Node, не означают, что PHP «умирает» или что-то в этом роде… Я чувствую, что как разработчики мы должны оставаться на переднем крае вещей, поэтому, если микросервисы находятся там, где они есть Тогда почему бы не изучить GoLang? Он идеально подходит (из-за низкой занимаемой площади, скорости и параллельной обработки) для разработки крошечных контейнерных приложений. Node и GoLang — это весело, потому что они позволяют вам создавать небольшие сервисы, которые являются частью большого племени, связывать их вместе и выпускать как эпический рой контейнеров Docker, если вы того пожелаете.
Тем не менее, все это удивительное и передовые решения и языки не означает, что PHP как-то больше не актуален или иным образом «мертв». Мы определенно собираемся создавать стеки MVC и конечные точки API на некоторое время.
Одна из проблем, которая не была решена MOA, заключается в том, что, хотя контейнеры помогают нам убить монолит на серверной стороне, мы все еще сталкиваемся со многими архитектурными проблемами в нашем интерфейсном слое, пользовательском интерфейсе или представлении.
Мы можем создать потрясающе надежное внутреннее приложение, но в конце оно ответит JSON, который каким-то образом должен быть отображен в клиентском приложении. Имеет ли значение, если конечный объект ответа прибывает из простого PHP, скажем, Lumen-ориентированной конечной точки (URL) или оркестра блоков принятия решений и обработки, отделенных интерфейсом обмена сообщениями? Это действительно очень зависит от ваших потребностей и требований вашего приложения.
В этом году научитесь Laravel следить за Docker, GoLang и определенно сосредоточиться на конвейере развертывания. Переход с локального на производственный процесс должен быть более плавным, чем раньше, особенно при создании приложений MVC.