Where the HTTP layer should be placed in a microservices architecture?

Question

I ran into problems when I moved the project from a monolithic architecture to microservices, and it turns out that my monolithic architecture might look like this, using the User module as an example：

user
├── handler
│   └── user.go     # handle HTTP Request
├── repository
│   ├── cache
│   │   └── user.go # caching layer
│   ├── dao
│   │   └── user.go # data access layer
│   └── user.go     # Aggregation of dao and cache, an abstraction layer for data processing
├── service         # Execute real business logic
│   └── user.go

For example, for a Login interface, the call chain would be handler -> service -> repository -> dao / cache.

But when I moved to using microservices, the rough architecture became something like this:

user
├── server
│   └── user.go     # Encapsulation of the RPC-generated Server, specifically calling the service to execute the real logic.
├── repository
│   ├── cache
│   │   └── user.go # caching layer
│   ├── dao
│   │   └── user.go # data access layer
│   └── user.go     # Aggregation of dao and cache, an abstraction layer for data processing
├── service         # Execute real business logic
│   └── user.go

My question is, now that server has a layer of encapsulation for service, where does the original handler go, and should it be coupled inside the module?If yes, then I have two questions: firstly, if coupled internally, it means that the module will be listening on two ports, one for HTTP service and the other for RPC service, which is against some microservices concepts, and secondly, if coupled internally, it means that the module will be listening on two ports, one for HTTP service and another for RPC service.Secondly, if coupled internally, does the handler call to the original service have to be changed to an RPC call instead of an in-process call?Because for some interfaces, it may not necessarily be called by other modules in the future, for example, Login, it must be an HTTP interface to call it, unlike GetUserInfo, which may need to be called by other modules in RPC.