Should services have "events" in a micro service architecture?

I was looking for some kind of best practice about something: In our application, we have a LOT of services, and there is a lot of interaction between them.

Some services would need to be able to notify that there has been change on their ends. Our intuitive developer approach would be to just an event in it and register on it. But I've the feeling that this is something that is kind of "dirty".

The service for me was something that was "offered" to the one requesting it, and was, but we should not be aware of the lifecycle of the service(nor should the service garbage collection of the service be prevent because somebody is still registered.

My alternatives are:

• ask to the service an object, on which I will register for event--> I don't find this much cleaner
• Provide to the service an object implementing a CallBack interface, and have the service calling the callback instead of notifying events.
• ???

What do you think is the best practice on this? What would be the cleanest approach?