1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/362330721-taoshop

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
README.md

Электронный коммерческий проект

Проект электронной коммерции: введение

Проект электронной коммерции Taoshop. Код проекта передан сообществу Open Source China: https://www.oschina.net/p/taoshop.

Открытый коммерческий проект, реализованный на основе технологий SpringBoot и Dubbo, представляет собой микросервисную архитектуру для создания распределённой системы электронного магазина. (Разработка продолжается.)

Открытый протокол

Taoshop использует открытый протокол Apache 2.0.

Функции

  • Портал:

    • поиск товаров (Lucene);
    • последние поступления;
    • поиск по категориям товаров;
    • акции с мгновенными скидками (обработка с высокой степенью параллелизма);
    • детали товара;
    • многоуровневая связь между категориями товаров.
  • Платформа управления:

    • центр пользователя;
    • система заказов;
    • управление магазином;
    • управление комментариями;
    • система управления рисками;
    • платформа закупок;
    • контент-менеджмент.

Стек технологий

  • Шаблонизатор: Thymeleaf.
  • Поисковая система: Lucene.
  • Балансировка нагрузки: Nginx.
  • Обработка кэша: Redis.
  • Основной фреймворк для бэкенда: SpringBoot, Mybatis.
  • Микросервисы: Dubbo.

Структура каталога платформы

├─taoshop---------------------------- родительский проект, общие зависимости
│  │
│  ├─taoshop-search-------------------------- глобальный поиск
│  │
│  ├─taoshop-quartz----------------------- система планирования задач
│  │
│  ├─taoshop-sso------------------------- система единого входа
│  │
│  ├─taoshop-portal-------------------------- портал сайта
│  │
│  ├─taoshop-cms-------------------------- платформа CMS
|  |
|  |─taoshop-order-------------------------- система заказов платформы
│  │
│  ├─paascloud-provider
│  │  │
│  │  │
│  │  ├─taoshop-provider-usc------------------ центр информации о пользователях
|  |  |
|  |  |-taoshop-provider-item------------------ информация о товарах
|  |  |
|  |  |-taoshop-provider-shop------------------ информация о магазине
│  │  │
│  │  └─taoshop-provider-order------------------ информация об заказах
│  │
│  ├─taoshop-provider-api
│  │  │
│  │  │-taoshop-provider-api-usc------------------ API центра информации о пользователях
|  |  |
|  |  |-taosho-provider-api-item------------------ API информации о товарах
|  |  |
|  |  |-taoshop-provider-api-shop------------------ API информации о магазине
|  |  |
│  │  └─taoshop-provider-api-order------------------ API информации об заказах
│  │
│  ├─taoshop-common
│  │  │
│  │  ├─taoshop-common-core------------------ основные зависимости платформы
│  │  │
│  │  ├─taoshop-common-zk------------------ конфигурация zookeeper
│  │  │
│  │  ├─taoshop-common-quartz------------------ система планирования задач
│  │  │
│  │  ├─taoshop-security-core------------------ ядро безопасности
│  │  │
│  │  └─taoshop-security-auth2------------------ аутентификация и авторизация API
│  │



Архитектура проекта

![Image text](https://github.com/u014427391/taoshop/raw/master/screenshot/архитектура проекта.png)

Демонстрация функций платформы

Приложение

Часть 1. Основы распределённых систем

1.1 Эволюция архитектуры

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

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

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

Далее возникла архитектура RPC, где ранее вертикальные приложения представляли собой обмен данными внутри одного процесса, а RPC — это обмен данными между процессами, то есть удалённый вызов процедур.

После появления RPC стало возможным осуществлять обмен данными между процессами. Однако при использовании серверов в кластере распределение ресурсов иногда может привести к их неэффективному использованию. Например, если есть система, обычно невозможно точно предсказать, сколько машин потребуется для её работы. В результате может возникнуть ситуация, когда часто используемые модули получают недостаточно машин, а редко используемые — слишком много. Это не позволяет эффективно использовать ресурсы, поэтому возникла SOA (Service Oriented Architecture), которая представляет собой центр регистрации служб и позволяет более рационально распределять ресурсы и повышать эффективность управления ими.

1.2 Основные понятия распределённых систем

Понимая эволюцию архитектуры, можно лучше понять концепцию распределённости. Распределённость фактически представляет собой архитектурный подход, который позволяет различным процессам обмениваться данными. Обычно это реализуется через фреймворки RPC, такие как Dubbo или Spring Cloud.

Часть 2. Введение в RPC

2.1 Концепция RPC

RPC (Remote Procedure Call) — это способ взаимодействия между процессами, позволяющий вызывать процедуры на удалённом компьютере.

2.2 Ключевые компоненты RPC

В RPC есть два ключевых компонента: коммуникация и сериализация.

Часть 3. Обзор Dubbo

3.1 Введение в Dubbo

Dubbo — это фреймворк Java RPC от Alibaba, который теперь открыт под лицензией Apache. Официальный сайт: http://dubbo.apache.org/.

3.2 Основные функции

a) Интеллектуальное обнаружение сбоев и балансировка нагрузки. b) Регистрация и обнаружение служб. c) Вызов методов интерфейса на расстоянии.

3.3 Обзор принципов работы

Приведённая выше диаграмма взята из официальной документации Dubbo. Она описывает роли и принципы работы в системе.

Роли:

Provider — поставщик услуг. Container — контейнер, в котором выполняется служба. Consumer — потребитель услуг, вызывающий удалённые службы. Registry — реестр служб, отвечающий за регистрацию и обнаружение сервисов. Monitor — компонент, отслеживающий количество вызовов и время выполнения служб.

Процесс вызова:

Согласно пониманию автора, процесс вызова происходит следующим образом:

  1. Контейнер отвечает за запуск, загрузку и выполнение служб поставщика.
  2. После запуска поставщик регистрирует свои услуги в реестре.
  3. Потребитель после запуска подписывается на нужные ему услуги в реестре.
  4. Реестр возвращает потребителю список доступных служб.
  5. Потребитель выбирает службу поставщика на основе алгоритма балансировки нагрузки. Этот поставщик может быть одним из списка поставщиков, и выбор осуществляется на основе алгоритма балансировки.
  6. Поставщик и потребитель периодически отправляют информацию о количестве вызовов и времени выполнения в компонент мониторинга. CAS单点登录简单介绍

Сообщение очереди

  • RocketMQ入门手册

Поиск двигателя

  • Apache Lucene глобальный поиск двигателя вводный курс

Dubbo

  • Dubbo учебные заметки
  • SpringBoot + Dubbo для создания микросервисов

Распределённая блокировка

  • Redis учебные заметки о распределённой блокировке

SpringBoot

  • Реализация многоуровневой ассоциации товаров и категорий на веб-сайте электронной коммерции с использованием SpringBoot и Thymeleaf

Mybatis

  • Решение проблемы отображения времени в формате переднего плана Mybatis + Thymeleaf
  • Решение для Mybatis3.2, которое не поддерживает Ant подстановочные знаки TypeAliasesPackage сканирование

Кэш

  • Изучение заметок Redis о базовых структурах данных
  • Изучение заметок Redis о растровых изображениях
  • Изучение заметок Redis об отложенной очереди
  • Изучение заметок Redis о распределённых блокировках
  • Интеграция SpringBoot с Redis для реализации обработки кэша (технология Spring AOP)

Шаблоны проектирования Создание шаблонов

  • Шаблоны проектирования: шаблон наблюдателя (поведенческий)
  • Шаблоны проектирования: паттерн моста (структурный)
  • Паттерны проектирования: адаптер (структурные)
  • Паттерны проектирования: строитель (создающие)
  • Паттерны проектирования: простой фабричный метод (создающий)
  • Паттерны проектирования: абстрактная фабрика (создающая)
  • Паттерны проектирования: синглтон (создающий)
  • Паттерны проектирования: фабричный метод (создающий)
  • Паттерны проектирования: прототип (создающий)

Структурные шаблоны

  • Паттерны проектирования: мост (структурный)

Поведенческие шаблоны

  • Паттерны проектирования: наблюдатель (поведенческий)
  • Паттерны проектирования: команда (поведенческая)
  • Паттерны проектирования: мемоизация (поведенческая)
  • Паттерны проектирования: посетитель (поведенческая)

Oracle знания

  • Oracle знания и заметки
  • Oracle заметки: блокировка и разблокировка таблиц
  • Рекурсивный запрос Oracle start with connect by prior
  • Использование функции vm_concat Oracle для объединения столбцов в строки
  • Oracle заметки: изменение типа поля таблицы
  • Функции Oracle nvl и nvl2

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

Проект электронной коммерции с открытым исходным кодом, реализация микросервисной архитектуры на основе стека технологий SpringBoot + Dubbo. Цель проекта — создание распределённой кластерной системы для интернет-магазина. Ссылки на релизы проекта: https://github.com/u014427391/taoshop/releases (в разработке...) Развернуть Свернуть
Apache-2.0
Отмена

Обновления

Пока нет обновлений

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/362330721-taoshop.git
git@api.gitlife.ru:oschina-mirror/362330721-taoshop.git
oschina-mirror
362330721-taoshop
362330721-taoshop
master