Can you solve the perfectionist problem?

Question

go

I have a lot of services. I moved all the functions that they repeat into a separate lib package.
For example, calling methods of other services, etc. But this already contradicts the idea of ​​microservice architecture (you can break everything at once). And I don’t want to copy-paste the code to all services for obvious reasons. So how can I be?
And here is how I bind to services
config.json

{
  "Auth":{
    "Conn":["127.0.0.1","5000","password"],
    "Method":{
      "Save":true
    }
  },
  "Game":{
    "Conn":["127.0.0.1","5001","password"],
    "Method":{
      "Reg":true
    }
  }
}

main.go

lib.ServiceConfigLoad("config.json")
  err := lib.ServiceGet(ps.ByName("service"), ps.ByName("method"), func(c Client.RpcConnect) {
    //отправляем запрос
    var dd map[string]string
    json.Unmarshal([]byte(ps.ByName("data")), &dd)
    r, err := c.Send(ps.ByName("method"), dd)
    if err != nil {
      log.Println(err)
    }
    //декодируем ответ и отдаём юзеру
    jsonString, err := json.Marshal(r)
    if err != nil {
      log.Println(err)
    }
    w.Write(jsonString)
  })
  if err != nil {
    w.Write([]byte(`{"code":"501","err":"` + err.Error() + `"}`))
  }

It infuriates me that I have to manually drive in all the available methods for each service. But I don't like the idea of ​​polling services about their API either. So what should I do?

Answer 1

In my opinion, here you can try several options. Of course, each of them is applicable to a particular situation to a different extent. So:
As already mentioned in the comments, this is a normal practice. For example, it is logical to move the system dealing with communication between microservices into a separate package. And tests can really help here. And ideally, it is better to put rarely changing functionality into such packages.
If some functionality is used in several microservices, then it may be worth moving it into a separate independent microservice. However, if these functions are used frequently, then such a microservice can quickly become a bottleneck in the system.
This point is more related to the wish "I have to type in all the available methods for each service by hand." Let me give you a small example to make the idea clearer. Imagine that there is a microservice responsible for working with users. And we communicate with him to get information about users from other microservices. In order not to manually transfer all methods, you can use protocols like Protobuf + gRPC. It describes a file of type users.proto in which we describe methods and fields:

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

service HelloService {
  rpc SayHello(HelloRequest) returns
  (HelloResponse);
}

When they are compiled, the output of the go file is included in the project. As a result, each microservice will be based on one standard. The bonus is a more economical and faster format compared to JSON.
All proto files can be stored if desired, even in a separate repository. This will be a kind of API standard for communication between microservices. By the way, an interesting article was recently published on Habré on this subject: https://habrahabr.ru/company/badoo/blog/305888/
In general, something like this) It will be interesting to hear your thoughts on this matter.