L'évolution du modèle de projet
1. Architecture d'application unique (ORM)
Object-Relationl Mapping, son rôle est de faire un mappage entre la base de données relationnelle et l'objet, de sorte que lorsque nous exploitons spécifiquement la base de données, nous n'avons pas besoin de traiter des instructions SQL complexes, tant que nous fonctionnons comme des objets normaux. Cela fera l'affaire
.
Un projet comprend des modules utilisateur, des modules de produit, des modules de gestion des droits, des modules de commande, des modules de financement, etc.
(le tout dans un seul projet) tel que le système de loterie à l'étape de base précédente. Système de gestion des livres
Avantages: développement simple, adapté aux petits trafics, une architecture unique centralise toutes les fonctions, réduisant les coûts de déploiement.
Inconvénients: si l'échelle devient plus grande, le trafic devient plus important, l'expansion, le développement secondaire et la maintenance, les coûts de maintenance élevés ne sont pas propices à l'expansion.
2. Architecture d'application verticale
Stupéfié quand j'en ai entendu parler pour la première fois? Quelle est l'architecture d'application verticale. Voir divers matériaux signifie superposer . C'est juste la superposition.
Le contrôleur --service-mapper
est illustré dans la figure ci-dessous
: Inconvénients: dans une architecture verticale, il peut y avoir une logique métier dupliquée entre les projets et la logique métier doit être répliquée en continu. Ne peut pas être réutilisé.
Avantages: Le problème de l'expansion de la capacité est résolu et le trafic peut être distribué à différents sous-systèmes.
Troisièmement, l'architecture d'application distribuée (appel de service à distance RPC)
Lorsqu'il y a de plus en plus d'applications verticales, l'interaction entre les applications est inévitable. Le cœur de métier est extrait en tant que service indépendant, formant progressivement un centre de service stable
RPC (Remote Procedure Call Protocol): appel de procédure à distance:
Deux serveurs A et B déploient respectivement différentes applications a et b. Lorsque le serveur A souhaite appeler une fonction ou une méthode fournie par l'application b sur le serveur B, il ne peut pas être appelé directement car il ne se trouve pas dans un espace mémoire. Il doit exprimer la sémantique de l'appel pour acheminer les données appelées à travers le réseau.
RPC est un protocole qui demande des services à des programmes informatiques distants sur le réseau sans comprendre la technologie réseau sous-jacente. Le protocole RPC suppose l'existence de certains protocoles de transmission, tels que TCP ou UDP, pour transporter des informations et des données entre les programmes de communication. Dans le modèle de communication réseau OSI, RPC couvre la couche de transport et la couche d'application. RPC facilite le développement d'applications, y compris plusieurs programmes distribués en réseau. RPC adopte un modèle client / serveur. Le demandeur est un client et le fournisseur de services est un serveur. Tout d'abord, le processus d'appel client envoie un message d'appel avec des paramètres de processus au processus de service, puis attend le message de réponse. Du côté du serveur, le processus reste en veille jusqu'à ce que les informations d'appel arrivent. Lorsqu'un message d'appel arrive, le serveur obtient les paramètres du processus, calcule le résultat, envoie le message de réponse, puis attend le message d'appel suivant. Enfin, le processus appelant client reçoit le message de réponse, obtient le résultat du processus, puis l'exécution de l'appel se
poursuit.
Par exemple: avant dans la simulation distribuée en utilisant httpclient pour appeler d'autres interfaces.
Quatrièmement, l'architecture informatique mobile (SOA)
Architecture orientée services
Avec le développement de l' architecture orientée services , il y a de plus en plus de services, et les appels et dépendances entre les services deviennent de plus en plus complexes. L'architecture orientée services (SOA) est née, et elle en découle Une série de technologies correspondantes ont été développées, comme un cadre de service qui encapsule des comportements tels que la fourniture de services, l'invocation de services, le traitement de connexion, le protocole de communication, la méthode de sérialisation, la découverte de services, le routage de services, la sortie de journal, etc.
Architected en couches, en utilisant cette méthode peut découpler les couches (ou maximiser le couplage lâche)
L'extension distribuée est soa
self (expliquée selon mes propres pensées):
S'il n'y a que cinq ou six services distribués, vous pouvez utiliser des services distribués. Si vous avez des dizaines de cœurs distribués, la logique est très compliquée. Si le service principal tombe en panne, vous devez toujours trouver Pendant longtemps. Soa donc lentement proposé. Système d'architecture orienté services.
dubbo + zookeeper est l'architecture SOA. Il existe deux architectures SOA couramment utilisées: dubbo et springcloud,
architecture de service dubbo
Avec le développement de la technologie, nous devons diviser certaines fonctions commerciales de manière plus fine, et nous pouvons avoir à appeler entre les services, pas seulement les appels entre WEB et Service, donc une architecture de
microservice a été produite. Springcloud
La compréhension actuelle est limitée et vous êtes invités à donner des conseils. Merci canard