Как создать короткий читаемый UUID в распределенной среде микросервисов

Question

Я работаю над превращением супермонолитного веб-сервиса в микросервисный подход с использованием CQRS и Event Sourcing. Учитывая это и учитывая предыдущую архитектуру, зависящую от инкрементных номеров идентификаторов SQL Server для каждой таблицы, для распределенной системы недопустимо полагаться на базу данных, поскольку теперь у нас будут различные проекции событий в системе.

Но нам все еще нужно сохранять отношения и передавать идентификаторы для аналитики, вызовов API и т. Д. Очевидным вариантом является GUID, и он выглядит хорошо, пока вы не дойдете до точки GET-запроса, http://awesomedomain.com/users/98e3b2ab-3c69-4077-aea1-38d22e79b007, хм, не так уж и красиво и довольно громоздко, но это будет работать. Также известно, что использование GUID в качестве ключей индекса в базе данных может привести к снижению производительности.

После просмотра некоторых ответов здесь, чтобы попытаться сгенерировать идентификаторы на основе отметок времени EPOCH UNIX , сократить GUID или , этот интересный подход (но выяснить, не глобальное решение), каждое решение не гарантирует глобальной уникальности, за исключением короткого GUId, но все еще неясно.

Другой вариант - использовать службу Guid с распределенной блокировкой (Redis) для генерации тикового идентификатора EPOCH UNIX, но это может дать нам снижение производительности, если у вас есть тысячи одновременных запросов на создание.

Должны ли мы действительно пытаться сократить GUID или найти другое решение, которое более "читабельно для человека"? Существуют ли другие решения для глобальных уникальных идентификаторов, которые мы могли бы реализовать?

Answer 1

То, что у тебя есть, хорошо.

Возможно, он не читается человеком, но это именно то, что и должно быть. Последовательные идентификаторы легко угадываются и вредны для безопасности. GUID довольно хорошо заполняют этот пробел.

В зависимости от того, как структурирована ваша система, вы можете использовать int ID в качестве первичных ключей, сохраняя при этом свои GUID, и они не обязательно должны быть первичными ключами. Однако это не всегда возможно.

Answer 2

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

Лично я бы сказал, что ключи автоинкремента базы данных и микросервисы не являются взаимоисключающими. У вас может быть множество экземпляров облегченного сервиса, и все они работают за одной базой данных, специфичной для микросервиса. Несмотря на то, что это может сделать соединение с БД узким местом или единственной точкой отказа, оно все еще жизнеспособно, и многие службы в Интернете работают нормально таким образом. Если вы правильно проектируете базу данных и сохраняете ее «микро», то она должна работать нормально, по крайней мере, для «тысяч запросов на создание».

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

Answer 3

Есть несколько вариантов, из которых вы можете выбрать:

все равно

Зачем беспокоиться о GUID.Никто не увидит это.Он используется только для обслуживания, чтобы обслужить связь или технические вызовы API.

Недостаток: может выглядеть уродливо.

использовать естественные ключи

Вещи могут иметь стандарты ISO, такие как страны иливалюты.Они читаются человеком в большинстве случаев.Некоторые другие вещи могут иметь другой естественный идентификатор, например, корабли.

Некоторые вещи не имеют.Это раздражает.Нет недостатков (помимо скорости вызовов в БД), но не всегда доступно.

локальное переформатирование идентификатора

Некоторые веб-части пользовательского интерфейса могут хранить некоторые супербыстрые элементы поиска в собственной базе данных, оптимизированной для поиска.Здесь вы можете иметь местный идентификатор.Но это плохо связывается с другими сервисами.

Недостаток: сложность интеграции.

более короткие направляющие

Мы можем сгенерировать случайное число, не так ли?Лучше человека читаемым.Хорошие URL.Круто.

Недостатки: не сильно, просто;нет связи с фактическим лицом.Но поскольку вы использовали GUID, у вас его не было с самого начала.

---

Конечно, я оставил некоторые параметры вне уравнения.В принципе;все зависит от ваших требований.Скорость, безопасность, возможности репликации и т. Д.: -)

Наслаждайтесь!