Распределенные системы роутинга на примере Framework Foton

В современном мире, где количество данных растет, а бота бывает тяжело отличить от человека просто необходимы альтернативы простым монолитным системам.

Микросервисная архитектура отчасти в этом помогает, не зря какое то время назад она стала мейнстримом в стиле архитектурного подхода, но архитектура намного более индивидуальна и имеет большое количество особенностей и многим сервисам мкросервисный подход только вредит, множество разных команд, независимых сервисов с плохим логированием и обратной связью, в результате никто не понимает как вся система работает в целом.

Постоянные тесты которые работают только в условиях тумана, в реальности серверные сбои, сбои хост соединений, переполнение памяти, ошибки синхронизации дат и это только начало.

После переезда на микросервисы многие думают: да лучше бы я туда и не лез.

Это действительно проблема. потому что мы смотрим не на архитектуру, а на представление. Это также как смотреть на mvc как паттерн проектирования, но это и поведенческий и порождающий паттерн, смотря как мы его используем. И проблема не в самом паттерне, а в шаблонном зашоренном мышлении.

Вы только подумайте какие-нибудь 50 лет назад вас бы засмеяли в сообществе за использование не просто готовых практик, а готовых шаблонов с заранее выбранными типами задач. Это же просто копипаст, сказали бы вам, а сейчас от вас этого требуют.

И в угоду чему?

Если в общем тому, чтобы хоть как то справится с текучкой тех долга по проектам.

Но на самом деле это не помогает, каждый нагромождает кучу паттернов поверх старых, старается сделать свою лучшую практику, но все вместе - это просто зоопарк микросервисов, которые по сути живут своей жизнью и только периодически как то фиксятся, когда падают и/или причиняют вред бизнесу.

Какой же выход из такой ситуации?

Создавать раздельные, предсказуемые и контролируемые системы - это и есть суть распределенных систем.

При этом нагрузка замечательно распределяется с помощью шардирования и репликации на внешних серверах. Никакой логики, только хранение данных. Да, вы скажете, что все равно риски высоки и система может в какой-то момент отказать вся целиком, это же монолит.

Но, кто вам сказал, что нужно делать монолит - распределенная система может иметь ряд кластеров на разных серверах, но в чем же отличие от обычных микросервисов?

Все кластеры имеют общую внутреннюю структуру взаимодействия - декларацию общения, каждый микросервис внутри может иметь разную логику взаимодействия с разными сервисами, но на вход и выход он отдает только определенную структуру данных являясь прослойкой между хаосом и порядком. При этом в одном кластере может находиться сколько угодно таких сервисов. Это может быть не очень понятно, поэтому мы приведем пример из лучших современных практик по распределенным системам на php - Framework Foton

Посмотрите на пример декларации микросервиса

{    
    "auth":{   },  //здесь содержатся настройки авторизации
    "exit":true,  //если true, то микросервис выключен, если false либо удален микросервис доступен
    "format":"xml",  //стандартно может быть xml,json,txt
    "log":false/true,  //пишем или не пишем логи
    "event":"event", //имеет три варианта event,api,data
    "name":"service", //название сервиса
    "arg":[{         //параметры вызова
        "model":"html",
        "table":"seo",
        "methods":{"echo":{"data":true}},
        "format":"X" 
    }],     
    "services":
    { //микросервисы для вызова при event:event
        "servis1":
        {
            //микросервис 1
        },        
        "servis2":
        {
           //микросервис 2
        }        
    }  
}

Здесь мы можем указывать другие микросервисы, ноды и поды приобретают совсем другой смысл, мы сразу же декларируем их присутствие.

Давайте пойдем дальше и посмотрим что же такое полноценная распределенная система и ограничивается ли она прослойками для микросервисов?

Оказалось, что нет, она намного больше этого.

Опишем пример типов запросов на Framework Foton:

1 тип - mvc - это стандартный тип запроса, он основной, если на конце строки запроса не указан ни один из типов вызывается mvc, поиск производится в таблице router по регулярным выражениям либо по названию mvc шаблона, если это не запрещено в настройках системы.

Пример - /news/firstnews.html

2 тип - ajax - этот тип данных вызывает методы ajax класса внешнего модуля. Например заглянув в network инспектора браузера при сохранении страницы в модуле визуальный редактор вы увидите такой путь /htmlred/files.ajax - это и есть роутинг ajax запроса, название модуля/название метода класса Ajax.ajax, также вы можете создавать файлы для представления методов в директории /dev/module/вашмодуль/ajax/вашметод.php

3 тип - micro - это тип для микросервисов, вы можете вызвать его через например alisa.micro, общая шина обработки запросов вызывается через all.micro

4 тип - ajaxadmin - если в админ панели вы нажмете обновление шаблонов и посмотрите в инспектор то увидите /updatesectionall.ajaxadmin, это вызов метода класса Ajaxadmin/Admin расположенного по пути /app/ajax/admin/admin.php, работает только когда пользователь авторизован в системе.

5 тип - ajaxsite - аналогичный предыдущему, только он работает и когда пользователь не авторизован, вызывает метод контроллера AjaxsiteSite по пути /app/ajax/site/site.php через название метода.ajaxsite, также как и ajaxadmin имеет неограниченный уровень вложенности, после установки вам доступна конструкция для теста /test/test2/test3.ajaxsite, вы можете написать /test/test2.ajaxsite для отображения шаблона представления, по структуре вам нужно создать директорию по названию метода в директории site и в ней либо контроллер для последующей обработки либо файл index.php с шаблоном для вывода, в шаблоне также работает доступ к массиву $data из метода

6 тип - modul - это внешние модули, при обращении /antivirus.modul происходит отработка всех публичных методов контроллера dev/modul/antivirus/controller.php модуля и вызов представления. Но можно обращаться и к вложенным модулям, например вот так /shop/visualeditor.modul

7 тип - tpl - это внутренние типы данных для отображения в интерфейсе ресурс контроллера, они расположены по пути /app/type/site, принадлежат конкретному сайту и включают css,js,php контроллер и php представление метода в формате названиетипа_названиеметода.php , обычно контроллер содержит метод index, первый аргумент это $id - номер записи, остальные аргументы можно добавлять, но также нужно добавить эти значения через запятую после названия типа: в модели данных, в представлении также доступен массив $data

8 тип - face - интерфейсы, расположены по пути /app/face/admin/ и работают только в админ панелях. включают css,js,php контроллер и php представление метода в формате названиеинтерфейса/названиеметода.php , в представление также передается массив $data

9 тип - widget - виджеты сайта, расположен по пути dev/widget/site и принадлежит конкретному сайту. контроллер расположен в файле index.php и содержит основной вызываемый метод index, хотя может содержать и другие, в директории index файл template.php является представлением, в представлении доступен массив $data из return метода.

10 тип - tplfront - аналогично tpl, только вызывает именно  css, js файлы внутреннего типа данных.

Каждый тип запроса - это отдельный алгоритм со своим контроллером, роутингом и рендерингом, со своей логикой и своей моделью поведения регламентированной общими правилами.

Это не только снижает нагрузку и облегчает тестирование, но и помогает лучше и быстрее разобраться в проекте, делает все состояния более прозрачными и консистентными.

Помимо этого мы можем напрямую обращаться к типам запросов из кода минуя роутинг, то есть обращаться к любой части системы и не просто обращаться, а создавать ее внутри нее же самой. Это дает огромные возможности для модульного тестирования, логирования, преобразования и контроля над данными.

В терминах работы с микросервисами это называется форматом RPC, который дает возможность строить архитектуру запросов через построение внутреннего api.

Все типы запросов могут быть представлены через текучий интерфейс view

<?php
$this->core->view()->tpl->html->echo->end(['name'=>'test','value'=>'test']); 
$this->core->view()->tplfront->html->echo->end(['name'=>'test','value'=>'test']); 
$this->core->view()->widget->htmlredactor->end(['value'=>'test','name'=>'name']);
$this->core->view()->mvc->company->end();
$this->core->view()->ajaxsite->test->test2->test3->end();
$this->core->view()->ajaxadmin->method->end();
$this->core->view()->ajax->shop->codeBlock->end();
$this->core->view()->modul->shop->end();
$this->core->view()->face->lists->end();
$this->core->view()->micro->alisa->end();

По итогу мы получаем контролируемую систему не за счет стандартов psr, готовых шаблонов и постоянных тестов, а из-за самого устройства архитектуры, декларация взаимодействия лучше любого паттерна из практик кодирования, потому что она не ограничивает творчество, не ограничивает выбор при решении проблемы, но дает возможность верного взаимодействия, дает те самые контракты которые есть на уровне взаимодействия внутри системы, но практически нет вне ее.