Ван Сяобо / Главный архитектор Tongcheng Travel

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

предисловие

В связи с непрерывным расширением системы компании и появлением все большего количества различных услуг программистам часто приходится беспокоиться о многих других вещах, помимо кода, таких как применение ресурсов, конфигурация среды, безопасность производительности и т. д., что приводит к низкой эффективности разработки. На конференции, посвященной 10-летию ECUG, Ван Сяобо, главный архитектор Tongcheng Travel, поделился опытом в процессе перехода Tongcheng Travel от традиционной архитектуры к микросервисной архитектуре, а затем от микросервисной архитектуры к бессерверной архитектуре. чистым и счастливым, сосредоточившись на коде.

---

Многие говорят, что индустрия OTA — это не интернет, на самом деле полностью интернетизировать туризм очень сложно. Если вы идете покупать блок питания и шапку, будь то на Taobao или JD.com, должна быть система, которая вам поможет. Но если вы покупаете отель или покупаете билет в том же путешествии, вас может обслуживать пять или шесть систем. Это потому, что данные, точки интереса и поведение пользователей совершенно разные. В результате кажется, что тысячи программистов в компании каждый день делают однообразные действия. Как изменить эту вещь? Сделайте программирование более счастливым и чистым.

Предыстория практики Tongcheng без сервера

Как далеко от SQL до службы?

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

В то же время многие продакт-менеджеры полны идей. Может быть, меня кто-то сбил утром в автобусе, я придумал идею, а потом пошел в компанию, чтобы программисты это поняли, и днем ​​она будет запущена. Программист сказал, что сегодня днем ​​не может быть онлайн, и давал разные объяснения, говоря, что ему нужно подать заявку на сервер или разные другие ресурсы. Эта серия вещей на самом деле исходит из этого вопроса: как далеко от SQL до службы. Если это время занимает всего 1 час, 8 часов в день позволяют менеджеру по продукту подумать над 8 вопросами. Отработав 4 часа сверхурочно по ночам, я могу подумать еще о 4 вопросах. Менеджер по продукту доволен, поэтому программисты-разработчики должны быть счастливее.

Какие факторы делают программистов несчастными

• окружение, фреймворк, зависимости

Первая — это окружение, фреймворк, зависимости, с этими проблемами очень сложно справиться.

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

Еще одна сложность — это зависимости, которые также являются большой головной болью в процессе разработки. Я сам Java-программист, и иногда пишу одну-две тысячи строк кода, всего одним-двумя файлами, а когда набираю пакет, выходит 60 и более мегабайт, с кучей зависимостей. Конечно, сейчас лучше использовать Go, но можно ли решить такую ​​проблему? Например, в одном и том же процессе много студентов, у нас также есть несколько разработчиков в Сучжоу и Пекине, у нас в Сучжоу около 1000 программистов. Когда так много программистов, как можно повысить эффективность этих программистов? Конечно, вы можете сделать это с управлением, с режимом разработки. Но не лучше ли использовать технологию разрешения зависимостей, чтобы не было никаких зависимостей? Даже если есть зависимость, она настраивается в виде интерфейса, что гораздо удобнее.

• Развертывание, эксплуатация и обслуживание, расширение

Другая часть — развертывание, эксплуатация, обслуживание и расширение. Я просто сказал, что студенты, которые могут развиваться, не очень хорошо осведомлены об эксплуатации и обслуживании, а студенты, которые занимаются эксплуатацией и обслуживанием, не слишком осведомлены о разработке, что приводит к проблемам. Tongcheng также продвигал DevOps раньше. Теперь каждый из наших студентов-разработчиков также может иметь свой собственный рабочий стол для эксплуатации и обслуживания для управления каждой машиной, которую он развертывает. Это не проблема. Но так ли хороша эта вещь? На самом деле, когда Тунчэн занимался этим, он обнаружил, что на самом деле попросил группу студентов-разработчиков заняться эксплуатацией и обслуживанием, и они не могли сделать это хорошо, и онлайн-сбои происходили каждый день, потому что выполнение операций, обслуживания и выполнение развития были две идеи. Поэтому позже, когда мы занимались DevOps, мы сначала перевели всех первоначальных студентов, занимающихся эксплуатацией и обслуживанием, в менеджеров по продуктам и менеджеров проектов по эксплуатации и обслуживанию, и позволили группе студентов-разработчиков работать в качестве платформы для эксплуатации и обслуживания, а затем, после Платформа эксплуатации и обслуживания была завершена для использования студентами-разработчиками, так что DevOps будет продвигаться. Звучит так, как будто это действительно решает проблему? На самом деле решения до сих пор нет, потому что студенты-разработчики все еще должны знать, что такое работа по эксплуатации и техническому обслуживанию, но некоторые студенты-разработчики могут не захотеть знать. Например, однажды утром продакт-менеджер захотел продать ланч-бокс, когда придумал тикет.Такую функцию можно написать в 50 строчках кода, так зачем этому разработчику изучать эксплуатацию и обслуживание?Таких на самом деле много студенты.

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

• отладка, производительность, безопасность, слишком сложно

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

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

Сравнение бессерверной и традиционной архитектуры

Это старейшая структура Tongcheng, которая в основном была написана боссами, когда Tongcheng начинал свой бизнес. Когда я посмотрел на эту систему 10 лет назад, я понял, что с ней все в порядке, и с такой архитектурой нет никаких проблем. Но если бы эта архитектура все еще использовалась в 2017 году, все бы подумали, что технология ОТА действительно слабая, и такая система все еще используется. Но на самом деле такая архитектура в системе Тунчэна сегодня действительно есть, а также есть новые системы, которые выглядят так. Почему такая проблема? Например, один из наших бизнес-одноклассников обнаружил, что в глубине пустыни в Австралии весело, а менеджер по продукту чувствует себя хорошо, поэтому он решил создать проект для этого. Тогда дайте ему трех программистов, и вы попросите их написать микросервисную систему, что невозможно. Было бы неплохо иметь возможность написать такую ​​архитектуру как выше.Может там и нет сервиса,а он напрямую завален в приложение. На всей туристической сцене существует много таких предприятий, мы называем это бизнесом проверки или инновационным бизнесом. Бизнес-подразделение будет инкубировать более N таких проектов, и если один из них будет завершен, он постепенно превратится в крупный проект.

Однако такая архитектура подвержена проблемам, и при подъеме трафика легко рухнуть, и можно умереть за день, поэтому ее нужно преобразовывать.

Tongcheng начал работать над микросервисами два года назад.Этот набор архитектуры микросервисов отличается от других.Помимо основного контейнера сервиса, есть промежуточный шлюз, который специально разработан для экранирования сервисов, не являющихся микросервисами. Это связано с тем, что в одном и том же процессе участвует множество инновационных бизнесов традиционной архитектуры. Эти инновационные бизнесы не означают, что они не будут звонить друг другу. Так как же эти немикросервисные сервисы могут вызываться микросервисами? Мы специально подумали о шаблоне в в то время это называлось режимом GNE. Можете ли вы подумать о том, являются ли микросервисы ложным предложением? На практике мы думаем, что это ложное утверждение, потому что никто не может сказать вам, насколько маленьким должен быть микросервис с очень четким номером, чтобы называть его микросервисом. И сервис давно кончается, и его точно станет больше. Например, если у вас уже есть интерфейс оформления заказов и вы публикуете его как микросервис, то заказ можно рассматривать как основной сервис. Если ваш продукт постоянно дорабатывается, то через месяц-два обязательно будет второй сервис, который называется «сервис нового заказа». Через три месяца обязательно появится новая услуга, которая называется «Служба нового заказа». Через полгода самый старый сервис будет помечен как «интерфейс заказа, который больше нельзя использовать, но нельзя отключить». Таким образом, возникнет проблема: во всех компаниях система очень легко переходит в режим онлайн, но если вы хотите, чтобы система вышла в автономный режим, вам нужно связаться с различными отделами, сжечь различные благовония и, наконец, выйти в автономный режим.

Результатом микросервисов является то, что сервис продолжает расти. Получается, что цель наших микросервисов — упростить бизнес, сделать его меньше, лучше и стабильнее, и развернуть его самостоятельно, и его можно оркестровать. Но когда вы снова посмотрите на него через три, пять месяцев или полтора года, вы обнаружите, что это толстая Ян Гуйфэй, а не та стройная дама. Хореографию не устроишь, потому что в ней слишком много вещей. Тогда это проблема, с которой столкнулся Tongcheng при создании микросервисов. Наше решение состоит в том, чтобы сделать еще один шлюз, чтобы запереть толстяка, и использовать несколько базовых интерфейсов микросервисов извне, но существуют разные стратегии маршрутизации, чтобы выбрать, какую версию интерфейса использовать. Фактически, после того, как это будет сделано, стоимость обслуживания и стоимость обслуживания очень высоки.

Почти все приложения Tongcheng теперь развернуты в Docker, включая базы данных. Однако по мере увеличения количества сервисов это на самом деле приносит большие проблемы с эксплуатацией и обслуживанием, а также с повторным использованием каждого сервиса, а сервисы не могут расти бесконечно, как сейчас. И обнаружил, что 30% обращений в службу со временем почти исчезли, иногда раз в день или раз в месяц. Это сервисы, которые можно перевести в автономный режим, но нельзя полностью отключить, и к ним поступает небольшой объем трафика. Таких сервисов накапливается все больше и больше, они потребляют много ресурсов вашего сервера, а отходы огромны.

Может ли сценарий кода быть микросервисом?

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

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

Чего достигает бессерверная технология Tongcheng?

Тот же самый процесс начал работать без сервера в апреле и мае 2016 года. Что такое бессерверная архитектура, по оценкам, сегодня никто не может точно сказать. Я вырезал здесь предложение: «Если ваш PaaS может запустить приложение, запущенное за полсекунды до этого, за 20 мс, назовите его бессерверным». В любом случае, когда мы это делали, мы не думали, сколько миллисекунд потребуется, чтобы запустить его. Один из наших принципов заключается в том, что эти легкие сервисы можно превратить в микросервисы, сделав их скриптом, а его вызов и развертывание можно динамически расширять. Когда у него нет трафика, лучше не потреблять большую часть ресурсов, и он может легко отключиться. Проблема, которую нам на самом деле нужно решить при использовании Serverless, заключается в следующем.имеютМного очень легких потребностей обслуживаниябыстроОнлайн и офлайн, и не хочется тратить огромные затраты ресурсов.

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

Второй уровень — это вычислительный уровень, в основном для выполнения нашей работы по планированию, как быстро распределять ресурсы. При работе без сервера есть два подхода, например, мы напрямую используем Docker-контейнеры для хранения, каждое расширение представляет собой контейнер, который нагромождается один за другим. Но я считаю, что это недостаточно красиво, и слишком грубо расширять контейнер напрямую, ведь сам контейнер все равно занимает ресурсы. И еще проблема в том, что вещи, развернутые здесь, определяются как один скрипт или один-два скрипта для выполнения.Этот код очень мал.Если вы выделяете что-то такое тяжелое, как контейнер, то ресурсы довольно расточительны. Поэтому, когда мы начинали, это было относительно просто, и для этого мы использовали динамические языки. Давайте сначала реализуем динамические языки, такие как Lua и Node.js, Его преимущество в том, что среда выполнения похожа на виртуальную машину, которую можно изолировать. После изоляции, когда каждый скрипт выполняется, он представляет собой отдельный исполняемый контейнер, а затем помещается в контейнер Docker. В настоящее время мы поддерживаем только динамические языки, и мы также пробуем Go, но это сложнее и не увенчалось успехом. Два приведенных выше рисунка расширяют интермодуляционные отношения между каждым из наших сценариев.

Это диаграмма использования ресурсов нашей бессерверной архитектуры. По сути, контейнер Docker развертывается на базе физической машины, а затем мы открываем контейнеры Docker один за другим для его развертывания, а затем изолируем. Мы провели эксперимент, и минимальный объем развертывания позволяет развернуть 100 000 приложений на 4 физических машинах. Конечно, это невозможно сделать в производственной среде, если 100 000 скриптовых сервисов имеют трафик в производственной среде, один только этот трафик убьет его. После использования таких бессерверных приложений многие легкие приложения могут быть отключены в любое время, что решает проблему сервисов, которые имеют небольшой трафик, но должны быть живыми.

Но вот другой вопрос, довольны ли в этом случае программисты программированием? Все еще несчастлив, я думаю. Что мне больше не нравится, так это то, что я хочу написать строку кода, чтобы получить часть данных из базы данных, в результате мне нужно найти драйвер, спросить у меня адрес БД, пароль и набрать различные библиотеки классов, что раздражает. Поэтому мы также начали делать SDK, чтобы код мог лучше его использовать. Пример извлечения данных из базы данных показан на рисунке ниже.Когда вы программируете, вам не нужно заботиться о том, где находится сервер, вы можете просто сосредоточиться на коде. Такой библиотекой Server.DB будет управлять центр конфигурации на всей платформе.Все БД можно настроить вручную.После настройки он сгенерирует этот объект.Для разработчиков его нужно только набрать.

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

Проделав так много всего, мы обнаружили, что Serverless недостаточно. Я просто сказал, что есть еще большая проблема.Локальная хорошо, но онлайн или тестовая среда не очень хорошо.Эта проблема не решена. Это по-прежнему сосредоточено на окружающей среде, а не только на коде. Поэтому мы сделали Web IDE, и разработчикам больше не нужно заботиться о локальной среде разработки, как и не нужно настраивать зависимости локальной среды разработки. Потому что при использовании микросервисов, особенно когда сотрудничает большое количество крупных команд, часто бывает сложно смоделировать их взаимозависимости локально. Мы предоставляем Web IDE, чтобы каждый студент мог писать код, открыв веб-страницу, чтобы при написании кода все было под моим контролем.

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

Без сервера в том же процессе

Эффективность в разработке, выпуске и эксплуатации

Мы обнаружили, что проделав подобное, на ранней стадии нашей разработки, когда любой проект, любая самостоятельно развернутая функция начинает размещаться, нужно применять ряд вещей, и мы экономим на этих вещах 90% времени. . Следующий шаг - поиск данных.Кажется тривиальным,где БД,но на самом деле это очень раздражает для разработки.Где БД в тестовой среде,где БД в среде разработки,а где БД в предрелизной среде? Так что после работы без сервера я сэкономил 80% времени на этих вещах. Для написания кода на самом деле экономия времени не так уж и велика, ведь еще много кода нужно написать людям. В этой ссылке многие SDK, которые мы предоставляем, сыграли большую роль, сэкономив 40% времени. 90% времени экономится на стороне эксплуатации и обслуживания.Когда приложение развернуто в виде небольшого скрипта, вся платформа будет платформизирована, и не будет инструментов разработки, поэтому это проще для эксплуатации и обслуживания. система мониторинга может делать это полностью автоматически.

веб приложение

Теперь все веб-страницы всех сайтов Tongcheng размещены на платформе только сейчас.Из-за этой платформы в конце 2016 года в Tongcheng произошла фронтенд-революция. Если раньше фронтенд-инженерам нужно было найти серверную часть, чтобы предоставить интерфейс после завершения страницы, то теперь, после создания этой платформы, так как это Node.js, фронтенд-инженеры могут закончить ее самостоятельно. и все виды баз данных можно найти напрямую. На самом деле это вопрос повышения спроса утром и выхода в интернет вечером, поэтому всем фронтендам нравится использовать эту платформу. Более того, эта платформа является не только веб-платформой, но и предоставляет множество API.Многие студенты начали создавать свои собственные инструменты.Например, они могут использовать Atom для подключения API платформы, а также могут писать эти коды с помощью Атом.

легкий сервис

Есть также несколько быстрых сервисов для простого бизнеса.Вышеприведенное изображение является реальным кодом, который на самом деле является просто скриптом.

Вспомогательная интеграция функций

Тогда есть служба расчета цен в режиме реального времени. Многие говорят, что у OTA нет красивых технологий, но на самом деле их довольно много. Возьмем, к примеру, самый традиционный бизнес — отели. Такой бизнес, как гостиничный, очень традиционный, но на самом деле очень сложный и сложный. Вы представляете, как выглядит цена, когда вы покупаете что-то на Али или JD.com? Блин, утренние цены не изменятся как минимум до полудня. Но цена отеля не та, почему? Если вы проживаете в отеле три дня подряд, или если в дате вашего пребывания есть выходные, или за три дня, или за одну неделю, цена отеля по каждому условию поиска будет разной. Цена проживания в отеле на неделю невысокая, может быть 280 юаней за отель стоимостью 300 юаней, если бронировать за две недели, то может быть дешевле. Но если вы бронируете на завтра или сегодня вечером, это дорого или на 30% больше на выходные, поэтому цена меняется в зависимости от критериев каждого поиска. В настоящее время при поиске отелей много мертвых данных, которые могут меняться и каждые 5 минут, и каждые полчаса. В настоящее время требуется расчет в реальном времени.Этот расчет в реальном времени на самом деле является проблемой расширения, потому что время расчета слишком велико. Конечно, теперь Саню можно очень быстро обыскать, потому что у него есть механизм расширения в реальном времени. Как и в случае с нашим отелем в том же путешествии, для ежедневного расчета требуется 480 узлов, которые можно увеличить до 1000 узлов или убрать.

Что делать дальше с Serverless

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

Q&A

Q1: Если проблема с сервером, на котором размещен код или другими серверамиКак сделать?

Ван Сяобо:На самом деле у отечественной разработки такая проблема.Общался с ними в фейсбуке два дня назад.У нас в Китае требуют чтобы код сдали в тот же день.Его вообще никто не читает.Задержишь фирму-повесишь вверх было бы лучше.

Q2: Например, при редактировании кода на веб-странице сеть внезапно отключается на полпути к процессу редактирования?

Ван Сяобо:Этого не будет. Я думаю, что ваш метод лучше, чем отечественный метод.

Q3: В последнее время я также работаю над корпоративными шлюзами.Позвольте мне поделиться своим опытом в шлюзах.

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