Сайт для продажи спецтехники и запчастей из Китая: как настроить автоматический парсинг каталогов с китайских заводов

Рынок тяжелой техники и запасных частей из Китайской Народной Республики переживает беспрецедентный рост. Такие известные бренды, как Liugong, XCMG, Zoomlion, Sany, SDLG, Shantui, Shacman и Sinotruk, стали привычными стандартами на строительных, дорожных и добывающих площадках в России и странах СНГ. Однако запуск полноценного интернет-магазина, маркетплейса или дилерского портала в этой нише сталкивается с колоссальной технической проблемой: ассортимент деталей исчисляется миллионами уникальных товарных позиций (SKU), каталоги заводов постоянно дополняются и видоизменяются, а китайские производители не предоставляют дистрибьюторам готовых API, структурированных файлов выгрузки (вроде XML, CSV или JSON) или хотя бы стандартизированных прайс-листов.

В данном подробном руководстве мы детально разберем, как спроектировать, разработать и внедрить надежную, масштабируемую и отказоустойчивую систему автоматического сбора данных (парсинга) с китайских фабрик, заводов и оптовых маркетплейсов. Мы рассмотрим выбор стека технологий, обход продвинутых систем защиты от ботов, архитектуру локального перевода и нормализации OEM-номеров, алгоритмы динамического расчета цен с учетом сложной международной логистики и пошлин, интеграцию с учетными системами семейства 1С, а также особенности реализации гибридной модели дропшиппинга для работы с виртуальным складом.

Почему парсинг — единственный рабочий путь для каталога спецтехники

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

1. Колоссальный объем данных. Один только каталог деталей для популярного бульдозера Shantui SD16 или фронтального погрузчика XCMG LW300FN включает в себя тысячи узлов, агрегатов и отдельных элементов — от крупных двигателей, кабин и мостов до мельчайших уплотнительных колец, прокладок, болтов и датчиков. Если дилер стремится закрывать потребности клиентов по нескольким брендам спецтехники, суммарная база данных быстро разрастается до 2–5 миллионов уникальных позиций.
2. Отсутствие стандартизации у производителей. Каждый китайский завод ведет техническую документацию по собственным стандартам. Зачастую актуальные каталоги деталей доступны только внутри закрытых порталов для внутреннего рынка (EPC — Electronic Parts Catalogs). Информация там может быть представлена в виде защищенных Flash-приложений, интерактивных веб-страниц с холстами HTML5 (Canvas) или тяжелых PDF-чертежей без текстового слоя, где номера деталей нанесены графически на изображения взрыв-схем.
3. Кросс-коды, замены и применимость деталей. Запчасти для китайской техники характеризуются высокой степенью взаимозаменяемости. Один и тот же гидронасос или стартер может устанавливаться на десятки моделей экскаваторов разных брендов. Без автоматического сопоставления оригинальных OEM-номеров (Original Equipment Manufacturer) с номерами аналогов и построения графа совместимости невозможно создать на сайте качественный поиск, который действительно будет приносить продажи.

Коротко: Каталог спецтехники и запчастей из Китая наполняется автоматическим парсером на Playwright с резидентными прокси и решением капчи, так как заводы не дают API. Данные нормализуются по OEM-номерам, переводятся через локальный словарь, проходят через калькулятор себестоимости с учетом логистики и пошлин и импортируются в 1С через очередь сообщений.

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

Источники данных: с каких китайских площадок собирать каталоги

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

1. Официальные дилерские порталы и EPC-системы китайских заводов. Бренды первого эшелона (например, XCMG, Sany, Zoomlion, SDLG) предоставляют своим авторизованным партнерам доступ к закрытым веб-каталогам запчастей. Парсинг таких ресурсов позволяет выкачать эталонную иерархию узлов и агрегатов конкретной модели техники, получить оригинальные артикулы деталей и связать их с графическими взрыв-схемами (каталожными чертежами).
2. Внутренние оптовые B2B-платформы Китая. Ключевым источником здесь выступает площадка 1688.com (внутренний аналог Alibaba для рынка КНР). Цены на 1688.com отражают реальную оптовую стоимость запчастей от непосредственных фабрик-производителей без экспортных наценок торговых компаний. Парсинг 1688 позволяет не только собирать цены OEM-производителей и дубликатов, но и находить альтернативных поставщиков для одной и той же детали. Также полезны площадки Taobao.com (для поиска редких б/у деталей) и Tmall.com.
3. Специализированные китайские справочно-информационные порталы. Сайты вроде HC360 (hc360.com), Chinamachinery (для спецтехники) и региональные каталоги производителей из промышленных кластеров (таких как провинции Шаньдун, Чжэцзян и Цзянсу), где сосредоточены крупнейшие заводы по производству гидравлических систем, трансмиссий и элементов ходовой части.

Техническая архитектура парсера: Playwright vs Puppeteer vs Scrapy

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

• Scrapy (Python): Это классический быстрый фреймворк для парсинга сайтов с простой версткой или доступными внутренними API. Он потребляет минимум оперативной памяти и процессора, позволяя отправлять тысячи асинхронных запросов в минуту. Однако современные китайские B2B-порталы активно используют SPA-архитектуру (Single Page Application), тяжелый рендеринг на стороне клиента с помощью React/Vue и сложные алгоритмы шифрования параметров запросов, что делает использование Scrapy крайне трудоемким процессом.
• Puppeteer и Playwright (Node.js/TypeScript): Инструменты для автоматизации и управления реальными браузерами на базе движка Chromium. В задачах парсинга защищенных китайских ресурсов безусловным лидером является Playwright. Он обладает встроенной поддержкой нескольких изолированных контекстов браузера (что экономит ресурсы по сравнению с запуском отдельных экземпляров Chromium в Puppeteer), продвинутыми механизмами ожидания элементов (auto-waiting) и удобным API для перехвата сетевых запросов (Network Interception).

Ниже представлен пример инициализации парсера на Node.js и Playwright с применением техник маскировки автоматизации под действия реального пользователя:

import { chromium, Browser, BrowserContext, Page } from 'playwright';

export interface ParserSession {
  browser: Browser;
  context: BrowserContext;
  page: Page;
}

export async function createStealthParserSession(proxyUrl: string): Promise<ParserSession> {
  // Запускаем браузер с отключением флага автоматизации
  const browser: Browser = await chromium.launch({
    headless: true,
    args: [
      '--disable-blink-features=AutomationControlled',
      '--no-sandbox',
      '--disable-infobars',
      '--disable-dev-shm-usage',
      `--proxy-server=${proxyUrl}`
    ]
  });

  // Создаем контекст с эмуляцией параметров реального устройства
  const context: BrowserContext = await browser.newContext({
    userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36',
    viewport: { width: 1440, height: 900 },
    locale: 'zh-CN',
    timezoneId: 'Asia/Shanghai',
    geolocation: { longitude: 121.4737, latitude: 31.2304 }, -- Эмуляция Шанхая
    permissions: ['geolocation']
  });

  // Внедряем скрипт для маскировки navigator.webdriver и фингерпринтов
  await context.addInitScript(() => {
    Object.defineProperty(navigator, 'webdriver', {
      get: () => undefined,
    });
    // Подмена языков и платформы
    Object.defineProperty(navigator, 'languages', {
      get: () => ['zh-CN', 'zh', 'en'],
    });
  });

  const page: Page = await context.newPage();
  
  // Устанавливаем таймаут на загрузку страниц
  page.setDefaultTimeout(30000);
  
  return { browser, context, page };
}

Обход блокировок: прокси-ротация, фингерпринты и капча

Китайские маркетплейсы, особенно холдинг Alibaba (Taobao, 1688), используют одни из самых совершенных систем защиты от роботов в мире. Они анализируют поведение посетителя по сотням параметров: от сетевого маршрута до микродвижений мыши.

Для долгосрочного сбора данных без блокировок необходимо реализовать три уровня защиты:

1. Пул ротируемых резидентных прокси (Residential Proxies). Серверные IP-адреса хостинг-провайдеров блокируются китайскими файрволами мгновенно. Сбор данных возможен только через резидентные прокси с IP-адресами реальных домашних пользователей из Китая (провайдеры China Telecom, China Unicom). Ротация должна осуществляться по принципу «один запрос — один IP» либо через фиксированные сессии длительностью 5–10 минут для прохождения процесса авторизации.
2. Эмуляция отпечатков устройств (Fingerprint Emulation). Системы защиты анализируют хеш Canvas, WebGL, аудио-отпечаток, перечень системных шрифтов и особенности сетевого стека TCP/IP. Использование библиотек маскировки (например, плагинов stealth для Puppeteer/Playwright) обязательно.
3. Автоматическое прохождение капч (Capcha Solving). При высокой интенсивности запросов неизбежно возникновение Geetest-слайдеров или капч с выбором китайских иероглифов. Для их решения в архитектуру парсера внедряются API-интеграции со специализированными сервисами (CapSolver, 2Captcha), которые с помощью нейросетей имитируют движение мыши и сдвигают слайдер в нужную точку.

Схематично архитектура обхода блокировок выглядит следующим образом:

┌─────────────────────────────────────────────────────────────────────────┐
│                          Парсер (Node.js/Playwright)                    │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
                        (Маршрутизация всех запросов)
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                      Прокси-менеджер (Proxy Rotator)                    │
│  - Выбор случайного китайского резидентного IP                          │
│  - Мониторинг скорости ответа и уровня блокировок                       │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
                        (Выполнение HTTP/JS запроса)
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     Антифрод-система завода (WAF)                       │
│  [Если появляется Geetest / Slider капча]                               │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
                         (Отправка скриншота/параметров)
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                   Внешний решатель капчи (CapSolver API)                │
│  - Распознавание координат слайдера с помощью ИИ                       │
│  - Возврат токена успешного решения парсеру                             │
└─────────────────────────────────────────────────────────────────────────┘

Обработка данных: перевод, очистка и сопоставление (Translation Mapping)

Информация с китайских заводов поступает исключительно на китайском языке (упрощенный китайский — 简体中文). Использование стандартных API машинного перевода (Google, Yandex, DeepL) напрямую при рендеринге страниц сайта нецелесообразно: это порождает огромные задержки, высокую стоимость API и критические ошибки в переводе специфических технических терминов.

Решением является построение локальной двухэтапной системы обработки данных:

Нормализация OEM-номеров деталей

Китайские менеджеры на заводах часто записывают одни и те же артикулы по-разному: со спецсимволами, дефисами, точками или пробелами (например, 9360008-0310, 93600080310, 936 0008 0310). Для сопоставления товаров внутри базы данных применяется функция нормализации, которая приводит артикул к верхнему регистру и удаляет все небуквенно-цифровые символы:

export function normalizeOemNumber(oem: string): string {
  if (!oem) return '';
  return oem.toUpperCase().replace(/[^A-Z0-9]/g, '');
}

В базе данных PostgreSQL для таблицы товаров создается индекс по полю oem_normalized для мгновенного поиска аналогов и кросс-кодов:

CREATE TABLE product_catalog (
    id SERIAL PRIMARY KEY,
    oem_original VARCHAR(100) NOT NULL,
    oem_normalized VARCHAR(100) NOT NULL,
    brand VARCHAR(100) NOT NULL,
    name_zh TEXT NOT NULL,
    name_ru TEXT,
    weight_kg NUMERIC(10, 3) DEFAULT 0,
    volume_m3 NUMERIC(10, 6) DEFAULT 0,
    last_parsed_price_cny NUMERIC(12, 2),
    source_url TEXT,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_product_oem_norm ON product_catalog(oem_normalized);
CREATE INDEX idx_product_brand_oem ON product_catalog(brand, oem_normalized);

Локальный словарь технических терминов (Translation Mapping)

Для перевода названий деталей разрабатывается специализированный терминологический словарь. Перед отправкой названия в дорогостоящий переводчик система проверяет каждое слово или словосочетание по локальной базе соответствий.

Пример структуры локальной таблицы словаря:

CREATE TABLE translation_dictionary (
    id SERIAL PRIMARY KEY,
    chinese_phrase VARCHAR(255) UNIQUE NOT NULL,
    russian_phrase VARCHAR(255) NOT NULL,
    is_verified BOOLEAN DEFAULT FALSE,
    usage_count INT DEFAULT 0
);

Если китайское наименование детали состоит из нескольких знакомых системе фраз (например, «发动机» — Двигатель + «滤清器» — Фильтр), система собирает перевод автоматически: «Фильтр двигателя». Если фраза новая, система обращается к API переводчика, сохраняет результат в базу данных с пометкой is_verified = FALSE и отправляет контент-менеджеру на модерацию.

Динамическое ценообразование: валютный калькулятор с учетом логистики

Цена детали на складе завода в Китае (в юанях) несопоставима с ценой, по которой товар должен продаваться клиенту в России или СНГ. Финальная стоимость должна рассчитываться динамически на основе формулы, учитывающей множество переменных факторов.

Математическая модель расчета конечной розничной цены ($P_{final}$):

$$P_{final} = \left( (P_{cny} + L_{china} + P_{pack}) \times (1 + T_{customs}) \times E_{cny\_rate} + W_{kg} \times L_{intl} \right) \times (1 + M_{markup})$$

Где:

• $P_{cny}$ — базовая оптовая цена товара на китайском заводе в юанях (CNY).
• $L_{china}$ — стоимость доставки товара по территории Китая от завода до склада консолидации дилера в приграничной зоне (например, в Маньчжурии, Хэйхэ или Урумчи).
• $P_{pack}$ — стоимость жесткой обрешетки или дополнительной упаковки (критично для хрупких деталей спецтехники).
• $T_{customs}$ — коэффициент таможенной пошлины и сопутствующих сборов (в среднем варьируется от 1.15 до 1.35 в зависимости от категории ТН ВЭД).
• $E_{cny\_rate}$ — внутренний коммерческий курс юаня к рублю, устанавливаемый владельцем сайта (обычно равен курсу ЦБ РФ + 3-5% на конвертацию).
• $W_{kg}$ — физический вес детали в килограммах (извлекается из характеристик товара при парсинге).
• $L_{intl}$ — тариф на международную доставку (карго или белая доставка) за 1 кг веса (например, $4.5 за килограмм).
• $M_{markup}$ — маржинальная наценка дилера, которая должна быть прогрессивной (чем дешевле товар в закупке, тем выше процент наценки).

Пример реализации алгоритма калькуляции цен на стороне сервера (Node.js):

interface CostCalculationParams {
  priceCny: number;
  weightKg: number;
  category: string;
}

export function calculateCustomerPrice(params: CostCalculationParams): number {
  const CURRENT_CNY_RUB_RATE = 13.65; // Внутренний курс юаня
  const CARGO_RATE_PER_KG_USD = 4.2;  // Тариф на доставку за 1 кг
  const USD_RUB_RATE = 91.50;         // Курс доллара к рублю
  
  const deliveryChinaCny = 15;        // Средняя доставка по КНР на позицию
  const packagingCny = 8;             // Упаковка
  const customsDutyPercent = 0.25;    // Пошлина + НДС (25%)

  // 1. Расчет себестоимости в Китае с учетом логистики до границы
  const localCostCny = params.priceCny + deliveryChinaCny + packagingCny;
  
  // 2. Конвертация в рубли с учетом таможни
  const baseCostRub = localCostCny * CURRENT_CNY_RUB_RATE * (1 + customsDutyPercent);
  
  // 3. Расчет стоимости международной доставки по весу
  const internationalDeliveryRub = params.weightKg * CARGO_RATE_PER_KG_USD * USD_RUB_RATE;
  
  // 4. Полная себестоимость товара на складе в РФ
  const totalNetCostRub = baseCostRub + internationalDeliveryRub;

  // 5. Применение прогрессивной маржинальной наценки
  let markupPercent = 0.35; // 35% по умолчанию
  
  if (totalNetCostRub < 1000) {
    markupPercent = 0.75;  // 75% на мелкие метизы, прокладки
  } else if (totalNetCostRub < 10000) {
    markupPercent = 0.50;  // 50% на средние детали
  } else if (totalNetCostRub > 100000) {
    markupPercent = 0.18;  // 18% на дорогостоящие узлы (ДВС, мосты)
  }

  const finalPrice = totalNetCostRub * (1 + markupPercent);
  
  // Округляем до ближайшего целого числа в большую сторону
  return Math.ceil(finalPrice);
}

Синхронизация с учетными системами и 1С

Прямая запись спарсенных данных в базу данных сайта (например, MySQL/PostgreSQL интернет-магазина) — распространенная архитектурная ошибка. База данных сайта не приспособлена для ведения складского учета, резервирования и проведения финансовых операций.

Правильный поток данных строится по следующей схеме:

1. Сбор данных: Парсер собирает сырые данные и складывает их во временную базу данных.
2. Очистка и агрегация: Данные переводятся, нормализуются и обогащаются медиа-файлами.
3. Очередь импорта (Broker): Через брокер очередей (например, RabbitMQ или BullMQ) сформированные карточки товаров отправляются в учетную систему 1С (1С:ERP, 1С:Комплексная автоматизация или 1С:УНФ).
4. Складской учет в 1С: В 1С создается новая номенклатура, сопоставляются цены поставщиков, рассчитывается плановая себестоимость.
5. Выгрузка на сайт: 1С выгружает актуальный каталог, цены и остатки на сайт с помощью стандартного протокола CommerceML или кастомного REST API.

Для передачи данных в 1С на стороне 1С создается HTTP-сервис. Ниже представлен пример структуры JSON-пакета, который парсер отправляет в 1С для создания или обновления карточки детали:

{
  "request_metadata": {
    "timestamp": "2026-06-09T16:52:40Z",
    "parser_version": "2.4.1"
  },
  "product_data": {
    "oem_normalized": "93600080310",
    "oem_original": "9360008-0310",
    "brand_name": "XCMG",
    "manufacturer_part_name_zh": "XCMG LW300FN 液压滤清器",
    "manufacturer_part_name_ru": "Фильтр гидравлический XCMG LW300FN",
    "parsed_price_cny": 45.00,
    "weight_kg": 1.250,
    "volume_m3": 0.003500,
    "images": [
      "https://example-cdn.com/images/xcmg/93600080310_1.jpg",
      "https://example-cdn.com/images/xcmg/93600080310_2.jpg"
    ],
    "specifications": [
      {
        "property_zh": "高度",
        "property_ru": "Высота",
        "value": "210 мм"
      },
      {
        "property_zh": "外径",
        "property_ru": "Внешний диаметр",
        "value": "95 мм"
      }
    ],
    "compatibility": [
      "LW300FN",
      "LW300K",
      "ZL30G"
    ]
  }
}

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

Дропшиппинг и гибридная модель поставок спецтехники

Для минимизации затрат на аренду складских помещений и закупку товаров большинство успешных интернет-магазинов спецтехники внедряют гибридную бизнес-модель:

• Модель «Собственный склад» (Быстрый сток). Самые востребованные и высокооборачиваемые позиции (расходные материалы: фильтры, ремни, прокладки, коронки ковшей, масла, датчики) закупаются оптом и хранятся на складе дилера в РФ. Информация о наличии таких товаров на сайте обновляется мгновенно, а доставка клиенту занимает от 1 до 3 дней.
• Модель «Дропшиппинг из Китая» (Виртуальный склад). Крупные узлы в сборе, элементы кабин, сложные редукторы, коленчатые валы и другие дорогостоящие или редкие детали отображаются на сайте со статусом «Под заказ, доставка 15–25 дней». При оформлении клиентом такого заказа система автоматически резервирует деталь у конкретного китайского поставщика на 1688 или отправляет заявку байеру в Китае.

Парсинг позволяет поддерживать актуальность «виртуального склада»: если деталь исчезает у поставщика в Китае, она автоматически временно скрывается с сайта дилера в СНГ, предохраняя компанию от получения невыполнимых заказов.

Что я делаю для этой сферы

• [ ] Разрабатываю высокопроизводительные парсеры закрытых EPC-каталогов китайских заводов спецтехники и B2B-платформ (1688, Taobao) с обходом Cloudflare и Geetest.
• [ ] Внедряю системы интеллектуального перевода каталогов на базе больших языковых моделей (LLM) с формированием отраслевых словарей терминов.
• [ ] Создаю динамические калькуляторы себестоимости и розничных цен с учетом многофакторной логистики, веса, габаритов и таможенных пошлин.
• [ ] Проектирую и настраиваю двухстороннюю интеграцию сайтов и парсеров с конфигурациями «1С:ERP», «1С:Комплексная автоматизация» и «1С:УНФ» через брокеры очередей.
• [ ] Разрабатываю современные B2B-порталы и интернет-магазины спецтехники под ключ с интерактивными взрыв-схемами деталей и личными кабинетами для дилеров.

Готовое решение по теме

Готовы обсудить вашу задачу?

Свяжитесь со мной напрямую для бесплатной технической консультации по вашему проекту:

• Telegram: @ваш_аккаунт — оперативный ответ, обсуждение архитектуры.
• VK: vk.com/ваш_профиль — группа с кейсами и отзывами.
• Каталог услуг: chimitdorzhi.tech — подробное portfolio и прайс-лист на разработку.

Часто задаваемые вопросы (FAQ)

Как часто нужно обновлять данные парсинга запчастей?

Частота обновления зависит от критичности данных. Цены поставщиков в Китае и курсы валют необходимо обновлять ежедневно, чтобы не продавать товары в убыток. Информация о наличии (остатках) на складах в КНР должна обновляться 1–2 раза в сутки. Технические характеристики, фотографии, применимость деталей к моделям техники и графические взрыв-схемы собираются один раз при первичном наполнении каталога и могут обновляться не чаще одного раза в месяц.

Зачем использовать резидентные прокси, если есть дешевые серверные?

Китайские системы безопасности (в частности, Alibaba WAF) превентивно блокируют целые диапазоны IP-адресов облачных хостингов (AWS, DigitalOcean, Hetzner, OVH). Попытка запустить парсер через серверные прокси приведет к мгновенной блокировке или постоянному показу капчи. Резидентные прокси арендуют IP-адреса у реальных домашних интернет-провайдеров Китая, поэтому запросы от парсера неотличимы для системы защиты от переходов обычных пользователей.

Как бороться с некорректным переводом названий запчастей?

Прямой машинный перевод часто переводит технические термины нелепо (например, «масляный радиатор» может превратиться в «холодильник для масла»). Проблема решается гибридным подходом: создается приоритетный локальный глоссарий (база соответствий терминов), который наполняется вручную техническими специалистами. Для нетипичных фраз используется API современных LLM с четким системным промптом, предписывающим осуществлять профессиональный инженерный перевод деталей спецтехники.

Что делать, если китайский завод заблокировал аккаунт парсера?

Для парсинга официальных EPC-каталогов заводов требуются дилерские учетные записи. Чтобы свести к минимуму риск блокировки аккаунтов, необходимо строго лимитировать количество запросов в единицу времени, имитировать движения мыши и клики реального человека (через API Playwright), парсить в часы минимальной нагрузки (ночью по китайскому времени) и распределять запросы по пулу из 5–10 аккаунтов, постоянно ротируя их.

Можно ли парсить интерактивные схемы узлов спецтехники?

Да, это возможно. Большинство современных EPC-каталогов выводят взрыв-схемы в формате векторной графики SVG или интерактивного HTML5 Canvas. Парсер считывает XML-структуру SVG-файла, извлекает координаты интерактивных точек (hotspots), к которым привязаны номера позиций на чертеже, сопоставляет их с текстовой таблицей спецификации и воссоздает кликабельную интерактивную схему на вашем сайте.

Каковы системные требования к серверу для парсинга миллиона товаров?

Поскольку для обхода защит используется Playwright/Chromium, процессы потребляют значительный объем оперативной памяти (в среднем 120–180 МБ на одну вкладку браузера). Для стабильного многопоточного парсинга рекомендуется сервер со следующими характеристиками: 8–16 ядер CPU, 32 ГБ RAM и быстрый SSD NVMe-накопитель. Для хранения сырых результатов парсинга используется СУБД PostgreSQL, а для управления очередями задач и кэширования — Redis.

Пошаговый план внедрения на 30 дней

Неделя 1: Аналитика, подготовка инфраструктуры и маскировка парсеров

• [ ] Анализ верстки и сетевых запросов целевых сайтов-источников (1688, дилерские порталы заводов).
• [ ] Развертывание виртуального сервера (VDS) и подключение пула китайских резидентных прокси.
• [ ] Написание базового скелета парсера на TypeScript и Playwright с интеграцией плагинов маскировки (Stealth).
• [ ] Проектирование архитектуры базы данных PostgreSQL для хранения сырых и обработанных данных каталога.
• [ ] Проведение первых успешных тестов сбора данных с обходом базовых блокировок.

Неделя 2: Разработка парсера, модулей очистки и перевода данных

• [ ] Написание парсеров для сбора структуры категорий, карточек товаров, цен, веса и медиа-файлов.
• [ ] Интеграция API сервиса решения Geetest/Slider капч (CapSolver или 2Captcha).
• [ ] Создание базы данных словаря перевода (Translation Mapping) и наполнение его стартовыми 2000 терминами.
• [ ] Разработка модуля нормализации OEM-номеров и удаления небуквенных символов.
• [ ] Запуск пилотного парсинга тестовой категории (до 10 000 товаров) с автоматическим переводом.

Неделя 3: Финансовые калькуляторы и интеграция с 1С

• [ ] Программирование модуля расчета цен (калькулятор с логистикой, пошлинами, упаковкой и прогрессивной наценкой).
• [ ] Разработка HTTP-сервисов (API) на стороне 1С для приема номенклатуры от парсера.
• [ ] Настройка очереди сообщений (BullMQ/RabbitMQ) для плавной отправки данных в 1С без перегрузки СУБД.
• [ ] Тестирование создания карточек товаров и привязки цен поставщиков в 1С.
• [ ] Настройка выгрузки остатков и цен из 1С на сайт.

Неделя 4: Настройка интерфейса сайта, импорт данных и запуск системы

• [ ] Развертывание каталога на сайте с поддержкой больших объемов данных (оптимизация базы данных сайта под 500 000+ товаров).
• [ ] Реализация быстрого поиска по OEM-номерам на фронтенде сайта с учетом нормализации и базы кросс-кодов.
• [ ] Интеграция кликабельных интерактивных взрыв-схем в карточках товаров.
• [ ] Проведение финального нагрузочного тестирования базы данных сайта и API.
• [ ] Настройка планировщика (Cron) для регулярного обновления цен и остатков, запуск проекта в промышленную эксплуатацию.