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

OSCHINA-MIRROR/apache-ServiceComb-Toolkit

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

Инструментарий | Китайский Статус сборкиСтатус охватаЛицензияСтатус Quality Gate Gitter

Инструментарий Apache ServiceComb — это набор инструментов для разработки микросервисов на основе контрактов.

Уведомление для участников: этот проект не активен из-за отсутствия поддержки. Если вас интересует этот проект, пожалуйста, свяжитесь с нами, и мы поможем вам стать участником.

Уведомление для пользователей: этот проект не активен из-за отсутствия поддержки. До тех пор, пока мы не найдем достаточно ресурсов, не используйте этот проект, если это возможно.

1 Введение

1.1 Концепции

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

1.2 Функции

  • Извлечение контракта из кода

    В приложениях, разработанных на основе модели SpringMVC/POJO/JAX-RS, одноклик-генерация файлов контрактов услуг, соответствующих спецификации OpenAPI.

  • Генерация микросервисного проекта на основе контракта

    Введите контракт услуг, соответствующий спецификации OpenAPI, одноклик-генерация микросервисного проекта с использованием ServiceComb/SpringCloud/Swagger как базового микросервисного фреймворка и SpringMVC/POJO/JAX-RS или SpringBoot как модели программирования.

  • Проверка согласованности контракта услуг и кода

    Проверка соответствия реального выполнения приложения (например, данных и API услуг) описанию контракта услуг. Проверка стиля и проверка совместимости контрактов

    Проверка стиля проверяет, соответствует ли контракт [OAS 3.0.2 спецификации] [openapi-3.0.2] и пользовательским правилам; проверка совместимости проверяет, совместим ли новый OAS-спецификационный контракт с старым.

  • Документация по генерации контрактов/кода

    Введите контракт, соответствующий спецификации OpenAPI, для однокнопочного создания документа в формате HTML.

  • Список задач

    • Поддержка плагинов для Gradle, Eclipse и IntelliJ.

    • Поддержка генерации популярных форматов документов, таких как Word и PDF.

    • Поддержка инкрементной генерации кода контракта. * Предоставление возможности как услуги.

    • Автоматическое/полуавтоматическое тестирование на стороне сервера.

    • Проверка соответствия интерфейсов.

    • Поддержка генерации каркаса микросервисов, содержащего фрагменты кода, которые подключаются к общим базам данных, таковым как MySQL/Redis.

1.3 Пригодные сценарии

  • Для пользователей, интегрирующих приложения нескольких поставщиков

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

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

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

2 Проектирование

2.1 Архитектура

image

2.2 Принцип работы

image

3 Быстрый старт

3.1 Сборка инструмента и плагинов из исходного кода

Требования к окружению сборки

# Получение последней версии исходного кода для toolkit из github
$ git clone https://github.com/apache/servicecomb-toolkit.git
$ cd toolkit
```# Сборка пакета

$ mvn clean install

### 3.2 Использование плагина toolkit-maven-plugin
#### 3.2.1 Настройка
Настроено в файле pom Maven-проекта
```xml
<plugin>
    <groupId>org.apache.servicecomb.toolkit</groupId>
    <artifactId>toolkit-maven-plugin</artifactId>
    <version>0.3.0-SNAPSHOT</version>
    <configuration>
        <!-- Установите значение на 'code', чтобы разрешить текущий проект. Установите значение на 'contract', чтобы разрешить файл контракта для указанного пути. Если значение не установлено, по умолчанию используется 'code' -->
        <sourceType>code</sourceType>
        <!-- Тип файла контракта, который будет сгенерирован. Если значение не установлено, по умолчанию используется 'yaml' -->
        <contractFileType>yaml</contractFileType>
        <!-- Тип сгенерированного документа. Если значение не установлено, по умолчанию используется 'html' -->
        <documentType>html</documentType>
        <!-- Корневая директория для сохранения проекта микросервиса, файла контракта и документа. Если значение не установлено, по умолчанию используется 'target' в директории, где выполняется команда -->
        <outputDirectory>. /target</outputDirectory>
        <!-- Путь к файлу контракта ввода. Действителен, когда sourceType установлен на 'contract', обязательно для установки -->
        <contractLocation>. /contract</contractLocation>
        <!-- Путь к проверенному файлу контракта. Действителен, когда sourceType установлен на 'contract', обязательно для установки -->
        <sourceContractPath>. /target/contract</sourceContractPath>
        <!-- Путь к образцу файла контракта, обязательно для установки -->
        <destinationContractPath>. /target/contract</destinationContractPath>
```/contract</destinationContractPath>
         <!-- Настройка сгенерированного проекта микросервиса -->
         <service>
             <!-- Тип микросервиса, который может быть сгенерирован 'provider/consumer/all', по умолчанию используется 'all' -->
             <serviceType>all</serviceType>
             <!-- Групповой идентификатор проекта микросервиса 'groupid', необязательный, по умолчанию используется 'domain.orgnization.project' -->
             <groupId>domain.orgnization.project</groupId>
             <!-- Идентификатор артефакта проекта микросервиса 'artifactId', необязательный, по умолчанию используется 'sample' -->
             <artifactId>sample</artifactId>
             <!-- Версия артефакта проекта микросервиса 'artifactVersion', необязательный, по умолчанию используется '0.1.0-SNAPSHOT' -->
             <artifactVersion>0.1.0-SNAPSHOT</artifactVersion>
             <!-- Пакетный идентификатор проекта микросервиса 'packageName', необязательный, по умолчанию используется 'domain.orgnization.project.sample' -->
             <packageName>domain.orgnization.project.sample</packageName>
         </service>
         <!-- Укажите дополнительные значения атрибутов, которые могут быть использованы шаблоном mustache. Используется только при цели плагина generate -->
          <additionalProperties>
              <prop1>value</prop1>
              <prop2>value</prop2>
              . . .
              <propN>value</propN>
          </additionalProperties>
      </configuration>
  </plugin>
  ```#### 3. 2. 2 Команда
 ```shell
 # Генерация контракта, документа и проекта микросервиса
 mvn toolkit:generate ```# Проверка согласованности кода и контракта
mvn toolkit:verify

3.2.2.1 Извлечение проекта микросервиса, файла контракта OpenAPI и документа из кода

Конфигурация (используйте стандартную конфигурацию, если не задан <configuration>)

пример

<plugin>
    <groupId>org.apache.servicecomb.toolkit</groupId>
    <artifactId>toolkit-maven-plugin</artifactId>
    <version>0.3.0-SNAPSHOT</version>
    <configuration>
        <!-- Установите значение 'code', чтобы разрешить текущий проект. Установите значение 'contract', чтобы разрешить файл контракта для указанного пути. Если не задано, стандартное значение — 'code' -->
        <sourceType>code</sourceType>
        <!-- Корневая директория для сохранения файла контракта и документа. Если не задана, стандартное значение — 'target' в директории, где выполняется команда -->
        <outputDirectory>./target</outputDirectory>
        <!-- Конфигурация генерируемого проекта микросервиса -->
        <service>
            <!-- Тип микросервиса, может быть 'provider/consumer/all', стандартное значение — 'all' -->
            <serviceType>all</serviceType>
        </service>
    </configuration>
</plugin>

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

mvn toolkit:generate

При генерации контрактов из кода поддерживается идентификация RESTful интерфейсов, написанных следующими аннотациями (уровень класса):

RestController, RestSchema, RpcSchema, RequestMapping

При генерации контрактов из кода методы доступа RESTful интерфейсов должны быть заданы как public

3.2.2.2 Генерация проекта микросервиса и документа из контрактаКонфигурация (используйте стандартную конфигурацию, если не задан <configuration>) Пример

<plugin>
    <groupId>org.apache.servicecomb.toolkit</groupId>
    <artifactId>toolkit-maven-plugin</artifactId>
    <version>0.3.0-SNAPSHOT</version>
    <configuration>
        <!-- Установите значение на 'code' для разрешения текущего проекта. Установите значение на 'contract' для разрешения файла контракта для указанного пути. Если значение не установлено, по умолчанию используется 'code' -->
        <sourceType>contract</sourceType>
        <!-- Корневая директория для сохранения файла контракта и документа. Если значение не установлено, по умолчанию используется 'target' в директории, где выполняется команда -->
        <outputDirectory>./target</outputDirectory>
        <!-- Путь к файлу контракта. Действует, если sourceType установлен на 'contract', обязательно для установки -->
        <contractLocation>./contract</contractLocation>
        <!-- Конфигурация сгенерированного проекта микросервиса -->
        <service>
            <!-- Тип микросервиса, может быть сгенерирован 'provider/consumer/all', по умолчанию используется 'all' -->
            <serviceType>provider</serviceType>
        </service>
    </configuration>
</plugin>
``` Запустить в командной строке
```shell
mvn toolkit:generate

3.2.2.3 Проверка контракта

Конфигурацияпример

<plugin>
    <groupId>org.apache.servicecomb.toolkit</groupId>
    <artifactId>toolkit-maven-plugin</artifactId>
    <version>0.3.0-SNAPSHOT</version>
    <configuration>
        <!-- Set the value to 'code' to allow the current project. Set the value to 'contract' to allow the contract file for the specified path. If not set, the default is 'code' -->
        <sourceType>code</sourceType>
        <!-- Example path to the contract file, must be set -->
        <destinationContractPath>./contract</destinationContractPath>
    </configuration>
</plugin>
```Запустить в командной строке
```shell
mvn toolkit:verify
```### 3.3 Использование toolkit cli
* Если вы используете официальную версию выпуска (>=0.2.0), вы можете использовать скрипты напрямую после распаковки двоичного пакета.
  * В окружении Linux и Mac, пожалуйста, используйте cli.sh
  * В окружении Windows, пожалуйста, используйте cli.cmd
* Если вы собираете из исходного кода, вы можете поместить `cli/scripts/cli.*` в ту же директорию, что и `cli/target/bin/toolkit-cli-{version}.jar`, а затем выбрать разные скрипты в зависимости от различных окружений. Все примеры ниже вводятся через cli.sh для Linux-среды.
```shell
$ ./cli.sh help

3.3.1 Проект микросервиса для генерации контрактов сервиса

$ ./cli.sh codegenerate -m ServiceComb -i swagger.yaml -o ./project -p SpringMVC

codegenerate Параметры команды

  • -m, --microservice-framework. Указывает микросервисную платформу, поддерживает ServiceComb. Пример: -m ServiceComb
  • -p, --programming-model. Указывает модель программирования, опционально JAX-RS, POJO, SpringMVC, SpringBoot. Пример: -p SpringMvc
  • -i, --input. Указывает файлы контракта, соответствующие спецификациям OpenAPI, поддерживаются форматы yaml и json, а также указание локальных и сетевых файлов. Пример: -i http://petstore.swagger.io/v2/swagger.json
  • -o, --output. Путь вывода сгенерированного кода проекта. Пример: -o ./project
  • --group-id. Указывает group id сгенерированного проекта. Пример: --group-id com.demo
  • --artifact-id. Указывает artifact id сгенерированного проекта. Пример: --artifact-id springmvc-example
  • --artifact-version. Указывает artifact version сгенерированного проекта. Пример: --artifact-version 1.0.0* --api-package : Указывает api-пакет сгенерированного проекта. Пример: --api-package com.demo.api
  • --model-package : Указывает model-пакет сгенерированного проекта. Пример: --model-package com.demo.model
  • -t, --service-type : Указывает тип микросервиса сгенерированного проекта. Опциональное значение может быть provider, consumer, all
    Пример: --service-type provider
  • --properties : Указывает дополнительные атрибутные значения, которые могут быть использованы шаблоном mustache
    Пример: --properties applicationId=app,providerServiceId=provider#### 3. 3. 2 Документация по генерации сервисного контракта
$ ./cli.sh docgenerate -i swagger.yaml -o ./document

docgenerate Параметры команды

  • -i, --input : Указывает файлы контракта, которые соответствуют спецификации OpenAPI, поддерживаются форматы yaml и json, а также поддерживается указание локальных и сетевых файлов. Пример: -i http://petstore.swagger.io/v2/swagger.json
  • -o, --output : Путь для вывода документа. Пример: -o ./document
  • -f, --format : Указывает формат выходного документа, в настоящее время поддерживаются swagger-ui. Пример: -f swagger-ui#### 3.3.3 Проверка стиля сервисного контракта
$ ./cli.sh checkstyle -r style-check-rules.yaml -f oas.yaml
или
$ ./cli.sh cs -r style-check-rules.yaml -f oas.yaml

checkstyle Параметры команды

  • -r, --rules-file. Файл свойств правил.
  • -f, --file. Файл спецификации OpenAPI v3 в формате yaml.

См. правила проверки стиля

3.3.4 Проверка совместимости сервисного контракта

$ ./cli.sh checkcompatibility left-oas.yaml right-oas.yaml
или
$ ./cli.sh cc left-oas.yaml right-oas.yaml

checkcompatibility Параметры команды

  • <files> Два файла спецификации OpenAPI v3 в формате yaml.

См. правила проверки совместимости

3.4 Пример использования

Некоторые примеры использования плагина можно найти здесь

4 Свяжитесь с нами

5 Внесите свой вклад

PR: Pull request

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

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

Введение

Apache ServiceComb Toolkit — это набор инструментов для разработки микросервисов на основе контрактов. 1. Введение 1.1 Цель Предоставить возможность преобразования и проверки соответствия между контрактами, кодом и документацией, чтобы помочь пользователям быстро создавать основанные на контрактах решения с помощью одной кнопки. Развернуть Свернуть
Java и 5 других языков
Apache-2.0
Отмена

Обновления

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

Участники

все

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

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