AS
думаю в мс прага или мс таллинн довольно просто попасть
Size: a a a
2020 March 04
AS
слышал в пражском офисе много русскоязычных
A
и там дотнет команда есть
2020 March 05
YK
Вопрос в студию, кто-нибудь встречался с подобным проектом?
https://github.com/solid/solid
https://www.csail.mit.edu/research/solid-social-linked-data
https://solid.mit.edu/
https://github.com/solid/solid
https://www.csail.mit.edu/research/solid-social-linked-data
https://solid.mit.edu/
2020 March 06
S
Здравствуйте!
Используете ли вы в микросервисах DateTime. UtcNow? Не боитесь ли рассинхрона? Может быть подскажите best practices?
Используете ли вы в микросервисах DateTime. UtcNow? Не боитесь ли рассинхрона? Может быть подскажите best practices?
AB
Есть мнение, что на дату и время логику особо закладывать не надо. Небольшой рассихрон обычно это норма. Разные серверы, вот это всё.
VS
Steven
Здравствуйте!
Используете ли вы в микросервисах DateTime. UtcNow? Не боитесь ли рассинхрона? Может быть подскажите best practices?
Используете ли вы в микросервисах DateTime. UtcNow? Не боитесь ли рассинхрона? Может быть подскажите best practices?
надо настраивать общий ntp
AB
надо настраивать общий ntp
+
S
Спасибо большое)
A
Это в целом поможет, но не сильно
A
Надо быть готовым к рассинхрону
A
Что я рекомендую делать, это абстракцию над UtcTime, у нас это было в Request Context свойством
A
Удобно мокать и можно фиксировать один таймстемп на весь запрос
VL
А что не так с utc? Хранить все в utc, клиенту все отдавать в его часовом поясе. И нет проблем.
VL
Если у вас на серверах фигово часы настроены, то проблема не в софте.
VS
Удобно мокать и можно фиксировать один таймстемп на весь запрос
тогда не получится трекать сколько времени каждый микросервис съедает
VS
а хотя может и получится, если относительно входящего времени остальное время высчитывать
A
тогда не получится трекать сколько времени каждый микросервис съедает
Получится, это ж отдельное
A
Это время для бизнес логики, а не для трассировки