Um es leichter zu verstehen, worum es in diesem Artikel geht, beginnen wir mit der Änderung der durchschnittlichen Tagesstatistik von Stack Overflow. Die folgenden Zahlen stammen aus den Statistiken vom 12. November 2013:
- Der Load Balancer akzeptierte 148.084.833 HTTP-Anfragen
- Davon waren 36.095.312 Seiten geladen
- Es werden 833.992.982.627 Bytes (776 GB) HTTP-Verkehr verwendet, um den Sender zu senden
- Insgesamt wurden 286.574.644.032 Bytes (267 GB) Daten empfangen
- Insgesamt wurden 1.125.992.557.312 Bytes (1.048 GB) Daten gesendet
- 334.572.103 SQL-Abfragen (einschließlich nur von HTTP-Anfragen)
- 412.865.051 Redis-Anfragen
- 3.603.418 Tag-Engine-Anfragen
- Es dauerte 558.224.585 ms (155 Stunden) bei SQL-Abfragen
- Es dauerte 99.346.916 ms (27 Stunden) bei Redis-Anfragen
- Ich habe 132.384.059 ms (36 Stunden) für die Tag-Engine-Anfrage verbracht
- Es dauerte 2.728.177.045 ms (757 Stunden) ASP.Net Prozessverarbeitung
Die folgenden Daten zeigen die Änderungen in den Statistiken zum 9. Februar 2016, sodass Sie vergleichen können:
- HTTP-Anfragen vom Load Balancer empfangen: 209.420.973 (+61.336.090)
- 66.294.789 (+30.199.477), von denen die Seite lädt
- HTTP-Daten gesendet: 1.240.266.346.053 (+406.273.363.426) Bytes (1,24 TB)
- Gesamtmenge der empfangenen Daten: 569.449.470.023 (+282.874.825.991) Bytes (569 GB)
- Gesamtmenge der gesendeten Daten: 3.084.303.599.266 (+1.958.311.041.954) Bytes (3,08 TB)
- SQL-Abfragen (nur aus HTTP-Anfragen): 504.816.843 (+170.244.740)
- Redis-Cache-Treffer: 5.831.683.114 (+5.418.818.063)
- Elastische Suchanfragen: 17.158.874 (2013 nicht erfasst)
- Tag-Motor-Anfragen: 3.661.134 (+57.716)
- Kumulierte Zeit, die für SQL-Abfragen benötigt wird: 607.073.066 (+48.848.481) ms (168 Stunden)
- Redis-Cache-Trefferzeit verbraucht: 10.396.073 (-88.950.843) ms (2,8 Stunden)
- Zeit verbraucht durch Tag-Engine-Anfragen: 147.018.571 (+14.634.512) ms (40,8 Stunden)
- In ASP.Net Bearbeitung verbrauchte Zeit: 1.609.944.301 (-1.118.232.744) ms (447 Stunden)
- 22,71 (-5,29) ms 49.180.275 Ausgabeseiten Durchschnittliche Renderzeit (davon 19,12 ms in ASP.Net)
- 11,80 ms (-53,2) ms 6.370.076 durchschnittliche Renderzeit der ersten Seiten (davon 8,81 ms in ASP.Net)
Sie fragen sich vielleicht, warum ASP.Net 61 Millionen Anfragen pro Tag bearbeitet, aber die Bearbeitungszeit um 757 Stunden verkürzt (im Vergleich zu 2013). Das liegt hauptsächlich an den Upgrades unserer Server Anfang 2015 sowie an vielen In-App-Performance-Optimierungsarbeiten. Vergiss nicht: Leistung ist immer noch ein Verkaufsargument. Wenn Sie sich mehr für die spezifischen Hardwaredetails interessieren, keine Sorge, ich gebe die genauen Hardwaredetails der Server, die diese Seiten betreiben, in Form eines Anhangs im nächsten Artikel (ich werde diesen Link aktualisieren, wenn es soweit ist).
Was hat sich also in den letzten zwei Jahren verändert? Nicht viel, nur ein paar Server und Netzwerkausrüstung ersetzt. Hier ist ein Überblick über die Server, mit denen Ihre Website heute betrieben wird (beachten Sie, wie sie sich seit 2013 verändert haben).
- 4 Microsoft SQL Server Server (2 davon verwenden neue Hardware)
- 11 IIS-Webserver (neue Hardware)
- 2 Redis-Server (neue Hardware)
- 3 Tag Engine-Server (davon 2 mit neuer Hardware)
- 3 Elasticsearch-Server (wie oben)
- 4 HAProxy-Lastverteilungsserver (2 hinzugefügt, um CloudFlare zu unterstützen)
- 2 Netzwerkgeräte (Nexus 5596 Core + 2232TM Fabric Extender, alle Geräte auf 10 Gbps Bandbreite aufgerüstet)
- 2 x Fortinet 800C Firewall (ersetzt Cisco 5525-X ASAs)
- 2 Cisco ASR-1001 Router (ersetzen Cisco 3945 Router)
- 2 Cisco ASR-1001-x Router (NEU!) ）
Was brauchen wir, damit Stack Overflow funktioniert? Seit 2013 hat sich nicht viel geändert, aber dank der oben genannten Optimierungen und der neuen Hardware brauchen wir jetzt nur noch einen Webserver. Wir haben diese Situation bereits unbeabsichtigt getestet, mit mehrfachem Erfolg. Bitte beachte: Ich habe gerade gesagt, dass es funktioniert, aber ich habe nicht gesagt, dass es eine gute Idee ist. Aber jedes Mal, wenn das passiert, ist es ziemlich interessant.
Jetzt, wo wir einige Basiszahlen zu Server-Skalierungsideen haben, schauen wir uns an, wie wir diese coolen Webseiten erstellt haben. Nur wenige Systeme existieren völlig unabhängig (und unsere bilden da keine Ausnahme), und ohne eine ganzheitliche Sichtweise, die diese Teile integriert, wird die Bedeutung der architektonischen Planung stark reduziert. Unser Ziel ist es, die Gesamtsituation zu erfassen. In Zukunft wird es viele Artikel geben, die in jedes einzelne Feld tief eingehen. Dieser Artikel ist lediglich eine Zusammenfassung der logischen Struktur der wichtigsten Hardware, und der nächste Artikel enthält spezifische Details zu dieser Hardware.
Wenn du sehen willst, wie diese Hardware heute aussieht, hier ein paar Fotos, die ich von Cabinet A (Cabinet B ist genau wie es) gemacht habe, als ich den Server im Februar 2015 aufgerüstet habe:
Kommen wir nun zum architektonischen Layout. Im Folgenden eine Zusammenfassung der logischen Architektur der wichtigsten bestehenden Systeme:
Grundprinzipien
Hier sind einige gängige Prinzipien, die nicht nacheinander eingeführt werden müssen:
- Alles hat redundante Backups.
- Alle Server und Netzwerkgeräte verfügen über mindestens zwei Verbindungen mit 10 Gbit/s.
- Alle Server verfügen über zwei Stromquellen, die Strom über zwei USV-Einheiten, zwei dahinterliegende Generatoren und zwei Netzspannungsvorrichtungen liefern.
- Alle Server verfügen über ein redundantes Backup, das sich in Rack A und Rack B befindet.
- Alle Server und Dienste haben doppelte redundante Backups in einem separaten Rechenzentrum (in Colorado), obwohl ich hauptsächlich New York abdecke.
- Alles hat redundante Backups.
Internet
Zuerst musst du unsere Website finden, die ist eine DNS-Sache. Webseiten zu finden geht schnell, deshalb geben wir sie jetzt an Cloudflare, weil sie DNS-Server in jeder Ecke der Welt haben. Wir aktualisieren DNS-Datensätze über APIs, und sie sind für die "Verwaltung" von DNS verantwortlich. In unseren schurkischen Köpfen haben wir jedoch immer noch eigene DNS-Server wegen der tief verwurzelten Vertrauensprobleme. Wenn die Apokalypse apokalyptisch ist – vielleicht wegen der GPL, Punyon oder Caching-Problemen – und die Leute trotzdem programmieren wollen, um ihre Aufmerksamkeit abzulenken, wechseln wir zu eigenen DNS-Servern.
Sobald Ihr Browser unser Versteck gefunden hat, gelangen HTTP-Verkehr von unseren vier ISPs (Level 3, Zayo, Cogent und Lightower in New York) in einen unserer vier fortschrittlichen Router. Wir nutzen das Border Gateway Protocol (BGP, ein sehr standardisiertes Protokoll), um Peer-to-Peer-Verkehr von Netzwerkanbietern zu steuern und den effizientesten Zugang zu unseren Diensten bereitzustellen. Die ASR-1001- und ASR-1001-X-Router sind in zwei Gruppen unterteilt, von denen jede den aktiven/aktiven Modus nutzen sollte, um den Datenverkehr von beiden Netzwerkanbietern zu verarbeiten – hier gibt es redundante Backups. Obwohl sie alle die gleiche physische Bandbreite von 10 Gbps haben, ist der Datenverkehr von außen unabhängig vom Datenverkehr des externen VLAN und separat mit der Lastverteilung verbunden. Nachdem der Datenverkehr den Router passiert hat, kommen Sie zum Load Balancer.
Ich denke, es ist an der Zeit zu erwähnen, dass wir MPLS mit 10 Gbit/s Bandbreite zwischen den beiden Rechenzentren haben, obwohl das nicht direkt mit Website-Diensten zusammenhängt. Wir nutzen diese Technologie, um externe Replikationen durchzuführen und Daten schnell wiederherzustellen, um bestimmte Notfälle zu bewältigen. "Aber Nick, da gibt es keine Redundanz!" Nun, aus technischer Sicht hast du recht (im positiven Sinne), es ist auf dieser Ebene wirklich ein Single Point of Failure. Aber warte! Über den Netzwerkanbieter haben wir außerdem zwei zusätzliche OSPF-Failover-Routen (MPLS ist die erste Wahl, und diese sind aus Kostengründen die zweite und dritte Option). Jedes der zuvor genannten Gerätegruppen wird entsprechend mit dem Rechenzentrum von Colorado verbunden, um im Falle eines Failovers den Netzwerkverkehr auszugleichen. Natürlich hätten wir diese beiden Gerätegruppen miteinander verbinden können, sodass es vier Pfade gibt, aber vergessen wir es, machen wir weiter.
Lastverteilung (HAProxy)
Die Lastverteilung ist mit HAProxy 1.5.15 implementiert, das auf CentOS 7 (unserer Lieblingsversion von Linux) läuft. Und ein TLS-(SSL) sicheres Übertragungsprotokoll auf HAProxy hinzufügen. Wir behalten auch HAProxy 1.7 im Auge, das sofort Unterstützung für das HTTP/2-Protokoll bieten wird.
Im Gegensatz zu anderen Servern mit zwei 10-Gbit/s-LACP-Netzwerkverbindungen hat jeder Lastenausgleicher zwei 10-Gbit/s-Verbindungen: eine für das externe Netzwerk und eine für die DMZ. Diese Server verfügen über 64 GB oder mehr Speicher, um die SSL-Protokollschicht effizienter zu verwalten. Wenn wir mehr TLS-Sitzungen im Speicher zwischenspeichern und wiederverwenden können, verbrauchen wir weniger Rechenressourcen, wenn wir mit demselben Client verbunden sind. Das bedeutet, dass wir Sitzungen schneller und günstiger wiederherstellen können. Memory ist so billig, dass es eine einfache Wahl ist.
Die Lastverteilung selbst ist einfach einzurichten. Wir hören verschiedene Websites mit mehreren verschiedenen IPs ab (hauptsächlich aus Gründen des Zertifikats- und DNS-Managements) und leiten dann den Datenverkehr an verschiedene Backends (hauptsächlich basierend auf Host-Headern). Das Einzige, was wir hier tun, ist, die Rate zu begrenzen und einige Header-Informationen (von der Webschicht) zu scrapen, um sich in die Systemlog-Nachrichten von HAProxy einzuloggen; so können wir für jede Anfrage Leistungsmetriken aufzeichnen. Das werden wir später ausführlich erläutern.
Webschicht (IIS 8.5, ASP.Net MVC 5.2.3 und .Net 4.6.1)
Die Lastverteilung verteilt den Datenverkehr zwischen 9 der sogenannten primären Webserver (01-09) und 2 Entwicklungs-Webservern (10-11, unsere Testumgebung). Der Hauptserver betreibt Stack Overflow, Careers und alle Stack Exchange-Standorte, während meta.stackoverflow.com und meta.stackexchange.com auf zwei weiteren Servern laufen. Die Haupt-Q&A-App selbst ist Multi-Tenant, das heißt, eine einzelne App bearbeitet alle Anfragen von der Q&A-Seite. Mit anderen Worten: Wir können die gesamte Q&A-App auf einem Anwendungspool auf einem Server ausführen. Andere Apps wie Careers, API v2, Mobile API usw. sind unabhängig. Das siehst du in IIS für die Master- und Dev-Server:
Hier ist die Verteilung des Webtiers von Stack Overflow, wie sie in Opserver (unserem internen Monitoring-Dashboard) zu sehen ist:
Und hier ist der Ressourcenverbrauch dieser Webserver:
Ich werde in einem weiteren Artikel noch näher darauf eingehen, warum wir so viele Ressourcen übermäßig bereitstellen, mit Fokus auf rollendes Build, Spielraum und Redundanz.
Dienstschicht (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 und HTTP. SYS)
Neben der Webschicht befindet sich die Service-Schicht. Sie laufen außerdem auf IIS 2012 unter Windows 8.5R2. Diese Schicht betreibt einige interne Dienste, die die Webschicht und andere interne Systeme der Produktionsumgebung unterstützen. Die beiden Hauptdienste sind: "Stack Server", der eine Tag-Engine betreibt und auf http.sys basiert (nicht IIS); Providence API (basierend auf IIS). Eine interessante Tatsache: Ich musste die beiden Prozesse korrelieren, um sich mit verschiedenen Sockets zu verbinden, weil der Stack Server beim Aktualisieren der Fehlerliste im zweiminütigen Abstand sehr häufig auf die L2- und L3-Caches zuging.
Die Maschinen, die diese Dienste ausführen, sind für die Tag-Engine und Backend-APIs kritisch, daher müssen sie redundant, aber nicht neunmal redundant sein. Zum Beispiel laden wir alle Artikel und ihre Tags alle n Minuten (derzeit 2 Minuten) aus der Datenbank, was nicht gering ist. Wir wollen diese Ladeoperation nicht 9 Mal auf der Webschicht wiederholen, 3 Mal ist für uns sicher genug. Wir verwenden außerdem verschiedene Hardwarekonfigurationen für diese Server, um besser auf die Berechnungs- und Datenladeeigenschaften der Tag-Engine und der elastischen Index-Jobs (ebenfalls in dieser Schicht) zu optimieren. Die "Tag Engine" selbst ist ein relativ komplexes Thema, das in einem speziellen Artikel behandelt wird. Das Grundprinzip ist, dass man, wenn man auf die Adresse /questions/tagged/Java zuruft, die Tagging-Engine benutzt, um die passenden Fragen zu erhalten. Die Engine übernimmt alle Tag-Matching außer /search, sodass überall, einschließlich der neuen Navigation, Daten über diesen Dienst erhalten.
Caching & Publishing/Abonnement (Redis)
Wir haben Redis an einigen Stellen verwendet, und es hat eine sehr stabile Stabilität. Obwohl es bis zu 160 Milliarden Operationen pro Monat gibt, überschreitet die CPU pro Instanz nicht 2 %, was in der Regel niedriger ist:
Wir nutzen Redis für Caching-Systeme auf L1/L2-Niveau. Die "L1"-Ebene ist der HTTP-Cache, der in einem Webserver oder einer ähnlichen Anwendung funktioniert. Das "L2"-Level dient dazu, Daten über Redis zu erhalten, nachdem der Cache des vorherigen Levels fehlgeschlagen ist. Unsere Daten werden im Protobuf-Format gespeichert, umgesetzt durch protobuf-dot-net, geschrieben von Marc Gravel. Für den Redis-Client haben wir die StackExchange.Redis-Bibliothek verwendet, eine Open-Source-Bibliothek, die intern entwickelt wurde. Wenn ein Webserver sowohl im L1- als auch im L2-Cache nicht trifft, holt er Daten aus seinen Datenquellen (Datenbankabfragen, API-Aufrufe usw.) und speichert die Ergebnisse im lokalen Cache und in Redis. Der nächste Server kann beim Abrufen derselben Daten im L1-Cache fehlen, aber er ruft die Daten in L2/Redis ab, wodurch Datenbankabfragen oder API-Aufrufe überflüssig werden.
Wir betreiben auch viele Q&A-Seiten, jede mit ihrem eigenen L1/L2-Cache: Schlüssel als Präfix im L1-Cache und Datenbank-ID im L2/Redis-Cache. Wir werden dieses Thema in zukünftigen Artikeln näher betrachten.
Zusätzlich zu den beiden Haupt-Redis-Servern (einem Master und einem Slave), die alle Site-Instanzen ausführen, richten wir auch eine Instanz für maschinelles Lernen (hauptsächlich aus Speichergründen) mit zwei weiteren dedizierten Slave-Servern ein. Diese Servergruppe wird genutzt, um Dienstleistungen wie das Empfehlen von Fragen auf der Startseite und die Verbesserung der Job-Matching zu bieten. Diese Plattform heißt Providence, und Kevin Montrose schrieb darüber.
Der Hauptserver von Redis verfügt über 256 GB RAM (etwa 90 GB genutzt), und der Providence-Server hat 384 GB Speicher (etwa 125 GB genutzt).
Redis ist nicht nur für Caching gedacht, sondern verfügt auch über einen Veröffentlichungs- und Abonnementmechanismus, bei dem ein Server eine Nachricht veröffentlichen kann und andere Abonnenten die Nachricht empfangen können (einschließlich Redis von nachgelagerten Clients auf dem Server). Wir nutzen diesen Mechanismus, um den L1-Cache anderer Dienste zu löschen und so die Cache-Konsistenz auf dem Webserver zu gewährleisten. Aber es hat eine weitere wichtige Funktion: Websockets.
Websockets (NetGain)
Wir nutzen Websockets, um den Nutzern Echtzeit-Updates zu senden, wie Benachrichtigungen in der obersten Leiste, Stimmen, neue Navigationen, neue Antworten, Kommentare und mehr.
Der Socket-Server selbst läuft auf der Webschicht und verwendet native Sockets. Dies ist eine sehr kleine Anwendung, die auf unserer Open-Source-Bibliotheksimplementierung basiert: StackExchange.NetGain. Zu Stoßzeiten hatten wir etwa 500.000 gleichzeitige Websocket-Verbindungen, was viele Browser entspricht. Fun Fact: Einige dieser Browser sind seit über 18 Monaten geöffnet, und du musst jemanden finden, der herausfinden kann, ob diese Entwickler noch existieren. Das folgende Diagramm zeigt das Muster der Websocket-Nebenläufigkeit in dieser Woche:
Warum Websockets verwenden? In unserem Maßstab ist das viel effizienter als Umfragen. So können wir einfach mehr Daten mit weniger Ressourcen pushen und für die Nutzer in Echtzeit verfügbar sein. Dieser Ansatz ist jedoch nicht ohne Probleme: temporäre Ports, erschöpfte Dateihandhabungen auf Load Balancer sind sehr interessante Probleme, über die wir später sprechen.
Suche (Elasticsearch)
Spoiler: Hier gibt es nicht viel, worüber man sich freuen könnte. Die Webschicht verwendet Elasticsearch 1.4 und implementiert einen ultra-leichten, leistungsstarken StackExchange.Elastic-Client. Im Gegensatz zu den meisten Dingen planen wir diesen Teil nicht als Open Source, einfach weil er nur eine sehr kleine Teilmenge der APIs offenlegt, die wir nutzen müssen. Ich bin mir sicher, dass die öffentliche Veröffentlichung den Verlust aufwiegt und die Entwickler nur verwirren wird. Wir nutzen in diesen Bereichen elastic:/search, um verwandte Fragen zu berechnen und Vorschläge zu geben, wenn wir Fragen stellen.
Jeder Elastic-Cluster (einer für jedes Rechenzentrum) enthält 3 Knoten, von denen jeder einen eigenen Index hat. Die Careers-Seite enthält außerdem einige zusätzliche Indexe. Ein etwas weniger standardisierter Teil unserer Konfiguration in elastischen Kreisen ist, dass unser Cluster aus drei Servern etwas leistungsfähiger ist als die übliche Konfiguration: Jeder Server verwendet SSD-Speicher, 192 GB Speicher, duales Netzwerk mit 10 Gbit/s Bandbreite.
Die gleiche Anwendungsdomäne wie Stack Server (ja, wir wurden hier von .Net Core herumgeworfen) beherbergt ebenfalls eine Tag-Engine, die ebenfalls Elasticsearch für kontinuierliche Indexierung nutzt. Hier verwenden wir einen kleinen Trick, zum Beispiel indem wir ROWVERSION in SQL Server (der Datenquelle) verwenden, um mit dem "letzten Platz"-Dokument in Elastic zu vergleichen. Da es offenbar sequentiell ist, ist es für uns einfach, Inhalte zu crawlen und zu indexieren, wenn sie nach dem letzten Besuch geändert werden.
Der Hauptgrund, warum wir Elasticsearch statt Technologien wie SQL-Volltextsuche verwenden, ist seine Skalierbarkeit und Kosteneffizienz. SQL ist auf CPUs relativ teuer, während Elastic viel günstiger ist und in letzter Zeit viele neue Funktionen bietet. Warum nicht Solr verwenden? Wir müssen im gesamten Netzwerk suchen (mit mehreren Indizes gleichzeitig), und Solr unterstützt dieses Szenario zum Zeitpunkt unserer Entscheidungen nicht. Der Grund, warum wir 2.x noch nicht verwendet haben, ist, dass sich die Typen in 2.x stark verändert haben, was bedeutet, dass wir alles neu indizieren müssen, wenn wir upgraden wollen. Ich habe einfach nicht genug Zeit, um für Änderungen der Anforderungen und Migrationen zu planen.
Datenbank (SQL Server)
Wir nutzen SQL Server als einzige Wahrheitsquelle. Alle Daten in Elastic und Redis stammen von SQL Server. Wir haben zwei SQL-Server-Cluster und sind mit AlwaysOn-Verfügbarkeitsgruppen konfiguriert. Jeder Cluster verfügt über einen Hauptserver in New York (der fast die gesamte Last übernimmt) und einen Replica-Server sowie einen Replica-Server in Colorado (unserem Notfall-Recovery-Datenzentrum). Alle Kopieroperationen sind asynchron.
Der erste Cluster besteht aus einer Reihe von Dell R720xd-Servern, jeweils mit 384 GB Speicher, einer PCIe-SSD mit 4 TB Speicherplatz und zwei 12-Kern-CPUs. Dazu gehören Stack Overflow, Sites (das ist ein schlechter Name, den erkläre ich später), PRIZM und die Mobile-Datenbank.
Der zweite Cluster besteht aus Dell R730xd-Servern, jeder mit 768 GB Speicher, einer PCIe-SSD mit 6 TB Speicherplatz und zwei 8-Kern-CPUs. Dieser Cluster enthält alle anderen Datenbanken, einschließlich Careers, Open ID, Chat, Ausnahmeprotokolle und andere Q&A-Seiten (z. B. Super User, Server Fault usw.).
Auf der Datenbankebene wollen wir die CPU-Auslastung auf einem sehr niedrigen Niveau halten, obwohl die CPU-Auslastung in der Praxis etwas höher sein wird, wenn geplante Caching-Probleme auftreten (die wir gerade beheben). Derzeit sind NY-SQL02 und 04 die Hauptserver und 01 und 03 die Replica-Server, und wir haben sie heute wegen des SSD-Upgrades neu gestartet. So haben sie in den letzten 24 Stunden abgeschnitten:
Unsere Verwendung von SQL ist sehr einfach. Einfach heißt schnell. Während einige Abfrageanweisungen verdreht sein können, erfolgt unsere Interaktion mit SQL selbst ziemlich nativ. Wir haben einige Legacy-Versionen von Linq2SQL, aber alle unsere neuen Entwicklungen nutzen Dapper, unser Open-Source-Mikro-ORM-Framework, das POCO nutzt. Lassen Sie mich das anders erklären: Stack Overflow hat nur eine gespeicherte Prozedur in seiner Datenbank, und ich werde diese letzte verbleibende gespeicherte Prozedur beenden und durch Code ersetzen.
Bibliothek
Nun, lass uns unsere Meinung ändern, hier sind Dinge, die dir direkter helfen können. Ich habe einige davon schon erwähnt, aber ich gebe Ihnen eine Liste der vielen Open-Source-.Net-Bibliotheken, die wir pflegen und die jeder nutzt. Wir machen sie als Open Source, weil sie keinen Kerngeschäftswert haben, aber sie können Entwicklern weltweit helfen. Ich hoffe, du kannst sie jetzt nutzen:
- Dapper (.Net Core) – Ein leistungsstarkes Micro-ORM-Framework für ADO.Net
- StackExchange.Redis – Ein leistungsstarker Redis-Client
- MiniProfiler – ein leichter Profiler, den wir auf jeder Seite verwenden (unterstützt außerdem Ruby, Go und Node)
- Außergewöhnlich – Für Fehlerprotokolle in SQL, JSON, MySQL usw
- Jil – Hochleistungs-JSON-Serialisierung und Deserialisierer
- Sigil – .Net CIL Generation Helper (verwendet, wenn C# nicht schnell genug ist)
- NetGain – Hochleistungs-Websocket-Server
- Opserver – Überwachungs-Dashboard, das die meisten Systeme direkt abfragt und Informationen von Orion, Bosun oder WMI abrufen kann
- Bosun – Überwachungssystem im Hintergrund, geschrieben in Go
|
Veröffentlicht am 11.04.2018 17:33:18
|
|
|
|
