Microservices and Scrum

What's wrong with how they currently have things structured? 

How do you apply Scrum working on a product with the micro-services architecture?

In which way, do you think, this makes the application of Scrum special?

I'll start by saying this: the architecture of your product is independent of the number of products. The fact that you have a single product that is designed using a microservices architecture doesn't have an impact on how your manage the product.

But a few thoughts on your specifics.

The fact that you say "a product" and "one app" leads me to believe that you should only have one Product Backlog. Since, right now, you only have one Scrum Team, that would also lead me to suggest having a single Sprint Backlog. Even if you were to split your developers into 2 teams, you would still only have one product, and therefore one Product Backlog, but you would have two Sprint Backlogs at this point. If you continued to grow and introduce a 3rd and 4th team, I'd begin to look at frameworks like LeSS and Nexus for ideas on scaling Scrum.

The fact that you have microservices, assuming it's a good architecture, lends itself well to scaling. Microservices, with their clearly defined boundaries and interfaces, are much easier to allocate work and can be helpful in minimizing dependencies

A team of 10 developers is starting to push the limits of a manageable team size. Unless you have extremely efficient events, you'll probably be pushing the timeboxes that I may expect, depending on your Sprint length. However, I don't think your team is necessarily too large and you may not quite be ready to split into teams. Having appropriate skillsets may also be a factor in deciding if and when to divide into two or more smaller Scrum teams.

As far as your Jira structure goes, I have some concerns. I use the approach that one Jira project equates to one product. This makes the versioning and release planning capabilities much more efficient. Jira also offers project level Components that would more align with a microservice. However, I can see the argument that a microservice can be released and deployed independently and you may want to release plan and version each one. The approach of one Jira project per product also lends itself well for multiple boards. A custom team field can help with Sprint Backlog management and let you filter to team boards and associated metrics. I think your approach may work, and I'm not sure I'd change it, but I'd want to think through growth (in terms of teams and services) and how that may work out.

Architecture is independent on applying scrum.

Apart from that, if you have a Microservice architecture, with 3 microservices, I am not sure if you are truly using microservices, or merely a SOA in general