Груп Ко

Несколько важных изменений в версии V2.0:

• Поддержка PHP версий не ниже 7.0, поддержка PHP5.6 и ниже прекращена.
• Разделение зависимостей и коммуникации между базовыми сервисами для обеспечения слабой связанности.
• Использование протокола Protobuf для передачи данных, что требует строгого определения типов данных в коде базовых сервисов.
• Базовые сервисы разделены на две части: интерфейс API и реализацию ServiceImpl.

Версия V1.X (https://github.com/fucongcong/GroupCo/tree/v1.1.1)

Структура фреймворка

Фреймворк состоит из двух основных блоков: клиентского (BFF — Backend For Frontend) и серверного, предоставляющего базовые сервисы.

Клиентский (BFF)

• Использование особенностей сопрограмм для написания асинхронного кода синхронным способом, что улучшает читаемость.
• Объединение асинхронных возможностей Swoole с традиционной MVC-архитектурой.
• BFF-клиент должен быть связующим слоем (аналогичным традиционному контроллеру MVC), который предоставляет API.

Серверный

• Создание с использованием многопроцессного режима Swoole. В текущей версии поддерживается только RPC-вызовы.

Сервисная архитектура

• Реализована сервисная архитектура с использованием Zookeeper, Redis и MySQL в качестве центров регистрации.
• Поддерживается централизованное управление конфигурацией Apollo.
• Обеспечивается обнаружение сервисов, кэширование клиентов, мониторинг сердцебиения и прослушивание сервисов.

Как использовать клиентские сопрограммы и чем они отличаются от традиционных фреймворков?

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

Почему на серверной стороне не используется версия 4.X сопрограмм Swoole?

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

Использование в производственных условиях

• Framework GroupCo уже полностью внедрен в нашей команде и обрабатывает миллионы запросов в день. Время отклика составляет примерно от 0,1 до 10 миллисекунд в зависимости от типа запроса.
• Для крупных проектов рекомендуется избегать использования Redis/MySQL в качестве сервисов обнаружения. Можно также интегрировать другие инструменты обнаружения сервисов, такие как etcd/consul (в будущем планируется поддержка).

Особенности

• Полная асинхронная диспетчеризация сопрограмм с поддержкой высокой параллельности.
• Обнаружение сервисов, кеширование клиентов, мониторинг сердцебиений и прослушивание сервисов.
• Централизованное управление конфигурациями.
• Асинхронные TCP, HTTP-клиенты.
• Асинхронный логинг.
• Асинхронное чтение и запись файлов.
• Асинхронная работа с MySQL.
• Обработка асинхронных транзакций MySQL.
• Поддержка TCP, MySQL, Redis, WebSocket пулов соединений.
• SOA-вызовы сервисов с внутренней полной реализацией RPC-коммуникации и асинхронной обработкой задач на сервере с последующим объединением данных и возвратом.
• Параллельное и последовательное асинхронное использование TCP-клиентов.
• Twig и Doctrine поддерживают представления и данные сервисов.
• Модульное тестирование с покрытием.

Обзор документации

• Быстрый старт
  • Зависимости среды
  • Запуск проекта
  • Запуск контейнера Docker
• Клиент
  • Асинхронный TCP-клиент
  • Асинхронный WebSocket-клиент
  • Асинхронный HTTP-клиент
  • Асинхронный Redis-клиент
  • Асинхронный MySQL-клиент
  • Обработка асинхронных исключений
• Сервер (для разработки базовых сервисов)
  • Сервис
  • Dao
  • Кэш
  • Логирование
  • Файловый кэш
• Центр сервисов
  • Процесс управления сервисами
  • Центр регистрации
  • Вызовы сервисов
  • Использование пула TCP-соединений
  • Мониторинг вызовов сервисов
  • События сбоев вызовов сервисов
  • Режим отладки
• Центр конфигурации
  • Применение центра конфигурации
• Основные классы фреймворка
  • Класс конфигурации Config
  • Статический класс кэша StaticCache
  • Маршрутный класс Route
  • Контроллер класса Controller
  • Представление класса View
  • Запрос класса Request
  • Ответ класса Response
  • Событие класса Event
  • Слушатель класса Listener
  • Подписчик класса Subscriber
  • Диспетчер событий EventDispatcher
• Модульное тестирование
• Консоль

Примеры и лучшие практики

• Простой пример WebSocket, обмен сообщениями в кластере
• Реализация уведомлений об аномалиях сервисов
• Система мгновенных распродаж, сравнение с Go
• Анализ журналов сервисов
• Api-сервисы

Обратная связь по ошибкам

Если вы столкнулись с ошибками безопасности или проблемами использования фреймворка во время работы, пожалуйста, создайте issue.

Модель архитектуры

• Модель архитектуры

Отличия от сопрограмм Go

Основанные на асинхронности Swoole и реализации генератора PHP, сопрограммы отличаются от встроенных сопрограмм языка Go.