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

Question

[Владимир Грабко]

У меня куча сервисов. Все функции которые у них повторяются я вынес в отдельный пакет 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 тоже не сильно нравится. Так как быть мне?

Comments

[landergate]

> Но и идея с опросом сервисов о их API тоже не сильно нравится.
Почему?

[Oleg Shevelev]

Добавь в код тесты... То что одинаковое во всех программах и микросервисах вполне нормально вынести в отдельные пакеты и линковать их везде где нужно. Просто такой пакет должен быть с тестами и желательно учитывающими все сценарии всех микросервисов. А иначе нельзя быть уверенным что ваш код функционирует.

[Владимир Грабко]

Oleg Shevelev: напиши в ответ. Помечу.

[Владимир Грабко]

landergate: ну хз

[Владимир Грабко]

landergate: можно сделать лучше но как не знаю.

[Oleg Shevelev]

Владимир Грабко: для ответа не подходит. Слишком расплывчато и не особо полезно. Очевидно в общем.

[Владимир Грабко]

Oleg Shevelev: это лучше чем ответ "сделай как в nginx"

[Oleg Shevelev]

Владимир Грабко: не, там более техничное:) Типо лучше:)

[landergate]

Владимир Грабко:
> ну хз
> можно сделать лучше но как не знаю.

Лучше, чем что?
Почему API не подходит?

Анонс доступных методов от API - это же обычная практика между сервисами.

Вы хотите сделать каждый сервис самодостаточным, и хотите, чтобы сервисы узнавали методы друг друга без вашего участия.
Как ещё сервис может узнать о возможностях другого сервиса, если не ответом от него самого?

[Владимир Грабко]

landergate: > > ну хз )) Я прост. думал что есть что получше, а я просто не знаю.

[Владимир Грабко]

Oleg Shevelev: ))

[landergate]

Владимир Грабко:
Давайте от обратного:
Чем раздражает использование выдачу методов через API?

[Владимир Грабко]

landergate: я не могу вам ответить. См. https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D...

[landergate]

Владимир Грабко:
Я понимаю, что такое перфекционизм, но не представляю, как можно дискомфортить по проблеме, которую невозможно сформулировать самому себе. Своими вопросами хотел способствовать появлению этого ответа.

Ведь признаков "несовершенного результата" в контексте с выдачей методов через API так и не было названо.

[Владимир Грабко]

landergate: я стремлюсь к идеалу И просто думаю что можно сделать лучше чем есть но но как не знаю.

[landergate]

Владимир Грабко: Что именно вызывает сомнения в том, что методы через API - идеал?

[Владимир Грабко]

landergate: в том что я не знаю другого способа делать это автоматически.

[landergate]

Владимир Грабко: Значит это и есть идеал? =)

[Владимир Грабко]

landergate: я в тупике. Вы убиваете мой перфекционизм :D

[landergate]

Владимир Грабко: ))
Перфекционизм предполагает, что Вы понимаете, к какому формату/виду Вы хотите привести результат, и дискомфортите, пока он к нему не приблизится.
Здесь же скорее вопрос, можно ли сделать лучше, но веских причин для поиска "лучше" пока выявить не получилось.

Answer 1

[Max Voronov]

На мой взгляд, тут можно попробовать несколько вариантов. Конечно, каждый из них применим для той или иной ситуации в разной степени. Итак:

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/
   
   

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