Quelques suggestions pour la conception de l'interface

1. Vérification des paramètres

La validation des paramètres doit être obligatoire pour chaque interface,Qu'il s'agisse d'une demande initiale,Tout autre appel à l'arrière - plan doit vérifier les paramètres,Par exemple,：Longueur du paramètre、Type、Format,Si le paramètre requis est transmis,Conformité aux règles commerciales convenues, etc..

RecommandéSpringBoot ValidationPour réaliser rapidement la vérification des paramètres de base.

Voir l'exemple suivant：

@Data
@ToString
public class DemoEntity {
    
	
	// Ne peut pas être vide,Les espaces sont supprimés lors de la comparaison
    @NotBlank(message = "Le nom ne peut pas être vide")
    private String name;
	
	// amount Doit être supérieur ou égal à 5,Jusqu'à10Nombre de
    @DecimalMax(value = "10")
    @DecimalMin(value = "5")
    private BigDecimal amount;

	// Doit être conforme àemailFormat
    @Email
    private String email;
	
	// sizeLa longueur doit être5À10Entre
    @Size(max = 10, min = 5)
    private String size;
	
	// ageLa taille doit être18À35Entre
    @Min(value = 18)
    @Max(value = 35)
    private int age;
	
	// userNon.null
    @NotNull
    private User user;
	
	//  La limite doit être décimale , Et entier integerLa plupart2Bits,DécimalefractionMax.4Bits
    @Digits(integer = 2, fraction = 4)
    private BigDecimal digits;
	
	//  La limite doit être une date future 
    @Future
    private Date future;

	//  La limite doit être la date d'expiration 
    @Past
    private Date past;
	
	//  La limite doit être un temps futur ou présent 
    @FutureOrPresent
    private Date futureOrPast;
	
	// Prise en charge des expressions régulières
	@Pattern(regexp = "^\\d+$")
	private String digit;
}

@RestController
@Slf4j
@RequestMapping("/valid")
public class TestValidController {
    

    @RequestMapping("/demo1")
    public String demo12(@Validated @RequestBody DemoEntity demoEntity) {
    
        try {
    
            return "SUCCESS";
        } catch (Exception e) {
    
            log.error(e.getMessage(), e);
            return "FAIL";
        }
    }
}

2. Limite de courant d'interface

Lors de la conception de l'interface, Nous devrions évaluer la capacité de charge de l'interface , En particulier lorsqu'il est mis à la disposition de tiers , Ainsi, lorsque le débit réel demandé dépasse le débit prévu , Nous pouvons prendre des mesures préventives , Pour éviter que le serveur ne s'écrase .

En général, la limitation du courant est principalement destinée à prévenir la malice Dos Accès d'affaires anormal comme une attaque ou un crawler , Par conséquent, l'approche générale consiste à éliminer directement la partie qui dépasse le seuil. .

Il existe de nombreuses façons de limiter le courant , Version autonome disponible GuavaDeRateLimiter, Distribué disponible Redis+Lua, Pour une solution plus complète, vous pouvez utiliser le sentinel.

3. Dégradation de l'interface、Fusible、isolement

En cette ère de micro - services, , Une demande de fond peut passer plusieurs fois RPCProcédure invoquée, Par conséquent, la communication normale entre le service et le service est très importante. , Nous ne pouvons pas parce qu'un service n'est pas disponible , Fait que les noeuds de toute la liaison sont touchés , Lentement, l'ensemble du service n'est pas disponible , C'est ce qu'on appelle l'effet d'avalanche. .

SiBDéfaillance du Service,CauseAService àB Toutes les demandes de services n'ont pas été traitées en temps opportun , Le résultat final est A Toutes les connexions au service sont épuisées .

Tu sais quoi?, En fait, il doit y avoir un réseau entre nos services , Bien sûr, il y aura aussi d'autres liens qui ADemandes de services.

Par exemple, il y aCDemandes directesADe,Oui.DDemandeC,Et puisCDemande à nouveauADe,Oui.EDemandes directesADe,Donc une foisA Connexion épuisée ,Ce qui signifieC/D/E Et les connexions seront épuisées , C'est comme ça que ça roule. , En fin de compte, les ressources de connexion des noeuds dans tout le maillage sont épuisées .

Comme vous pouvez le voir,, L'impact des avalanches de service est très grave , Nous devons être prudents. , Et fusible 、 La rétrogradation est un moyen très efficace .

D'abord, nous devons échouer rapidement. , Réponse à la demande une fois le délai écoulé ,Il revient automatiquement, Demander au client de demander un délai ou autre ,En dernier analyse, Nous avons besoin d'une réponse rapide dans la mesure où le service est acceptable .

Les fusibles peuvent nous aider à répondre à des demandes qui ont expiré plusieurs fois , Donner quelques solutions , Comme ne plus demander dans un certain délai ,En plus de ça,, L'isolement des ressources est également possible ,Comme pourXAppel d'interface, Juste une allocation. MRessources（ Les ressources ici se réfèrent généralement aux fils ）.

Et la dégradation peut être interprétée comme Plan B, C'est - à - dire lorsque la réponse à la demande dépasse le seuil que vous avez fixé , Quel est votre plan de secours? , Que va - t - il se passer ensuite? ？ La façon la plus simple de le faire est de donner une réponse amicale au client , Comme un service de dépannage , Tout en assurant un service stable , Peut également donner au client une bonne expérience .

Parmi euxnetlfixOpen SourcehystrixComponents,Ça peut être facile avecspring cloud Intégration écologique , Pour l'isolement des ressources 、Service fusible、 Il existe des solutions éprouvées pour la rétrogradation, etc. ,Peut essayer d'utiliser.

4. Retry Timeout

Utiliser le mécanisme de retry, Croyez - vous que la demande peut être acceptée? , Dans certains cas, l'échec d'une demande peut être simplement dû à l'instabilité du réseau. , Peut - être qu'il vaudrait mieux demander à nouveau. , À ce stade, il n'est pas préférable de retourner directement au client en cas d'échec. .

Il existe de nombreuses stratégies pour réessayer , Comme le nombre de retraits 、Fréquence, Lorsque le noeud cible est un déploiement groupé , Vous pouvez également utiliser le noeud de commutation pour réessayer, etc ,Par exemple,：Si demandéAÉchec du noeud, Passez automatiquement à la demande BNoeud.

Timeout retry peut être utilisé spring-retry,C'estspringEncapsuléAPI, Diverses stratégies de retry peuvent être définies directement par annotation ,Mise en œuvre du mécanisme de retry.

netifixOpen Sourceribbon,Équilibrer la charge en tant que client, Le mécanisme de retry est également encapsulé ,Son rez - de - chaussée est également basé surspring-retryRéalisé.

5. Idempotence

Maintenant qu'il y a un nouvel essai, il faut tenir compte de l'idémpotence ,Ce qu'on appelle l'idémpotence,En termes simples, Est d'exécuter plusieurs requêtes répétées sur une interface , Même résultat qu'une seule demande , Le concept semble très facile à comprendre , Mais pour vraiment maintenir cet objectif dans le système , C'est un design très rigoureux. .

Sauf pour réessayer. 、 Comme les notifications de rappel asynchrones 、MQ La conception de l'interface doit également garantir l'idémpotence , Ce n'est pas pour dire qu'il n'y a pas d'idéalisme sans ces conceptions. , Comme nous l'avons mentionné précédemment lors de l'examen , Le réseau lui - même a un mécanisme de retry ,Nous savons queTCPEst un Protocole de couche de transport fiable, Puisque vous voulez vous assurer que les paquets sont accessibles , Il doit y avoir un mécanisme pour réessayer. .

Il y a beaucoup de façons de garantir l'idémpotence ,Par exemple,：Verrouillage、Clé unique de la base de données、Machine d'état, etc..

6. Performance de l'interface

La performance est un sujet très vaste , Il n'y a pas d'expansion complète dans cet article , Mais il y a quelques directions , Après cela, le lecteur peut réfléchir profondément dans chaque direction .

6.1 Parallèle

Le parallélisme est la pleine utilisation CPU Une façon d'utiliser les ressources ,JDK Il y a aussi beaucoup de classes d'outils parallèles ,Par exemple,：CompletableFuture, S'il y a plus d'un lien de demande à la fois IODemande, Et ces demandes n'ont pas de dépendance séquentielle , Vous pouvez alors essayer le traitement parallèle .

Le parallélisme exige que nous contrôlions le parallélisme .

6.2 Asynchrone

Je crois en l'asynchrone. 、 Des concepts tels que la programmation réactive doivent également être bien connus , Asynchrone peut facilement obtenir un débit bien au - delà des demandes de synchronisation , Il existe de nombreux scénarios d'affaires qui sont particulièrement adaptés au traitement asynchrone , Par exemple, les notifications SMS après l'inscription d'un nouvel utilisateur 、Notification par courrier.

6.3 Cache

Mentionner l'amélioration des performances , Il doit y avoir beaucoup d'utilisation du cache , C'est en soi la conception de l'ordinateur qui décide .

Si vous avez une idée des retards d'accès à tous les niveaux , Vous pouvez prendre des mesures ciblées ,Comme dansCPUCache, Est le cache au niveau du système d'exploitation , En général, ce que nous pouvons contrôler, c'est le type d'accès , Les données dont nous avons besoin proviennent - elles du disque ou de la mémoire? , Ou une fois TCPDemande d'accès.

Bien sûr., Le cache est bon. , Mais il ne peut pas non plus être utilisé à mauvais escient. ,Après tout, les ressources sont limitées., La mémoire est beaucoup plus chère que le disque , Et le principe de la localisation de l'espace et du temps , Tu devrais tout savoir. , Si le taux de succès du cache n'est pas élevé , Ce serait contre - productif. .

6.4 Algorithmes

Nous disons que nous obtenons les mêmes résultats , Le processus de mise en œuvre peut varier ,O(n^2) La complexité temporelle de O(n)Même siO(logn) L'écart de complexité temporelle est encore évident , Cela n'est pas perceptible lorsque la quantité de données est faible , Mais une fois qu'il y a plus de données, , C'est évident. .

En plus de ça,, Il faut également tenir compte de l'utilisation de l'espace , Cela peut entraîner une fréquence élevée GC,Le résultat estCPUConsommation excessive, Même en fin de compte ,CauseOOM

7. Sécurité

Enfin, Il y a un autre sujet qui ne tourne pas rond. , C'est la sécurité de l'interface. , Si votre interface n'est utilisée que dans un réseau interne , Ne t'inquiète pas trop. , Mais si c'est une interface exposée au réseau public , Alors, il faut tenir compte de la sécurité .

Il y a beaucoup de choses à considérer pour la sécurité des interfaces ,C'est toujours pareil, Cet article ne peut que mentionner , Il n'y a aucun moyen de le faire un par un. .

7.1 Données sensibles

Les informations sensibles comprennent généralement: ,Carte d'identité、Numéro de téléphone portable、Numéro de carte bancaire、Plaque d'immatriculation、Nom, etc., Doit être traité conformément aux règles de désensibilisation .

7.2 Vulnérabilité

Contient généralement,CSRF、XSS、SQLInjection、Vulnérabilité de téléchargement de fichiers, etc.

CSRF

Demande de falsification inter - station（Anglais：Cross-site request forgery）,Aussi appelé one-click attack Ou session riding,Généralement abrégé en CSRF Ou XSRF, Est une sorte de menace pour l'utilisateur actuellement connectéWebMéthodes d'attaque pour effectuer des opérations non intentionnelles sur une application.Suivi des scripts inter - sites（XSS）Comparé à,XSS Tirer parti de la confiance de l'utilisateur dans le site Web spécifié,CSRF Profitez de la confiance du site dans le navigateur Web de l'utilisateur.

XSS

Attaque de script inter - site (Cross Site Scripting, XSS) C'est arrivé au client,Peut être utilisé pour voler la vie privée、Fraude à la pêche、 Voler le mot de passe 、 Propagation d'attaques telles que le Code malveillant . Un attaquant malveillant place du Code nuisible au client sur le serveur en tant que contenu Web , Faire en sorte que d'autres utilisateurs du site regardent cette page , Ce code est injecté dans le navigateur de l'utilisateur pour l'exécution , L'utilisateur est attaqué .En général, Attaque avec script inter - site , Session cambriolable de l'attaquant Cookie Pour voler la vie privée des utilisateurs du site .

SQLInjection

SQLL'injection signifiewebL'application ne juge pas la légitimité des données saisies par l'utilisateur ou ne filtre pas strictement,Un attaquant peutwebAjouter un supplément à la fin de l'instruction de requête prédéfinie dans l'applicationSQLDéclarations,L'extraction et l'exécution de code malveillant sont effectuées du côté du navigateur,.Ceci permet de tromper le serveur de base de données pour effectuer des requêtes arbitraires non autorisées,Afin d'obtenir plus d'informations sur les données correspondantes.

Vulnérabilité de téléchargement de fichiers

Web Lorsque l'application traite le téléchargement de fichiers , Accepter le chemin et le nom de fichier spécifiés par l'utilisateur pour le téléchargement , Un attaquant exploite cette vulnérabilité pour télécharger d'autres fichiers du serveur, même des fichiers arbitraires （Code source、 La base de données passwd Attendez.）.

7.3 Token、 Cryptage、Signature

Token Le mécanisme est principalement utilisé pour l'authentification , Dans les interfaces fournies à l'extérieur , Utilisé pour identifier le demandeur d'interface .

La signature peut être utilisée pour empêcher l'altération des données 、 .Le cryptage peut être utilisé pour empêcher les données d'être espionnées .

7.4 Noir、 Mécanisme de la liste blanche

L'utilisation du mécanisme de la liste blanche peut encore améliorer la sécurité de l'interface , Une fois que le service est disponible pour interagir avec le service , Le fournisseur d'interface peut limiter les IPPour accéder à, De cette façon, le demandeur d'interface n'a qu'à exporter IP C'est bon. .

Mécanisme de liste noire correspondant , Est l'interaction entre l'application et le client ,Parce que le clientIPTout n'est pas fixé, Le mécanisme de la liste blanche ne peut donc pas être utilisé , Mais nous pouvons encore utiliser la liste noire pour intercepter certaines demandes qui ont été identifiées comme illégales. IP.