об авторе
квадратный
Отвечал за потоковое вещание на работу в Cisco, отвечал за развитие системы подачи микроблогов, три года опыта разработки в игровой индустрии, действующий главный архитектор Ло Цзи, думая, ведущий Луо Цзи, думая о преобразовании микросервиса.
план содержания
1. Предыстория трансформации
2. Перейти языковую практику в процессе трансформации
3. Сводка опыта
4, что делает?
1. Фон из макияжа
Самый ранний APP — это отдельное приложение PHP, которое представляет собой самый большой желтый блок на рисунке, а синий блок в середине представляет различные модули. Желтая часть ниже представляет собой паспорт и платежную систему, которая существовала до того, как ее можно было сделать, потому что в первые дни у компании был бизнес электронной коммерции в WeChat.
Быть
Позже выяснилось, что некоторую бизнес-логику не нужно получать, а некоторые работы по преобразованию формата данных не нужно полностью совмещать с бизнесом, поэтому шлюз со слоем PHP — это часть V3, показанная на рисунке. ниже. Однако при этом также возникают некоторые проблемы.Бэкенд PHP — это FPM.Поскольку интерфейс бэкенда медленный, необходимо запускать большое количество FPM для обеспечения одновременного доступа, что приводит к высокой нагрузке на операционную систему. С этой точки зрения, используйте PHP для выполнения этой части работы.Не подходит.
1.1 Дом протекает, когда ночью идет дождь
31 августа крупный сбой
31 августа 2017 года начальник провел мероприятие, в результате которого трафик превзошел ожидания, и система зависла на два часа.
Учитель Луо празднует Новый год
Каждый год г-н Луо произносит речь в канун Нового года. В первый год это было на Youku, и более 2 миллионов человек посмотрели его в Интернете. Во второй год он сотрудничал с такими видеосайтами, как Youku и Shenzhen Satellite TV. для прямой трансляции.В 2016 году рейтинги спутникового телевидения Шэньчжэня были первыми на местном уровне. В 2017 году начальник хотел что-то отправить, и сцена отправки чего-то была довольно страшной: как только выдавался QR-код, его одновременно запрашивало большое количество пользователей.
Самое страшное, что вещей, которые хочет отправить начальник, 31 августа нет в наличии, и их надо разрабатывать в ближайшие два месяца. С одной стороны, бизнес-итерация не может быть остановлена, а с другой стороны, ее нужно провести до Нового года, поэтому нам нужно трансформировать бизнес-систему.
1.2 Цели преобразования
высокая производительность
Во-первых, высокая производительность: если на одной машине запускать десятки запросов в секунду, то группе машин сложно удовлетворить требования.
Обслуживание
На самом деле сервисизация началась до сбоя, и, поскольку наши разные бизнес-команды уже отвечают за разные предприятия, на самом деле необходимо продолжать сервисизацию.
Разделение ресурсов и изоляция
В процессе сервисизации ресурсы должны быть разделены, каждая служба должна предоставлять соответствующий интерфейс, и службы не могут напрямую обращаться к базе данных или кэшу других служб.
Высокая доступность
Целью в то время была доступность 99,9.
1.3 Почему стоит выбрать Go
Go имеет много преимуществ, самое главное, что PHP-программистам легче начать работу, а производительность намного выше.
2. Процесс трансформации
2.1 Во-первых, это схема архитектуры системы
Быть
Для преобразования системы первое, что вам нужно знать, это то, во что система должна быть преобразована. Итак, нам нужен архитектурный план. Это наш архитектурный план. Первое, что вам нужно, это унифицированный внешний API GATEWAY, верхняя желтая часть на рисунке. Сиреневая часть посередине — внешняя бизнес-служба. Светло-зеленая часть — это основная служба ресурсов, такая как информация аудиодокумента, служба шифрования. Красные части ниже — это общедоступные сервисы, такие как оплата и паспорт, а справа — некоторые распространенные фреймворки и промежуточное ПО. Нижний уровень — это некоторая инфраструктура.
Наш фреймворк переплетается с улучшением инфраструктуры и реконструкцией системы.Это не значит, что с самого начала будет полностью беспроблемный дизайн.С трансформацией бизнеса будет добавлено много новых функций.
2.2 Улучшение структуры и инфраструктуры
Я не буду говорить о том, как разделить систему приложений, потому что бизнес-системы каждой компании разные, я расскажу о нашем фреймворке и промежуточном программном обеспечении.
API gateway
API Gateway — это наша команда с командой Chen Hao (знаменитая мышь для левого уха). Их команда очень помогает нашему успешному Новому году, во-первых, спасибо.
-
Цель
-
Ограничение
Основная цель API-шлюза - ограничить ток.В процессе трансформации у нас есть более 400 интерфейсов онлайн, и часто добавляются новые функции. Мы можем гарантировать работоспособность нового интерфейса, но всегда есть старые интерфейсы, которые были заброшены в процессе обновления.Ограничитель тока шлюза API может гарантировать, что некоторые пользователи старых интерфейсов будут доступны при большом трафике.
-
Обновить API
Большинство обновлений API решается с клиентом, но мы не заставляем пользователей обновляться, что приводит к существованию старого онлайн-интерфейса в течение длительного времени.Нам нужно что-то делать на уровне шлюза API для преобразования формата данных из нового интерфейса в старый интерфейс Работа формата данных.
-
Аутентификация
После того, как служба разделена, интерфейс должен быть аутентифицирован и доступ к нему должен быть унифицирован. Практика отрасли обычно выполняется на уровне шлюза, и мы не являемся исключением.
-
Затем посмотрите на архитектуру Gateway API
Быть
Шлюз API состоит из узла записи и нескольких узлов чтения, и узлы обмениваются данными через протокол сплетен. Верхний уровень каждого узла имеет командную строку CLI, которую можно использовать для вызова Gateway API. Базовый HTTPServer — это подключаемый модуль, а несколько подключаемых модулей формируют разные конвейеры для обработки разных запросов. Я опишу конструкцию этого позже. У каждого узла есть модуль статистики для получения некоторой статистики, в основном это среднее время отклика интерфейса, количество запросов в секунду и т. д. После изменения конфигурации узел записи синхронизирует информацию о конфигурации с узлом чтения и сохранит ее на локальном диске через модуль модели.
Быть
Запрос проходит через два конвейера, первый из которых основан на запрошенном URL-адресе. Разные плагины можно комбинировать на разных пайплайнах. Предполагая, что интерфейс не требует ограничения тока, необходимо только добавить плагин ограничения в конфигурацию интерфейса. Второй конвейер основан на конфигурации сервера бэкенда и выполняет некоторую работу по балансировке нагрузки.
Далее давайте рассмотрим аспекты процесса и планирования всего запуска шлюза API.
Быть
Начало относительно проста для загрузки плагина, затем перейдите на загрузочный файл конфигурации, в зависимости от файла конфигурации, а трубопровод плагина согласен. Планировщик разделен на верхний правый угол статического и динамического планирования. Предполагается, что статическое планирование выделено 5 Go Repinifine Rebable, всегда имеет пять процедур GO для обработки запроса. Запрос динамического планирования занят между максимальными и минимальными изменениями.
Быть
Аутентификация шлюза API относительно проста: клиент вызывает интерфейс входа в систему, и паспорт передает токен и идентификатор пользователя шлюзу API, а шлюз API затем передает соответствующий токен в приложение. Клиент примет запрос на токен в следующий раз, и если токен не может быть проверен, он вернется к клиенту. Если проверка получена путем вызова различных служб на серверной части, результат, наконец, возвращается клиенту.
Наконец, давайте подчеркнем, как работает API-шлюз.
Быть
Мы вводим две текущие стратегии ограничения в шлюзе API
1.Ограничение тока в скользящем окне
Зачем ограничивать ток в соответствии с раздвижным окном? Поскольку есть слишком много онлайн-интерфейсов, мы не знаем, ограничивает ли 100, 200 или 10000, если каждый не подвергается стрессовым тестированию. Используйте скользящее окно для подсчета времени отклика, количество успехов и сбоев в окне временного времени и принять решение о том, ограничивает ли ток в окне следующего времени.
2. Предел тока QPS
Зачем по-прежнему оставлять текущее ограничение количества запросов в секунду? Поскольку действие должно быть выполнено, скользящее окно является временным окном.Во время действия клиент берет мобильный телефон и сканирует QR-код, и трафик поступает мгновенно.Скользящее окно в этом случае трудно воспроизвести. .
сервисная структура
-
Цель
-
Упрощение разработки приложений
-
Обнаружение регистрации службы
-
Простое управление конфигурацией
-
Общая архитектура сервисной инфраструктуры
Быть
Первый способ — сделать библиотеку и скомпилировать соответствующие функции в сам сервис. Здесь есть две проблемы: во-первых, мы совместимы с несколькими языками, а объем разработки относительно велик. Другой заключается в том, что после того, как клиент последует за вызывающим сервисом и выпустит его в производственную среду, если клиентская библиотека будет обновляться в будущем, вызывающий сервис должен будет изменить код и повторно опубликовать его, поэтому существует значительное сопротивление обновление и продвижение этого решения. В промышленности этот механизм используют весеннее облако, даббо и мотан.
Быть
Другое решение состоит в том, чтобы взять функцию Lord Balancing и превратить ее в агента, и запустить его отдельно с потребителем.Каждый раз, когда потребитель запрашивает, он получает адрес поставщика услуг через агента, а затем вызывает поставщика услуг. Преимущество заключается в том, что он упрощает вызывающую службу, не требует разработки клиентских библиотек для разных языков, а обновление LB не требует от вызывающей службы изменения кода. Недостатки тоже очевидны, деплой сложнее, и определение доступности будет чуть хлопотнее, да и агент может зависнуть. Если агент зависает, вся служба также отключается. То же самое делают внутренняя BNS Baidu и система обнаружения сервисов Airbnb SmartStack. Поскольку у нас больше внутренних языков, был выбран второй подход.
Быть
В кластере Consul агент Consul должен быть развернут и запущен на каждом узле, предоставляющем услуги, а совокупность всех запущенных узлов агента Consul составляет кластер Consul. Консул агент имеет два режима работы: Сервер и Клиент. Сервер и Клиент здесь отличаются только на уровне кластера Consul и не имеют ничего общего со службами приложений, построенными на кластере. Узел агента Consul, работающий в режиме сервера, используется для поддержания состояния кластера Consul.Официально рекомендуется, чтобы каждый кластер Consul имел как минимум 3 или более работающих на сервере. Агент режима и клиентский узел не ограничены.
Роли Клиента и Сервера строго не различаются в DDNS.Сервис является Клиентом, когда услуга запрашивается, и Сервером, когда услуга предоставляется.
NNDS предоставляет SDK, который можно легко интегрировать и расширять как независимую услугу, а также интегрировать больше функций. В режиме агента установленный агент будет развернут на каждом сервере для поддержки запросов с использованием HTTP и grpc.
Быть
После того, как сервис запустится и сможет предоставлять услуги внешнему миру, запросите интерфейс агента v1/service/register для его регистрации в DDNS;
Если регистрация прошла успешно, другие клиенты могут получить информацию об узле APP через интерфейс обнаружения DDNS;
Если регистрация не удалась, приложение будет неоднократно пытаться перерегистрироваться, а если это не удастся три раза, оно подаст сигнал тревоги;
Быть
Предполагая, что службе A необходимо запросить службу B, имя службы — bbb, и напрямую запросить интерфейс локального агента v1/service/getservice для получения информации об узле службы bbb.
Для агента, если сервис bbb запрашивается в первый раз, он запросит кластер Consul, после получения данных сервиса bbb выполнит локальный ведомый кеш и наблюдает за мониторингом узла, обслуживающего bbb, и обновляет местная служебная информация регулярно;
В случае сбоя сбора данных укажите причину и подайте сигнал тревоги, если это системная ошибка;
Это базовый интерфейс сервисного фреймворка.
Быть
Это инкапсуляция клиентского вызова, который может одновременно поддерживать HTTP и JRTC.После этого мы также делаем контроль разрешений RBAC.Мы надеемся, что какие сервисы могут быть настроены могут осуществлять контроль разрешений.
Многомашинный кеш
Быть
Когда клиент запрашивает сервер, сервер сначала ищет в кеше, возвращает его, если он найден, и ищет в базе данных, если он не найден.Если он найден, он устанавливается обратно в кеш, а затем возвращается в клиент. Вот более простая модель. Есть только кеш первого уровня, но кеша первого уровня может не хватить.Например, в ходе стресс-теста мы обнаружили, что поддерживаемый редисом QPS на интерфейс в нашей бизнес-ситуации составляет около 10 000. Что, если QPS выше? Мы вводим многоуровневое кэширование.
Быть
Чем ближе кеш к верху, тем меньше кеш.Первый уровень это служебный локальный кеш.Если попадется,то возвращает данные.Если нет,то переходит на L1 для проверки.Если найдется,то локальный кеш обновляется и данные возвращаются. Если у вас нет уровня L1, перейдите
Проверка уровня L2, если данные найдены, кэш L1/локальный кэш обновляется, и данные возвращаются
Быть
То, что мы видели выше, — это кеш для отдельного фрагмента контента, а если посмотреть на весь стек, то шлюз может также кэшировать часть данных без запроса проникновения. Что означает пунктирная линия 5? Поскольку данные необходимо обновлять после модификации, иногда на уровне приложения могут возникать сбои, поэтому прочитайте бинарный журнал базы данных, чтобы заполнить пробел и уменьшить несогласованность данных.
Быть
我一直觉得如果有泛型代码好写很多，没有泛型框架里面就要大量的反射来代替泛型。
|
php with redis cache |
go with redis cache |
go with big cache |
go with object cache |
|
|
Бесплатная колонка Главная |
100+ |
600+ |
2000+ |
12000+ |
|
Главная страница платного доступа |
200+ |
900+ |
2400+ |
14000+ |
После того, как добавили многоуровневый кеш, сравнили общую производительность.Самый ранний PHP был сто-двести.После перехода на Go он был ненамного сильнее.Позднее Go и больших кешей было около двух тысяч,но были некоторые проблемы, которые будут обсуждаться позже, когда проблемы. Кэш на основе объектов позже кэширует объект.Машина, на которой мы запускаем тест, является восьмиядерной, и этот результат является приемлемым.
Слияние понижения
Быть
Интерфейс одновременно запрашивает внутренние сервисы.Сервис7, 8 и 9 разные.Сервис5 находится в приостановленном состоянии, но внешний сервис все равно каждый раз вызывается.Нам нужно уменьшить количество вызовов и дать сервису5 восстановиться.
Быть
В открытом состоянии, если сбой достигает определенного порога, оно будет закрыто.После того, как взорванное окно закончится, оно достигнет полуоткрытого состояния и примет часть запроса. Если порог отказа высокий, вернитесь в закрытое состояние. Этот статистический подход представляет собой алгоритм скользящего окна, о котором мы упоминали ранее.
Быть
Вот библиотека, пересаженная с помощью JAVA hystrix.В JAVA есть много хорошо сделанных фреймворков и библиотек, на которых стоит поучиться.
3. Сводка опыта
3.1 Общая базовая библиотека очень важна
В только что упомянутой части улучшения производительности нам потребовался всего один день, чтобы увеличить количество запросов в секунду с 600 до 12000. Основная причина в том, что мы сделали много оптимизации с помощью базовой библиотеки, и улучшение базовой библиотеки принесет пользу. все услуги.
3.2 Удовлетворенность инструментами
• Generate + Framework Улучшает эффективность развития
• pprof+trace+go-torch для выявления проблем с производительностью
Например, мы используем множество generate + framework для генерации большого количества кода с помощью generate и шаблонов. При проверке производительности pprof+trace+go-torch может сэкономить вам много работы. Go-torch предназначен для графов пламени, а в новой версии Go есть встроенные функции графов пламени.
Быть
Это для генерации соответствующего кода доступа к базе данных в соответствии с нашей структурой таблицы.Многоуровневый кеш абстрагирует все обращения в KV, K-LIST и другие режимы доступа.Это слишком громоздко каждый раз писать вручную, поэтому мы просто делаем. есть инструмент, какую таблицу вы используете, инструмент будет сгенерирован, вам просто нужно его собрать.
При обнаружении проблем с производительностью необходимо использовать графики пламени.
Быть
Например, проблема производительности позиционирования зависит от того, где находится самое длинное место, и мы сосредоточимся на оптимизации кода этой горячей точки.Во время стресс-теста мы обнаружили, что есть проблема с графиком пламени 600 и 900. После оптимизация завершена, показан следующий рисунок.
3.3 Краткий обзор другого опыта
Оптимизация для горячего кода
Разумное повторное использование объектов
старайтесь избегать отражений
Разумные методы сериализации и десериализации
GC накладных расходов
Например, раньше у нас был сервис, который получал список множества идентификаторов из кеша, а данные хранились в формате json [1, 2, 3]. Таким образом, мы обнаружили, что накладные расходы на сериализацию json и десериализация очень велика, в основном будет составлять более 50% стоимости. Утром Didi рассказали о своей json библиотеке, которая может повысить производительность в 10 раз.На самом деле в нашем сценарии она не может так сильно улучшиться.Его можно только удвоить.Конечно удвоение производительности тоже большое улучшение (потому что вам нужно изменить только одну строку. Код можно улучшить очень сильно). Во-вторых, проблема GC, вызванная сериализацией риса json, тоже очень серьезная, и может достигать 20% загрузки ЦП в пике, даже когда алгоритм Go тоже неплохо справляется. Окончательное решение — ввести здесь PB вместо json. Производительность десериализации PB (в нашем случае) действительно в 10 раз выше, чем у json, и выделяет гораздо меньше временных объектов, что также снижает накладные расходы GC.
Зачем избегать отражения? Мы построили локальный кеш локально, и для кеширования всего объекта требуется, чтобы вы не могли изменять объект вне кеша, но на самом деле это бизнес-требование. После того, как мы столкнулись с такой ситуацией, мы используем рефлексию для глубокого копирования. Отражение JAVA также можно использовать, потому что jvm будет генерировать код JAVA из кода отражения и фактически вызывать сгенерированный код. Но этого нет в Go.Изначально производительность Go близка к производительности C. После многократного использования отражения производительность близка к производительности python. Позже мы определили клонируемый интерфейс и позволили программисту вручную выполнить клонирование.
испытание давлением
В основном мы используем ab и Siege, которые обычно являются стресс-тестами для одной системы. На самом деле, в процессе использования могут возникнуть проблемы в каждой части цепочки вызовов. Так что в случае с микросервисами нагрузочное тестирование отдельной системы хоть и важно, но недостаточно для полного устранения всех проблем с нашей системой.
Например, когда босс Луо хочет что-то доставить в канун Нового года, он должен сначала получить вещь, то есть интерфейс, затем пользователь обычно пролистывает купленный список, чтобы увидеть, доступен ли он, и, наконец, подтверждает, что вещь он получил правильно неправильно. Следовательно, вам необходимо провести стресс-тестирование всей ссылки, а не только принимающего интерфейса, что может быть проблематично. Предположим, что интерфейс вашего купленного списка относительно медленный. После того, как пользователь его получит, вы можете провести пальцем, чтобы увидеть, есть ли он. Если нет, обычный пользователь продолжит листать, и чем медленнее интерфейс, тем больше вероятность, что это так. стать узким местом. Следовательно, необходимо разумно планировать путь доступа и проводить стресс-тестирование всех сервисов на канале, а не только одного сервиса.
Мы напрямую купили услугу Alibaba Cloud PTS, Их подход заключается в моделировании запросов на узлах CDN, которые могут моделировать весь путь доступа.
4. Что ты делаешь
4.1 Подтаблица подбазы данных и распределенная транзакция
Выбор базы данных имеет отношение к операциям, связанным с вашей компанией. Здесь важнее распределённые транзакции, у нас много ссылок на покупку, раз микросервис разобрали, пока ошибка в одном месте, нужно откатывать всё. Наш текущий подход — это ручное управление, но, поскольку у вас есть все больше и больше предприятий, невозможно контролировать все вручную.В настоящее время требуется структура распределенных транзакций, поэтому мы сейчас делаем свою собственную на основе TCC. .
Подтаблица подбазы данных также является жестким требованием.Причина, по которой мы не использовали tidb здесь, в основном состоит в том, что группа администраторов баз данных не знакома с tidb. Наша предыдущая подбаза данных и подтаблица также обрабатывались самими программистами, и теперь мы работаем над фреймворком, который поддерживает как подбазу данных, так и подтаблицу, а также хэш и диапазон.
4.2 API gateway
Есть много вещей, которые можно сделать на шлюзе API, и мы сделали некоторые вещи в автоматическом выключателе и даунгрейде. Многое из того, что сейчас делают некоторые сервисные сетки, связано с большой нагрузкой на внутренний API-шлюз, который является элементом управления и не должен касаться бизнес-логики. Мы также рассматриваем возможность совмещения шлюза API и SM.
4.3 APM
После демонтажа микросервиса самая большая проблема заключается в том, что неудобно локализовать конкретную проблему. У нас иногда бывают проблемы.Я прошу нескольких человек посмотреть, исправны ли системы, за которые они отвечают.Все видят, где проблема.Это довольно болезненный подход. После входа в APM+tracing нам удобно отслеживать, где проблема.
4.4 Контейнеризация
Наша текущая онлайн-среда по-прежнему использует виртуальные машины. Среда моделирования и тестовая среда уже являются контейнерами.У использования контейнеров много преимуществ, поэтому я не буду перечислять их все. Это также ключевая работа, которую предстоит выполнить во втором полугодии.
4.5 Кэш-сервис
Сейчас мы реализуем многоуровневое кэширование, но многоуровневое кэширование по-прежнему реализовано в виде библиотеки. Если кеш извлечен, используйте протокол memcached или redis и извлеките его, чтобы он стал независимой службой. Когда последующая бизнес-система повторяется, вам не нужно заботиться о стратегии расширения и сжатия самого кэша.
Вот и все, чем я делюсь сегодня, спасибо всем!
【Вопросы и ответы】
Спрашивающий 1
Просить:Из вашего описания я знаю, что у вас уже был опыт работы с JAVA. На самом деле у нашего Go нет готового решения для более зрелого микросервиса, такого как JAVA spring cloud. Теперь позвольте вам переделать сервис- ориентированное преобразование, как бы вы выбрали?
Квадратный:Труднее дать группе PHP-программистов изучить JAVA, но легче выучить Go. Во-вторых, принять микросервисный фреймворк сейчас не так сложно. Поскольку многие программы с открытым исходным кодом уже предоставляют соответствующие функции, не так уж много колес нужно строить.
Спрашивающий 2
Вопрос:Поддерживает ли структура подтаблиц вашей подбазы данных горизонтальную подбазу данных?
Квадратный:служба поддержки.
Спрашивающий 3
Просить:Общеизвестно, что PHP — лучший язык в мире, вы переключаетесь на Go, и эффективность разработки Go выше, чем у PHP (04:49:50).
Квадратный:Я не очень хорошо разбираюсь в PHP, и писать на Go самому должно быть намного быстрее, чем на PHP. Для нашей команды эффективность разработки на Go немного ниже, чем на PHP, но производительность намного выше.
Просить:Повторно выберите выбор технологии, вы выбираете Go, когда впервые приходите, или вы переходите от PHP к Go?
Квадратный:Я определенно выбрал Go, когда пришел, я все еще думаю, что у PHP нет никаких преимуществ в качестве API для отдыха.
Gopher Meetup 2018 начнет первую остановку в Шэньчжэне.На этот раз многие новые лекторы приглашены поделиться опытом использования Go со всеми~
нажмитечитать оригиналзарегистрироваться