Источник событий с магазином событий и ORM - PullRequest
0 голосов
/ 05 февраля 2019

Я создаю службу аутентификации с помощью Django для архитектуры микроуслуг.это скорее эксперимент, чем реализация в реальном мире, чтобы лучше понять источник событий.

Я понимаю, что у Django есть ORM, который очень связан с фреймворком, и использование Flask было бы более простым подходом, но я пытаюсьчтобы найти способ обойти это.

Вариант использования очень прост.Пользователь регистрируется и получает электронное письмо для активации своей учетной записи.пользователь снова активируется. Я стреляю по электронной почте, чтобы сообщить ему, что его учетная запись активна.

Насколько я понимаю, в системе источников событий.события запускаются и сохраняются, и мы можем получить последнее состояние и сохранить его, например, в базе данных.в моем случае это был бы Postgres, использующий Django ORM.

Я публикую событие в kafka, используя сигналы в django.pre_save () сигналы.и тогда модель сохранит объект.

В случае обновления, которое еще не реализовано ниже.Я бы опубликовал только обновленные поля.и обновите объект в Django.

Кто-нибудь видит какие-либо предостережения с таким подходом или было бы лучше реализовать это в методе сохранения модели?

Я хотел бы услышать ваши отзывына это.

# app/services.py

class KafkaService:

    def __init__(self):
        try:
            self.producer = KafkaProducer(bootstrap_servers=settings.KAFKA_BROKERS,
                                          value_serializer=lambda m: json.dumps(m).encode('ascii'))
        except KafkaError as ke:
            logger.exception(f"Something went wrong creating a kafka producer: {ke}")
            self.producer = None
        except Exception as ex:
            logger.exception(f"Something went wrong creating a kafka producer: {ex}")
            self.producer = None

    def publish(self, topic, key, data):
        if not self.producer:
            logger.error(f"Kafka Producer could not establish a connection")
            pass
        try:
            self.producer.send(topic, key=bytes(key, encoding='utf-8'), value=data)
            self.producer.flush()
            logger.info("Message has been published to Kafka")
        except Exception as ex:
            logger.info(f"Errored while publishing to Kafka: {ex}")
# app/events.py

class UserEvent:

    def __init__(self, event_store):  # event store here is Kafka
        """ A user event class which is an injectable. I am using here.
        I need a key for kafka to place the correct event in the correct partition.

        :parameters:
            - event_store: a class form example :class:`KafkaService` which publishes data
        """
        self.event_store = event_store

    def user_created(self, email, data):
        """ Publish an event to the event store when a user is created

        :param email: string
        :param data: string - json
        """
        self.event_store.publish('user-created', email, data)

    def user_activated(self, email, data):
        """ Publish an event to the event store when a user is activated """
        self.event_store.publish('user-activated', email, data)
# app/signals.py

kafka_service = KafkaService()

user_event = UserEvent(kafka_service)

def user_added_event(sender, instance, created, **kwargs):
    if created:
        from users.api.v1.serializers import UserSerializer  # Avoid (Apps Not Read)

        value = UserSerializer(instance).data
        user_event.user_created(instance.email, value)

    else:
        logger.info("User Updated")

1 Ответ

0 голосов
/ 05 февраля 2019

Кто-нибудь видит какие-либо предостережения с этим подходом или было бы лучше реализовать это в методе сохранения модели?

Обычный дизайн разделяет модель предметной области (иначе бизнес-логика)) из соображений постоянства.

Если последовательность событий является вашим источником истины, из этого следуют две вещи: во-первых, вы хотите быть уверены, что вы успешно сохраните ваших событий до того, как они опубликовано .Во-вторых, вы хотите быть уверены, что ваша семантика записи «выигрывает первый писатель».

Если вы понимаете это правильно, и все понимают, что модель в базе данных может быть «позади» событий в хранилище событийсо временем, тогда вы в хорошей форме.

В конечном итоге непротиворечивые системы усложняют ожидания «читайте сами».Так что у вас там может быть дополнительная работа.

...