Практика оптимизации архитектуры туристической системы Туниу

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже приведены принципы микросервисов, которые мы суммируем.

- Бизнес-ориентированный, вокруг доменной модели

- Скрыть детали реализации

- Сосредоточьтесь на пользователях и API

- Децентрализованный

- Автономное автоматизированное развертывание

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

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

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

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

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

Вообще говоря, вся архитектура использует режим CQS.

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