I. Einleitung
Der Architekturentwurf kann je nach Implementierungsprozess in mehrere Dimensionen wie technische Architektur, Geschäftsarchitektur und Bereitstellungsarchitektur unterteilt werden. Ein guter Systemarchitekturstandard sollte die Merkmale Skalierbarkeit, Wartbarkeit, Zuverlässigkeit, Sicherheit und hohe Leistung aufweisen. Obwohl diese Funktionen jedem bekannt sind, sind wir mehr daran interessiert, den Schlüsselpfad zum Erreichen dieser Anforderungen zu kennen, um diese Funktionen in den Architekturentwurf zu integrieren. Nur so können wir sicherstellen, dass sich das System an zukünftiges Geschäftswachstum und Liefereffizienz anpassen kann. Dieser Artikel konzentriert sich auf die Durchführung des Entwurfs einer technischen Architektur.
2. Wert zuerst
Wenn im Plan Unklarheiten bestehen, ist es sehr wichtig, den Plan zu prüfen und eine Entscheidung aus der Perspektive des (kommerziellen) Produktwerts zu treffen;
Zwei Missverständnisse, denen Technologie ausgesetzt ist:
Ankömmlinge werden nicht abgelehnt : Die vom Produktmanager geäußerten Anforderungen sind alle angemessen und ich bin dafür verantwortlich, sie zu erfüllen.
Technologiegetrieben : Diese Art der Technologieimplementierung ist besonders raffiniert und ermöglicht die Anpassung von Produktfunktionen an die Technologieimplementierung.
Die oben genannten beiden Arten von Missverständnissen können leicht zu Abweichungen im Verständnis von F&E über den Produktwert führen und leicht einen subversiven Einfluss auf nachfolgende technische Iterationen haben. Aus der Perspektive des (kommerziellen) Werts des Produkts können alle an der Zusammenarbeit beteiligten Parteien die Probleme aus einer gleichberechtigten Perspektive betrachten. Es kann nicht nur einfacher sein, einen Konsens zu erzielen, sondern auch die Geschäftsentwicklung und Technologieiteration besser planen zu können.
Software ist ebenfalls ein Produkt, und wenn das System entworfen wird, dreht es sich auch um mehrere Produktionsfaktoren wie Markt, Organisation und Ressourcen.
Der Markt ist das Ziel unserer Produkte, die die Grundlage unseres Bausystems bilden;
Die Organisation dreht sich um den Ressourcenkoordinierungs- und Garantiemechanismus im Produktlieferungsprozess.
Ressourcen sind die Produktionsmaterialien wie Maschinen, Personal, Zeit, Betriebsabläufe usw., die rund um das Produkt investiert werden;
Softwareentwicklung ist eine Produktions- und Managementaktivität, bei der es um das Verhältnis von Input zu Output (ROI) geht. Skalierbarkeit, Wartbarkeit, Zuverlässigkeit, Sicherheit und hohe Leistung sind allesamt Merkmale unserer Produkte, und für die Realisierung jedes Merkmals sind erhebliche Investitionen erforderlich.
Die Geschwindigkeit des Sportwagens ist das herausragendste Merkmal und geht zu Lasten der Anpassungsfähigkeit an den Straßenzustand, des Fahrkomforts und der Fahrsicherheit;
Das Highlight von Geländefahrzeugen ist die Anpassungsfähigkeit an den Straßenzustand, was zu Lasten von Geschwindigkeit und Komfort geht.
Das Auto hat ein relatives Gleichgewicht zwischen Anpassungsfähigkeit an den Straßenzustand, Fahrkomfort, Fahrsicherheit und Fahrgeschwindigkeit erreicht und ist zu einem gängigen Transportmittel geworden.
Wie das Sprichwort sagt: „Der General ist unterwegs, nicht hinter dem kleinen Hasen her“, gibt es immer einen Kompromiss. Wir streben nicht danach, ein perfektes komplexes System zu schaffen, aber wir können unter begrenzten Bedingungen Spitzenleistungen anstreben!
3. Architekturdesign
Architekturmuster beschreiben die Beziehungen, Verantwortlichkeiten und Interaktionsmethoden zwischen verschiedenen Komponenten in einem Softwaresystem und stellen so eine Spezifikation und Einschränkung für den Softwareentwurf bereit und verbessern so die Effizienz der Softwareproduktion. Dies spiegelt sich hauptsächlich in den folgenden zwei Aspekten wider:
Helfen Sie Entwicklern, Softwaresysteme besser zu organisieren und zu entwerfen;
Fördern Sie die Zusammenarbeit und Kommunikation zwischen Teams und erleichtern Sie den Teammitgliedern das Verständnis und die Aufteilung der Arbeit.
3.1 Engineering-Rahmen
Neue Systeme beginnen häufig mit dem Aufbau des grundlegenden technischen Rahmens des Projekts, einschließlich technischer Einschränkungen wie Verzeichnisstruktur, Konfigurationsdateien und Codevorlagen. Sie werden hauptsächlich zur Standardisierung der Projektstruktur, der Verantwortungsgrenzen und des Codestils verwendet, wodurch die Codequalität verbessert wird Wartbarkeit. Berücksichtigen Sie insbesondere folgende Aspekte:
Die Abhängigkeiten und Interaktionsmethoden jedes Moduls werden vereinbart;
Standardisieren Sie das Schnittstelleninteraktionsprotokoll.
Einheitliche Ausnahmecodierung, -erfassung und -behandlung;
Standardisieren Sie das Protokolldruckformat.
Andere öffentliche Normbeschränkungen;
Im Folgenden finden Sie einige praktische Ideen zur am häufigsten verwendeten Schichtarchitektur und DDD-Architektur.
3.1.1 Schichtarchitektur
Es gibt viele Formen der Schichtarchitektur, wie z. B. MVC, sechseckige Architektur usw., die sich mit der Entwicklung von Geschäft und Technologie schrittweise weiterentwickelt haben.
In den Anfängen des Internets war die Form von Internetprodukten aufgrund von Faktoren wie schlechter Computerhardwareleistung, langsamer Netzwerkgeschwindigkeit und hohen Speicherkosten relativ einfach und nur relativ einfache Produkte wie einfache Portal-Websites usw BBS-Foren könnten realisiert werden. In der damaligen technischen Architektur gab es kein Layering-Konzept, und es wurden hauptsächlich Skriptsprachen wie ASP, JSP und PHP verwendet. In diesen Skripten wurden häufig HTML, JavaScript, CSS und SQL gemischt und geschrieben Dateien. Mit der Entwicklung der Internettechnologie und der Online-Attraktivität komplexerer Unternehmen sind nach und nach die Nachteile dynamischer Skriptsprachen zutage getreten. Nehmen Sie als Beispiel die JSP-Skriptsprache:
Komplexität : Die Entwicklung und Wartung der JSP-Skriptsprache ist komplizierter, da sie sich mit der Mischung von Java-Code und HTML-Code befassen muss.
Sicherheit : Die JSP-Skriptsprache ist anfällig für Sicherheitslücken wie SQL-Injection-Angriffe, was zu Systeminstabilität oder Angriffen führt.
Skalierbarkeit : Die Skalierbarkeit der Skriptsprache ist relativ begrenzt, da Java-Code direkt in die HTML-Seite geschrieben werden muss, was zu einer unklaren Systemstruktur führt;
Um die oben genannten Probleme zu lösen, sind verschiedene Frameworks entstanden, wie z. B. Spring, Struts usw. Diese Frameworks ersetzten nach und nach die JSP-Skriptsprache und schlugen auch das Konzept der Schichtarchitektur vor. Das typischste davon ist das MVC-Architekturmuster (Model, View, and Controller), dessen Hauptzweck darin besteht, verschiedene Teile der Anwendung zu entkoppeln und so die Wartung und Erweiterung zu erleichtern. Die spezifische Implementierung ist wie folgt:
Trennung von Bedenken : Durch die Aufteilung der Anwendung in drei Hauptteile kann jeder Teil unabhängig entwickelt und getestet werden, was zu einer besseren Trennung von Bedenken führt.
Verbessern Sie die Wartbarkeit : Aufgrund der Trennung der Belange auf drei Ebenen ist es einfacher, verschiedene Teile der Anwendung zu warten und zu ändern.
Verbessern Sie die Skalierbarkeit : Anzeigelogik und Geschäftslogiksteuerung sind getrennt, was die Erweiterung verschiedener Teile der Anwendung erleichtert.
In einer mehrschichtigen Architektur verwendet die Ansichtsschicht normalerweise ein vorlagenbasiertes Framework (wie Thymeleaf, Freemarker, Velocity) oder einen separaten Technologie-Stack (wie Vue.js, React). Die Weiterentwicklung dieser Technologien kann komplexere Probleme lösen, wie z. B. Finanzversicherungs- und E-Commerce-Szenarien, wird aber auch einige neue Schwachstellen mit sich bringen:
Steile Lernkurve : Da das MVC-Architekturmuster von Entwicklern verlangt, mehrere Konzepte und Technologien zu verstehen und zu beherrschen, ist die Lernkurve steil;
Erhöhte Komplexität : Da das MVC-Architekturmuster die Anwendung in mehrere Teile unterteilen muss, erhöht es die Komplexität der Anwendung.
Längere Entwicklungszeit : Es sind mehr Test- und Integrationsarbeiten erforderlich, was die Entwicklungszeit verlängert.
Um die Effizienz der Produktlieferung zu verbessern und technische Schwellenwerte zu senken, wird die moderne Forschungs- und Entwicklungsarbeit normalerweise in mehrere Positionen unterteilt, darunter Front-End-Entwicklung, Back-End-Entwicklung, Qualitätstests, Betriebs- und Wartungsgarantie usw. Diese Positionen müssen zusammenarbeiten, um Produktforschungs- und -entwicklungsaufgaben zu erfüllen. Um die ordnungsgemäße Zusammenarbeit zwischen mehreren Geschäftsbereichen und mehreren Positionen sicherzustellen und Prozessrisiken effektiv zu verwalten und zu kontrollieren, gibt es in der Regel Projektmanagementpositionen.
Die MVC-Architektur trennt den Fokus von der gesamten Geschäftsimplementierung, aber in komplexeren Großprojekten, insbesondere im Szenario der Zusammenarbeit mehrerer Personen und der Parallelität mehrerer Dienste, erscheint die MVC-Architektur oft machtlos. Zu diesem Zeitpunkt muss eine feinere Aufteilung vorgenommen werden, um die Parallelität mehrerer Geschäftsbereiche ohne große Aufgabenressourcenkonflikte zu erreichen. Natürlich gibt es in verschiedenen Geschäftsszenarien unterschiedliche Aufteilungsmodi. Der häufigste Aufteilungsmodus ist der mehrschichtige Architekturmodus, wie in der folgenden Abbildung dargestellt:
Durch die horizontale Schichtarchitektur haben wir die Arbeitsteilung und Zusammenarbeit in Forschung und Entwicklung realisiert und alle Erfahrungsbeschränkungen spiegeln sich hier wider. In der Abbildung oben ist die Kontrollebene zweifach unterteilt. Es kann auch entsprechend dem tatsächlichen Anwendungsszenario nachjustiert werden. Ob sich das Webmodul beispielsweise auf das RPC-Modul verlassen kann, kann in der POM-Datei eingeschränkt werden, sodass jeder die Entwicklungsarbeit gemäß der bestehenden Projektvereinbarung umsetzen kann.
Beschreiben Sie kurz die Rolle der einzelnen Modulschichten:
Datenzugriffsschicht : Die Entkopplung der Geschäftslogikschicht und der Datenspeicherschicht gehört zur Kategorie der Modellschicht. Es interagiert mit den zugrunde liegenden Datenquellen (MySQL, Hbase, EleasicSearch). Zu den gängigen Frameworks gehören: MyIbatis, Hibernate usw.;
Remote-Anrufschicht : Die RPC-Schicht ist eine Datenzugriffsschicht parallel zur DAO-Schicht. Der Unterschied besteht darin, dass sie Zugriffsfunktionen über Schnittstellen oder Plattformdienste von Drittanbietern bereitstellt. Der Unterschied zur DAO-Schicht besteht im Dateneigentum und in der Domänentransaktionskontrolle.
Transaktionsverwaltungsschicht : Wird auch als allgemeine Geschäftsverarbeitungsschicht bezeichnet und weist die folgenden Merkmale auf:
◦Für das übergeordnete Unternehmen werden die Geschäfts- und Technologie-Sharing-Funktionen verringert, wie zum Beispiel: einheitliche Auftragsproduktionskapazität für mehrere Geschäftsformate, allgemeine verteilte Transaktionskonsistenzlösungen usw.;
◦Verlassen Sie sich auf die untere Schicht, kombinieren Sie die Funktionen der DAO-Schicht und der RPC-Schicht und realisieren Sie die Transaktionsverwaltung eines einzelnen Unternehmens.
◦Bei einfachen Geschäftssystemen kann die Verantwortung der Managerschicht durch die Serviceschicht ersetzt werden;
4. Geschäftslogikschicht : Relativ spezifische Geschäftslogik-Dienstschicht, die hauptsächlich für die Zusammenstellung und Anordnung von Geschäftsprozessen verantwortlich ist. Hier spiegeln sich hauptsächlich die tatsächliche Flexibilität und Skalierbarkeit wider.
5. Anforderungsverarbeitungsschicht : Hauptsächlich Weiterleitung der Zugriffskontrolle, Gestaltung von Eingabeparametern, Anpassung von Ausgabeparametern usw. Seine Verantwortung besteht darin, jedes Terminal oder jeden Drittanbieter direkt zu kontaktieren.
6. Offene Dienstschicht : Definieren Sie den extern bereitgestellten RPC-Dienst. Die funktionalen Verantwortlichkeiten ähneln denen der Webschicht. Faktoren wie Gateway-Sicherheitskontrolle und Flusskontrolle müssen ebenfalls berücksichtigt werden.
7. Terminal-Anzeigeebene : Vorlagenrendering und Ausführungsanzeige jedes Terminals, Geschwindigkeit, Reaktion, mobiles IOS-Terminal usw.;
Herkömmliches Softwaredesign führt oft zu einer engen Kopplung zwischen verschiedenen Komponenten, was die Wartung und Erweiterung des Codes erschwert. Das hexagonale Architekturmuster ist eine Variante des Schichtmusters, das ein lose gekoppeltes Design durch die Trennung der Geschäftslogik von technischen Details wie Frameworks und Bibliotheken erreicht und so die Wartung und Erweiterung des Codes erleichtert . Gleichzeitig kann das hexagonale Architekturmuster Entwicklern auch dabei helfen, Unit-Tests und Integrationstests besser umzusetzen und so die Softwarequalität zu verbessern. Dies ist in verschiedenen technologiebasierten Geschäftsszenarien sehr nützlich, wie in der folgenden Abbildung dargestellt:
3.1.2 DDD-Architektur
Domain-Driven Design (DDD) ist eine Softwareentwicklungsmethode, die sich auf die Geschäftsdomäne konzentriert. Durch ein tiefes Verständnis des Geschäftsdomänenwissens wird die Geschäftslogik in das Domänenmodell gekapselt, um eine bessere Wartbarkeit und Wartbarkeit des Codes zu erreichen. Skalierbarkeit und Wiederverwendbarkeit.
DDD gehört zu einer losen Schichtarchitektur und die Verantwortlichkeiten und Funktionen jeder Schicht sind wie folgt:
Benutzeroberflächenschicht: externe Eingabeanforderungen wie Webanforderungen, RPC-Anforderungen und MQ-Nachrichten;
Anwendungsschicht: Verantwortlich für Orchestrierung, Weiterleitung, Überprüfung usw. und unterscheidet sich von der Serviceschicht in MVC, in der eine große Menge an Geschäftslogik gespeichert ist.
Domänenschicht: Dies ist die Modellschicht, die für die Darstellung von Geschäftskonzepten, Geschäftsstatus und Geschäftsregeln verantwortlich ist. Enthält alle komplexen Geschäftswissensabstraktionen und Regeldefinitionen in diesem Bereich, einschließlich Entitäten, Wertobjekten, Aggregaten (Aggregatwurzeln), Domänendiensten, Domänenereignissen, Lagerhaltung, Fabriken usw.;
Infrastrukturschicht: Bereitstellung von Persistenzmechanismen und anderen allgemeinen technischen Supportfunktionen für das Domänenmodell, z. B. Nachrichtenkommunikation, allgemeine Tools, Konfiguration usw.;
Warum ist die Beliebtheit von DDD das ganze Jahr über ungebrochen, in unserem eigentlichen Systementwicklungsprozess gibt es jedoch nur wenige Projekte, die vollständig umgesetzt sind? Mit anderen Worten: Systeme mit MVC-Architekturstil sind sehr verbreitet, Systeme mit DDD-Architekturstil sind jedoch selten zu sehen. Dies muss auf DDD selbst zurückgehen: Es handelt sich um eine Softwareentwicklungsmethodik zur Lösung komplexer Unternehmen .
Wenn auch das gemeinsame CRUD-Geschäftssystem nach diesem Modell implementiert wird, erhöht sich die Komplexität des Systems. Im Allgemeinen ist der DDD-Modus auf die folgenden Szenarien anwendbar:
Unterstützung bei der Verarbeitung komplexer Geschäftslogikszenarien : Wenn eine Anwendung komplexe Geschäftslogik verarbeiten muss, kann DDD die Geschäftslogik im Domänenmodell kapseln, wodurch Geschäftsanforderungen und Geschäftsprozesse besser widergespiegelt und die Komplexität der Systemarchitektur verringert werden.
Hochgradig wartbare und skalierbare Szenarien : DDD teilt die Anwendung in mehrere Subdomänen auf, von denen jede über ein eigenes Domänenmodell verfügt, wodurch die Geschäftskomplexität besser verwaltet werden kann.
Szenarien, die eine schnelle Iteration und Bereitstellung erfordern : Jede Subdomäne kann unabhängig entwickelt, bereitgestellt und erweitert werden, sodass das Team Anwendungen schnell iterieren und bereitstellen kann.
Um die Komplexität des Geschäfts einzuschätzen, müssen wir mehrere Aspekte berücksichtigen, wie zum Beispiel Geschäftsprozesse, Produktregeln, Datenstrukturen und Häufigkeit von Nachfrageänderungen. Im Allgemeinen erfordert die Einführung dieses Architekturmusters eine sorgfältige Bewertung, da die Implementierung dieses Entwicklungsmusters mit den folgenden Herausforderungen konfrontiert ist:
Es ist ein tiefes Verständnis der Geschäftsdomäne erforderlich : DDD ist eine Entwurfsmethode, die sich auf die Geschäftsdomäne konzentriert. Daher ist ein tiefes Verständnis der Geschäftsdomänenkenntnisse erforderlich, um ein Domänenmodell zu entwerfen, das den Geschäftsanforderungen entspricht.
Abteilungsübergreifende Zusammenarbeit ist erforderlich : Die Implementierung von DDD erfordert eine abteilungsübergreifende Zusammenarbeit, einschließlich Geschäftspersonal, Entwickler, Tester usw., und alle müssen zusammenarbeiten, um einen Konsens zu erzielen.
Hoher technischer Schwierigkeitsgrad : DDD muss viele komplexe Konzepte wie Domänenereignisse, Aggregatwurzeln, Domänendienste usw. verstehen und erfordert von Entwicklern ein bestimmtes technisches Niveau.
Kurz gesagt, es gibt in jeder Hinsicht große Herausforderungen, sei es im Team-Zusammenarbeitsmodus, in Bezug auf persönliche technische Fähigkeiten oder im geschäftlichen Konsens. Dies bedeutet jedoch nicht, dass DDD in normalen Geschäftssystemen nutzlos ist. Seine Ideen zur Lösung komplexer Probleme können uns immer noch zugute kommen. Häufig verwendete Tool-Frameworks wie das CQRS-Framework, die ereignisgesteuerte Architektur und das Microservice-Framework weisen alle den Schatten der DDD-Designideen auf.
Betrachten Sie am Beispiel der Microservice-Architektur zunächst die folgenden Fragen:
Wie sollten Microservices gestaltet sein?
Was ist die Grundlage für die Aufteilung von Microservices?
Wie trennen Microservices Grenzen?
Sind Microservices zu fein aufgeteilt, erhöhen mehr Services den Betrieb und die Verwaltung, sind sie zu grob, ist der Grad der funktionalen Kopplung hoch und es kommt zu Defiziten bei Flexibilität und Skalierbarkeit. Das ist also eine schwierigere Frage.
Die Bestimmung der Geschäfts- und Anwendungsgrenzen ist der Schlüssel zur Lösung des Microservice-Dilemmas. DDD löst das Problem der Geschäftsgrenzen sehr gut und bietet eine Methodik zur Aufteilung des Umfangs von Geschäftsdomänen.
Microservice besteht darin, eine Anwendung in mehrere Subdomänen aufzuteilen, und jede Subdomäne öffnet ihre Fähigkeiten in Form von Microservices für die Außenwelt. Microservices begrenzen komplexe Geschäftsprozesse und Regeln innerhalb des Domänenbereichs, d. h. sie implementieren intern eigene Domänenmodelle und Datenspeicher. Aus Sicht der Anwendungsschicht wird dadurch die Implementierung von Domänendiensten standardisiert und vereinheitlicht, die Codelogik erheblich vereinfacht und die Geschäftskomplexität besser verwaltet.
3.2 Technologieauswahl
Neben dem Grundgerüst spielt auch der Aufbau der Engineering-Architektur eine wichtige Rolle, nämlich die Auswahl verschiedener grundlegender Middleware, die wir oft als Technologieauswahl bezeichnen. Lassen Sie mich anhand von Beispielen erläutern, auf welche wesentlichen Punkte bei der Technologieauswahl geachtet werden muss.
3.2.1 Geschäftsanforderungen
Verstehen Sie Geschäftsanforderungen und klären Sie Systemfunktionen, Leistung, Sicherheit und zukünftige Erweiterungsanforderungen.
Beispiel: Bei der Aufteilung von Systemmodulen werden einige Systeme in zwei Anwendungssätze [WEB] + [JSF-Mikroservice] zur separaten Bereitstellung aufgeteilt, während einige Systeme nur eine [WEB]-Anwendung bereitstellen. Was ist der Beurteilungsmaßstab in der Mitte? Welche Funktion hat der [JSF-Microservice], der zerlegt wird?
Wiederverwendung von Funktionen: Die Microservice-Schicht verfügt über ein allgemeineres Modelldesign und eine stärkere Fähigkeit zur Wiederverwendung mehrerer Geschäftsszenarien. Im Servicebetrieb kann es je nach Unternehmen vertikal eingesetzt werden;
Ressourcenisolation: Durch den vertikalen Einsatz durch Unternehmen können Hardwareressourcen wie Netzwerke und Maschinen auf verfeinerte Weise optimiert werden. Andererseits kann durch die Ressourcenisolation zwischen WEB-Anwendungen der oberen Schicht und Mikrodiensten der unteren Schicht auch eine verfeinerte Ressourcenzuweisung erreicht werden.
Zusammenfassend lässt sich sagen: Wenn Ihr Dienst kein Multi-Terminal-Multiplexing und keinen Ressourcenbetrieb erfordert, besteht keine Notwendigkeit, die Bereitstellung zu zerlegen und die Mehrfachinvestition von Anrufverbindungen und Maschinenressourcen zu erhöhen. Im Gegenteil: Die Vorteile des Service-Splittings sind sogar noch größer.
3.2.2 Technische Eigenschaften
Bewerten Sie die Eigenschaften verschiedener Technologien, einschließlich Aspekten wie Benutzerfreundlichkeit, Leistung, Sicherheit, Skalierbarkeit, Wartbarkeit usw.
Beispiel: Ich bin einmal auf ein System gestoßen, bei dem die zugrunde liegende Speicherschicht db4o (eine objektorientierte Open-Source-Datenbank) verwendet. Diese Middleware hat viele Vorteile:
Greifen Sie direkt auf Daten zu, indem Sie Objekte speichern.
Es ist kein Datenbankserver erforderlich, es wird nur eine Datendatei benötigt und die DLL-Größe beträgt nur mehr als 300 KB.
Datenabfrage, einfach zu bedienen und leistungsstark, auch ohne SQL;
Es wird jedoch immer noch nicht empfohlen, es hier zu verwenden, da wir ein verteilter Clusterdienst sind und diese Datenbankdatei nur auf einem einzelnen Computer gespeichert werden kann, dh es gibt ein Problem mit einem einzigen Fehlerpunkt, der am schwerwiegendsten ist. Um ähnliche Mängel auszugleichen, müssen Sie manchmal mehr Kosten aufwenden. Wenn es hingegen als eingebettete Datenbank verwendet und auf einige Einzelchip-Mikrocomputer angewendet wird, können seine Vorteile zum Vorschein kommen.
3.2.3 Community-Unterstützung
Berücksichtigen Sie den Grad der Community-Unterstützung der Technologie, einschließlich der Frage, ob es eine aktive Community gibt, ob eine große Anzahl von Dokumenten und Tutorials vorhanden ist, ob ausgereifte Bibliotheken von Drittanbietern vorhanden sind usw.
Beispiel: Im verteilten Planungsframework war tbschedule relativ früh Open Source, aber lange nachdem es Open Source war, hat niemand es gepflegt. Wenn es im normalen Geschäftsleben nur selten verwendet wird und die Anwendungsschicht gut überwacht wird, sollte es kein großes Problem darstellen . Wenn es jedoch weit verbreitet als Basis-Middleware verwendet wird, ist es offensichtlich, dass es im Hinblick auf die Beobachtbarkeit des Planungsprozesses, den ZK-Wiederverbindungsmechanismus und die automatische Wiederherstellung von Planungsausnahmen dringend aktualisiert und optimiert werden muss. Aber die Realität ist, dass die Community bereits aufgehört hat, es zu pflegen, was problematisch ist.
3.2.4 Teamfähigkeit
Wählen Sie die richtige Technologie basierend auf dem Kompetenzniveau Ihres Teams und vermeiden Sie zu komplexe oder unbekannte Technologien. Dies ist sehr wichtig, da sonst die späteren Wartungskosten und die Verbesserung der Iterationseffizienz zu einem großen Problem werden.
Beispiel: Die Cobol-Sprache ist eine Programmiersprache, die in den 1970er Jahren in der Finanzbranche weit verbreitet war. Es kann große Datenmengen und komplexe Berechnungen verarbeiten und verfügt über ein hohes Maß an Zuverlässigkeit und Sicherheit. Bis 2015 betrieb es außerdem 43 % des weltweiten Bankensystems und 95 % der Geldautomaten.
Doch im März 2023 gab Japan bekannt, dass es plant, das gesamte Bankensystem Cobol auf die JAVA-Sprache umzustellen. Der Grund dafür ist, dass es sehr wenige Techniker gibt, die diese alte Sprache beherrschen, und das Cobol-Ökosystem nicht mit neuen Entwicklungen wie maschinellem Lernen und Cloud-Integration mithalten kann. Die Wartungskosten und die Iterationseffizienz des gesamten Systems sind weitaus niedriger als beim modernen JAVA-Ökosystem .
3.2.5 Kosteneffizienz
Bewerten Sie die Kosteneffizienz verschiedener Technologien, einschließlich Entwicklungskosten, Betriebs- und Wartungskosten, Lizenzgebühren usw.
Wenn ausgereifte Open-Source-Plugins verfügbar sind, sollten wir versuchen, sie zu verwenden, anstatt das Rad neu zu erfinden;
Bei Aufgaben, die andere Teams erledigt haben, müssen wir überlegen, ob sie wiederverwendet werden können;
Beispiel: Die meisten aktuellen Technologie-Middlewares erfordern die Unterstützung von JDK8 oder höher. Daher müssen wir bei der Auswahl der Technologie die entsprechende JDK-Version berücksichtigen. Mit der Veröffentlichung von Spring Boot 3 ist die standardmäßig unterstützte JDK-Version 17 und JDK8 wird nicht mehr unterstützt. Für das neue System erscheint es sinnvoller, die neue Version zu wählen. Für das Bestandssystem muss berücksichtigt werden, ob das Upgrade auf die neue Version den Kosten der Systemtransformation und den damit verbundenen Vorteilen gerecht wird, anstatt neue Technologien als Selbstverständlichkeit zu verfolgen.
3.2.6 Risikobewertung
Bewerten Sie die Risiken verschiedener Technologien, einschließlich Technologiereife, Sicherheitslücken, Abhängigkeiten usw.
Beispiel: Fastjson ist eine Open-Source-JSON-Parsing-Bibliothek, die JSON-formatierte Strings analysieren kann, die Serialisierung von Java Beans in JSON-Strings und die Deserialisierung von JSON-Strings in JavaBeans unterstützt. Es zeichnet sich durch eine hohe Ausführungseffizienz und ein breites Anwendungsspektrum aus. Bei der Auswahl der Technologie müssen Sie nun vorsichtig sein. Der Grund dafür ist, dass in den letzten zwei Jahren häufig Sicherheitslücken aufgedeckt wurden und abhängige Anwendungen häufig aktualisiert werden müssen, um die Schwachstellen zu beheben. Dies ist nur der Schein, und der tiefere Grund ist der Mangel an Sicherheitsgarantien, ein Faktor, der bei der Auswahl der Technologie berücksichtigt werden muss.
3.2.7 Zusammenfassung
Bei der Auswahl einer technischen Lösung ist es nicht notwendig, sich auf die neueste und neueste Technologie zu konzentrieren. Es ist ratsam, bei der Auswahl der am besten geeigneten Lösung mehrere Faktoren wie Geschäftsanforderungen und Teamfähigkeitsreserven umfassend zu berücksichtigen. Um sich an die sich ständig ändernden Geschäftsanforderungen und Technologieentwicklungstrends anzupassen, ist es natürlich auch erforderlich, sich der zeitnahen technischen Bewertung und Aktualisierung bewusst zu sein.
4. Normativer Konsens
Die Bedeutung des Konsenses besteht darin, eine konsistente Kommunikation und ein einheitliches Verständnis zwischen den Teammitgliedern sicherzustellen. Durch die Formulierung von Spezifikationen und Prozessen können Doppelarbeit und Fehler reduziert sowie Konflikte und Missverständnisse vermieden werden, was der Verbesserung der F&E-Effizienz und -Qualität förderlich ist.
4.1 Datenschichtung
4.1.1 Objektkonvertierung
In einer Schichtarchitektur gibt es gegenseitige Abhängigkeiten und Referenzen zwischen Schichten, und Daten werden über Parameterobjekte weitergeleitet. Um die Stabilität der inneren Struktur jeder Schicht sicherzustellen, müssen wir ein Korrosionsschutzdesign durchführen. Dies ist der Schlüssel zum Erreichen einer hohen Kohäsion und einer geringen Kopplung.
Beispiel: Eine Tabelle in der Modellebene hat 20 Felder und das entsprechende PO-Objekt hat 20 Attribute. Die Terminal-Anzeigeschicht muss jedoch nur 10 Felder anzeigen. Wenn die Anforderungsverarbeitungsschicht (Web) Daten erhält, ist es nicht erforderlich, das gesamte PO-Objekt zurückzugeben. Zu diesem Zeitpunkt können wir das DTO-Objekt nur mit diesen 10 verwenden Attribute, um das Ergebnis an die Anforderungsverarbeitungsschicht weiterzuleiten, sodass die Servertabellenstruktur und einige vertrauliche Daten nicht offengelegt werden.
Die gängige Methode für den Korrosionsschutz von Daten besteht darin, auf jeder Ebene eine eigene Datenstruktur zu definieren. Die gängigen Methoden sind:
VO (Objekt anzeigen): Objekt anzeigen, das hauptsächlich dem auf der Schnittstelle angezeigten Datenobjekt entspricht;
DTO (Data Transfer Object): Datenübertragungsobjekt, das hauptsächlich an Orten verwendet wird, an denen eine große Anzahl von Übertragungsobjekten erforderlich ist, z. B. bei Remote-Aufrufen.
DO (Domänenobjekt): Domänenobjekt ist eine materielle oder immaterielle Geschäftseinheit, die von der realen Welt abstrahiert ist;
PO (Persistent Object): Persistentes Objekt, das eine entsprechende Zuordnungsbeziehung mit der Datenstruktur der Persistenzschicht (normalerweise einer Datenbank) bildet;
In der tatsächlichen Entwicklung ist es aus Gründen der Bequemlichkeit nicht unbedingt erforderlich, für jede Serviceschicht ein eigenes Datenobjekt zu definieren, das je nach tatsächlicher Situation flexibel gehandhabt werden kann. In einigen einfachen Geschäftsszenarien können Sie beispielsweise DO-Layer-Objekte überspringen und PO-Objekte direkt in VO-Objekte konvertieren.
4.1.2 Wiederverwendung von Objekten
In einem System, das über einen langen Zeitraum iteriert wurde, kann es leicht zu einem Problem kommen, das heißt, der Umfang einiger Objekte gerät außer Kontrolle und seine typischen Merkmale sind:
Für ein Eingabeobjekt werden mehrere Methoden gemeinsam genutzt. Das Anpassen der Definition eines Attributwerts hat vielfältige Auswirkungen und ein hohes Risiko.
Verwenden Sie den Kartencontainer direkt als Eingabe- oder Ausgabeobjekt Ihres eigenen Dienstes. Niemand kann sagen, wie viel Inhalt sich im Container befindet.
In einer Objektdefinition gibt es mehrere ähnliche Attributdefinitionen. Wenn neue Anforderungen aufkommen, definieren Sie einfach eine neue, um das Risiko zu verringern, und so weiter;
Das außer Kontrolle geratene Problem des Objektumfangs führt zu einer erheblichen Verringerung der Gesamtstabilität und Iterationseffizienz des Systems. Dieses Problem ist normalerweise ein langsamer kumulativer Prozess, der sich unbewusst entwickelt. Die Nachteile treten häufig bei größeren Systemanpassungen zum Vorschein.
Um solche Probleme zu lösen, können wir von folgenden Aspekten ausgehen:
Prävention: Geben Sie beim Entwurf der Architektur eine klare Spezifikationsdefinition an;
Entdeckung: Führen Sie regelmäßig Entwurfs- und Codeüberprüfungen durch und beheben Sie Probleme rechtzeitig, nachdem Sie sie entdeckt haben.
Stop-Loss: Wenn ein solches System entdeckt wird, muss Mikro-Refactoring in Betracht gezogen werden, um eine kontinuierliche Korruption zu verhindern;
Überprüfung: Überprüfen Sie das System regelmäßig und zeitnah, fördern Sie eine gute Entwicklung, beheben Sie Mängel und entwickeln Sie eine gute technische Atmosphäre.
4.2 Ausnahmeverwaltung
4.2.1 Ausnahmen abfangen
Bei der Ausnahmeerfassung kann es auch leicht zu zwei Extremen kommen: Eines ist Try-Catch für jede Methode und es gibt mehrere Gruppen in einer Methode. Das andere ist, dass der gesamte Link keinen Try-Catch hat und sich in einem Streifenzustand befindet. Wie fängt man also Ausnahmen ab? Schauen Sie sich zunächst den Zweck des Abfangens von Ausnahmen an:
Die Bearbeitung von Ausnahmen vor dem Urteil ermöglicht die Fortsetzung des Prozesses;
Probleme schnell erkennen und lokalisieren, um die Systemstabilität sicherzustellen;
Basierend auf dem Zweck der Ausnahmebehandlung ist auch die entsprechende Verarbeitungsstrategie klar:
Soll der Prozess fortgesetzt werden, muss die Ausnahme abgefangen und am entsprechenden Knoten verarbeitet werden;
Wenn Sie das Problem schnell finden und lokalisieren möchten, können Sie am Anrufeintrag eine einheitliche Erfassungsverarbeitung durchführen, und im Ausnahmestapel werden detaillierte Gründe für die Ausnahme angezeigt.
Kurz gesagt, Ausnahmen müssen abgefangen werden, aber wo und wie man sie abfängt, können wir je nach Zweck flexibel damit umgehen.
4.2.2 Ausnahmen behandeln
Geschäfts- und Systemausnahmen sollten Spuren hinterlassen, um die zukünftige Problemlokalisierung und statistische Analyse zu erleichtern, z. B. Protokolle, Nachrichten usw.;
Durch die regelmäßige Kodierung verschiedener Ausnahmen können Probleme schnell lokalisiert und die Einrichtung von Notfallplänen erleichtert werden. Die Regeln können sich auf die Kodierung von HTTP-Anforderungsantworten beziehen.
Drucken Sie Informationen zum Ausnahmestapel. Dies ist ein wichtiges Mittel, um die Ursache des Problems schnell zu lokalisieren.
Längsschnittstatistiken und Vergleich abnormaler Daten zur Erleichterung der Identifizierung des Systemgesundheitszustands;
4.3 Protokollverwaltung
Vereinheitlichen Sie das Protokoll-Framework. Es wird empfohlen, das SLF4J-Protokoll-Fassaden-Framework zu verwenden und für die spezifische Implementierung Log4j2, Logback usw. auszuwählen.
Konfigurieren Sie das Protokoll-Framework, einschließlich Protokollausgabeformat, Ausgabeort, Ausgabeebene, Ausgabemethode (asynchrones Drucken) usw.;
Verwenden Sie unterschiedliche Ebenen, um unterschiedliche Arten von Informationen aufzuzeichnen und in unterschiedliche Dateien zu drucken.
Überprüfen und bereinigen Sie die Protokolldateien regelmäßig, um zu vermeiden, dass sie zu viel Speicherplatz beanspruchen.
Je nach Bedarf können die Protokollinformationen an andere Systeme gesendet oder analysiert und verarbeitet werden, um das System besser zu überwachen und zu verwalten.
Bauen Sie bei Bedarf die Möglichkeit ein, die Protokollebene dynamisch anzupassen;
4.4 Überwachung und Management
Systemleistungsüberwachung: Überwachen Sie die Nutzung von CPU, Speicher, Festplatte, Netzwerk und anderen Ressourcen des Systems sowie den Ausführungsstatus von Anwendungen. Wie Nagios, Zabbix;
Protokollüberwachung: Überwachen Sie System- und Anwendungsprotokollinformationen, führen Sie Trace-IDs und Geschäftsidentitäts-IDs ein und erkennen Sie ungewöhnliche Situationen rechtzeitig. Wie ELK (Elasticsearch, Logstash, Kibana);
Sicherheitsüberwachung: Überwachen Sie den Sicherheitsstatus von Systemen und Anwendungen und entdecken Sie potenzielle Sicherheitsbedrohungen rechtzeitig. Wie Snort, Suricata;
Geschäftsüberwachung: Überwachen Sie verschiedene Indikatoren des Geschäftssystems, das Besuchsvolumen, die Reaktionszeit, die Fehlerrate usw. und entdecken Sie rechtzeitig Geschäftsanomalien. Wie Grafana, Prometheus;
Anruflink-Verfolgung: Sie können den Anruflink einer Anfrage im gesamten verteilten System verfolgen, die Verarbeitungszeit und den Status jedes Serviceknotens aufzeichnen und diese Informationen zu einem vollständigen Anruflink-Diagramm zusammenfassen, um eine einfache Analyse und Fehlerbehebung zu ermöglichen. Wie zum Beispiel: Zipkin, SkyWalking;
Überwachung und Frühwarnung: Um Probleme schnell zu lokalisieren, sind verschiedene Überwachungsinstrumente eine wirksame Hilfe. Um Probleme überhaupt zu finden, ist ein fundierter und wirksamer Frühwarn- und Kontaktmechanismus unerlässlich. Wie E-Mail, Firmen-WeChat, SMS, Telefonanrufe usw.;
4.5 Kollaborativer Konsens
4.5.1 Verwenden alle HTTP-Dienstanfragen POST?
Vor kurzem ist in unserer APP ein Problem aufgetreten. In einigen Fällen gaben Dienstaufrufe den Antwortfehler „HTTP 414 URI Too Long“ zurück. Die Hauptursache für dieses Problem liegt darin, dass Tomcats standardmäßige Längenbeschränkung für Get-Anfragen (einschließlich Anforderungszeile und Anforderungsheader) 8192 Zeichen überschreitet. Um dieses Problem zu lösen, gibt es mehrere Möglichkeiten:
Lockern Sie die Einschränkung, indem Sie den Attributwert maxHttpHeaderSize im Connector-Element in der Datei server.xml ändern (z. B. auf 16384);
Passen Sie das Anforderungsprotokoll des Dienstes von nur der Unterstützung der GET-Methode an, um gleichzeitig die POST-Anforderungsmethode zu unterstützen, da die POST-Anforderungsmethode nicht über diese Größenbeschränkung verfügt.
Vereinfachen Sie die Header-Anfrageparameter, standardisieren und begrenzen Sie das Schreiben von Cookies und Geschäftsparametern;
Lösung 1, die Erweiterung des Containerlimits von Tomcat, scheint kurzfristig möglich zu sein, stellt jedoch ein öffentliches Problem dar. Möglicherweise müssen Tausende von Anwendungscontainern angepasst werden, und es handelt sich eher um eine vorübergehende Lösung als um eine dauerhafte Lösung.
Die zweite Möglichkeit besteht darin, alle GET-Anfragemethoden so anzupassen, dass sie gleichzeitig die POST-Anfragemethode unterstützen. Es sind Hunderte von Anwendungen beteiligt, und der Arbeitsaufwand ist ziemlich hoch.
Lösung 3, die Optimierung der Header-Anforderungsparameter, ist die vernünftigste und sicherste Lösung und stellt auch die wesentliche Ursache des Problems dar. Sie ist jedoch auch sehr schwierig, wenn es um die Interaktion zwischen zwei APPs und die gemeinsame Sortierung und Transformation von Dutzenden oder mehreren geht Hunderte Abteilungen.
Wenn Sie es wären, wie würden Sie eine Lösung wählen?
4.5.2 Das Frontend führt keine Logikverarbeitung durch, sondern nur Datenrendering?
Front-End-Perspektive: Da die Veröffentlichung der APP-Version Versionsüberprüfungen, Benutzer-Downloads und -Updates sowie andere Prozesse umfasst, ist einerseits der Zyklus lang und andererseits können Benutzer ein Upgrade verweigern. Dies führte dazu, dass die Front-End-Forschung und -Entwicklung den Slogan vorschlug: „Das Front-End führt keine Geschäftslogikverarbeitung durch, sondern nur Datenrendering“. Wenn das Front-End einerseits die Verarbeitung der Geschäftslogik durchführt, ist die Behebung eines Fehlers sehr teuer und kann nicht einmal behoben werden, wenn der Benutzer die Version nicht aktualisiert. Wenn andererseits das Front-End einen Teil der Geschäftslogik übernimmt, wird es schwierig sein, die Grenzen der Verantwortlichkeiten klar vom Back-End abzugrenzen, was verborgene Gefahren für die Zusammenarbeit birgt.
Back-End-Perspektive: ein Standardhintergrundbild, eine sofortige Kopie, eine Schriftfarbe ... Müssen wir all diese vorhersehbaren Daten senden, die nicht angepasst werden? Erhöhte Datenkomplexität und erhöhte Netzwerkbandbreite. Darüber hinaus verfügt das Frontend auch über Hot-Update-Technologie, und komplexe Seiten, die leicht zu ändern sind, können auch über H5 realisiert werden. Warum können wir also nicht eine einfache Geschäftslogik erstellen?
Wie soll das Programm ausgewählt werden?
4.5.3 Zusammenfassung
Die Lösungen für viele technische Probleme haben keine offensichtliche Voreingenommenheit, abhängig von der Umgebung und der jeweiligen Position. Beispielsweise besteht die vernünftigste Lösung für das Problem übermäßig langer HTTP-GET-Anforderungsparameter darin, die Header-Parameter zu vereinfachen. Dies erfordert jedoch langfristige Anstrengungen und ist kurzfristig schwer zu erreichen. Daher können wir bei der Lösung des aktuellen Problems zwei weitere Optionen in Betracht ziehen. Ebenso müssen wir bei der Frage, ob das Front-End die Geschäftslogik verarbeiten soll, unsere Positionierung der APP und den Aufbau der Grundfunktionen des Front-Ends und Back-Ends berücksichtigen. Die Kriterien für die Beurteilung einer guten Lösung sollten sein: Sie kann das aktuelle Problem zu geringen Kosten lösen und bringt keine neuen Probleme mit sich.
V. Zusammenfassung
In diesem Artikel werden einige wichtige Aspekte beschrieben, die beim Aufbau einer System-Engineering-Architektur beachtet werden müssen. Treffen Sie Entscheidungen basierend auf dem Wert des Produkts. Und ausgehend von der Entwicklung der System-Engineering-Architektur, der Auswahl technischer Lösungen und der Erzielung eines Konsenses über Systemspezifikationen werden Lösungen für häufige Probleme im Implementierungsprozess bereitgestellt. Schließlich verwende ich die „Markierung des Mondfingers“ im „Langa Sutra“ als abschließende Bemerkung, um sie den Lesern mitzuteilen: „Es ist, als würde man mit einer bescheidenen Meinung auf den Mond zeigen, aber man kann den Mond nicht sehen, indem man hinschaut.“ am Finger. Diejenigen, die sich den Namen merken, werden meine Wahrheit nicht sehen.“
-Ende-