Зачем говорить об управлении услугами
По мере того, как просмотр Интернета становится все больше и больше, традиционная единая архитектура MVC продолжает увеличиваться вместе с масштабом приложения и модулями приложения, и все приложение становится все более и более раздутым и сложным в обслуживании.
Мы должны принять меры для разделения по приложениям, то есть разделить исходное приложение на несколько приложений в соответствии с бизнес-характеристиками. Например, крупномасштабная система электронной коммерции может включать пользовательскую систему, товарную систему, систему заказов, систему оценки и т. д. Мы можем разделить их на отдельные приложения. Особенность многоприкладной архитектуры в том, что приложения независимы друг от друга и не вызывают друг друга.
Хотя использование нескольких приложений решает проблему раздутых приложений, приложения не зависят друг от друга, а некоторые общие службы или коды нельзя использовать повторно.
Единое прикладное решение
Для крупномасштабной интернет-системы, как правило, существует несколько приложений, и среди приложений часто есть общие службы, а также между приложениями существует взаимосвязь вызова. Кроме того, перед крупномасштабными интернет-системами стоят и другие задачи, например, как справиться с быстрым ростом числа пользователей, как управлять группой исследований и разработок для быстрой итерации разработки продукта, как сделать обновления продукта более стабильными и т. д.
Поэтому, чтобы сделать бизнес хорошо переиспользуемым, а модули проще расширять и поддерживать, мы надеемся, что бизнес и приложение разделены, и определенный бизнес больше не принадлежит приложению, а поддерживается как независимый сервис. Само приложение больше не представляет собой раздутый стек модулей, а представляет собой комбинацию модульных сервисных компонентов.
Обслуживание
Функции
затем используйте服务化
Каковы особенности, которые имеют эти основные моменты?
- Приложения разбиты на сервисы по бизнесу
- Каждая служба может быть развернута независимо
- Сервисы могут совместно использоваться несколькими приложениями
- связь между сервисами
- Система более понятна по структуре
- Базовые модули стабильны, а сервисные компоненты обновляются по частям, что позволяет избежать риска частых выпусков.
- Легкое развитие и управление
- Независимая поддержка команды, четкая работа, четкие обязанности
- Повторное использование в бизнесе, повторное использование кода
- очень легко расширить
Проблемы, стоящие перед сервисизацией
После обслуживания системы увеличивается сложность зависимостей, а также увеличивается количество взаимодействий между службами.fpm
В режиме разработки Поскольку невозможность размещения в памяти приводит к тому, что каждый запрос должен загружаться с нуля в процесс выхода, что добавляет много бесполезных накладных расходов, а соединение с базой данных нельзя повторно использовать или защитить.fpm
в технологических установкахfpm
Количество процессов также определяет количество параллелизма, что такжеfpm
Простота разработки приносит нам проблемы, так почему же сейчас интернет-платформаJava
более популярным,.NET
иPHP
Не в этом плане.PHP非内存常驻
Разумеется. Помимо этого, есть много других проблем, которые необходимо решить.
- Все больше и больше сервисов, сложное управление конфигурацией
- Сложные межсервисные зависимости
- Балансировка нагрузки между сервисами
- Расширение услуг
- сервисный мониторинг
- понижение уровня обслуживания
- аутентификация службы
- Сервис онлайн и офлайн
- Сервисная документация ......
Вы можете себе представить преимущества, которые дает нам резидентная память, такие как
-
Только начать инициализацию кадраЕсли он находится в памяти, мы просто инициализируем фреймворк обработки в памяти при запуске и концентрируемся на обработке запросов.
-
мультиплексирование соединения, некоторые инженеры не особо понимают, если пул коннекта не нужен, как насчет отправки коннекта на запрос? Это приведет к слишком большому количеству подключений к внутренним ресурсам. Для некоторых базовых служб, таких как Redis, база данных, подключение требует больших затрат.
Так есть ли хороший план? Ответ - да, и многие люди используют этот фреймворк, это -Swoft
.Swoft
это服务治理
функциональныйRPCРамка.Swoft
Это первый полнофункциональный фреймворк для резидентных сопрограмм памяти PHP, основанный наSpring Boot
Основная идея о том, что предлагаемое соглашение больше, чем конфигурация
Swoft
обеспечивает аналогичныеDubbo
Более элегантный способ использованияRPC
Служить,Swoft
Производительность фантастическая с аналогичнымиGolang
производительность, ниже мояPC
правильноSwoft
Измерение давления производительности.
ab
Скорость обработки стресс-тестов потрясающая, вi78代
CPU, 16GB
ОЗУ下
100000万个请求只用了
5s时间在
fpm开发模式下基本不可能达到. 这也足以证明
Высокая производительность и стабильность Swoft,
Элегантное управление услугами
Регистрация и обнаружение службы
В процессе управления микросервисами часто требуется регистрация и запуск сервисов для сторонних кластеров, таких как consul / etcd и т. д. В этой главе в качестве примера используется компонент swoft-consul в структуре Swoft для реализации регистрации и обнаружения сервисов.
реализовать логику
<?php declare(strict_types=1);
namespace App\Common;
use ReflectionException;
use Swoft\Bean\Annotation\Mapping\Bean;
use Swoft\Bean\Annotation\Mapping\Inject;
use Swoft\Bean\Exception\ContainerException;
use Swoft\Consul\Agent;
use Swoft\Consul\Exception\ClientException;
use Swoft\Consul\Exception\ServerException;
use Swoft\Rpc\Client\Client;
use Swoft\Rpc\Client\Contract\ProviderInterface;
/**
* Class RpcProvider
*
* @since 2.0
*
* @Bean()
*/
class RpcProvider implements ProviderInterface
{
/**
* @Inject()
*
* @var Agent
*/
private $agent;
/**
* @param Client $client
*
* @return array
* @throws ReflectionException
* @throws ContainerException
* @throws ClientException
* @throws ServerException
* @example
* [
* 'host:port',
* 'host:port',
* 'host:port',
* ]
*/
public function getList(Client $client): array
{
// Get health service from consul
$services = $this->agent->services();
$services = [
];
return $services;
}
}
Сервисный предохранитель
В распределенной среде, особенно в распределенной системе со структурой микрослужб, очень часто одна программная система вызывает другую удаленную систему. Вызываемый объект этого удаленного вызова может быть другим процессом или другим хостом в сети.Самая большая разница между этим удаленным вызовом и внутренним вызовом процесса заключается в том, что удаленный вызов может завершиться ошибкой или зависнуть, а ответа нет до истечения времени ожидания. Хуже того, если несколько вызывающих абонентов вызывают одну и ту же приостановленную службу, то очень вероятно, что тайм-аут службы быстро распространится на всю распределенную систему, вызывая цепную реакцию, которая потребляет всю службу. Ресурсы. В конечном итоге это может привести к системному параличу.
Шаблон Circuit Breaker предназначен для предотвращения аварий, вызванных этим каскадом цепных реакций в распределенных системах.
В базовом режиме автоматического выключателя гарантируется, что поставщик защиты не будет вызван, когда выключатель находится в разомкнутом состоянии, но также необходимы дополнительные меры по сбросу автоматического выключателя после возобновления работы поставщика. Выполнимый способ заключается в том, что автоматический выключатель периодически определяет, восстановлена ли служба поставщика, и после восстановления устанавливается состояние «замкнут». Автоматический выключатель находится в полуоткрытом состоянии при повторной попытке.
Использование предохранителей простое и мощное, с@Breaker
Просто комментируйте,Swoft
Автоматический выключатель можно использовать в любом сценарии, например, когда вызывается служба, а когда запрашивается третья сторона, он может быть взорван и понижен.
<?php declare(strict_types=1);
namespace App\Model\Logic;
use Exception;
use Swoft\Bean\Annotation\Mapping\Bean;
use Swoft\Breaker\Annotation\Mapping\Breaker;
/**
* Class BreakerLogic
*
* @since 2.0
*
* @Bean()
*/
class BreakerLogic
{
/**
* @Breaker(fallback="loopFallback")
*
* @return string
* @throws Exception
*/
public function loop(): string
{
// Do something
throw new Exception('Breaker exception');
}
/**
* @return string
* @throws Exception
*/
public function loopFallback(): string
{
// Do something
}
}
Лимит сервисного тока
Ограничение тока, предохранитель, понижениеЭто невозможно переоценить, потому что это действительно важно. Когда служба выходит из строя, она должна быть взорвана. Ограничение тока — самое большое оружие для защиты себя.Если нет механизма самозащиты, независимо от того, сколько подключений, он его получит.Если бэкэнд не справится с этим, он обязательно зависнет, когда фронтенд-трафик будет большим.
Текущее регулирование предназначено для ограничения количества параллелизма и запросов при доступе к ограниченным ресурсам, таким как мгновенные убийства и раскупаемые продукты, чтобы эффективно сократить пики и сгладить кривую потока. Целью текущего регулирования является ограничение скорости одновременного доступа и одновременных запросов или ограничение скорости запросов в течение временного окна для защиты системы.После достижения или превышения ограничения скорости в обслуживании может быть отказано или поставлена в очередь для ждать.
Swoft
Нижний слой текущего ограничителя использует алгоритм ведра маркеров, а нижний слой зависит отRedis
Реализовать распределенное ограничение тока.
Ограничитель скорости Swoft может не только ограничивать поток контроллера, но и ограничивать методы в любом bean-компоненте, а также может контролировать скорость доступа к методу. Вот подробное объяснение использования следующих примеров
<?php declare(strict_types=1);
namespace App\Model\Logic;
use Swoft\Bean\Annotation\Mapping\Bean;
use Swoft\Limiter\Annotation\Mapping\RateLimiter;
/**
* Class LimiterLogic
*
* @since 2.0
*
* @Bean()
*/
class LimiterLogic
{
/**
* @RequestMapping()
* @RateLimiter(rate=20, fallback="limiterFallback")
*
* @param Request $request
*
* @return array
*/
public function requestLimiter2(Request $request): array
{
$uri = $request->getUriPath();
return ['requestLimiter2', $uri];
}
/**
* @param Request $request
*
* @return array
*/
public function limiterFallback(Request $request): array
{
$uri = $request->getUriPath();
return ['limiterFallback', $uri];
}
}
ключ поддерживается здесьsymfony/expression-language
выражение, которое будет вызываться, если скорость ограниченаfallback
определено вlimiterFallback
метод
Центр конфигурации
Прежде чем говорить о конфигурационном центре, давайте поговорим о конфигурационном файле, который нам знаком, он дает нам возможность динамически изменять работу программы. Чтобы процитировать кого-то еще:
Динамическая регулировка положения в полете во время работы системы (runtime)!
Я мог бы назвать нашу работу починкой деталей на быстро летящем самолете. Мы, люди, всегда были не в состоянии все контролировать и предсказывать. Для нашей системы нам всегда нужно резервировать некоторые линии управления, чтобы вносить коррективы, когда нам нужно контролировать направление системы (например, управление оттенками серого, настройка ограничения тока), что особенно важно для интернет-индустрии, которая принимает изменения.
Для автономной версии мы называем это конфигурацией (файлом), для распределенной кластерной системы — центром конфигурации (системой);
Что такое распределенный центр конфигурации?
С развитием бизнеса и обновлением микросервисной архитектуры количество сервисов и конфигурация программы увеличиваются (разные микросервисы, разные адреса серверов, разные параметры), а традиционный метод конфигурационного файла и метод базы данных уже не актуальны. достаточно для разработки.Требования к персоналу для управления конфигурацией:
- Безопасность: конфигурация хранится в базе кода вместе с исходным кодом, что может привести к утечке конфигурации;
- Своевременность: чтобы изменить конфигурацию, вам необходимо перезапустить службу, чтобы она вступила в силу;
- Ограничение: не поддерживает динамическую регулировку: например, переключение журнала, переключение функций;
Поэтому нам нужен центр конфигурации, чтобы управлять конфигурацией единообразно! Освободив бизнес-разработчиков от сложных и громоздких конфигураций, им нужно сосредоточиться только на самом бизнес-коде, что может значительно повысить эффективность разработки, эксплуатации и обслуживания. В то же время развязка пакетов конфигурации и выпуска еще больше повышает процент успешных выпусков и обеспечивает мощную поддержку мелкомасштабного контроля и аварийного управления эксплуатацией и обслуживанием.
Что касается центра распределенной конфигурации, то в Интернете уже есть много решений с открытым исходным кодом, таких как:
Apollo — это распределенный центр конфигурации, разработанный отделом инфраструктуры Ctrip. Он может централизованно управлять конфигурацией различных сред и кластеров приложений. После модификации конфигурации его можно передать на сторону приложения в режиме реального времени. Он имеет стандартизированные разрешения, управление процессами и другие функции, подходящие для микросервисов Сценарии управления конфигурацией.
Эта глава начинается сApollo
Например, извлеките конфигурацию из удаленного центра конфигурации и безопасно перезапустите службу. если правильноApollo
Незнакомо, можешь сначала посмотретьSwoft
расширятьApollo
компоненты и чтениеApollo
Официальная документация.
Эта глава начинается сSwoft
используется вApollo
Например, когдаApollo
После изменения конфигурации перезапустите службу (http-server/rpc-server/ws-server). Ниже приведен пример агента:
<?php declare(strict_types=1);
namespace App\Model\Logic;
use Swoft\Apollo\Config;
use Swoft\Apollo\Exception\ApolloException;
use Swoft\Bean\Annotation\Mapping\Bean;
use Swoft\Bean\Annotation\Mapping\Inject;
/**
* Class ApolloLogic
*
* @since 2.0
*
* @Bean()
*/
class ApolloLogic
{
/**
* @Inject()
*
* @var Config
*/
private $config;
/**
* @throws ApolloException
*/
public function pull(): void
{
$data = $this->config->pull('application');
// Print data
var_dump($data);
}
}
Выше приведен простой пример конфигурации Apollo,Swoft-Apollo
Помимо этого метода, есть и другие способы его использования.