Lifting du système : application pratique du modèle de conception de la chaîne de responsabilité (explosion, le délai de développement a été réduit de 45 jours à 1 jour)

Application chinoise open source, commencez ! Il s’agit d’une toute nouvelle version que vous n’avez jamais vue auparavant.

Cet article présente le contexte et l'expérience de l'utilisation du modèle de conception de chaîne de responsabilité, afin que les lecteurs puissent approfondir leur impression de ce modèle de conception, et même être inspirés pour « looker » les projets dans lesquels ils sont actuellement impliqués et dont ils sont responsables, améliorant ainsi la « lifting » du système. Partagez chaque détail de votre travail.

1. Origines

Il existe un tel module dans le système dont je suis responsable, le module de partition. Si vous regardez ce mot directement, je pense que beaucoup de gens seront confus ou même mal compris. En fait, sa véritable signification est « routage ». Je vais décrire brièvement ce qu'est le « routage ».

Je pense que tout le monde a eu une expérience d'achat en ligne. Chaque fois que nous passons une commande, nous pouvons vérifier l'état du suivi logistique de la commande à tout moment et n'importe où. Le concept de « routage » mentionné ci-dessus fait référence : au transport de la commande d'un point A à un point. B. La ligne de routage, par exemple, la commande order1 doit être transportée de A à la destination F. Elle peut aller de A->B->D->F, ou de A->D->F Quant à l'itinéraire à suivre. être prises, cela dépend de Les itinéraires configurés dans le système et les règles de correspondance correspondantes sont filtrées.

Pendant longtemps, la configuration et les règles de routage du système ont été statiques (ce qu'on appelle statique signifie qu'elles ont été configurées à l'avance et sont presque fixes. L'inconvénient de cette approche est évident, c'est-à-dire que le coût ne peut pas). être contrôlé, comme mentionné ci-dessus, dans l'exemple cité, il existe évidemment des possibilités de réduire l'itinéraire de transport, voire de le livrer directement (les marchandises de A à F peuvent évidemment remplir N camions, mais elles doivent être transportées selon l'itinéraire). établis dans le système), mais ils sont bloqués par le système. En raison des règles d'itinéraire fixes, nous ne pouvons emprunter que plus de routes, ce qui augmente le coût des opérations de main d'œuvre et de transport.

Sur cette base, un expert a découvert une opportunité commerciale pour réduire les coûts et augmenter l'efficacité : activer cette ligne et ces règles de routage, afin que le système puisse être compatible de manière plus flexible avec les situations ci-dessus et atteindre l'utilisation ultime des ressources : Par exemple : Par exemple, s'il y a plusieurs commandes, elles sont toutes destinées de A à la destination F. La configuration de la ligne statique dans le système est uniquement A->B->D->F. Cependant, après surveillance et calcul du système, il a été constaté que le. La quantité de marchandises de A à F peut remplir deux camions. Ensuite, à ce moment, un nouvel itinéraire est temporairement généré pour ces commandes de A à F. En même temps, les marchandises sont reçues et expédiées sur le site A. Tout lien pratique. impliquant la correspondance des lignes de routage est compatible avec ce scénario de routage temporaire, de sorte que le coût global peut être réduit sans changer les habitudes des utilisateurs, et l'efficacité du transport vers la destination a également été considérablement améliorée.

Le plan proposé par cet expert était très bon et a été largement reconnu et salué par tous. Une fois le projet établi, il est entré dans une phase de développement vigoureuse et j'ai eu la chance de me voir confier la tâche importante de diriger le développement et la livraison du projet. ce projet.

Il convient de mentionner que les modifications apportées au circuit de routage s'étendent à tout le processus opérationnel réel de la commande ainsi qu'à certaines requêtes auxiliaires de bout en bout, rapports statistiques et autres fonctions. De nombreux scénarios sont impliqués, donc la pression est toujours là. assez élevé, même s'il est vrai qu'au cours de cette période, nous avons fait beaucoup de détours, mais le résultat final a été bon. Même plus tard, il y a eu plusieurs besoins similaires pour changer de lignes de routage. Mais sur la base de cette transformation, nous pouvons facilement y faire face. . Cela sera discuté plus loin dans l'article. Cela se reflétera dans l'effet.

Cela dit, pensez-vous que tout cela n'a aucun sens ? Haha, c'est effectivement un peu long. Ensuite, jetons un coup d'œil à Menghui Road et reproduisons l'ensemble du processus de transformation qui est fragmenté mais qui a un sentiment d'accomplissement. .

2. Idées et méthodes

Le partitionnement mentionné dans les articles suivants est la signification des règles de correspondance pour le routage

Tout d’abord, examinons un diagramme schématique simple du processus de fonctionnement pratique.

Les règles de correspondance de partition seront impliquées dans le processus de fonctionnement réel de chaque site.Dans le même temps, les règles de correspondance de routage seront également impliquées dans la fonction de requête ou la fonction de rapport de certaines opérations auxiliaires, donc une fois que les règles de correspondance de partition devront être modifiées, alors vous serez confronté aux problèmes suivants

◦Tout d'abord, au niveau métier, cela couvrira presque tout le processus, qu'il s'agisse d'évaluation, de développement, de tests, etc., il sera confronté au problème d'une charge de travail énorme.

◦Encore une fois, au niveau du système, l'état actuel de cette partie du code est également très hostile, se reflétant principalement dans :

▪Les règles métier de base de la correspondance de partition sont cohérentes, mais le code est écrit différemment et dispersé, ce qui le rend difficile à lire et à maintenir, et il comporte également le risque de scénarios manquants.

▪La fonction de correspondance de partition est actuellement écrite par chaque instance et couplée dans chaque scénario d'utilisation. Elle n'est pas évolutive. Une fois les règles changées, le coût de modification est très élevé.

Sur la base des points douloureux ci-dessus, j'ai décidé de restructurer et de rectifier ce module. Premièrement, je vais m'améliorer grâce à ce défi, et deuxièmement, j'ouvrirai également la voie à la possibilité de changer à nouveau cette règle à l'avenir. dois-je faire spécifiquement ? Comment résoudre les problèmes mentionnés ci-dessus ? C'est ce que j'ai fait

1. Faire une évaluation approfondie au niveau business : reflétée dans la conception détaillée du développement (comme je connais très bien les règles métier, c'est mon avantage haha), comme le tri des scènes, la modification du plan, et même dans la conception Le schéma logique de modification et l'emplacement du code de fonctions spécifiques (clics sur les boutons, appui sur les déclencheurs après avoir saisi dans la zone de saisie, etc.) ont été approfondis dans les moindres détails, afin que tous les développeurs participants puissent l'utiliser comme guide pour une utilisation rapide. développement, et les testeurs peuvent l'utiliser pour cela. Cela sert de guide pour rédiger des cas d'utilisation, et le personnel produit l'utilise comme dictionnaire pour approfondir sa propre compréhension de cette activité, etc. Cela n'a-t-il pas l'air génial ? Hahaha, c'est un peu de la vantardise ici. Cet article ne se concentrera pas sur cela, il présente principalement le modèle de conception.

2. C'est notre point fort. Au niveau du système, cela se reflète principalement dans le code. Après tout, peu importe à quel point vous le dites, si vous ne pouvez pas implémenter le code et voir l'effet, tout cela est en vain. nous sommes dans une position. D'accord, pas beaucoup de bêtises. Dites, continuez à regarder ma performance haha.

▪Tout d'abord , les modules de base correspondant aux partitions sont unifiés et une seule instance est conservée dans le système pour fournir des services. Cela peut non seulement résoudre le problème des coûts de maintenance élevés du code dispersé, mais également éviter le risque de scénarios manquants.

Voyant cela, certaines personnes pourraient se demander si cela posera un autre problème : bien que les scènes ne soient pas manquées, une fois le changement de code atteint, toutes les scènes prendront effet, mais les scènes originales de certaines scènes seront-elles modifiées ? Je pense que les étudiants ici sont en effet très prudents. Si la fermeture est forcée, ce nouveau problème se posera effectivement, donc la fermeture unifiée doit prendre en charge l'expansion et réserver des hooks pour prendre en charge le traitement différencié de chaque scène. C'est plutôt abstrait. Par exemple : Par exemple, la règle générale du scénario est que toutes les commandes sont transportées selon les règles de zonage de la configuration établie du système, mais maintenant certains commerçants ont ouvert certains services pour livrer rapidement à destination, alors pour ceux-ci commandes des commerçants Il n'est plus possible d'utiliser les règles générales existantes pour l'appariement des partitions et le transport. Il est nécessaire d'effectuer l'appariement des partitions selon les nouvelles règles pour atteindre l'objectif d'un transport rapide. C'est la différence à l'intérieur.

▪Réutilisez les structures de données existantes, ajoutez des types de partition et ajustez les services SQL et de service correspondants (ce n'est pas le sujet de cet article, je n'entrerai donc pas dans les détails) et prenez en charge l'expansion des règles de partition sur la base de la compatibilité avec logique de production existante.

▪Ajuster la structure du code des règles de correspondance de partition en fonction de l'idée de modèles de conception : adopter le modèle de chaîne de responsabilité (c'est ici l'objet de cet article)

Alors, quel est exactement le modèle de chaîne de responsabilité ?

La définition donnée par Daniel : donner la possibilité à plusieurs objets de traiter des requêtes, évitant ainsi la relation de couplage entre l'émetteur et le destinataire de la requête. Ces objets sont connectés dans une chaîne et la requête est transmise le long de la chaîne jusqu'à ce qu'un objet la gère.

Parlons de la façon dont je l'applique en fonction de l'activité réelle du système existant : j'ai déjà introduit en arrière-plan du chapitre d'ouverture que les règles de correspondance de partitions existantes sont des correspondances de partitions statiques (telles qu'un certain point d'affaires à point, un certain point commercial vers une zone de plage) Attendez, je n'entrerai pas dans les détails spécifiques de l'entreprise. Sachez simplement qu'il y a beaucoup de règles de correspondance ici.) Nous devons maintenant ajouter une nouvelle règle pour prendre en charge la dynamique (c'est aussi une variété). de correspondance, je n'entrerai donc pas dans les détails). Ici, je définis chaque règle de partition comme un type de partition et chaque type de partition comme un nœud de partition. Tissez ces nœuds dans une chaîne, afin que chaque requête puisse trouver une ligne correspondante. cette chaîne de transport.

Étant donné que les détails commerciaux sont relativement sensibles, ils ne seront pas divulgués en détail dans l'article, ce qui n'affectera pas la compréhension de l'application des modèles de conception clés.

En combinant la définition et l’analyse ci-dessus, la situation réelle est-elle adaptée à l’utilisation du modèle de conception de chaîne de responsabilité ? Je pense que tant que les problèmes ci-dessus peuvent être résolus et que les avantages globaux l’emportent sur les inconvénients, alors cela est applicable. Premièrement, les avantages de l’utilisation de ce modèle pour transformer sont les suivants :

◦ Demandes et traitements séparés (sans couplage avec les opérations commerciales, ne vous souciez pas de l'origine de la demande, concentrez-vous simplement sur la correspondance des règles de partition)

◦Amélioration de la flexibilité et de l'évolutivité du système (s'il y a de nouvelles règles, il suffit d'ajouter des nœuds)

Bien entendu, ce modèle présente également certains défauts : lorsque la chaîne de responsabilité est relativement longue, puisque chaque requête va parcourir toute la chaîne, il peut y avoir des problèmes de performances. En même temps, le débogage peut être plus compliqué pour les étudiants qui ne comprennent pas. les affaires.

Dans l'ensemble, l'avantage est qu'il résout nos problèmes actuels et facilite l'expansion ultérieure, tandis que la partie performances des inconvénients peut être ignorée en combinant les fonctions de hook réservées en mode modèle (si la requête actuelle ne convient pas au nœud de partition actuel règles ) pour minimiser l'impact des problèmes de performances, et en même temps, il est également nécessaire que les développeurs comprennent le métier. Il semble donc que, globalement, les avantages l’emportent sur les inconvénients.

Cela dit, jetons d’abord un coup d’œil à un simple diagramme de comparaison du module de partition avant et après la transformation.

Bien que le diagramme soit très simple, le sens de la comparaison est encore évident.Avant la transformation : la correspondance de partition et le traitement métier sont couplés après la transformation : la correspondance de partition est une chaîne et il n'y a pas de traitement de logique métier dedans ; Les extensions libérées du couplage sont également prises en charge. Certaines personnes peuvent être confuses après avoir vu ceci : ce qui précède ne dit-il pas qu'une seule règle de correspondance dynamique a été ajoutée ? Pourquoi y a-t-il tant de nœuds dans la chaîne, et il y a encore deux chaînes ? Permettez-moi de vous expliquer un peu ici : les deux chaînes actuelles ont connu de nombreux changements de version de demande. À l'heure actuelle, il semble que la différence ne soit pas grande, principalement parce que les scénarios spécifiés par l'entreprise source qu'elles fournissent sont différents les uns des autres. interférant avec leurs opérations respectives, les nœuds introduits à de nombreux endroits dans cet article ont également été ajoutés plus tard, et sont toujours les règles de nœuds utilisées dans le système jusqu'à présent (c'est ce que j'ai mentionné au début de l'article : Et s'il y avait). Il y a des changements de règles plus tard. Bien sûr, c'est toujours aussi intelligent que moi, la "prophétie" s'est réalisée. En effet, je vais vous dire l'importance de soutenir l'expansion ici pour raccourcir la période de construction.)

3. Processus pratique

Je pense que de nombreux lecteurs constateront que ce qui précède parle de clôture unifiée et de combinaison avec le mode modèle pour éviter au maximum l'impact sur les performances, de sorte que votre chaîne de responsabilité ne peut pas être prise en charge par un seul mode de conception.

Oui, vous avez raison, Smart. Il est vrai que le simple fait d'utiliser un seul modèle de conception de chaîne de responsabilité est loin d'obtenir l'effet mentionné ci-dessus. Ici, nous combinons l'usine, le modèle et la chaîne de responsabilité. Obtenez le bean de la chaîne.Le modèle est utilisé pour définir les méthodes générales, les appels entre méthodes et les commutateurs, le pré- et post-traitement, la différenciation et d'autres méthodes réservées à l'implémentation des sous-classes.La chaîne de responsabilité est utilisée pour combiner divers nœuds. sont quelques exemples simples. Le nœud affiche le diagramme de classes comme suit.

Cette section est relativement simple.Après tout, il ne s'agit que de codage.Le diagramme de classes ci-dessus est presque une application pratique dans le code et constitue également la partie centrale du code.Dans les appels réels, la chaîne de beans est obtenue via l'usine pour des raisons spécifiques. correspondance de partition.

4. Réflexions sur le processus de pratique et évaluation des effets

Les résultats après la transformation se reflètent principalement dans l'expansion et la maintenance ultérieures. Comme mentionné au début de l'article, une fois les règles de correspondance des partitions modifiées, il y aura deux problèmes. La manifestation la plus directe se situe dans la période de construction. première fois que je prends ce bloc Lors de la modification des exigences des nouvelles règles de routage, la période globale de construction réelle est de 45 jours côté R&D, sans compter qu'une fois un BUG rencontré, la période de test n'est pas garantie (correspondant aux nœuds dynamiques dans les nœuds de la figure ci-dessus)

Mais peu de temps après, de nouvelles exigences en matière de règles de correspondance ont été ajoutées (correspondant au nœud de covoiturage dans le nœud ci-dessus). Pour des exigences similaires, la période de construction a été réduite de près de moitié et les 45 jours optimaux ont été réduits à 27 jours. l'exigence inclut également Pour la transformation d'autres modules non partitionnés, bien sûr, la transformation de la première version présentait certains aspects parfaits. Après ce délai, elle a été optimisée en fonction des besoins de.

Les deux suivants incarnent réellement ce qu'on appelle la disparition de la période de construction. L'une est la première exigence de règle de zonage du conseil, et l'autre est la règle de zonage direct dans les récentes exigences d'intégration du réseau B.

◦Le délai de construction pour la distribution directe est de 2 jours

◦La période de construction du premier zonage du conseil n'est que d'un jour

Pour être honnête, je ne m'attendais pas à un effet aussi important si je n'ai pas examiné les données. Avec le recul, qui aurait pensé que l'application d'un modèle de conception pouvait raccourcir la période de construction. 45 jours pour 1 Dieu, c'est incroyable.

Bien sûr, certains domaines peuvent également être améliorés et mis à niveau. À l'heure actuelle, l'assemblage des nœuds de la chaîne de responsabilité est spécifié manuellement et peut être modifié en assemblage automatique (je l'ai déjà implémenté dans la transformation d'un autre scénario commercial, et cela sera également effectuée ici. Transformation synchrone), une autre consiste à contrôler le nombre de nœuds. Si le nombre est trop grand, vous devrez peut-être envisager une solution de compatibilité.

Comme le dit le proverbe, il ne faut pas un jour pour percer une goutte d'eau, et il ne faut pas un jour pour geler un mètre de glace. Il est certainement possible d'utiliser des outils puissants et de nouvelles technologies, mais ne le faites pas. N'oubliez pas les petits changements dans le travail quotidien. Dans peu de temps, vous ne pourrez peut-être rien voir, mais une fois que les changements quantitatifs entraîneront des changements qualitatifs, je pense que les résultats seront très impressionnants.