一篇比较AsyncAPI与CloudEvents的文章，很不错，原文连接：https://www.asyncapi.com/blog/asyncapi-cloud-events/
I’ve been receiving the same question for a long time now: Should I use CloudEvents or AsyncAPI? — And my response has always been the same: it depends!
There is the belief by many people that AsyncAPI and CloudEvents are competing for the same thing. This can’t be less true, and I’d like to explain you why. Read on!
What is CloudEvents?
From cloudevents.io:
Enter CloudEvents, a specification for describing event data in a common way. CloudEvents seeks to ease event declaration and delivery across services, platforms and beyond!
The purpose of CloudEvents is to establish a common format for event data description. And it makes a lot of sense when you realize they are part of the CNCF’s Serverless Working Group.
If you are doing serverless or FaaS (Function as a Service), then CloudEvents is your best friend because the event is the only information you will have in your function during runtime. No topics or channels, no servers, no subscribers. Just the event and some extra information you may need to make your function work.
CloudEvents is focused on the event and defines an envelope for your application’s data. See an example from their repo:
{ "specversion" : "0.2", "type" : "com.github.pull.create", "source" : "https://github.com/cloudevents/spec/pull/123", "id" : "A234-1234-1234", "time" : "2018-04-05T17:31:00Z", "comexampleextension1" : "value", "comexampleextension2" : { "othervalue": 5 }, "contenttype" : "text/xml", "data" : "<much wow=\"xml\"/>" }Here your event is actually <much wow=\"xml\"/> and the rest is meta information about your event. This envelope is what CloudEvents defines with the purpose of making event declaration reusable across services and platforms.
What is AsyncAPI?From the AsyncAPI repo:
Create machine-readable definitions of your event-driven APIs.
The purpose of AsyncAPI is to provide a way for you to define how your event-driven applications (or APIs) communicate with the rest of the world. AsyncAPI is focused on the application and the channels it uses to communicate. Similar to what OpenAPI and RAML do for REST APIs. Unlike CloudEvents —who focuses on the message— AsyncAPI does not impose how your event must look like but, instead, allows you to strictly define its shape. See an example:
asyncapi: 2.0.0-rc1 id: urn:com.asyncapi.examples.user info: title: User service version: 1.6.3 channels: user/signedup: publish: message: payload: type: object properties: fullName: type: string email: type: string format: emailLooking at the example above, one can rapidly say this is the AsyncAPI definition of a User service, which its API version is 1.6.3 and it publishes to the user/signedup channel an event that is an object containing two properties: fullName and email.
We can define the event payload but its structure is totally free and user-defined. And that’s what makes AsyncAPI so powerful! Since our event payload can be anything, it can also be a CloudEvents event.
AsyncAPI + CloudEventsLet’s see an example of the two combined:
asyncapi: 2.0.0-rc1 id: urn:com.asyncapi.examples.user info: title: User service version: 1.6.3 channels: user/signedup: publish: message: payload: type: object properties: specversion: type: string enum: [‘0.2‘] type: type: string example: com.github.pull.create source: type: string format: uri example: urn:com.asyncapi.examples.user id: type: string example: ‘A234-1234-1234‘ time: type: string format: date-time example: 2018-04-05T17:31:00Z contenttype: type: string example: ‘application/json‘ data: type: object properties: fullName: type: string email: type: string format: email