задний план

Каждая система имеет свои основные индикаторы. Например, в сфере эквайринга: первое важное для системы поступления деталей — обеспечение точности поступающих деталей, а второе — обеспечение оперативности размещения заказов. Первое важное в клиринговой и расчетной системе – обеспечение точной оплаты, а вторая важная вещь – обеспечение своевременной оплаты. Система, за которую мы отвечаем, является основным звеном смарт-платежей Meituan Dianping, который отвечает за 100% трафика смарт-платежей, который по внутренним привычкам называется основной транзакцией. Поскольку это включает в себя поток средств между всеми продавцами офлайн-транзакций и пользователями Meituan Dianping, для основных транзакций: первая важная вещь — это стабильность, а вторая важная вещь — стабильность.

поднятая проблема

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

Идеал очень полный, но реальность заключается в том, что поскольку ежедневные заказы сотен тысяч в начале 2017 года к концу года однодневные заказы превысили 7 миллионов, а система сталкивается с огромными проблемами. Оплата каналов увеличивается; Ссылки удлиняются; и сложность системы увеличивается соответственно. Из оригинальной POS-машины до более поздних продуктов QR-кода, маленьких белых ящиков, маленьких черных ящиков и мгновенного платежа ... Диверсификация продуктов и позиционирования системы также меняется все время. И система отвечает на изменения, как черепаха в гонке с зайцем.

Из-за быстрого роста бизнеса, даже если в системе нет обновлений версий, могут внезапно произойти некоторые аварии. Частота аварий становится все выше и выше, а модернизация самой системы зачастую затруднена. Модернизация инфраструктуры, вышестоящая и нижестоящая, часто имеет «эффект бабочки» и затрагивается без предупреждения.

анализ проблемы

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

Показатели доступности

Отраслевой стандарт высокой доступности измеряется временем простоя системы:

Поскольку отраслевой стандарт является апостериорным показателем, принимая во внимание руководящую значимость для повседневной работы, мы обычно используем платформу управления услугами OCTO для подсчета доступности. Метод расчета:

Разбивка доступности

Есть еще два наиболее часто используемых в отрасли ключевых показателя надежности системы:

Среднее время наработки на отказ (MTBF): среднее время нормальной работы системы до возникновения сбоя.
Среднее время ремонта (MTTR): среднее время ремонта, когда система переходит из состояния неисправности в рабочее состояние.

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

проблема решена

1. Если частота встречаемости ниже, другие умрут, а мы не умрем

1.1 устраняет зависимость, зависимость и ослабляет контрольную зависимость

Возьмем сценарий с использованием правила STAR:

ситуация

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

задача

Проанализируйте явные и неявные требования к системе А: 1> Необходимо получить параметры, переданные от восходящего потока, параметры включают бизнес-информацию, информацию о пользователе, информацию об оборудовании, информацию о скидках. 2> Создайте номер заказа и сохраните информацию о заказе транзакции. 3> Конфиденциальная информация должна быть зашифрована. 4> Вызвать интерфейс нижестоящего банка. 5> для поддержки возврата. 6>Синхронизировать информацию о заказе с пунктами списания и другими отделами. 7> Чтобы дать продавцам интерфейс для просмотра заказов. 8> Чтобы иметь возможность рассчитаться с продавцом. Исходя из вышеперечисленных требований, давайте разберем, как сделать стабильной самую основную ссылку «оплата через POS-терминал».

действие

Анализ: Требования с 1 по 4 - это необходимые ссылки для оплаты, которые можно сделать в подсистеме, назовем ее платежной подсистемой. От 5 до 8 являются независимыми, и каждый может быть выполнен как подсистема Конкретная ситуация связана с количеством разработчиков и затратами на обслуживание. Стоит отметить, что зависимости между требованиями 5-8 и подсистемой сбора не имеют функциональных зависимостей, только зависимости данных. То есть все они зависят от сгенерированных данных заказа. Подсистема сбора является ядром всей системы и требует очень высокой стабильности. Другие подсистемы имеют проблемы, и подсистема сбора не может быть затронута. Основываясь на приведенном выше анализе, нам необходимо отделить подсистему сбора данных от других подсистем и унифицировать управление данными в других системах. Это называется «подсистемой переадресации подписки», если эта система не влияет на стабильность подсистемы сбора. Грубая схема архитектуры выглядит следующим образом:

результат

Как видно из рисунка выше, прямой зависимости между подсистемой инкассации и подсистемой возврата, подсистемой расчетов, подсистемой синхронизации информации и подсистемой просмотра заказов нет. Эта архитектура достигает эффекта устранения зависимостей. Подсистема сбора не должна полагаться на подсистему подписки и пересылки данных, а подсистема подписки и пересылки данных должна полагаться на данные подсистемы сбора. Мы контролируем зависимости, а подсистема подписки и пересылки данных извлекает данные из подсистемы сбора без необходимости, чтобы подсистема сбора передавала данные в подсистему подписки и пересылки данных. Таким образом, подсистема подписки и пересылки данных зависает, а подсистема оплаты не затрагивается. Давайте поговорим о том, как подсистема подписки на данные и пересылки извлекает данные. Например, данные хранятся в базе данных MySQL, а данные извлекаются путем синхронизации Binlog. Если очередь сообщений используется для передачи данных, существует зависимость от промежуточного программного обеспечения очереди сообщений. Если мы проектируем решение для аварийного восстановления: если очередь сообщений зависает, для передачи данных выполняются прямые вызовы RPC. Для этой очереди сообщений достигается эффект ослабления зависимостей.

1.2 Транзакция не содержит внешних вызовов

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

Решение:

Проверьте код каждой системы, чтобы проверить, есть ли в транзакции трудоемкие операции, такие как вызовы RPC, HTTP-вызовы, операции с очередями сообщений, кэширование и циклические запросы.Эта операция должна быть перемещена за пределы транзакции.В идеале только база данных обрабатывается внутри транзакции.
Добавляйте сигналы мониторинга к крупным транзакциям. Когда происходят крупные события, вы будете получать напоминания по электронной почте и текстовыми сообщениями. Для транзакций базы данных он обычно делится на три уровня оповещений о транзакциях: 1 с или более, 500 мс или более и 100 мс или более.
Рекомендуется не настраивать транзакции в XML, а использовать аннотации. Причина в том, что транзакция конфигурации XML, первая не очень удобочитаема, второй аспект обычно настроен слишком сильно, что легко может привести к тому, что транзакция будет слишком большой, а третий сложно обрабатывать правила вложенности.

1.3 Установите разумные тайм-ауты и повторные попытки

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

Служба A использует данные обеих служб для выполнения этой операции. Обычно проблем не возникает.Если время отклика службы B увеличивается или даже останавливает службу без вашего ведома, а время ожидания вашего клиента установлено слишком большим, время ответа для вас для выполнения этого запроса станет больше.Если авария происходит, последствия будут серьезными.

Контейнер сервлетов Java, будь то Tomcat или Jetty, представляет собой многопоточную модель и использует рабочие потоки для обработки запросов. Это можно настроить с помощью верхнего предела.Когда ваши запросы будут заполнены максимальным количеством рабочих потоков, оставшиеся запросы будут помещены в очередь ожидания. У очереди ожидания также есть верхний предел: как только очередь ожидания заполнена, веб-сервер откажет в обслуживании, и соответствующий возврат Nginx будет 502. Если ваша служба является службой с более высоким QPS, в основном в этом сценарии ваша служба также будет перетаскиваться вниз. Если ваш восходящий поток не имеет разумного тайм-аута, сбой будет продолжать распространяться вверх. Этот пошаговый процесс усиления ошибок и есть эффект сервисной лавины.

Решение:

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

1.4 Решайте медленные запросы

Медленные запросы снижают скорость отклика и производительность приложения. В случае увеличения объема бизнеса резко возрастает загрузка ЦП сервера, на котором расположена база данных, в тяжелых случаях база данных не будет отвечать и может быть решена только путем перезапуска. Для медленного запроса вы можете обратиться к нашей предыдущей статье «Технический блог».Принцип индекса MySQL и медленная оптимизация запросов".

Решение:

Запрос в режиме реального времени, запрос в режиме реального времени и автономные запросы. Запросы в режиме реального времени проникают в базу данных, другие базы данных не ходят, могут использоваться для реализации запроса Elasticsearch center, обработки запросов в режиме реального времени и автономных запросов.
Чтение и запись разделения. Запишите основную библиотеку, прочитайте из подчиненной библиотеки.
Оптимизация индекса. Слишком большое количество индексов может повлиять на производительность записи в базу данных. Если индекса недостаточно, запрос будет медленным. DBA рекомендует, чтобы количество индексов для таблицы данных не превышало 4.
Большие столы не допускаются. Когда объем данных таблицы базы данных MySQL достигает десятков миллионов, эффективность начинает резко падать.

1.5 Фьюзинг

Когда зависимая услуга недоступна, вызывающая служба должна предоставить вредную услугу вверх с помощью некоторых технических средств, чтобы обеспечить гибкость бизнеса. Тем не менее, система не сломана.Если в нисходящем канале вызова службы происходит сбой нисходящей службы из-за проблем с логикой кода, проблем с сетью, тайм-аутов вызовов, всплеска вызовов по продвижению бизнеса, недостаточной пропускной способности службы и т. д., это может привести к доступу уровень не работает Другие сервисы недоступны. На следующем рисунке показан анализ диаграммы «рыбий скелет» без эффекта плавления:

Решение:

Автоматический выключатель: вы можете использовать Hystrix от Netflix или собственный Rhino от Meituan-Dianping, чтобы быстро выйти из строя.
Ручной прерыватель цепи: Убедившись, что нисходящий платежный канал нестабилен или недоступен, вы можете вручную закрыть канал.

2. Если частота встречаемости ниже, не убивайте себя

Если ты не убиваешь себя, ты должен сделать две вещи: во-первых, ты не делаешь этого сам, а во-вторых, ты не умрешь.

2.1 Не делать

Что касается непроизводства, я резюмировал следующие 7 пунктов: 1> Неправильная морская свинка: используйте только зрелые технологии и не влияйте на стабильность системы из-за проблем с самой технологией. 2> Единство обязанностей: оно не ослабляет и не препятствует выполнению наиболее важных обязанностей из-за объединения обязанностей. 3> Стандартизация процесса: уменьшить влияние человеческого фактора. 4> Автоматизация процессов: сделайте систему более эффективной и безопасной. 5> Емкость избыточна: чтобы справиться с ситуацией, когда конкурирующая система недоступна, и пользователи обращаются к нашей системе, и грядет большая акция, а также по причинам аварийного восстановления, необходимо как минимум 2-кратное резервирование системы. быть гарантировано. 6> Непрерывный рефакторинг. Непрерывный рефакторинг — это эффективный способ гарантировать, что код останется нетронутым в течение длительного времени, а проблемы возникнут, как только он будет перемещен. 7> Своевременное устранение уязвимостей: Meituan Dianping имеет механизм эксплуатации и обслуживания уязвимостей безопасности, напоминая и побуждая различные отделы устранять уязвимости безопасности.

2.2 Бессмертие

Что касается смерти не мертвых, у земли есть пять основных неудачных зверей: может остановить метаболизм «водяного червя» в суровых условиях; может вернуться к старому «маяку»; «»» в твердой оболочке восстанавливается; вода, сухопутный, паразитический «Зов»; «Рарп» со скрытой способностью. Их общая черта заключается в том, что они используются в области проектирования систем. Понятие «отказоустойчивость» здесь заключается в том, что система имеет возможность допустить ошибку, то есть в случае возникновения ошибки она все еще имеет возможность продолжить назначенный процесс. Ошибка - это отказоустойчивость, которая является именно ошибкой, не допускающей ошибки (ошибки).

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

3.1 Ограничение тока

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

Решение:

С помощью стресс-тестирования производительности службы сервера можно проанализировать относительно разумное максимальное число запросов в секунду.
Три наиболее часто используемых алгоритма управления потоком — это бакеты с маркерами, бакеты с дырками и счетчики. Этого можно достичь с помощью RateLimiter в Guava. Среди них SmoothBurstry основан на алгоритме ведра маркеров, а SmoothWarmingUp основан на алгоритме дырявого ведра.
Для основной транзакции платформа управления службы Meituan Octo используется для одобрения. Он может поддерживать квоту гранулярности интерфейса, поддерживать одну квоту машины / кластерную квоту, поддерживать указанную квоту потребителей, поддержать режим тестирования и своевременного уведомления о тревоге. Где тестовый режим только тревожит, а не на самом деле дросселирование. Когда режим теста выключен, система бросает исключения, когда превышен пороговой предел тока. Стратегия дросселирования может быть выключена в любое время.
Вы можете использовать Hystrix от Netflix или собственный Rhino от Meituan-Dianping для специального целевого ограничения тока.

4. Изоляция с малым радиусом неисправности

Изоляция относится к разделению систем или ресурсов для ограничения масштабов распространения и влияния в случае сбоя системы.

Принцип физической изоляции сервера

① Различия между внутренними и внешними системами: внутренние системы и внешне открытые платформы рассматриваются отдельно. ② Внутренняя изоляция: от восходящего к нисходящему потоку он изолирован от физических серверов по каналам, а службы с низким трафиком объединяются. ③ Внешняя изоляция: изоляция по каналам, и каналы не влияют друг на друга.

Изоляция ресурсов пула

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

Изоляция ресурсов семафора

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

5. Более быстрое восстановление после сбоя, чем быстрое обнаружение

Обнаружение делится на предварительное обнаружение, обнаружение в событии и обнаружение после события. Основными средствами предварительного обнаружения являются стресс-тестирование и отработка неисправностей; основными средствами обнаружения в ходе события являются мониторинг и оповещение; основным средством обнаружения после события является анализ данных.

5.1 Стресс-тест всей ссылки в режиме онлайн

Подходит ли ваша система для полносвязного онлайн-нагрузочного тестирования?Вообще говоря, полносвязное стресс-тестирование подходит для следующих сценариев:

① Для систем с длинными ссылками, множеством ссылок и сложными зависимостями служб онлайн-нагрузочное тестирование всей ссылки может быстрее и точнее выявить проблемы. ② Существует полный мониторинг и сигнализация, и операция может быть прекращена в любое время, если есть проблема. ③ Существуют очевидные взлеты и падения в бизнесе. Даже если есть проблема в период корыта, влияние на пользователя относительно невелико.

Основные цели онлайн стресс-тестирования на всей ссылке следующие:

① Понимание вычислительной мощности всей системы ② Устранение узких мест производительности ③ Убедитесь, что такие механизмы, как ограничение тока, переход на более раннюю версию, предохранитель и аварийный сигнал, соответствуют ожиданиям, и проанализируйте данные, чтобы в свою очередь скорректировать эти пороговые значения и другую информацию. ④ Соответствует ли выпущенная версия ожиданиям в часы пик ⑤ Убедитесь, что зависимости системы соответствуют ожиданиям.

Простая реализация полносвязного измерения давления:

① Собирать данные онлайн-журнала для воспроизведения трафика.Чтобы изолировать трафик от реальных данных, необходимо выполнить обработку смещения в некоторых полях. ② обработка данных окраски. Промежуточное ПО можно использовать для получения и передачи меток трафика. ③ Вы можете использовать таблицу теневых данных для изоляции трафика, но вам нужно обратить внимание на дисковое пространство.Рекомендуется использовать другие методы для изоляции трафика, если оставшееся место на диске составляет менее 70%. ④ Для внешних вызовов может потребоваться Mock. С точки зрения реализации, фиктивная услуга может быть сгенерирована случайным образом, и может использоваться распределение времени задержки для времени возврата внешнего онлайн-вызова. В инструменте стресс-тестирования основная транзакционная сторона использует pTest, разработанный Meituan Dianping.

6. Быстрое место для устранения неисправности

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

7. Быстрое решение для восстановления после сбоя

Чтобы решить, заранее найти и определить местонахождение. Скорость разрешения также зависит от того, является ли оно автоматизированным, полуавтоматическим или ручным. Core Transaction намеревается построить высокодоступную систему. Наш лозунг: «Не изобретайте колесо, используйте его с пользой». Это интегрированная платформа, и ответственность заключается в следующем: «Сосредоточьтесь на основных транзакциях, высокой доступности, лучше, быстрее и эффективнее».

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

Введение инструмента

Hystrix

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

Изоляция ресурсов пула потоков

преимущество

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

недостаток

Основным недостатком пула потоков является то, что он увеличивает нагрузку на ЦП, поскольку выполнение каждой команды включает в себя организацию очереди (используя SynchronousQueue по умолчанию, чтобы избежать очереди), планирование и переключение контекста.
Добавление сложности к коду, который зависит от состояния потока, например, использование ThreadLocal, требует ручной передачи и очистки состояния потока (накладные расходы на изоляцию потока считаются внутри Netflix достаточно небольшими, чтобы не вызывать значительных затрат или влияния на производительность).

Изоляция ресурсов семафора

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

преимущество

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

недостаток

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

Сравните изоляцию ресурсов пула потоков и изоляцию ресурсов семафора

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

Rhino

Rhino — это компонент обеспечения стабильности, разработанный и поддерживаемый командой инфраструктуры Meituan-Dianping.Он обеспечивает такие функции, как имитация неисправностей, отработка понижения, сервисные предохранители и ограничение тока обслуживания. По сравнению с Хайстрикс:

Внутренне через CAT (система мониторинга с открытым исходным кодом Meituan Dianping, см. предыдущий блог "Углубленный анализ распределенного мониторинга CAT с открытым исходным кодом») выполнил ряд заглубленных точек, что удобно для обслуживания аварийной сигнализации.
Получите доступ к центру конфигурации, который может обеспечить динамическое изменение параметров, таких как принудительное объединение, частота отказов модификации и т. д.

Заключать мысли

Ван Говэй рассказал о своем академическом опыте в «Человеке Цихуа»: «В древние времена и в наше время те, кто добивается больших успехов и больших исследований, должны пройти через три сферы:

первое царство

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

второе царство

Постепенно расширяя пояс и ни разу не пожалев об этом, И Сяо осушил людей.

третье царство

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

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

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

Об авторе

Сяоцзин окончил компьютерный факультет Северо-восточного университета в возрасте 20 лет. В первой компании после выпуска, благодаря своему выдающемуся языковому таланту, он начал изучать японский язык с нуля за один год и сдал международный экзамен по японскому языку 1 уровня на супервысокие оценки, а также два года работал переводчиком с японского языка. После этого он работал на Renren и перешел в интернет-разработку. Аспирант по психологии Китайской академии наук. Есть около 100 патентов на технические изобретения и партнер начинающей компании. У него есть опыт технической поддержки в Токио, Японии и Силиконовой долине в США. В настоящее время он является техническим экспертом Meituan Dianping, отвечающим за основные транзакции. (Приглашаем обратить внимание на личный технический публичный аккаунт Джингера: программирование на всю жизнь)

Карьера

Финансовые операции группы США набирают стажеров основные требования: 19 лет выпускников, направление Java, техническое стремление. Быстрое развитие бизнеса требует высокоскоростной команды разработчиков, как основного сектора, мы считаем, что технологии изменили мир и срочно нуждаются в вас! Заинтересованные стороны, пожалуйста, обратите внимание на мой личный номер и технические публичные комментарии.

Если вы заинтересованы в нашей команде, вы можете следить за нашимистолбец.