Kushughulikia Hitilafu na Majaribio Upya ya Didit API kwa Ustadi Katika Go (SW)

Elewa Mipaka ya Viwango vya DiditTekeleza udhibiti wa upande wa mteja na urejeshaji wa kielelezo kwa majibu ya 429, ukitumia vichwa vya habari vya X-RateLimit-Limit, X-RateLimit-Remaining, na X-RateLimit-Reset ili kuzuia usumbufu wa huduma.

Tofautisha Aina za HitilafuTofautisha kati ya hitilafu za muda mfupi (k.m., masuala ya mtandao, kutopatikana kwa huduma) na hitilafu za kudumu (k.m., funguo batili za API, maombi yaliyopangika vibaya) ili kutumia mantiki sahihi ya kujaribu upya au kushindwa haraka.

Tekeleza Mifumo Imara ya Kujaribu UpyaTumia mizunguko ya kujaribu upya iliyopangika na urejeshaji wa kielelezo, msisimko, na majaribio ya juu zaidi ya kujaribu upya ili kushughulikia hitilafu za muda mfupi kwa ufasaha, kuboresha uaminifu wa shughuli muhimu kama vile uundaji wa kipindi.

Mbinu ya Didit Inayoangazia Wasanidi Programu Hurahisisha UjumuishajiDidit inatoa nyaraka wazi za API, vichwa maalum vya vikomo vya viwango, na usanifu wa moduli, kuwezesha wasanidi programu wa Go kuunda mtiririko thabiti wa uthibitishaji wa utambulisho kwa urahisi na kujiamini.

Kuunganisha API za wahusika wengine ni msingi wa ukuzaji wa programu za kisasa, na uthibitishaji wa utambulisho sio ubaguzi. Unapofanya kazi na huduma muhimu kama jukwaa la utambulisho la Didit, kuhakikisha ujumuishaji wako unastahimili mabadiliko ya mtandao, matatizo ya huduma, na vikomo vya viwango ni muhimu sana. Mwongozo huu unachunguza ushughulikiaji wa hitilafu wa hali ya juu na mikakati ya kujaribu upya iliyoundwa mahsusi kwa ujumuishaji wa Didit API kwa kutumia Go, kukusaidia kuunda mifumo imara na thabiti.

Kuelewa Mazingira ya Hitilafu ya Didit API

Kabla ya kutekeleza mantiki yoyote ya kujaribu upya, ni muhimu kuelewa aina za hitilafu unazoweza kukutana nazo. Didit API, kama huduma nyingi zilizoundwa vizuri, huwasiliana hali mbalimbali kupitia misimbo ya hadhi ya HTTP. Wakati misimbo ya kawaida ya 2xx inaonyesha mafanikio, utazingatia zaidi 4xx (hitilafu za mteja) na 5xx (hitilafu za seva), na hasa 429 (Maombi Mengi Zaidi).

Kizuizi cha Kiwango cha Didit na Maana Yake Kwako

Didit inatekeleza kizuizi cha kiwango ili kudumisha utulivu wa API. Hili ni jambo muhimu la kusimamia katika ujumuishaji wako. Kwa mfano, vituo vya mwisho vya GET kwa kawaida vina kikomo cha jumla cha maombi 300 kwa dakika kwa kila programu, huku vituo maalum vya mwisho kama session-decision (100 rpm) au session-v2-create (600 rpm) vikiwa na vikomo vyao wenyewe, ambavyo vinaweza kuwa vikali zaidi. Unapofikia kikomo cha kiwango, Didit hujibu kwa msimbo wa hadhi wa 429 Too Many Requests na inajumuisha vichwa vya habari muhimu:

• X-RateLimit-Limit: Idadi ya juu zaidi ya maombi yanayoruhusiwa katika dirisha la sasa.
• X-RateLimit-Remaining: Idadi ya maombi yaliyobaki katika dirisha la sasa.
• X-RateLimit-Reset: Muda (katika sekunde za epoch) wakati dirisha la sasa la kikomo cha kiwango linapowekwa upya.
• Retry-After: (Mara nyingi hujumuishwa) Idadi ya sekunde za kusubiri kabla ya kufanya ombi lingine.

Mteja wako wa Go anapaswa kufuatilia kikamilifu vichwa hivi. Wakati X-RateLimit-Remaining inaposhuka chini ya kizingiti fulani (k.m., 15% ya X-RateLimit-Limit), unapaswa kupunguza kwa uangalifu maombi yako. Kupuuza haya kunaweza kusababisha makosa ya 429 yanayoendelea, kuathiri uwezo wa programu yako kuunda vipindi vya uthibitishaji au kupata matokeo kutoka kwa bidhaa kama vile Uthibitishaji wa Vitambulisho vya Didit au Uchunguzi wa AML.

Kutekeleza Mikakati Imara ya Kujaribu Upya kwa Kutumia Exponential Backoff katika Go

Kwa hitilafu za muda mfupi (k.m., muda wa mtandao kuisha, kutopatikana kwa huduma kwa muda, au 429s), kujaribu upya ni muhimu. Hata hivyo, majaribio ya upya yasiyo na uzoefu yanaweza kuzidisha matatizo. Kiwango cha dhahabu ni urejeshaji wa kielelezo na msisimko.

Exponential Backoff na Jitter

Exponential backoff inamaanisha kuongeza muda wa kusubiri kati ya majaribio upya kwa kielelezo. Jitter (kuongeza ucheleweshaji mdogo wa nasibu) huzuia tatizo la 'kundi lenye nguvu' ambapo wateja wengi hujaribu upya kwa wakati mmoja baada ya kuzimika, na kuzidi huduma tena. Huu hapa ni mfano wa Go:

package main

import (
	"fmt"
	"io/ioutil"
	"net/http"
	"time"
	"math/rand"
)

func callDiditAPIWithRetry(url string, maxRetries int) ([]byte, error) {
	client := &http.Client{Timeout: 10 * time.Second}
	rand.Seed(time.Now().UnixNano())

	for i := 0; i <= maxRetries; i++ {
		resp, err := client.Get(url)
		if err != nil {
			// Handle network errors (e.g., connection refused, timeout)
			fmt.Printf("Attempt %d: Network error: %v\n", i+1, err)
			if i == maxRetries {
				return nil, fmt.Errorf("failed after %d retries: %w", maxRetries, err)
			}
			sleepTime := time.Duration(1<<i)*time.Second + time.Duration(rand.Intn(1000))*time.Millisecond // Exponential backoff + jitter
			fmt.Printf("Retrying in %v...\n", sleepTime)
			time.Sleep(sleepTime)
			continue
		}
		defer resp.Body.Close()

		switch resp.StatusCode {
		case http.StatusOK:
			fmt.Printf("Attempt %d: Success!\n", i+1)
			return ioutil.ReadAll(resp.Body)
		case http.StatusTooManyRequests:
			// Respect Retry-After header if present
			retryAfter := resp.Header.Get("Retry-After")
			if retryAfter != "" {
				if sleepSeconds, err := time.ParseDuration(retryAfter + "s"); err == nil {
					fmt.Printf("Attempt %d: Rate limited. Retrying after %v.\n", i+1, sleepSeconds)
					time.Sleep(sleepSeconds)
					continue
				}
			}
			// Fallback to exponential backoff if Retry-After is missing or invalid
			fmt.Printf("Attempt %d: Rate limited (429).\n", i+1)
			if i == maxRetries {
				return nil, fmt.Errorf("rate limited after %d retries", maxRetries)
			}
			sleepTime := time.Duration(1<<i)*time.Second + time.Duration(rand.Intn(1000))*time.Millisecond
			fmt.Printf("Retrying in %v...\n", sleepTime)
			time.Sleep(sleepTime)
			continue
		case http.StatusInternalServerError, http.StatusBadGateway, http.StatusServiceUnavailable, http.StatusGatewayTimeout:
			// Server-side errors that might be transient
			fmt.Printf("Attempt %d: Server error %d. Retrying.\n", i+1, resp.StatusCode)
			if i == maxRetries {
				return nil, fmt.Errorf("server error %d after %d retries", resp.StatusCode, maxRetries)
			}
			sleepTime := time.Duration(1<<i)*time.Second + time.Duration(rand.Intn(1000))*time.Millisecond
			fmt.Printf("Retrying in %v...\n", sleepTime)
			time.Sleep(sleepTime)
			continue
		default:
			// Non-retryable errors (4xx client errors, etc.)
			body, _ := ioutil.ReadAll(resp.Body)
			return nil, fmt.Errorf("non-retryable API error: %d %s, response: %s", resp.StatusCode, resp.Status, string(body))
		}
	}
	return nil, fmt.Errorf("unexpected control flow") // Should not be reached
}

func main() {
	// Example usage: Replace with actual Didit API endpoint
	// For a real integration, you'd be POSTing to /v3/session/ or similar
	// and handling the verification_url.
	apiURL := "https://verification.didit.me/health"
	data, err := callDiditAPIWithRetry(apiURL, 5)
	if err != nil {
		fmt.Println("Failed to call API:", err)
	} else {
		fmt.Println("API Response:", string(data))
	}
}

Kipande hiki kinaonyesha jinsi ya kushughulikia hitilafu za mtandao, 429s (kwa kuheshimu Retry-After), na hitilafu za kawaida za 5xx na urejeshaji wa kielelezo na msisimko. Pia inaonyesha kushindwa haraka kwa hitilafu zisizoweza kujaribiwa tena za 4xx, ambazo kwa kawaida hutokana na uingizaji usio sahihi na hazitatatuliwa kwa kujaribu tena. Hili ni muhimu kwa shughuli kama vile kuunda kipindi cha uthibitishaji kwa kutumia usanifu wa moduli wa Didit.

Kutekeleza Mfumo wa Kivunja Mzunguko

Wakati majaribio ya upya yanasaidia na masuala ya muda mfupi, kujaribu upya huduma inayoshindwa kunaweza kuizidisha zaidi au kupoteza rasilimali ikiwa huduma imezimwa kweli. Hapa ndipo mfumo wa kivunja mzunguko unapoingia. Kivunja mzunguko hufuatilia kushindwa na, ikiwa vinafikia kizingiti fulani, "hufungua" mzunguko, kuzuia maombi zaidi kwa kipindi maalum. Baada ya kipindi hicho, huruhusu maombi machache ya kupima ili kuona kama huduma imepona.

Katika Go, unaweza kutumia maktaba kama sony/gobreaker kutekeleza mfumo huu:

package main

import (
	"errors"
	"fmt"
	"io/ioutil"
	"net/http"
	"time"

	"github.com/sony/gobreaker"
)

var cb *gobreaker.CircuitBreaker

func init() {
	st := gobreaker.Settings{
		Name:        "DiditAPICircuitBreaker",
		MaxRequests: 3, // Allow 3 requests in half-open state
		Interval:    5 * time.Second, // Period to collect data for trip decisions
		Timeout:     10 * time.Second, // Open circuit for 10 seconds
		ReadyToTrip: func(counts gobreaker.Counts) bool {
			return counts.ConsecutiveFailures > 5 // Trip after 5 consecutive failures
		},
		OnStateChange: func(name string, from gobreaker.State, to gobreaker.State) {
			fmt.Printf("Circuit Breaker '%s' changed from %s to %s\n", name, from, to)
		},
	}
	cb = gobreaker.NewCircuitBreaker(st)
}

func callDiditAPIWithCircuitBreaker(url string) ([]byte, error) {
	body, err := cb.Execute(func() (interface{}, error) {
		resp, err := http.Get(url)
		if err != nil {
			return nil, err // Network error
		}
		defer resp.Body.Close()

		if resp.StatusCode != http.StatusOK {
			// Only count 5xx and 429 as failures for circuit breaker
			if resp.StatusCode == http.StatusTooManyRequests || resp.StatusCode >= http.StatusInternalServerError {
				return nil, fmt.Errorf("API returned status %d", resp.StatusCode)
			}
			// For other 4xx errors, we might not want to trip the breaker, but still return an error
			bodyBytes, _ := ioutil.ReadAll(resp.Body)
			return nil, fmt.Errorf("non-retryable API error: %d %s, response: %s", resp.StatusCode, resp.Status, string(bodyBytes))
		}

		return ioutil.ReadAll(resp.Body)
	})

	if err != nil {
		if errors.Is(err, gobreaker.ErrOpenState) {
			return nil, fmt.Errorf("circuit breaker is open: %w", err)
		}
		return nil, err
	}

	return body.([]byte), nil
}

func main() {
	// Example usage
	apiURL := "https://verification.didit.me/health"
	for i := 0; i < 10; i++ {
		data, err := callDiditAPIWithCircuitBreaker(apiURL)
		if err != nil {
			fmt.Printf("Call %d failed: %v\n", i+1, err)
		} else {
			fmt.Printf("Call %d successful: %s\n", i+1, string(data))
		}
		time.Sleep(1 * time.Second)
	}
}

Kuunganisha vivunja mzunguko na urejeshaji wa kielelezo kunahakikisha kuwa programu yako inabaki ikiitikia na haizidi huduma ya nje inayojitahidi. Hili ni muhimu sana unaposhughulika na maombi ya uthibitishaji wa utambulisho yenye ujazo mkubwa, kama vile yale yanayohusisha Uthibitishaji wa Vitambulisho vya Didit au ukaguzi wa Utekelezaji wa Kazi na Kazi Tendaji.

Kushughulikia Kushindwa kwa Webhook na Matokeo ya Asynchronous

Didit API mara nyingi hutoa matokeo kwa njia ya asynchronous kupitia webhooks, kwa mfano, baada ya mtumiaji kukamilisha mtiririko wa uthibitishaji wa kitambulisho au wakati ukaguzi wa Uchunguzi wa AML umekamilika. Kituo chako cha mwisho cha webhook lazima kiwe thabiti. Ikiwa kituo chako cha mwisho kitashindwa kuchakata webhook (k.m., kinarudisha msimbo wa hadhi wa 5xx), Didit itajaribu tena kutoa webhook. Ni muhimu:

• Kukiri Kupokea Mara Moja: Rudisha msimbo wa hadhi wa 2xx haraka iwezekanavyo ili kuashiria kupokea kwa mafanikio, hata kama usindikaji unachukua muda mrefu.
• Chakata kwa Asynchronous: Peana malipo ya webhook kwa mfanyakazi wa nyuma au foleni ya ujumbe (k.m., Kafka, RabbitMQ) kwa usindikaji. Hii inazuia kituo chako cha mwisho cha webhook kutoka kumaliza muda wa majaribio upya ya Didit.
• Idempotency: Hakikisha mantiki yako ya usindikaji wa webhook ni idempotent. Ikiwa Didit itajaribu tena na kutoa webhook sawa mara nyingi, mfumo wako unapaswa kuichakata mara moja tu ili kuzuia vitendo viwili au kutofautiana kwa data.
• Thibitisha Saini: Daima thibitisha saini ya webhook kwa kutumia Webhook Secret Key yako kutoka kwa Console ya Didit ili kuhakikisha ombi lilitoka kweli Didit na halijaharibika.

Jinsi Didit Inavyosaidia

Didit imeundwa kwa kuzingatia uzoefu wa msanidi programu na uaminifu, ikitoa vipengele vinavyorahisisha ushughulikiaji wa hitilafu wa hali ya juu na mikakati ya kujaribu upya kwa ujumuishaji wako wa Go. Mbinu yetu inayomlenga msanidi programu kwanza inamaanisha nyaraka wazi, kamili za API, sandbox ya papo hapo, na API safi zinazofanya ujumuishaji kuwa rahisi.

• Kizuizi cha Kiwango Kinachotarajiwa: Didit inafafanua wazi vikomo vya kiwango vya kimataifa na maalum vya kituo cha mwisho, pamoja na vichwa vya kawaida vya HTTP (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After) kuelekeza udhibiti wako wa upande wa mteja na mantiki ya urejeshaji. Uwazi huu unakuwezesha kuunda mifumo bora ya kujaribu upya kwa huduma kama vile Uthibitishaji wa Vitambulisho na Uchunguzi wa AML.
• Usanifu wa Moduli: Vipengele vyetu vya utambulisho vya moduli vinamaanisha unaweza kuunda mtiririko wa kazi ambao ni thabiti kwa muundo. Ikiwa ukaguzi mmoja maalum (k.m., Uthibitisho wa Anwani) unakutana na suala la muda mfupi, mtiririko wako wa jumla wa kazi unaweza kusanidiwa kurekebisha au kujaribu tena vipengele maalum bila kuathiri hatua zisizohusiana za uthibitishaji.
• Uaminifu wa AI-Asilia: Backend ya Didit inayotegemea AI imeundwa kwa ajili ya kuongezeka na uaminifu, kupunguza hitilafu za upande wa seva unazoweza kukutana nazo. Hii inakuwezesha kuelekeza ushughulikiaji wako wa hitilafu kwenye masuala ya mtandao na upande wa mteja, badala ya kukatika kwa huduma mara kwa mara.
• KYC ya Msingi Bila Malipo & Bei Rahisi: Anza na kiwango cha Didit kisicholipishwa kwa KYC ya Msingi, kukuruhusu kujaribu kikamilifu ushughulikiaji wako wa hitilafu na mikakati ya kujaribu upya katika mazingira kama ya uzalishaji bila gharama za awali. Mfumo wetu wa malipo kwa kila ukaguzi uliofanikiwa unaendana zaidi na mafanikio yako.

Uko Tayari Kuanza?

Uko tayari kuona Didit ikifanya kazi? Pata demo ya bure leo.

Anza kuthibitisha vitambulisho bila malipo na kiwango cha Didit kisicholipishwa.