Об авторе:

Ши Сонгран, старший инженер-разработчик Didi, отвечает за обслуживание и развитие среднего и тайваньского бизнеса. Основное содержание этой статьи — практический опыт построения основной бизнес-платформы Didi на базе Go.

Схема содержания:

1. Разработка приложений и масштабирование Golang в бизнесе Didi

2. Опыт Didi в использовании модуля управления Go

3. Расскажите о двух конкретных проблемах приложения Go

4. Порекомендуйте два инструмента с открытым исходным кодом

текст

1.Go Приложение и разработка внутри Didi

В репозитории кода Didi содержится более 1500 модулей, содержащих фрагменты кода Golang, и более 1800 Gophers отправили написанный на Golang код в Didi.Только в нашем промежуточном сервисе более 2000 машин работают с сервисом Go.

1.1 Что мы делаем с Go

DUSE — это механизм распределения заказов Didi, отвечающий за согласование между водителями и пассажирами Didi и отвечающий за согласование 10 000 уровней каждую секунду.

DOS — это система заказов Didi, которая отвечает за циркуляцию статуса заказов в режиме реального времени и поиск исторических заказов Didi.Это служба поиска десятков миллиардов данных.

DISE — это наша собственная разработка службы хранения данных без схемы, использующая реализацию, подобную Bigtable.

Служба DESE представляет собой бессерверную распределенную структуру.Ей нужно только выполнить бизнес-функцию, чтобы завершить построение распределенного бизнеса, аналогично бизнесу Amazon Lambda.

1.2 Средний офисный бизнес

Быть

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

1.3 Проблемы

При разработке услуг мидл-офиса возникают некоторые проблемы, в основном связанные с тремя аспектами:

1. Высокая доступность: Служба промежуточного офиса поддерживает все внешние службы. В случае возникновения проблемы внешняя служба будет зависать вместе. Высокая доступность очень важна.

2. Высокий уровень параллелизма. Служба промежуточного офиса является носителем всего трафика и требует очень высокой пропускной способности и высокой скорости отклика.

3. Сложность бизнеса. Услуга мидл-офиса также является бизнес-услугой, поэтому сложность бизнеса напрямую определяет сложность системы мидл-офиса.

1.4 Why Golang

Во-первых, эффективность исполнения очень высока.

Во-вторых, отличная эффективность разработки.Синтаксис Golang относительно лаконичен и ясен, что может скрыть многие технические детали и сделать развитие бизнеса более плавным.

В-третьих, это активное сообщество Golang и богатые библиотеки, которые помогают нам решать многие проблемы.

В-четвертых, это низкая стоимость обучения. Когда мы впервые начали использовать Go, мы обнаружили, что набирать инженеров очень сложно. Инженеры, говорящие на других языках, могли узнать о Go, ознакомиться с Go и разрабатывать программы на Go за счет быстро учится.

2.Опыт Didi в управлении модулями Go

2.1 Огромная бизнес-система

Бизнес Didi особенный.Каждый запрос включает в себя информацию о статусе водителей, пассажиров и заказов.У нас есть множество микросервисов для обеспечения статуса сервиса. Я сделал простую статистику, если взять экспресс-заказ и посмотреть, там задействовано более 50 подсервисов, 300 Rpc-запросов и более 1000 строк лога, анализировать вручную очень сложно.

2.2 Проблемы управления услугами

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

Аномальное местоположение

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

нормализация журнала

Быть

поток журналов

Быть

Мы ссылаемся на набор логики OpenTracing, через SpanID и TraceID. Все TraceID и SpanID хранятся в журнале, все запросы объединяются через TraceID, а потребление времени каждым узлом записывается через SpanID. В то же время структура журнала стандартизирована в виде набора спецификаций журнала, удобных для людей и поддающихся анализу для машин, и выражает то, что этот журнал записывает через DLTAG. Недостаточно просто стандартизировать журналы, просто объединить журналы проще, и это все еще очень сложно, если вы полагаетесь на ручной анализ. На этот раз мы создали единую систему обработки для сбора, расчета, хранения, индексации и, наконец, визуализации данных журнала унифицированным образом. Как эта система это делает? Наши журналы обычно поступают со стороны сервера и со стороны приложения.Мы собираем эти журналы через службу сбора журналов SWAN и отправляем их в очередь сообщений; служба SRIUS считывает информацию журнала из очереди сообщений и превращает журналы в наши структурированные данные. , а затем сохранить структурированные данные в системе ARIUS. Нижний уровень системы ARIUS фактически является поиском ES. Благодаря построению индекса журнала он может помочь нам быстро получить журнал. Наконец, есть пульс, который фактически представляет собой приложение, построенное на системе ARIUS.Посредством запроса ARIUS Didi завершает восстановление связи бизнеса, анализ услуг и отслеживание производительности.

Быть

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

Быть

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

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

Быть

После того, как мы идентифицируем трафик, каждый бизнес-модуль, через который проходит трафик, требует дополнительной разработки. Когда служебный модуль идентифицирует трафик измерения давления, служебный модуль должен прозрачно передать метку трафика, чтобы гарантировать, что все служебные модули могут воспринимать метку измерения давления. Наш модуль Cache создаст короткий тайм-аут для этого трафика, чтобы гарантировать, что ресурсы кэша могут быть освобождены как можно скорее после завершения стресс-теста. Наконец, в области базы данных мы создадим набор структур данных, которые точно такие же, как в Интернете, набор таблиц, которые мы называем теневыми таблицами.Теневые таблицы отвечают только за обработку трафика измерения давления. Мы называем набор логики маркировки трафика и модификацию каждого модуля каналом измерения стресса. DiDi очень часто проводит стресс-тестирование.В дополнение к стресс-тестированию новых аппаратных, он также периодически проводит стресс-тестирование сервисов, чтобы убедиться, что система может соответствовать ожиданиям проектирования пропускной способности системы при быстро меняющихся сервисах. Диапазон измерения давления включает в себя все наши основные технологические модули, чтобы обеспечить относительную стабильность наших услуг.

Решена проблема онлайн стресс теста, как отправить тест? Как я только что упомянул, предприятиям сложно проводить стресс-тесты посредством воспроизведения трафика.

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

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

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

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

Во-первых, это проблема с производительностью. Мы хотим, чтобы он перешел на более производительную платформу.

Второе — точность интерфейса. Мы надеемся, что интерфейс имеет точную характеристику, а некоторые динамические языки вызывают неопределенность некоторых интерфейсов, что является просто недостаточной надежностью.

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

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

2.3 На что надеяться

  Как Didi переносит свой бизнес 

Когда дело доходит до миграции, мы хотим иметь возможность сделать три вещи.

Во-первых, бизнес незаметен. Мы надеемся, что при миграции мидл-офисного сервиса у фронтенд-бизнеса нет восприятия, и он понятия не имеет, что мы мигрировали, или что он просто помогает нам наблюдать за сервисом, а микровосприятия достаточно.

Во-вторых, миграция сервиса стабильна, не зависает во время миграции.

В-третьих, нет никакой разницы в функциях старого и нового модулей после миграции.

Опыт миграции

Быть

В этой части в качестве примера используется типичный MVC-фреймворк PHP. Это типичный серверный сервис. В идеале он должен переводить PHP-код напрямую с помощью Go. В итоге API и функции полностью согласованы. Все довольны. На самом деле, когда мы это сделали, мы обнаружили, что это не так просто. Когда мы разрабатываем, все будут использовать какие-то динамические особенности языка, например, может не быть различия между строковыми и числовыми типами, или ассоциативные массивы PHP и обычные массивы смешиваются для работы. В настоящее время жесткий перевод требует, чтобы код Golang делал множество адаптеров для адаптации к языковым различиям, что серьезно загрязняет бизнес-код Golang.

Быть

Следовательно, в дополнение к переводу кода Go требуется дополнительный уровень Proxy или SDK. Мы надеемся, что сервер Go может сосредоточиться на своем бизнесе и бизнес-логике, а не на деталях интерфейса.Если интерфейс несовместим или если тип интерфейса несовместим по каким-то особым причинам, через уровень прокси у нас есть интерфейс Golang и Интерфейс прокси, Различия скрыты, чтобы гарантировать, что наш сервер Go относительно чист, и мы можем сосредоточиться только на своем собственном бизнесе. В то же время уровень Proxy также может помочь нам перенаправить трафик. Например, при сокращении трафика мы используем Proxy для сокращения трафика. Через интервал Proxy мы можем гарантировать, что Клиент не знает о миграции нашего сервера Go. в то же время, этот прокси также может обрабатывать офлайн-трафик. сервер для тестирования. Допустим, мы наконец-то закончили разработку кода Go и прошли тест.Все чувствуют, что проблемы нет, и мы готовы выйти в онлайн.В это время также самый опасный момент всего процесса - пора перерезать поток.

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

Быть

Первым шагом является развертывание сервера Go и направление 100% обходного трафика на сервер Go через прокси-сервер, что на самом деле является стресс-тестом для сервера Go. Возвращаемое значение клиента основано на возвращаемом значении PHP, что означает, что прокси-сервер асинхронно настраивает сервер Go, но не передает данные во внешний интерфейс. В это время мы проведем Diff в прокси, чтобы убедиться, что их данные непротиворечивы, а в нижней части Go Server и Proxy мы перейдем к Diff их базовому хранилищу, чтобы увидеть, непротиворечива ли бизнес-логика, и есть ли Проблема, иди ремонтируй. Когда весь процесс продлится какое-то время, а количество diff достигнет определенного контролируемого уровня, переходим к следующему шагу - малый поток отсечки потока.

Быть

Мы постепенно передаем возвращаемое значение Go Server Клиенту через Proxy, это относительно медленный процесс, 1%, 2%, 10%, 20%, и продолжительность обрезки потока может быть относительно большой. В это время мы просим бизнес-сторону клиента наблюдать, нет ли каких-либо отклонений.В это время прокси-уровень все еще продолжает сравнивать возвращаемое значение, а нижний уровень также проверяет согласованность хранилища. Если процесс очень гладкий, проблем нет и логика последовательна, он перейдет к следующему шагу.

Быть

Как и на первой картинке, PHP Server стал обходным трафиком, Go Server — основным трафиком, а Client — полностью логикой Go Server. Мы будем продолжать наблюдать онлайн в течение периода времени, который может измеряться месяцами. Этот метод используется для проверки возможности Go Server. Если нет проблем с наблюдением, мы загрузим PHP-сервер справа Когда дует ветер, мы срезаем его.

Быть

После разговора о сокращении потока я только что рассказал о пульсе, измерении давления и переносе трафика.Каждая служба мидл-офиса может иметь доступ к этим компонентам управления услугами, доступ к измерению давления, измерению пульса и обнаружению услуг и другим службам. Балансировка нагрузки и другие модули, если мидл-офисные службы подключаются поэтапно, то дополнительная нагрузка на разработку очень велика. В то же время доступ к каждому компоненту управления службами затруднен, что приводит к длительному циклу разработки, трате большого количества рабочей силы и затруднениям в продвижении. В это время студенты факультета управления услугами предложили идею DIRPC, которая фактически представляет собой набор стандартизированных компонентов SDK. Взаимодействия восходящего и нисходящего потоков разделены в виде стандартного SDK, обеспечивая унифицированное универсальное обнаружение служб, отказоустойчивое планирование, мониторинг и сбор и т. д., тем самым снижая затраты на разработку, эксплуатацию и обслуживание служб.

3. Что обсуждается?

О чем мы говорим, когда обсуждаем RPC и SDK? Студенты, изучающие управление службами, надеются предоставить унифицированное универсальное решение для управления доступом к службам. С помощью универсальной сервисной платформы можно реализовать единый пакет SDK и управление службами. расходы на разработку услуг и затраты на эксплуатацию и техническое обслуживание, а также обеспечение стабильности услуг. В дополнение к отказоустойчивости на стороне C, обнаружению сервисов, встраиванию запросов и спецификациям сервисов, DIRPC также реализует логику только что введенного канала измерения давления и обнаружения импульсов.

Как ты сделал это? Мы инкапсулируем базовую библиотеку в базовые базовые компоненты, которая содержит базовые компоненты, такие как статус службы и балансировка нагрузки, а затем разрабатываем собственный клиент на верхнем уровне. Служба промежуточного офиса использует эти клиенты для разработки бизнес-пакетов SDK и в то же время должна соответствовать определенным спецификациям, чтобы можно было разработать пакет SDK. Это наш идеал, но есть много сложностей в развитии

Во-первых, они не могут полностью соответствовать определенным спецификациям, потому что компонентов много и это занимает очень много времени.

Во-вторых, если некоторые модули уже имеют SDK, а затем мигрируют на новый SDK, стоимость миграции будет слишком высокой, и возникнут риски для стабильности. В это время на DiRPC только что был сделан еще один набор вещей, названный DiRPCGen. Это набор инструментов CodeGen.Расширяя IDL бережливости, пока бизнесу необходимо написать набор IDL, компоненты SDK можно генерировать напрямую через этот набор инструментов Dirpc, что очень удобно. В то же время все спецификации могут быть напрямую реализованы в DiRPCGen. Это относительно большой проект.В настоящее время этот IDL совместим с синтаксисом Thrift, и в IDL Thrift были внесены некоторые расширения для поддержки нашего http-протокола и других вещей. Таким образом, когда мы мигрируем каждую из наших служб мидл-офиса, стоимость очень низкая, а получаемые преимущества очень велики, каждый модуль готов к миграции, и продвижение проходит относительно гладко.

4.Теперь поговорим о двух небольших проблемах с двумя Golang.

4.1 Первая проблема — интерфейс net.Conn Golang, проблема двойного закрытия

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

Быть

Мы внедрили глобальный счетчик службы, +1, когда ссылка установлена, и -1, когда ссылка закрыта. Когда сервис выйдет, проверьте, обнулено ли это.Если обнулено, то он выйдет, иначе будет ждать обнуления.Видно, что нижний слой на самом деле является WaitGroup. Операция ссылки размещается в базовом пакете net.http, и у нас нет прямых операций в нашем собственном net.Conn.

Быть

В результате, когда мы поставили эту логику на линию, сервисная паника упала, потому что счетчик стал отрицательным. Идея состоит в том, что ссылку можно открыть только один раз и закрыть только один раз, поэтому не должно быть отрицательных чисел. Разве в пакете net.http есть несколько операций закрытия ссылки? В результате было обнаружено, что это действительно так. Мы обнаружили, что базовый net.http Golang может закрывать ссылку несколько раз при обработке ссылки. Я перечислил два здесь. Это ошибка?

Быть

Хотите подать заявку? На самом деле это не ошибка.Если вы обратите внимание на комментарии к интерфейсу net.Conn, вы обнаружите, что «несколько сопрограмм могут одновременно вызывать функции в интерфейсе net.Conn в одно и то же время», что означает, что при реализации операции ссылки Вы должны убедиться, что первое — это предотвращение параллелизма, а второе — предотвращение повторного входа, и мы не можем думать, что нижний слой Golang будет открыт и закрыт только один раз.Все должны обратить на это внимание.

4.2 Вторая проблема GC

Ранее мы собирались запустить модельный сервис, этот модельный сервис имеет относительно большую размерность и различные параметры. После того, как сервис подключен к сети, в автономном тестировании нет проблем, и он очень стабилен. Сервис закинул в сеть и обнаружил, что по мере увеличения трафика запросов на таймаут становится все больше, но среднее время не очень высокое. Если вы посмотрите на трудоемкий 99-й процентиль, сбой очень серьезный, и он достиг запроса второго уровня. БытьВо-первых, была проверена память процессора машины, и изменение было небольшим, и не было больших колебаний.Кроме того, была проверена сеть. БытьПосле исключения объективных факторов машины мы сомневаемся, есть ли проблема с написанием кода.

Мы проанализировали наш код инструментами Golang и вскоре обнаружили, что много ресурсов ЦП занимает функция сканирования алгоритма трехцветной маркировки golang GC, при этом количество in_used объектов в сервисе также достигало целых 1000 Вт. Хотя время STW текущего GC относительно короткое, трехцветный алгоритм маркируется одновременно, и для обхода этих объектов может использоваться большое количество ресурсов ЦП, что приводит к высокому уровню потребления наших ресурсов ЦП, что косвенно влияет пропускная способность и качество услуг.  Зная причину, идея оптимизации очень ясна.Мы пытаемся уменьшить выделение некоторых ненужных типов объектов.Так что же такое тип объекта в Golang? В дополнение к более привычным указателям, String, map, slice — все это типы объектов. Превратив строку в массив фиксированной длины, чтобы избежать обхода трехцветного алгоритма и некоторых ненужных срезов, все они становятся массивами и т. д., можно уменьшить выделение типов объектов. Хотя некоторые ресурсы памяти тратятся впустую, это может помочь нам уменьшить потребление GC.Эффект после оптимизации очевиден, и потребление времени 99-го процентиля скоро будет уменьшено. Это решение является более общим.Если вы обнаружите, что среднее время, затрачиваемое на 99, относительно велико, а заусенцы серьезные, вы можете увидеть, существует ли такой фактор.

 5.  последний рывокрекомендоватьДва колеса с открытым исходным кодом для всех

5.1 Первое колесо — это вспомогательные средства работы с базой данных Didi с открытым исходным кодом——gendry

Он предоставляет три инструмента для управления связями с базами данных, создания операторов SQL и полного сопоставления отношений данных.

Первый компонент — это класс управления пулом соединений, который помогает вам управлять информацией о пуле соединений и выполнять некоторые основные операции.

Второй — это инструмент построения SQL, который может помочь вам выполнить операцию объединения SQL.

Последний сканер — это инструмент отображения структуры, который сопоставляет необработанные данные, которые вы находите, с объектами.

5.2 Второе колесоJsoniter

Это набор инструментов кодека Json. Несмотря на совместимость с собственной библиотекой кодеков golang json, эффективность повышается примерно в 6 раз. Я настоятельно рекомендую эту библиотеку.По сравнению с easyJson, преимущество в том, что ей не нужно генерировать дополнительный код обработки json.Ей нужно только заменить ссылку, что может отлично помочь вам достичь шестикратного преимущества.

Выше все содержание, спасибо!

【время вопросов】

Спрашивающий 1

   Просить:Говорят, что при обходе онлайнового PHP как не конфликтует другое состояние службы, база данных и хранилище? 

  Ши Сонгран:Базовое хранилище двух систем изолировано. Например, сегодня мы запускаем обход на день, и мы будем использовать скрипт для сравнения данных, хранящихся в нижней части двух систем.Если мы обнаружим различия в хранилище, это означает, что есть какие-то логические различия, которые приводят к несогласованным место хранения. Два сохраненных данных синхронизируются с помощью сценариев на регулярной или периодической основе.Вначале преобладает PHP, а позже преобладает Go.

   Просить:Вы начали говорить о полном объеме опрессовки.В начале вы сказали, что источник данных сложно построить.Как вы это сделали потом?

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

Спрашивающий 2

   Просить:При переходе с PHP Server на Go Server вы сказали, что вам нужно перенести онлайн-трафик, и вам нужно различать PHP Server и Go Server.Запросы и ответы пользователей в вашем бизнесе различаются в зависимости от реальной ситуации. этот сервер PHC возвращает то же самое, что и сервер Go?

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

  Вопрос:Я видел двух агентов, как заставить этих двух агентов имитировать реальную среду?

Ши Сонгран:Я общался со своими одноклассниками. Их нижний слой — это два механизма событий. В соответствии с периодом времени, когда смоделированный водитель выходит в сеть, разные функции запускаются разными возвращаемыми значениями системы. Когда заказ получен, соответствующая функция выбирается в соответствии с обработчиком событий для обработки, что реализуется путем имитации различных функциональных операций водителя и пассажира.

Спрашивающий 3

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

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

   Просить:Будет ли проблема с тайм-аутом? Какая несогласованность исключений вызвана этой разницей?

   Ши Сонгран:Да, проблема тайм-аута также может быть вызвана сетевой проблемой. Такая ситуация обязательно будет иметь место.Нам сложно добиться 100% согласованных результатов на интерфейсном уровне.Поэтому в процессе отсечки небольшого потока трафика необходимо вручную оценивать, связано ли это с тайм-аутом сетевого джиттера или с логическими проблемами. . Необходимо постоянно наблюдать за небольшим трафиком, чтобы определить, вызвана ли проблема сбоями в работе сети.

Спрашивающий 4

   Просить:Когда фоновая служба обновляется в большом масштабе, произошла ли кратковременная остановка службы или это плавный переход?

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

   Просить:Так что производительность пользовательской стороны может застрять на какое-то время, верно?

   Ши Сонгран:Большинство из них незаметны, потому что при повторной попытке, если у вас 100 машин, одна машина и одна машина в сети, вам трудно столкнуться с ситуацией, когда вы попадете один после двух повторных попыток, такая вероятность очень мала.

   Просить:Для выполнения одного заказа требуется 300 операций Rpc, что является относительно ресурсоемким процессом. Является ли этот процесс полностью асинхронным?

   Ши Сонгран:Нет, 300 Rpc на самом деле относятся ко всему процессу заказа, это не 300 Rpc, вызванные одним запросом Rpc. Например, это RPC для водителя, чтобы выйти из машины, а это RPC для счета пассажира.Все они могут включать более десятка или двадцати связанных запросов.Это не одноразовый RPC-запрос.

---

Gopher Meetup 2018 начнет первую остановку в Шэньчжэне.На этот раз многие новые лекторы приглашены поделиться опытом использования Go со всеми~

нажмитечитать оригиналзарегистрироваться