предисловие
статус кво
- Различные решения для трассировки
- Сравнение систем трассировки основных производителей
Обзор трассировки узлов
NodeTracing использует
Реализовать идеи
Трудности реализации
Детали дизайна и реализации
контрольная работа
использованная литература
постскриптум

предисловие

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

статус кво

Различные решения для трассировки

Есть ли хорошее решение этой неприятной проблемы? Ответ да, и нет... В настоящее время коммерческие решения распределенной трассировки в основном включают следующие категории:

Распределенная система трассировки, не соответствующая стандарту OpenTacing
Решение для управления Service Mesh с использованием архитектуры ServiceMesh

envoy
istio ...

Встроенная распределенная система трассировки на основе стандарта OpenTraing

zipkin
jaeger
skywalking ...

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

Вторая категория — это использование схемы управления сервисной сеткой для распределенной трассировки с архитектурного уровня.Преимуществами являются мощные функции, широкая широта управления, высокая точность отслеживания и большой охват отслеживания. Но очевидны и недостатки: в настоящее время, будь то ServiceMesh первого поколения, представленный envoy, или ServiceMesh второго поколения, представленный istio, оба чрезвычайно тяжеловесны., требует специальной архитектуры и группы эксплуатации и обслуживания для тщательной предварительной подготовки и планирования перед внедрением, а стоимость развертывания высока.

Категория 3Распределенная система трассировки с использованием стандарта OpenTracing, OpenTracing — это стандарт трассировки, разработанный CNCF (знаменитый фонд облачных вычислений) для стандартизации отраслевых систем распределенной трассировки.Это может решить проблему кроссплатформенности и совместимости распределенной системы трассировки.. В настоящее время такие известные компании, как twitter, uber и apple, полностью следуют этому стандарту при разработке систем отслеживания.

Сравнение систем трассировки основных производителей

Различные продукты распределенной системы слежения всесторонне сравниваются в соответствии с целями проектирования и стандартами* (данные из Интернета, не являются официальными)*:

наименование товара	Производитель	открытый источник	Стандарт OpenTracing	инвазивный	стратегия применения	Своевременность	политическая поддержка	визуализация	низкое потребление	податливость
jaeger	uber	открытый источник	полностью поддерживаю	Частичное вторжение	Гибкая стратегия	Экономичный по времени протокол UDP для передачи данных (любая установка Jaeger в Uber может легко обрабатывать миллиарды интервалов в день).	Поддержка принятия решений лучше, а базовая часть поддерживает индикаторы метрик.	Отчеты небогаты, пользовательский интерфейс относительно прост	низкое потребление	Jaeger более сложен и использует множество фреймворков, например, фреймворк rpc принимает протокол thrift и не поддерживает протокол pb. Внутреннее хранилище более сложное. Но после масштабного использования uber обладает хорошей пластичностью.
zipkin	twitter	открытый источник	Частичная поддержка	Инвазивный	Гибкая стратегия	хорошая своевременность	Общее принятие решений (одна функция, недостаточные размеры для контроля и информация для контроля. Нет функции сигнализации)	Отчеты с расширенными данными	низкие системные накладные расходы	Хорошая пластичность
CAT	Публичный комментарийУ Цимин	открытый источник	-	Инвазивный	Гибкая стратегия	Своевременность хорошая, а инфраструктура rpc использует tcp для передачи данных.	хороший выбор	Богатые отчеты для удовлетворения различных потребностей	Низкий расход, многие отечественные производители используют	-
Appdash	sourcegraph	открытый источник	полностью поддерживаю	менее инвазивный	Поддержка частоты дискретизации (детализация: выборка не зависит от трафика, зависит только от количества запросов); нет переключения трассировки	Высокая своевременность	низкая поддержка принятия решений	Визуализация слишком слабая, нет анализа отчета	потребление. Крупномасштабное развертывание не поддерживается, так как appdash в основном зависит от памяти, хотя ее можно сохранить на диск, а хранилище памяти поддерживает хранение хэшей, хранение карт с периодом действия и неограниченное хранилище памяти.Хранение в памяти не может быть удовлетворено	плохая пластичность
MTrace	Мейтуан	Не с открытым исходным кодом	-	-	-	-	-	-	-	-
CallGraph	Цзиндон	Не с открытым исходным кодом	-	-	-	-	-	-	-	-
Watchman	Сина Вейбо	Не с открытым исходным кодом	-	-	-	-	-	-	-	-
EagleEye	Таобао	Не с открытым исходным кодом	-	-	-	-	-	-	-	-
skywalking	Хуавей Ву Шэн	открытый источник	полностью поддерживаю	менее инвазивный	Гибкая стратегия	лучшая своевременность	Благодаря более тонкой цепочке вызовов автор поддерживает хороший баланс между производительностью и точным отслеживанием. хороший выбор	Отчеты с расширенными данными	более низкое потребление	Пластичность очень хорошая, и уровень теоретически расширяется бесконечно

Комплексное сравнение распределенных систем отслеживания

1. jaeger对于go开发者来说，可能比较合适一些，但是入手比较困难。它的rpc框架采用thrift协议，现在主流grpc并不支持。后端丰富存储，社区正在积极适配
2. appdash对于go开发者想搭建一个小型的trace比较合适，不适合大规模使用
3. zipkin项目，github很活跃，star数量很多，属于java系。很多大厂使用
4. CAT项目也属于java系, github不活跃，已不太更新了。不过很多大厂使用，平安、大众点评、携程...
5. skywalking项目, 也属于java系。目前已成为Apache下的项目了，github活跃，作者也非常活跃，当当、华为正在使用。
6. appdash项目，go语言开发，因为可视化过于简单、且完全内存存储，不太适合大规模项目使用。

В дополнение к распределенной системе слежения с закрытым исходным кодом, описанной выше, jaeger, zipkin и skywalking являются хорошим выбором с открытым исходным кодом.Однако читатели могли обнаружить, что,Вышеупомянутые распределенные системы трассировки имеют хорошую поддержку платформы Java, но поддержка других платформ относительно ограничена, особенно автоматическая часть малоинвазивного кода.. Более того, все вышеперечисленные распределенные системы трассировки,Все без исключения производственные развертывания (не простые опыты) сложны, некоторые даже зависят от kubernetes. Это отпугивает многие малые и средние предприятия, которые хотят использовать распределенные системы отслеживания для решения практических задач.

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

Обзор трассировки узлов

Я хотел бы иметь возможность вставить строку в приведенную выше таблицу:

наименование товара	Производитель	открытый источник	Стандарт OpenTracing	инвазивный	стратегия применения	Своевременность	политическая поддержка	визуализация	низкое потребление	податливость
NodeTracing	cheneyxu	открытый источник	полностью поддерживаю	Автоматический датчик, почти неинвазивный	Гибкая стратегия	Своевременность в секундах	Лучшее принятие решений и непрерывная эскалация	Различные диаграммы, включая диаграмму топологии службы, диаграмму Ганта и т. д., которые постоянно обновляются.	Очень низкое потребление	Ассоциативная архитектура без сохранения состояния, полностью контейнеризированные узлы отслеживания, легкая и простая кластеризация, постоянное хранилище с памятью и LevelDB могут обрабатывать более миллиарда данных.

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

#NodeTracingUse ##скачать

git clone https://github.com/cheneyweb/nodetracing
cd nodetracing && npm i

##Быстрый старт и одноэлементный старт

cd server && npm run standalone

##Производственное развертывание и запуск кластера

docker stack deploy --prune -c docker-compose.yml nodetracing

**Развернуть NodeTracing так просто! **После выбора одноэлементного запуска/запуска кластера по мере необходимости откройте браузер для доступа:http://localhost:3636/nodetracing/web/index.htmlВы можете увидеть страницу управления системой, пароль учетной записи по умолчанию: admin/123456

##Установить автоматический зонд

npm i nodetracing

Инициализация зонда (первая строка записи приложения)

const nodetracing = require('nodetracing')
const tracer = new nodetracing.Tracer({
	serviceName: 'S1',      // 必须，服务名称
	rpcAddress: 'localhost',// 必须，后台追踪收集服务地址

	rpcPort: '36361',       // 可选，后台追踪收集服务端口，默认：36361
	auto: true,             // 可选，是否启用自动追踪，默认：false
	stackLog: false,        // 可选，是否记录详细堆栈信息（包括代码行号位置等，启用内存消耗较大），默认：false
	maxDuration: 30000      // 可选，最大函数执行时间（垃圾回收时间间隔），默认：30000
})

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

асинхронный автоматический зонд (поддерживает асинхронные функции)

async function func1(){
	...
}
async function func2(){
	...
}
func1 = nodetracing.aop(func1)
func2 = nodetracing.aop(func2)
...

автоматический зонд http-запроса (axios)

axios.interceptors.request.use(nodetracing.axiosMiddleware())

автоматический зонд HTTP-ответа (koa/express)

//koa
app.use(nodetracing.koaMiddleware())
//express
app.use(nodetracing.expressMiddleware())

автоматический зонд grpc-client (собственный)

const grpc = require('grpc')
const Service = grpc.loadPackageDefinition(...)[packageName][serviceName]
new Service("ip:port", grpc.credentials.createInsecure(), { interceptors: [nodetracing.grpcClientMiddleware()] })

автоматический зонд grpc-server (собственный)

const grpc = require('grpc')
const interceptors = require('@echo-health/grpc-interceptors')
let server = new grpc.Server()
server = interceptors.serverProxy(this.server)
server.use(nodetracing.grpcClientMiddleware())

автоматический зонд grpc-client (фреймворк x-grpc)

const RPCClient = require('x-grpc').RPCClient
const rpcClient = new RPCClient({
    port: 3333,
    protosDir: "/grpc/protos/",
    implsDir: "/grpc/impls/",
    serverAddress: "localhost"
})
rpcClient.use(nodetracing.grpcClientMiddleware())
rpcClient.connect()
let result = await rpcClient.invoke('demo.User.login', { username: 'cheney', password: '123456' } , optionMeta?)

автоматический зонд grpc-сервера (фреймворк x-grpc)

const RPCServer = require('x-grpc').RPCServer
const rpcServer = new RPCServer({
    port: 3333,
    protosDir: "/grpc/protos/",
    implsDir: "/grpc/impls/",
    serverAddress: "localhost"
})
rpcServer.use(nodetracing.grpcServerMiddleware())
rpcServer.listen()

Реализовать идеи

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

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

Трудности реализации

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

Ручные зонды довольно навязчивы в коде, и почти сложно требовать от разработчиков всегда помнить о том, чтобы закапывать зонды, а ручное сокрытие также чревато ошибками, которые легко могут привести к неверным результатам.
По сравнению с ручными зондами автоматические зонды являются лучшим выбором, но автоматические зонды сложно внедрить, а объем поддержки ограничен в зависимости от степени внедрения.
Службы отслеживания, способ развертывания кластера необходимо учитывать при разработке архитектуры, а максимально простое развертывание является первоочередной задачей.
Сервис визуализации, как выбрать схему сохранения данных? Как сбалансировать простое развертывание и высокую производительность — это сложно
Общий выбор языка разработки решения, высокая производительность сети, высокая асинхронная производительность, низкая зависимость от платформы и низкая сложность развертывания являются приоритетом, поэтому нет сомнений, что nodejs — лучший выбор.

Детали дизайна и реализации

Зонды NodeJS

OpenTracing API

Во-первых, для реализации зонда стандарт OpenTracing фактически дал интерфейс, для текущей начальной версии приоритет отдается платформе nodejs, которая еще не имеет зрелой распределенной системы трассировки. Итак, первый шаг должен быть основан наopentracing-javascriptРеализовать интерфейс API OpenTracingК сожалению, на этом этапе официальные документы, предоставленные OpenTracing, очень ограничены.Если вы хотите полностью реализовать полный набор API, вы должны набраться терпения и прочитать исходный код JS OpenTracing.Другого пути нет.

Async Hook

После внедрения OpenTracing API завершается только внедрение ручного зонда, т.к.OpenTracing на самом деле только определяет стандарты интерфейса и стандарты данных отслеживания и не дает идеи реализации автоматических зондов.Поэтому на самом деле реализация автоматических зондов зависит от свободных характеристик каждой языковой платформы. Но неотделимо от него,Любая языковая платформа, которая хочет реализовать автоматические проверки, должна реализовать АОП и отслеживание контекста, иначе это практически невозможно.Поскольку предпочтительнее поддерживать платформу nodejs, реализация автоматических зондов на nodejs в основном зависит от двух ключевых технологий:

async hook
function merging

в,Async Hook - это схема отслеживания асинхронного ресурса, запущенная после Node8.x, до сегодняшнего дня node11.x изначально созрел. Используйте асинхронный хук для отслеживания всех асинхронных взаимосвязей ресурсов, что необходимо для автоматических зондов.

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

Слияние функций в основном используется для реализации АОП на платформе nodejs., здесь в основном нужны некоторые навыки грамматики для достижения, АОП очень критичен для автоматических зондов, с АОП есть возможность межсервисного отслеживания

Зонд Java (планирование...)

служба отслеживания

Служба отслеживания используется для получения спанов, загруженных зондом., очевидно, что если архитектурный проект службы отслеживания не является хорошим, то это будет узким местом производительности всей системы отслеживания. И что является узким местом производительности самой системы мониторинга APM? так,Кластеризация сервисов отслеживания неизбежна. Однако кластеризация неизбежно столкнется с проблемой высокой сложности и сложности развертывания.Я не хочу, чтобы все, кто использует NodeTracing, чувствовали, что его сложно развертывать, иГотовое производство — это первоначальный замысел создания NodeTracing.. Поэтому при выборе этого шагаDocker Swarm — лучший выбор, минималистская элегантность Docker Swarm действительно впечатляет, на этот раз я все же решил использовать контейнерный кластер, чтобы решить проблему узкого места производительности службы отслеживания.

Во-первых, службу отслеживания требований можно легко масштабировать параллельно, что потребует, чтобы каждая отдельная служба не имела состояния и не была связана друг с другом.Вот колеса, которые сделал сам раньшефреймворк x-grpc. Это независимая структура службы grpc, которая очень подходит для этой простой, быстрой и высокопроизводительной пропускной способности данных rpc.
Затем упакуйте службу отслеживания в зеркальное отображение.
Наконец, мы можем передать простое предложениеdocker stackкоманда для развертывания кластера отслеживания на любом узле

сервис визуализации

На этапе сервиса визуализации мы наконец-то прошли уровень, а это значит, что данные пролета собраны, и нам нужно подумать, как их использоватьПостоянное хранение и визуальное представление для принятия решенийПоследним пороговым значением здесь является постоянное хранилище, поскольку решения для постоянного хранения крупномасштабных данных, как правило, очень сложны, а производительность одноточечной базы данных имеет узкие места, но если используется такое решение, как распределенная база данных, это значительно увеличит сложность развертывания. . Если пользователь хочет установить автоматический зонд, установка службы отслеживания займет некоторое время и, наконец, потребуется развернуть распределенную базу данных? Ясно, что компромисс здесь труден. Но к счастью наконец нашелся более совершенное решение, ** то есть — LevelDB. Это база данных kv, реализованная Google, которая может поддерживать масштаб данных на уровне миллиардов и характеризуется чрезвычайно высокой пропускной способностью записи. ** Написано Джеафом Дином и Санджаем Гемаватом, легендарными инженерами Google.

Открытие LevelDB меня очень взволновало, потому что она почти родилась для распределенных систем слежения, и все спецэффекты очень подходили для требований постоянства систем слежения. ** В качестве встроенной базы данных ее можно запустить вместе со службой без дополнительного развертывания, а скорость записи чрезвычайно высока. **После сравнительного анализа LevelDB я сразу же принял его в качестве решения для хранения данных для NodeTracing, потому что его производительность настолько привлекательна.

контрольная работа

После того, как первая версия была завершена, были проведены некоторые эталонные тесты пропускной способности NodeTracing:

Один узел, двухъядерный сервис отслеживания памяти i5 + 4G, может обрабатывать 10 000 интервалов в секунду (на самом деле тест больше ограничен скоростью сети).
После параллельного расширения до 10 узлов система работает стабильно (тесты развертывания более крупных узлов будут проведены позже)
Емкость в среднем около 1 ГБ может сохраняться до4 миллиона пролетов(Исходя из контекста разных размеров и отличий от фактической работы, значение указано только для справки)

использованная литература

Dangdang 11.11: высокодоступный мобильный вход и поиск в новой архитектуре
Заметки об исследованиях распределенной системы отслеживания вызовов
Система отслеживания распределенных услуг JD-CallGraph
Полный мониторинг каналов (1): обзор и сравнение схем
Сравнение архитектуры системы отслеживания распределенных каналов крупных заводов
skywalking
opentracing-javascript

постскриптум

Спасибо за прочтение, если эта статья может вам помочь, надеюсь, вы сможете зажечь звезду за NodeTracing на github :) На момент завершения этой статьи NodeTracing только что прошел тест OpenTracing.registryЗарегистрируйтесь, можете перейти в поиск для просмотра Объем этой статьи ограничен, и нет возможности подробно описать все детали конфигурации и реализации NodeTracing.Заинтересованные читатели могут перейти на github, чтобы прочитать подробности, и добро пожаловать, чтобы задать вопросы и мнения

Автор: Чейни Сюй
Электронная почта: 457299596@qq.com
Гитхаб:NodeTracing
Докер Хаб:NodeTracing-Image