A company might have a
People table in which those people's social security number (or any other government-issued identifier) is listed. That identifier is the PK (or functional equivalent) of some government database somewhere. But the company does not have access to the government database. The company's application uses the identifier without direct access to the fovernment's database, and you really wouldn't want everyone who uses that identifier to all have access to the government's database, right?
So how can it trust that the identifier that the user entered exists and is correct? Well, it could fire off a request to the government API to verify the identifier.
While this maybe does not fit the current example scenario very well, your frontend UI could also have asked the government API a list of all people (with their identifiers), had the user select the correct person, and then the frontend would know which identifier to send to its backend service.
Your Customer and Order microservices will behave very similarly to the above example.
What I don't still understand is how could those two services exchange information about customers.
Only the customer microservice deals with customer information. That's why it's the customer microservice.
The order microservice does not deal with customer information except an identifier, something that uniquely identifies a particular customer. While a PK seems to fit the bill here, it's generally advised to not use a DB-related value as it causes tight coupling.
Let's say you're on the webpage where (eventually) an order will be created. You'll already know who your customer is. So when you click the "Place Order" button, obviously you should be able to POST a request to the order microservice and include the customer's identifier. The order microservice then uses that identifier as simple data that it adds to its order entity.
If, for whatever reason, the order microservice needs to know the full name of the customer who placed order 123, then it will have to query the customer microservice using the customer identifier in order to find out the customer's details.
But how would this relationship work in a microservice environment without having to read the same data base ?
I hope the above explanation already helps shift your expectation here. There should not be any FK constraint between the Customer and Order tables, because they're in different microservices.
What's more, you shouldn't even be using the same database for multiple microservices. Each microservice manages its own data and therefore it should be given a private data storage that cannot be directly accesses by anyone but the microservice. If anyone else needs to know any of that data, they need to come through the microservice's API and have the microservice be the one who interacts with its database.
Overall, I think you need to read up on microservices to a greater extent than you already have. You seem to understand the separation of different contexts well (Customer vs Order), but your implicit reliance on an underlying shared datastore suggests that you don't really understand what microservices aim to achieve and how they achieve it.
A total separation of each microservice's private resources lies at the heart of the microservice architecture. If you infringe that core concept, which is technically perfectly possible to do, you will lose out on the major benefit of having a microservice architecture. Your not-really-a-microservice approach will most likely end up being something that cost you more effort than the benefits you gained from it.
This answer is a basic reframing of your interpretation of a microservice, a proper readthrough of an actual learning resource will tell you more than I can in this answer.