Skip to content

Latest commit

 

History

History
207 lines (132 loc) · 9.52 KB

欧拉消息中心使用指南.md

File metadata and controls

207 lines (132 loc) · 9.52 KB
Raw

欧拉消息中心使用指南

背景：

**现状：**欧拉社区的对接的系统增加，使得信息极大丰富，但缺乏统一的治理和分发渠道，由于存在大量的异构系统，当前存在消息泛滥，格式混乱，分发渠道不归一等问题

**目标：**社区服务到服务间支持统一格式的消息分发和订阅，支持开发者/用户精细化订阅社区的消息，精确到具体的服务和事件

当前现状：

已支持eur构建消息，gitee事件消息的精细化订阅

工作原理

消息采集服务对接不同上游系统，采集原始事件，经过消息清洗转换为cloudevents规范的标准消息格式，根据用户在消息中心页面输入的订阅和推送

配置将消息推送到不同渠道

架构总览

[消息中心架构](/Users/shishupei/Downloads/消息中心架构.png

![image-20240627105849039](/Users/shishupei/Library/Application Support/typora-user-images/image-20240627105849039.png)

消息中心服务整体架构如上图所示，所有服务均采用golang语言开发

gitee-robot-access

欧拉社区统一配置gitee webhook的服务，非消息中心服务，详见

docs/robot-access.md · yangwei9999/robot-operating-guide - Gitee.com

message-collect-githook

消息中心gitee事件采集服务，通过配置endpoint端点到方式接收gitee-robot-access采集到的webhook事件（配置方式docs/robot-access.md · yangwei9999/robot-operating-guide - Gitee.com，将事件消息发送到kafka队列

支持的消息类型为：

  • pull request事件
  • 评论事件
  • push事件
  • issue事件

message-collect

消息中心eur事件采集服务，通过消费eur构建事件kafka队列的方式将采集到的eur构建事件发送到kafka对接

支持的消息类型为：

  • 构建开始事件
  • 构建结束事件

message-transfer

消息中心清洗服务，消费上面采集服务发送到kafka消息，的读数据库中的清洗映射配置，将不同来源和类型的原始消息清洗为cloudevents规范的标准消息格式，发送到kafka,并保存到数据库，标准消息格式包含以下字段：

id

  • Type: String
  • Description: Identifies the event. Producers MUST ensure that source + id is unique for each distinct event. If a duplicate event is re-sent (e.g. due to a network error) it MAY have the same id. Consumers MAY assume that Events with identical source and id are duplicates.
  • Constraints:
    • REQUIRED
    • MUST be a non-empty string
    • MUST be unique within the scope of the producer
  • Examples:
    • An event counter maintained by the producer
    • A UUID

source

  • Type: URI-reference

  • Description: Identifies the context in which an event happened. Often this will include information such as the type of the event source, the organization publishing the event or the process that produced the event. The exact syntax and semantics behind the data encoded in the URI is defined by the event producer.

    Producers MUST ensure that source + id is unique for each distinct event.

    An application MAY assign a unique source to each distinct producer, which makes it easy to produce unique IDs since no other producer will have the same source. The application MAY use UUIDs, URNs, DNS authorities or an application-specific scheme to create unique source identifiers.

    A source MAY include more than one producer. In that case the producers MUST collaborate to ensure that source + id is unique for each distinct event.

  • Constraints:

    • REQUIRED
    • MUST be a non-empty URI-reference
    • An absolute URI is RECOMMENDED

  • Examples

    • Internet-wide unique URI with a DNS authority.
    • Universally-unique URN with a UUID:
      • urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
    • Application-specific identifiers
      • /cloudevents/spec/pull/123
      • /sensors/tn-1234567/alerts
      • 1-555-123-4567

specversion

  • Type: String

  • Description: The version of the CloudEvents specification which the event uses. This enables the interpretation of the context. Compliant event producers MUST use a value of 1.0 when referring to this version of the specification.

    Currently, this attribute will only have the 'major' and 'minor' version numbers included in it. This allows for 'patch' changes to the specification to be made without changing this property's value in the serialization. Note: for 'release candidate' releases a suffix might be used for testing purposes.

  • Constraints:

    • REQUIRED
    • MUST be a non-empty string

type

  • Type: String
  • Description: This attribute contains a value describing the type of event related to the originating occurrence. Often this attribute is used for routing, observability, policy enforcement, etc. The format of this is producer defined and might include information such as the version of the type - see Versioning of CloudEvents in the Primer for more information.
  • Constraints:
    • REQUIRED
    • MUST be a non-empty string
    • SHOULD be prefixed with a reverse-DNS name. The prefixed domain dictates the organization which defines the semantics of this event type.
  • Examples
    • com.github.pull_request.opened
    • com.example.object.deleted.v2

datacontenttype

  • Type: String per RFC 2046

  • Description: Content type of data value. This attribute enables data to carry any type of content, whereby format and encoding might differ from that of the chosen event format. For example, an event rendered using the JSON envelope format might carry an XML payload in data, and the consumer is informed by this attribute being set to "application/xml". The rules for how data content is rendered for different datacontenttype values are defined in the event format specifications; for example, the JSON event format defines the relationship in section 3.1.

    For some binary mode protocol bindings, this field is directly mapped to the respective protocol's content-type metadata property. Normative rules for the binary mode and the content-type metadata mapping can be found in the respective protocol.

    In some event formats the datacontenttype attribute MAY be omitted. For example, if a JSON format event has no datacontenttype attribute, then it is implied that the data is a JSON value conforming to the "application/json" media type. In other words: a JSON-format event with no datacontenttype is exactly equivalent to one with datacontenttype="application/json".

    When translating an event message with no datacontenttype attribute to a different format or protocol binding, the target datacontenttype SHOULD be set explicitly to the implied datacontenttype of the source.

  • Constraints:

    • OPTIONAL
    • If present, MUST adhere to the format specified in RFC 2046

  • For Media Type examples see IANA Media Types

dataschema

  • Type: URI
  • Description: Identifies the schema that data adheres to. Incompatible changes to the schema SHOULD be reflected by a different URI. See Versioning of CloudEvents in the Primer for more information.
  • Constraints:
    • OPTIONAL
    • If present, MUST be a non-empty URI

time

  • Type: Timestamp
  • Description: Timestamp of when the occurrence happened. If the time of the occurrence cannot be determined then this attribute MAY be set to some other time (such as the current time) by the CloudEvents producer, however all producers for the same source MUST be consistent in this respect. In other words, either they all use the actual time of the occurrence or they all use the same algorithm to determine the value used.
  • Constraints:
    • OPTIONAL
    • If present, MUST adhere to the format specified in RFC 3339

user

  • Type: string
  • Description:产生事件的用户名
  • Constraints:
    • OPTIONAL
    • If present, 必须是存在于社区用户

sourceurl

  • Type: URI-reference
  • Description:产生消息的用户名
  • Constraints:
    • OPTIONAL
    • If present, 必须是存在于社区用户

summary

  • Type: string
  • Description:消息摘要
  • Constraints:
    • OPTIONAL

title

  • Type: string
  • Description:消息标题
  • Constraints:
    • OPTIONAL

message-push

消息中心推送服务，接收消息清洗服务到kafka消息，读取数据库中的订阅映射配置，将消息推送到不同的下游，当前支持短信，邮件，站内信

message-manager-website

消息服务前端，测试地址：message-center.test.osinfra.cn/config

message-manager

消息服务后端，供前端调用，当前包含以下功能

  • 站内信列表
  • 接收人管理
  • 消息接收设置

api文档：

message-manager/docs/swagger.json at hrz_dev · opensourceways/message-manager (github.com)