Ziel ist es, unter modernen Bedingungen ein neues, hoch belastetes Startup zu schaffen. Wir werden die Schaffung von Architektur am Beispiel von
Billingolang betrachten , einem universellen Abrechnungsprojekt für allgemeine Zwecke, das in Golang geschrieben wurde. Das Projekt umfasst den Zugriff über API, Website, Integration in Buchhaltungssysteme, Berichte und Grafiken.
Single-Threaded-Systeme wurden zunächst zurückgeworfen. Ich musste mich zwischen Erlang, Golang und Rust entscheiden. Golang wurde als Hauptprogrammiersprache ausgewählt, da es schwierig ist, Erlang-Programmierer zu finden, obwohl Stabilität und Hot-Swapping des Codes ein Plus für Erlang waren. Rust eignet sich trotz des formalen Mangels an Rennbedingungen immer noch besser nicht zum Schreiben von Anwendungen, sondern für Treiber und Betriebssysteme.
Messaging zwischen Systemkomponenten erfolgt nicht auf dem klassischen
RabbitMQ , sondern auf
NATS. Letzteres zeigte Benchmarks auf dem aktuell verwendeten Server an, 1 Million Nachrichten (+ 360 KB für Clustering) pro Sekunde gegenüber 40 KB für einen Hasen. Ja, und es gruppiert sich schneller und einfacher als RabbitMQ.
Datenbank:
MySQL InnoDB Cluster 7.6 (MySQL Server 8.0). Wunderschönes Layout- und Debugging-Community-Tool
MySQL Workbench .
API - geschrieben in
Swagger (OpenAPI 2.0). Dies vermeidet Fehler durch verschiedene Programmierer und generiert sauberen, gut dokumentierten Code und API-Dokumentation. Leider verwendet Swagger standardmäßig
Gorilla / Mux zum Rooten , aber nach dem Generieren der gesamten API wird das Stammverzeichnis für
Kataras / Muxie erneuert - es ist schneller.
Frontend: Aus den verfügbaren Frameworks: Iris, Beego und Revel - Revel wird ausgewählt. Langsamer als Iris, aber alles ist sofort einsatzbereit, einschließlich der Integration in Grafiken. Die Hauptlast wird weiterhin von der API getragen.
Skalierung: Alle Systemkomponenten werden in LXC-Containern zusammengebaut, vor ihnen befindet sich der
HAProxy- Balancer. Die Idee der Skalierung besteht darin, konsequent auf leistungsstärkere Server umzusteigen, wobei die Struktur der Container beibehalten wird, wenn die Clients wachsen, und die Container anschließend auf separate Server zu verteilen, wodurch HAProxy durch NATS ersetzt wird. Zusätzlich zur klassischen Skalierung durch Hardware besteht immer die Möglichkeit, die Anzahl der Goroutinen in den Container-Handlern zu erhöhen, um die API und die Site anzufordern. Obwohl dieser Prozess, wie die Praxis gezeigt hat, logische Einschränkungen aufweist.
Im Allgemeinen ist die Hauptidee des Artikels und meine tiefe Überzeugung, dass die anfängliche Architektur von Hochlastprojekten unter modernen Bedingungen trotz ihrer jahrelangen entwickelten Infrastruktur und der Anwesenheit einer großen Anzahl verfügbarer Programmierer sinnlos ist, auf Single-Thread-Systemen aufzubauen. Und das gesamte Projektschema muss zunächst erstellt werden, indem eine einfache Übertragung auf leistungsfähigere und verteilte Geräte erfolgt. Dies wird es in Zukunft ermöglichen, auf einfache Weise ein Gleichgewicht zwischen Skalierungshardware und Code zu finden, ohne die Kosten zu multiplizieren.
Ein häufiger und häufiger Fehler neuer Startups ist eine schlechte anfängliche Entwicklung der Architektur. Nach dem Prinzip - "Fangen Sie schnell an zu schreiben, und dann werden wir es herausfinden." Dies führt in der Regel zum Zusammenbruch des Projekts.
Wie sie sagen - "90% des Erfolgs ist Vorbereitung". Haben Sie keine Angst, zunächst für die Erstellung einer kompetenten, durchdachten Architektur aufzuwenden - es wird sich gut auszahlen.
Viel Glück