Инструментарий Apache ServiceComb — это набор инструментов для разработки микросервисов на основе контрактов.
Уведомление для участников: этот проект не активен из-за отсутствия поддержки. Если вас интересует этот проект, пожалуйста, свяжитесь с нами, и мы поможем вам стать участником.
Уведомление для пользователей: этот проект не активен из-за отсутствия поддержки. До тех пор, пока мы не найдем достаточно ресурсов, не используйте этот проект, если это возможно.
Извлечение контракта из кода
В приложениях, разработанных на основе модели 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.
Для пользователей, интегрирующих приложения нескольких поставщиков
Сцена: языки программирования, привычки и фреймворки различных поставщиков различаются, стандарты данных и услуг всей системы не согласованы, пользователи сталкиваются с трудностями при интеграции и управлении конечным качеством доставки.
Решение: с помощью единого определенного стандарта описания интерфейсов (контракта) используется набор инструментов для генерации микросервисного проекта на основе выбранного микросервисного фреймворка, и согласованность всей системы координируется через проверку контракта. Координация нескольких команд разработки снижает издержки коммуникации и избегает пост-хаоса.
Для пользователей, переходящих с устаревших систем на микросервисы Сцена: перед тем как можно спроектировать, построить и разработать микросервисный проект в соответствии с выбранным микросервисным фреймворком, требуется дополнительное изучение и понимание деталей микросервисного фреймворка. Для пользователей требуется отвлечение внимания от бизнес-задач. Решение: с помощью набора инструментов анализируется извлечение контракта из устаревшего приложения, а затем генерируется микросервисный проект на основе выбранного микросервисного фреймворка, что позволяет сосредоточиться на развитии бизнеса и снизить издержки обучения микросервисному фреймворку.
Требования к окружению сборки
# Получение последней версии исходного кода для 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
Конфигурация (используйте стандартную конфигурацию, если не задан <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
<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
Конфигурацияпример
<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
$ ./cli.sh codegenerate -m ServiceComb -i swagger.yaml -o ./project -p SpringMVC
codegenerate Параметры команды
$ ./cli.sh docgenerate -i swagger.yaml -o ./document
docgenerate Параметры команды
$ ./cli.sh checkstyle -r style-check-rules.yaml -f oas.yaml
или
$ ./cli.sh cs -r style-check-rules.yaml -f oas.yaml
checkstyle Параметры команды
$ ./cli.sh checkcompatibility left-oas.yaml right-oas.yaml
или
$ ./cli.sh cc left-oas.yaml right-oas.yaml
checkcompatibility Параметры команды
См. правила проверки совместимости
Некоторые примеры использования плагина можно найти здесь
PR: Pull request
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Комментарии ( 0 )