VGrabko
@VGrabko
Golang, Php, Js

Пожете решить проблему перфекциониста?

У меня куча сервисов. Все функции которые у них повторяются я вынес в отдельный пакет lib.
К примеру вызов методов других сервисов и т.д. Но это уже противоречит идее микросервисной архитектуры (сломать можно всё и сразу). А копипастить код во все сервисы я не хочу по понятным причинам. Так как же мне быть?

А вот как я связываюсь с сервисами
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() + `"}`))
	}


Меня бесит что я должен руками вбить все доступные методы для каждого сервиса. Но и идея с опросом сервисов о их API тоже не сильно нравится. Так как быть мне?
  • Вопрос задан
  • 414 просмотров
Пригласить эксперта
Ответы на вопрос 1
RavenRage
@RavenRage
На мой взгляд, тут можно попробовать несколько вариантов. Конечно, каждый из них применим для той или иной ситуации в разной степени. Итак:
  1. Выделение функционала в отдельные пакеты
    Как писали уже в комментариях, это нормальная практика. Например, систему занимающуюся коммуникацией между микросервисами логично вынести в отдельный пакет. И тесты тут действительно хорошо могут помочь. И в идеале, лучше выносить в подобные пакеты редко изменяющийся функционал.

  2. Выделение функционала в микросервисы
    Если какой-то функционал используется в нескольких микросервисах, то возможно его стоит вынести в отдельный независимый микросервис. Однако если эти функции используются часто, то такой микросервис может довольно быстро стать узким местом в системе.

  3. Использование RPC
    Этот пункт больше относится к пожеланию "я должен руками вбить все доступные методы для каждого сервиса". Приведу небольшой пример, чтобы была яснее идея. Представим что есть микросервис отвечающий за работу с пользователями. И мы с ним общаемся чтобы получить инфо о юзерах из других микросервисов. Чтобы вручную не переносить все методы, можно использовать протоколы вроде Protobuf + gRPC. В нем описывается файлик типа users.proto в котором описываем методы и поля:
    message HelloRequest {
      string greeting = 1;
    }
    
    message HelloResponse {
      string reply = 1;
    }
    
    service HelloService {
      rpc SayHello(HelloRequest) returns
      (HelloResponse);
    }

    Когда они компилятся, то получается на выходе go файл подключаемый в проект. В итоге каждый микросервис будет опираться на один стандарт. Бонусом более экономный и быстрый по сравнению с JSON`ом формат.

    Все proto файлы можно хранить при желании хоть в отдельном репозитории. Это будет своего рода стандартом API для коммуникации между микросервисами. На этот счет, кстати, недавно на Хабре вышла интересная статья: https://habrahabr.ru/company/badoo/blog/305888/


В целом как то так) Будет интересно услышать ваши мысли на этот счет.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы