Über die Contract-First-Entwicklung (API First) von Java Chassis 3

Das Open-Source-Community-Team China machte seine erste Live-Übertragung und erzählte im Namen des Teilens die Geschichte hinter der Open-Source-Community China.“

Dieser Artikel wurde von der Huawei Cloud Community „ Java Chassis 3 Technology Decryption: Contract First (API First) Development “ geteilt, Autor: liubao68.

Bei der Contract-First-Entwicklung (API First) geht es darum, das API-Design zur Aufgabe mit erster Priorität im Anwendungsentwicklungsprozess zu machen. Die vertragsorientierte Entwicklung hat mit der Entwicklung des Web-Services-Konzepts weiterhin Aufmerksamkeit erhalten, insbesondere nach dem Aufkommen der Microservice-Architektur ist das API-Design zu einem Schlüsselfaktor geworden, der sich auf Themen wie Funktionsöffnung und Leistungsoptimierung auswirkt. Zu den gängigen Frameworks und Mustern für die Contract-First-Entwicklung gehören die folgenden:

Mit der Web-Services-Technologie können Designer zunächst WSDL schreiben, um WEB-Service-Inhalte zu beschreiben, und diese dann mit Tools kombinieren, um Code zu generieren. WSDL kann verteilt werden und verschiedene Sprachen können mit WSDL kombiniert werden, um Clients zu generieren.
Mit der gRPC-Technologie können Designer zunächst IDL schreiben, um RPC-Dienstinhalte zu beschreiben, und diese dann mit Tools kombinieren, um Code zu generieren. gRPC löst hauptsächlich Anrufe zwischen Diensten.
Mit Spring Boot können Entwickler mit dem Swagger-Tool zunächst die Open API-Schnittstelle schreiben und dann über das Tool RESTFul-Servercode generieren.

Diese Technologien erfordern alle, dass Designer eine sprachunabhängige Beschreibungssprache (WSDL, IDL, Swagger usw.) beherrschen und mithilfe von Tools sprachspezifischen Code generieren. Auch die von ihnen unterstützten Anwendungsszenarien sind unterschiedlich. Web Service eignet sich für externe WEB-Dienste und gRPC eignet sich für interne RPC-Dienste. Die vertragsorientierte Entwicklung von Java Chassis bietet die folgenden Verbesserungen:

Ermöglicht die direkte Verwendung der Java-Sprache zum Definieren von Serviceschnittstellen, ohne dass Designer eine neue Beschreibungssprache beherrschen müssen.
Definieren Sie gleichzeitig die Webservice-Schnittstelle und die interne RPC-Schnittstelle.

Wie Spring Boot ist die sprachunabhängige Beschreibungssprache von Java Chassis immer noch eine offene API. Durch die offene API kann sie die Anforderungen der sprachübergreifenden und Dienstverteilung erfüllen.

Entwicklungsprozess der Vertragspriorität

Die vertragsorientierte Entwicklung kann den gesamten Prozess der Softwareentwicklung wie Design, Entwicklung, Tests, Bereitstellung, Betrieb und Wartung abdecken. Durch Verträge kann eine parallele Arbeit in verschiedenen Verknüpfungen erreicht werden, wodurch die Entwicklungseffizienz verbessert wird. Ein einfacher Vertragsentwicklungsprozess sieht wie folgt aus:

Der folgende Code veranschaulicht kurz den Prozess der Definition eines Vertrags mithilfe der Java-Semantik und der Implementierung von Anbietern und Verbrauchern.

Servicevertrag definieren

@RequestMapping(path = "/provider")
öffentliche Schnittstelle ProviderService {
  @GetMapping("/sayHello")
  String sayHello(@RequestParam("name") String name);
}

Anbieter definieren

@RestSchema(schemaId = "ProviderController", schemaInterface = ProviderService.class)
Die öffentliche Klasse ProviderController implementiert ProviderService {
  @Override
  öffentlicher String sayHello(String name) {
    return „Hallo“ + Name;
  }
}

Definieren Sie Verbraucher

@Aufbau
öffentliche Klasse ProviderServiceConfiguration {
  @Bohne
  öffentlicher ProviderService ProviderService() {
    return Invoker.createProxy("provider", "ProviderController", ProviderService.class);
  }
}

Verwenden Sie RPC, um auf den Anbieter zuzugreifen.

@RestSchema(schemaId = "ConsumerController", schemaInterface = ConsumerService.class)
Die öffentliche Klasse ConsumerController implementiert ConsumerService {
  privater AnbieterDienstleisterService;

  @Autowired
  public void setProviderService(ProviderServiceProviderService) {
    this.providerService = ProviderService;
  }

  @Override
  öffentlicher String sayHello(String name) {
    return anbieterService.sayHello(name);
  }
}

Serviceverteilung und Webservice-Zugriff

Die Dienstdefinition des Anbieters generiert die folgenden Open API-Informationen

offenes Feuer: 3.0.1
die Info:
  Titel: Swagger-Definition für org.apache.servicecomb.samples.api.ProviderService
  Version: 1.0.0
Server:
- URL: /provider
Pfade:
  /sag Hallo:
    erhalten:
      operationId: sayHello
      Parameter:
      - Name Name
        in: Abfrage
        erforderlich: wahr
        Schema:
          Typ: Zeichenfolge
      Antworten:
        „200“:
          Beschreibung: Antwort von 200
          Inhalt:
            application/json:
              Schema:
                Typ: Zeichenfolge
            Anwendung/Protobuf:
              Schema:
                Typ: Zeichenfolge
            Text/einfach:
              Schema:
                Typ: Zeichenfolge
Komponenten: {}

Diese Informationen können beispielsweise für den Zugriff auf WEB-Dienste verwendet werden

GET /providers/sayHello?name=World

HTTP-Anfrage für den Zugriff. Für andere Frameworks oder Sprachen können Sie auch Open API verwenden, um entsprechenden Code für den Zugriff zu generieren.

Service-Governance

Die Service-Governance ist so konzipiert, dass sie unabhängig vom Entwicklungsprozess ist. Durch die Kombination von Open API und Service-Governance-Regelbeschreibungssprache ist es möglich, Service-Governance für APIs zu konfigurieren.

Servicekamm:
  matchGroup:
    halloOperation: |
      Streichhölzer:
        - apiPath:
            Präfix: „/provider/sayHello“
  rateLimiting:
    ## Der aktuelle Begrenzer erlaubt 100 Anfragen alle 10 Millisekunden. Wenn eine Anfrage länger als 1000 Millisekunden nicht empfangen wird,
    ## Die Erlaubnis wird verweigert
    halloOperation: |
      Rate: 100
      limitRefreshPeriod: 10
      TimeoutDauer: 1000

Die oben genannten Regeln schränken den Fluss von API-Schnittstellen ein.

Andere Aspekte der Covenant-First-Entwicklung

Was das Testen angeht, kann automatisierter Testcode durch Verträge generiert werden, um API-Tests abzudecken. Im Hinblick auf die Bereitstellung und Implementierung können Open-API-Informationen in das Gateway importiert werden, um die Offenlegung, Authentifizierung und Abrechnung von API-Funktionen zu ermöglichen. Darüber hinaus können Verträge auch in verschiedenen Aspekten wie der Dokumentenerstellung und Anwendungsüberwachungsstatistiken verwendet werden.

Zusammenfassen

Java Chassis basiert auf der Schnittstellendefinition der JAVA-Sprache, die die SDK-Verteilung sowohl der Muttersprache als auch der plattformunabhängigen Beschreibungssprache erfüllen kann und keine Tools zum Generieren von zusätzlichem Laufcode erfordert, was einen einheitlichen und konsistenten Ansatz bietet für externe Serviceentwicklung und interne Serviceentwicklungserfahrung. Die vertragsorientierte Entwicklung ist eine sehr effiziente Prozessmethode für die serviceorientierte/mikroserviceorientierte Entwicklung. Java Chassis bietet eine gute Toolunterstützung zur Unterstützung der vertragsorientierten Entwicklung.

Klicken Sie hier, um zu folgen und so schnell wie möglich mehr über die neuen Technologien von Huawei Cloud zu erfahren~