Advice on managing microservice complexity

Hello and I hope you're feeling well.

I'm a fairly novice engineer and my experience with attempting to build microservices has been plagued with the following problems:

1. Request/Response for service communication with a 'n' number of services has often led to a huge ball of a system with n:n message connections.
2. Introducing an event driven style meant adding a layer of indirection (message queue, event log), complexity in logic in terms of aggregation and sequencing, and the emergent behavior of the system becoming harder to "learn" and understand.
3. A gradual loss of abstraction as new business requirements often lead to having to share/fetch state between services AND a gradual muddling of initially defined service responsibilities.

Any advice would be appreciated but I do have more specific questions if that may help:

1. How to design service boundaries and responsibilities that will endure new business requirements?
2. In a request/response communication style, how does one avoid the "distributed monolith" conundrum?