How does the database come with the event source? I read the CQRS pattern, but can't figure out how the CQRS pattern is related to the event store and event objects?
The "Query" part of CQRS tells you how to create an event projection that is applicable in some kind of "limited context" where the database can be used as a means to save this projection. The "Team" part allows you to isolate the data transformation logic and separate it from the "query" and "persistence" aspects of your application. To just say, you simply project the flow of events into the database in different ways (the projection can also be relational), depending on the task. In this model, the “request” and “command” have their own way of projecting and storing event data optimized for the needs of this particular part of the application. The same data will be stored in events and in projections, which will allow to achieve simplicity and free communication between subdomains (limited contexts, microservices).
Can any body provide me with a complete picture, and many operations take place with all the players to collect: CQRS template, event source (including event storage module) and, finally, various microservices?
Have you seen how Greg Young tried to provide the simplest possible implementation ? If you're still confused, consider creating a more specific question about his example.
Should a system consisting of many microservices have one event store or each microservice has its own? or are both possible?
Usually this is one common event store, but there can definitely be some exceptions, extreme cases when you really need several stores for different microservices here and there. It all depends on the business case. If you are not sure, most likely you just need one repository.
same question about CQRS. Is this template implemented in all microservices or in only one?
It can be implemented in most high-performance microservices. It all depends on how complex your implementation is when you introduce CQRS into it. If it gets easier - why not implement it everywhere? But if the people in your team are becoming more and more confused by the need to have a clearer synchronization between teams and parts of the requests - perhaps cqrs is too much for you. It all depends on your team, on your domain ... Unfortunately, there is no single simple answer.
Finally, in the case of using the microservice architecture, is it necessary to have only one database or should each microservice have its own?
If the same microservices use the same tables - this is usually considered antipattern, since it increases adhesion, the system becomes more fragile. You can still use the same database, but there should not be shared tables. In addition, tables from one microservice should not have FK for tables in another microservice. For the same reason, reduce traction.
PS: do not ask rude questions, as it will be difficult to get an answer from people. A few smaller, more specific questions will be more likely to get an answer.