архитектуры ✦ Проблема владения кодовой базой Путь нашей команды ✦ Первые шаги ✦ Управление корутинами на WaitGroup ✦ ErrGroup Итоговое решение ✦ Rutina как «скелет» приложения ✦ Политики окончания ✦ Rutina для пакетных задач ✦ Примеси
развития, подходы, а значит и код, могут активно изменяться или даже заменяться другими решениями. Эту проблему решили тривиальным образом, создав общую библиотеку собственных пакетов для работы с БД, очередями и т.п. и на ней останавливаться мы не будем. Самая первая и самая очевидная проблема – копипаст общих частей из проекта в проект.
а на каждое изменение приходится либо копить техдолг, либо тратить время на рефакторинг. Этого никто не хочет. Активное развитие заставляет изменяться не только коду, но и самой архитектуре микросервисов.
микросервисном подходе становится актуальна проблема владения кодом всех разработчиков. Приложения должны быть устроены так, чтобы любой разработчик мог быстро: ✦ Разобраться в их устройстве ✦ Найти интересующее место бизнес-логики, не отвлекаясь на сервисный код ✦ Выполнить поставленную задачу
без ошибок: ✦ DoNothingOnDone – не производится дополнительных действий ✦ RestartOnDone – горутина перезапускается с теми же аргументами ✦ ShutdownOnDone – закрывается контекст, тем самым отправляется сигнал на завершение другим горутинам
без ошибок: ✦ DoNothingOnDone – не производится дополнительных действий ✦ RestartOnDone – горутина перезапускается с теми же аргументами ✦ ShutdownOnDone – закрывается контекст, тем самым отправляется сигнал на завершение другим горутинам Политики при завершении горутины с ошибкой: ✦ DoNothingOnError – не производится дополнительных действий ✦ RestartOnError – горутина перезапускается с теми же аргументами ✦ ShutdownOnError – закрывается контекст, тем самым отправляется сигнал на завершение другим горутинам
без ошибок: ✦ DoNothingOnDone – не производится дополнительных действий ✦ RestartOnDone – горутина перезапускается с теми же аргументами ✦ ShutdownOnDone – закрывается контекст, тем самым отправляется сигнал на завершение другим горутинам Политики при завершении горутины с ошибкой: ✦ DoNothingOnError – не производится дополнительных действий ✦ RestartOnError – горутина перезапускается с теми же аргументами ✦ ShutdownOnError – закрывается контекст, тем самым отправляется сигнал на завершение другим горутинам Поведение по умолчанию совпадает с таковым у ErrGroup: ✦ ShutdownOnDone ✦ ShutdownOnError
"http://url2.ru/....", "http://url3.ru/....", ... "http://urlN.ru/....", } for _, task := range tasks { task := task r.Go(func (ctx context.Context) error { // Некий парсинг со страницы return worker(ctx, task) }, rutina.RestartIfError) } r.Wait() Но что делать, если мы хотим залогировать или как-то обработать ошибки, а не заглушить их?
создает канал с ошибками горутин с политиками DoNothingOnError, RestartOnError ✦ WithStdLogger и WithLogger(logger log.Logger) – добавляет логирование стандартным или собственным логгером ✦ WithContext(ctx context.Context) – заставляет Rutina использовать внешний контекст, например, контекст запроса или родительского экземпляра Rutina ✦ WithLifecycleListener(func (event rutina.Event, rid int)) – позволяет повесить функцию-слушатель на внутренние события Rutina ✦ WithListenOsSignals() – автоматически слушает сигналы ОС, нет необходимости вручную запускать r.ListenOsSignals()