Comments 7
Всегда думал, что атрибут fault-tolerance относится к архитектуре сложной системы, а на каком языке написаны отдельные её компоненты - не важно.
Очередная бесполезная рекламная статья. Да ещё и с вредными советами.
по-русски это будет "отказоустойчивые системы"
Напомню, что у моих друзей из OTUS есть целый ряд практических курсов про архитектуру приложений, где вы можете изучить не только Fault-tolerant системы,
Хотите сказать что в этом самом OTUS учат делать отказоустойчивые системы (что за мания такая всё обанглоязычивать?) исключительно только с помощью какого-то языка программирования? Других советов на эту тему что-то я не увидел... может проглядел.
package main
import "fmt"
func mayPanic() {
panic("a problem occurred")
}
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered. Error:\n", r)
}
}()
mayPanic()
fmt.Println("After mayPanic()")
}
Функция mayPanic вызывает панику. В функции main, блок defer с функцией recover перехватывает эту панику, позволяя программе продолжить выполнение после функции mayPanic. Без recover программа бы завершилась сразу после паники, не выполнив код, следующий за вызовом mayPanic.
Автор, ты точно пишешь на Go? Код на 18 строке недостижим. Эта программа в текущем исполнении никогда не выведет "After mayPanic()". После выполнения всех отложенных вызовов (defer) происходит возврат из функции, в данном случае - завершение программы. Код после паники никогда не будет исполняться, даже если будет вызвана функция recover, иначе это бы не имело смысла. Неужели перед публикацией было очень сложно скопировать кусок кода и проверить его в Go Playground?
Помоему CircuitBreaker у вас недописан. halfOpenMutex нигде не используется. А статус StateHalfOpen отличается от StateClosed только названием, ведь при StateHalfOpen не должен учитываться счетчик неудачных попыток. Сами же счетчики стоило сделать через atomic.
А вообще статья полезна советами, чтобы пойти и поизучать тему более глубоко.
Проектирование fault-tolerant систем на Go