Привет всем, я树下搜胡(Название происходит от романа, который я читал раньше, может быть, все читали, изменил слово О(∩_∩)О ха-ха~), технический старик, который занимается интернет-индустрией более 10 лет, сражался на переднем крае технологий, преодолевая трудности, в данный момент работаю архитектором в неизвестной интернет-компании, спасибо за внимание, в будущем буду больше общаться.
В этой статье в основном описывается метод практического тестирования, чтобы увидеть, улучшается ли производительность за счет развертывания службы.
При необходимости вы можете обратиться к
Если было полезно, не забудь поставить лайк ❥
Публичная учетная запись WeChat открыта, cto Alliance, студенты, которые не обратили на это внимание, не забудьте обратить внимание!
1. Развертывание версии для одной машины
1.1. Архитектура развертывания
База данных и приложение находятся на одном физическом компьютере, и между базой данных и приложением будет конфликт ресурсов.
1.2. Тестовый случай давления
Отчет о полимеризации: среднее время отклика, пропускная способность (количество запросов в секунду)
График кривой TPS:
График кривой ВУ:
Чрезвычайно высокие требования: каждый интерфейс составляет десятки мс, в пределах 100 мс
2. Раздельный режим
2.1. Отдельная архитектура развертывания
Для связи с сервером используется связь внутри сети, поэтому влияние сети незначительно. (связь внутри локальной сети)
2.2. Ситуация с испытанием под давлением
Совокупные отчеты: увеличение на 400 запросов в секунду
График кривой TPS:
РТ: время отклика
Процессор, ввод-вывод, память являются эксклюзивным режимом для программы.
3. Распределенное развертывание
3.1. Архитектура развертывания
Оценка трафика: Одна машина: 3288 2 машины: 3288*2 = 6500+
3.2. Openresty
.configure
make && make install
Установка по умолчанию: /usr/local/openresty
Конфигурация:
3.3. Ситуация с испытанием под давлением
Сводный отчет:
График кривой TPS:
Обычно настроенный сервер: развертывание нескольких служб на одном сервере имеет низкую производительность и низкую стабильность; Высокопроизводительный сервер: 64cpus 128G IBM Unix ($200w) ------ автономное развертывание ---- перезагрузка
4. Масштабируемая емкость K8s
4.1. облачный носитель
Alibaba: В прошлом году все проекты были переведены в облако (порядок: 50 Вт+/с)
Облачный родной:
Большое количество серверов образуют среду, и эта среда может рассматриваться в целом, которая является компьютером (CPU: сумма, память: сумма)
Вопрос: сложно управлять
Openstack
构建企业级私有云 （虚拟机）
容器（docker容器）
Docker容器中部署很多服务，海量服务需要部署，意味着有海量的容器（google：2亿容器/day）
Проблема: сложно управлять
Kubernetes
Облачный родной:
1、容器化 （所有的项目都必须跑在容器中）
2、微服务 （按照function进行拆分）
3、DevOps 开发+运维
4、ci/cd
CNCF : service mesh 服务网格架构加入云原生 （服务限流，熔断，治理…… istio）
架构师： 构建适合云原生的项目架构即可
Бессерверный ---- без обслуживания
4.2. Архитектура развертывания
Если служба POD обнаружит, что использование ЦП и памяти слишком велико, она немедленно расширит емкость модуля, чтобы облегчить атаку большого трафика. Следовательно, также необходимо развернуть HPA (автоматически запускать расширение и сжатие)
Стресс-тест: HPA Увеличение использования памяти, ЦП, расширение емкости и увеличение параллелизма
4.3. развертывать
1. объект ресурса развертывания развертывания 2. Объект сервисного ресурса 3. Входной ресурсный объект 4. Ресурсный объект HPA
Пропускная способность одного устройства POD: (1 ЦП, 2 ГБ памяти)
TPS:
4.4. Реализация расширения
Можно обнаружить, что когда наступает пик трафика, реплика пода расширяется;