Blokketting is 'n innoverende tegnologie wat beloof om baie areas van die menslike lewe te verbeter. Dit dra werklike prosesse en produkte na die digitale ruimte oor, verseker spoed en betroubaarheid van finansiële transaksies, verminder hul koste, en laat jou ook toe om moderne DAPP-toepassings te skep deur slim kontrakte in gedesentraliseerde netwerke te gebruik.
Gegewe die vele voordele en uiteenlopende toepassings van blokketting, lyk dit dalk verbasend dat hierdie belowende tegnologie nog nie in elke bedryf sy pad gemaak het nie. Die probleem is dat moderne gedesentraliseerde blokkettings nie skaalbaarheid het nie. Ethereum verwerk ongeveer 20 transaksies per sekonde, wat nie genoeg is om aan die behoeftes van vandag se dinamiese besighede te voldoen nie. Terselfdertyd is maatskappye wat blockchain-tegnologie gebruik huiwerig om Ethereum te laat vaar weens sy hoë mate van beskerming teen inbraak en netwerkfoute.
Om desentralisasie, sekuriteit en skaalbaarheid in die blokketting te verseker, en sodoende die Scalability Trilemma op te los, die ontwikkelingspan Plasma Cash geskep, 'n filiaalketting wat bestaan uit 'n slim kontrak en 'n private netwerk gebaseer op Node.js, wat periodiek sy staat na die wortelketting (Ethereum) oordra.
Sleutelprosesse in Plasma Kontant
1. Die gebruiker noem die slimkontrakfunksie 'deposito' en gee die bedrag ETH wat hy in die Plasma Kontant-token wil deponeer daarin. Die slimkontrakfunksie skep 'n teken en genereer 'n gebeurtenis daaroor.
2. Plasma Kontant-nodusse wat ingeteken is op slimkontrakgeleenthede, ontvang 'n geleentheid oor die skep van 'n deposito en voeg 'n transaksie oor die skep van 'n teken by die swembad.
3. Spesiale Plasma Kontant-nodes neem van tyd tot tyd alle transaksies uit die swembad (tot 1 miljoen) en vorm 'n blok daarvan, bereken die Merkle-boom en dienooreenkomstig die hash. Hierdie blok word na ander nodusse gestuur vir verifikasie. Die nodusse kyk of die Merkle-hash geldig is en of die transaksies geldig is (byvoorbeeld of die sender van die teken sy eienaar is). Nadat die blok geverifieer is, roep die nodus die `submitBlock`-funksie van die slimkontrak, wat die bloknommer en Merkle-hash na die randketting stoor. Die slim kontrak genereer 'n gebeurtenis wat die suksesvolle toevoeging van 'n blok aandui. Transaksies word uit die swembad verwyder.
4. Nodusse wat die blokindieningsgebeurtenis ontvang, begin die transaksies toepas wat by die blok gevoeg is.
5. Op 'n stadium wil die eienaar (of nie-eienaar) van die token dit uit Plasma Cash onttrek. Om dit te doen, roep hy die `startExit`-funksie en gee inligting oor die laaste 2 transaksies op die token daarin, wat bevestig dat hy die eienaar van die teken is. Die slim kontrak, met behulp van die Merkle-hash, kontroleer die teenwoordigheid van transaksies in die blokke en stuur die teken vir onttrekking, wat oor twee weke sal plaasvind.
6. As die teken-onttrekkingsoperasie plaasgevind het met oortredings (die teken is spandeer nadat die onttrekkingsprosedure begin het of die teken was reeds iemand anders s'n voor die onttrekking), kan die eienaar van die teken die onttrekking binne twee weke weerlê.
Privaatheid word op twee maniere bereik
1. Die wortelketting weet niks van die transaksies wat binne die kinderketting gegenereer en aangestuur word nie. Inligting oor wie ETH van Plasma Kontant gedeponeer en onttrek het, bly publiek.
2. Die kinderketting laat anonieme transaksies toe met behulp van zk-SNARKs.
Tegnologie stapel
- NodeJS
- Redis
- Etherium
- Grond
toets
Terwyl ons Plasma Cash ontwikkel het, het ons die spoed van die stelsel getoets en die volgende resultate verkry:
- tot 35 000 transaksies per sekonde word by die poel gevoeg;
- tot 1 000 000 transaksies kan in 'n blok gestoor word.
Toetse is op die volgende 3 bedieners uitgevoer:
1. Intel Core i7-6700 Quad-Core Skylake incl. NVMe SSD - 512 GB, 64 GB DDR4 RAM
3 validerende Plasma Kontant nodusse is verkry.
2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SATA SSD – 500 GB, 64 GB DDR4 RAM
Die Ropsten-toetsnet ETH-knooppunt is verhoog.
3 validerende Plasma Kontant nodusse is verkry.
3. Intel Core i9-9900K Octa-Core incl. NVMe SSD – 1 TB, 64 GB DDR4 RAM
1 Plasma Kontant-indieningsnodus is verhoog.
3 validerende Plasma Kontant nodusse is verkry.
'n Toets is van stapel gestuur om transaksies by die Plasma Cash-netwerk te voeg.
Totaal: 10 Plasma Kontant nodusse in 'n private netwerk.
Toets 1
Daar is 'n limiet van 1 miljoen transaksies per blok. Daarom val 1 miljoen transaksies in 2 blokke (aangesien die stelsel dit regkry om deel van die transaksies te neem en in te dien terwyl dit gestuur word).
Aanvanklike toestand: laaste blok #7; 1 miljoen transaksies en tokens word in die databasis gestoor.
00:00 — begin van transaksiegenereringskrip
01:37 - 1 miljoen transaksies is geskep en versending na die nodus het begin
01:46 — indiennodus het 240 8 transaksies uit die poel en vorms blok #320 geneem. Ons sien ook dat 10 XNUMX transaksies binne XNUMX sekondes by die poel gevoeg word
01:58 — blok #8 is onderteken en gestuur vir bekragtiging
02:03 — blok #8 is bekragtig en die `submitBlock`-funksie van die slimkontrak word met die Merkle-hash en bloknommer geroep
02:10 - demo-skrip het klaar gewerk, wat 1 miljoen transaksies in 32 sekondes gestuur het
02:33 - nodusse het begin om inligting te ontvang dat blok #8 by die wortelketting gevoeg is, en het begin om 240k transaksies uit te voer
02:40 - 240k transaksies is uit die poel verwyder, wat reeds in blok #8 is
02:56 - indiennodus het die oorblywende 760 9 transaksies uit die poel geneem en die Merkle-hash begin bereken en tekenblok #XNUMX
03:20 - alle nodusse bevat 1 miljoen 240k transaksies en tokens
03:35 — blok #9 is onderteken en gestuur vir bekragtiging na ander nodusse
03:41 - netwerkfout het voorgekom
04:40 — wag vir blok #9-bekragtiging het uitgetel
04:54 - indiennodus het die oorblywende 760 9 transaksies uit die poel geneem en die Merkle-hash begin bereken en tekenblok #XNUMX
05:32 — blok #9 is onderteken en gestuur vir bekragtiging na ander nodusse
05:53 — blok #9 word bekragtig en na die wortelketting gestuur
06:17 - nodusse het inligting begin ontvang dat blok #9 by die wortelketting gevoeg is en 760k transaksies begin uitvoer
06:47 — die poel het transaksies wat in blok #9 is, skoongemaak
09:06 - alle nodusse bevat 2 miljoen transaksies en tokens
Toets 2
Daar is 'n limiet van 350k per blok. As gevolg hiervan het ons 3 blokke.
Aanvanklike toestand: laaste blok #9; 2 miljoen transaksies en tokens word in die databasis gestoor
00:00 — transaksiegenereringskrip is reeds bekendgestel
00:44 - 1 miljoen transaksies is geskep en versending na die nodus het begin
00:56 — indiennodus het 320 10 transaksies uit die poel en vorms blok #320 geneem. Ons sien ook dat 10 XNUMX transaksies binne XNUMX sekondes by die poel gevoeg word
01:12 — blok #10 word onderteken en na ander nodusse gestuur vir bekragtiging
01:18 - demo-skrip het klaar gewerk, wat 1 miljoen transaksies in 34 sekondes gestuur het
01:20 — blok #10 word bekragtig en na die wortelketting gestuur
01:51 - alle nodusse het inligting van die wortelketting ontvang dat blok #10 bygevoeg is en begin om 320k transaksies toe te pas
02:01 - die swembad het skoongemaak vir 320 10 transaksies wat by blok #XNUMX gevoeg is
02:15 — indiennodus het 350 11 transaksies uit die swembad en vormsblok #XNUMX geneem
02:34 — blok #11 is onderteken en na ander nodusse gestuur vir bekragtiging
02:51 — blok #11 word bekragtig en na die wortelketting gestuur
02:55 — die laaste nodus het transaksies vanaf blok #10 voltooi
10:59 — die transaksie met die indiening van blok #9 het baie lank in die wortelketting geneem, maar dit is voltooi en alle nodusse het inligting daaroor ontvang en begin om 350k transaksies uit te voer
11:05 - die swembad het skoongemaak vir 320 11 transaksies wat by blok #XNUMX gevoeg is
12:10 - alle nodusse bevat 1 miljoen 670k transaksies en tokens
12:17 — indiennodus het 330 12 transaksies uit die swembad en vormsblok #XNUMX geneem
12:32 — blok #12 is onderteken en na ander nodusse gestuur vir bekragtiging
12:39 — blok #12 word bekragtig en na die wortelketting gestuur
13:44 - alle nodusse het inligting van die wortelketting ontvang dat blok #12 bygevoeg is en begin om 330k transaksies toe te pas
14:50 - alle nodusse bevat 2 miljoen transaksies en tokens
Toets 3
In die eerste en tweede bedieners is een validerende nodus vervang deur 'n indienende nodus.
Aanvanklike toestand: laaste blok # 84; 0 transaksies en tokens gestoor in die databasis
00:00 — 3 skrifte is bekendgestel wat elk 1 miljoen transaksies genereer en stuur
01:38 — 1 miljoen transaksies is geskep en die versending van nodus #3 het begin
01:50 — stuur nodus #3 het 330 85 transaksies uit die poel geneem en vorm blok #21 (f350). Ons sien ook dat 10 XNUMX transaksies binne XNUMX sekondes by die poel gevoeg word
01:53 — 1 miljoen transaksies is geskep en die versending van nodus #1 het begin
01:50 — stuur nodus #3 het 330 85 transaksies uit die poel geneem en vorm blok #21 (f350). Ons sien ook dat 10 XNUMX transaksies binne XNUMX sekondes by die poel gevoeg word
02:01 — dien nodus #1 in het 250 85 transaksies uit die poel geneem en vorm blok #65 (XNUMXe)
02:06 — blok #85 (f21) word onderteken en na ander nodusse gestuur vir bekragtiging
02:08 - demo-skrip van bediener #3, wat 1 miljoen transaksies in 30 sekondes gestuur het, het klaar gewerk
02:14 — blok #85 (f21) word bekragtig en na die wortelketting gestuur
02:19 — blok #85 (65e) is onderteken en na ander nodusse gestuur vir bekragtiging
02:22 — 1 miljoen transaksies is geskep en die versending van nodus #2 het begin
02:27 — blok #85 (65e) bekragtig en na die wortelketting gestuur
02:29 — stuur node #2 het 111855 transaksies uit die poel geneem en vorm blok #85 (256).
02:36 — blok #85 (256) is onderteken en na ander nodusse gestuur vir bekragtiging
02:36 - demo-skrip van bediener #1, wat 1 miljoen transaksies in 42.5 sekondes gestuur het, het klaar gewerk
02:38 — blok #85 (256) word bekragtig en na die wortelketting gestuur
03:08 - bediener #2-skrip het klaar gewerk, wat 1 miljoen transaksies in 47 sekondes gestuur het
03:38 - alle nodusse het inligting van die wortelketting ontvang dat blokke #85 (f21), #86(65e), #87(256) bygevoeg is en begin om 330k, 250k, 111855 transaksies toe te pas
03:49 - die poel is skoongemaak teen 330k, 250k, 111855 transaksies wat by blokke #85 (f21), #86(65e), #87(256) gevoeg is
03:59 — indien node #1 het 888145 88 transaksies van die poel en vorms blok #214 (2), indien node #750 het 88k transaksies van die poel geneem en vorms blok #50 (3a), indien node #670 het 88k transaksies geneem van die swembad en vorm blok #3 (dXNUMXb)
04:44 — blok #88 (d3b) word onderteken en na ander nodusse gestuur vir bekragtiging
04:58 — blok #88 (214) is onderteken en na ander nodusse gestuur vir bekragtiging
05:11 — blok #88 (50a) is onderteken en na ander nodusse gestuur vir bekragtiging
05:11 — blok #85 (d3b) word bekragtig en na die wortelketting gestuur
05:36 — blok #85 (214) word bekragtig en na die wortelketting gestuur
05:43 - alle nodusse het inligting van die wortelketting ontvang wat blokke #88 (d3b), #89(214) is bygevoeg en begin 670k, 750k transaksies toepas
06:50 — weens 'n kommunikasiefout is blok #85 (50a) nie bekragtig nie
06:55 — dien nodus #2 in het 888145 transaksies uit die poel geneem en vorm blok #90 (50a)
08:14 — blok #90 (50a) is onderteken en na ander nodusse gestuur vir bekragtiging
09:04 — blok #90 (50a) word bekragtig en na die wortelketting gestuur
11:23 - alle nodusse het inligting van die wortelketting ontvang dat blok #90 (50a) bygevoeg is, en begin om 888145 transaksies toe te pas. Terselfdertyd het bediener #3 reeds transaksies vanaf blokke #88 (d3b), #89(214) toegepas
12:11 - alle swembaddens is leeg
13:41 — alle nodusse van bediener #3 bevat 3 miljoen transaksies en tokens
14:35 — alle nodusse van bediener #1 bevat 3 miljoen transaksies en tokens
19:24 — alle nodusse van bediener #2 bevat 3 miljoen transaksies en tokens
Struikelblokke
Tydens die ontwikkeling van Plasma Cash het ons die volgende probleme teëgekom wat ons geleidelik opgelos en besig is om op te los:
1. Konflik in die interaksie van verskeie stelselfunksies. Byvoorbeeld, die funksie om transaksies by die poel te voeg, het die werk van die indien en validering van blokke geblokkeer, en omgekeerd, wat gelei het tot 'n daling in spoed.
2. Dit was nie onmiddellik duidelik hoe om 'n groot aantal transaksies te stuur terwyl data-oordragkoste tot die minimum beperk word nie.
3. Dit was nie duidelik hoe en waar om data te stoor om hoë resultate te behaal nie.
4. Dit was nie duidelik hoe om 'n netwerk tussen nodusse te organiseer nie, aangesien die grootte van 'n blok met 1 miljoen transaksies ongeveer 100 MB in beslag neem.
5. Werk in enkeldraadmodus verbreek die verband tussen nodusse wanneer lang berekeninge plaasvind (byvoorbeeld, die bou van 'n Merkle-boom en die berekening van sy hash).
Hoe het ons dit alles hanteer?
Die eerste weergawe van die Plasma Kontant-nodus was 'n soort kombinasie wat alles op dieselfde tyd kon doen: transaksies aanvaar, blokke indien en bekragtig, en 'n API verskaf vir toegang tot data. Aangesien NodeJS inheems enkeldraad is, het die swaar Merkle-boomberekeningsfunksie die voegtransaksiefunksie geblokkeer. Ons het twee opsies gesien om hierdie probleem op te los:
1. Begin verskeie NodeJS-prosesse, wat elkeen spesifieke funksies verrig.
2. Gebruik worker_threads en skuif die uitvoering van 'n deel van die kode na drade.
As gevolg hiervan het ons albei opsies gelyktydig gebruik: ons het logies een nodus in 3 dele verdeel wat afsonderlik, maar terselfdertyd sinchronies kan werk
1. Voorleggingsnodus, wat transaksies in die swembad aanvaar en blokke skep.
2. 'n Validerende nodus wat die geldigheid van nodusse kontroleer.
3. API node - bied 'n API vir toegang tot data.
In hierdie geval kan u met behulp van cli aan elke nodus koppel via 'n Unix-sok.
Ons het swaar operasies, soos die berekening van die Merkle-boom, in 'n aparte draad geskuif.
Dus het ons normale werking van alle Plasma Kontant-funksies gelyktydig en sonder mislukkings bereik.
Sodra die stelsel funksioneel was, het ons die spoed begin toets en het ongelukkig onbevredigende resultate gekry: 5 000 transaksies per sekonde en tot 50 000 transaksies per blok. Ek moes uitvind wat verkeerd geïmplementeer is.
Om mee te begin, het ons die meganisme van kommunikasie met Plasma Cash begin toets om die piekvermoë van die stelsel uit te vind. Ons het vroeër geskryf dat die Plasma Cash-nodus 'n unix-sok-koppelvlak bied. Aanvanklik was dit teksgebaseer. json-objekte is gestuur met behulp van `JSON.parse()` en `JSON.stringify()`.
```json
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
```
Ons het die oordragspoed van sulke voorwerpe gemeet en ~ 130k per sekonde gevind. Ons het probeer om die standaardfunksies vir werk met json te vervang, maar werkverrigting het nie verbeter nie. Die V8-enjin moet goed geoptimaliseer wees vir hierdie bedrywighede.
Ons het met transaksies, tokens en blokke deur klasse gewerk. By die skep van sulke klasse het die prestasie met 2 keer gedaal, wat aandui dat OOP nie vir ons geskik is nie. Ek moes alles oorskryf na 'n suiwer funksionele benadering.
Opname in die databasis
Aanvanklik is Redis gekies vir databerging as een van die mees produktiewe oplossings wat aan ons vereistes voldoen: sleutelwaardeberging, werk met hash-tabelle, stelle. Ons het redis-benchmark bekendgestel en het ~80k bewerkings per sekonde in 1 pyplynmodus gekry.
Vir hoë werkverrigting het ons Redis fyner ingestel:
- 'n Unix-sokverbinding is tot stand gebring.
- Ons het die stoor van die staat op skyf gedeaktiveer (vir betroubaarheid kan u 'n replika opstel en op skyf stoor in 'n aparte Redis).
In Redis is 'n poel 'n hash-tabel omdat ons alle transaksies in een navraag moet kan ophaal en transaksies een vir een moet uitvee. Ons het probeer om 'n gewone lys te gebruik, maar dit is stadiger wanneer die hele lys afgelaai word.
By die gebruik van standaard NodeJS het die Redis-biblioteke 'n prestasie van 18k transaksies per sekonde behaal. Die spoed het 9 keer gedaal.
Aangesien die maatstaf vir ons gewys het dat die moontlikhede duidelik 5 keer groter is, het ons begin om te optimaliseer. Ons het die biblioteek na ioredis verander en prestasie van 25k per sekonde gekry. Ons het transaksies een vir een bygevoeg deur die `hset`-opdrag te gebruik. Ons het dus baie navrae in Redis gegenereer. Die idee het ontstaan om transaksies in bondels te kombineer en dit met een opdrag `hmset` te stuur. Die resultaat is 32k per sekonde.
Om verskeie redes, wat ons hieronder sal beskryf, werk ons met data deur `Buffer` te gebruik en, soos dit blyk, as jy dit omskakel na teks (`buffer.toString('hex')`) voordat jy skryf, kan jy bykomende kry optrede. Die spoed is dus tot 35k per sekonde verhoog. Op die oomblik het ons besluit om verdere optimalisering op te skort.
Ons moes oorskakel na 'n binêre protokol omdat:
1. Die stelsel bereken dikwels hashes, handtekeninge, ens., en hiervoor benodig dit data in die `Buffer.
2. Wanneer dit tussen dienste gestuur word, weeg binêre data minder as teks. Byvoorbeeld, wanneer 'n blok met 1 miljoen transaksies gestuur word, kan die data in die teks meer as 300 megagrepe opneem.
3. Om data voortdurend te transformeer, beïnvloed prestasie.
Daarom het ons ons eie binêre protokol vir die stoor en oordrag van data as basis geneem, ontwikkel op grond van die wonderlike `binêre-data`-biblioteek.
As gevolg hiervan het ons die volgende datastrukture gekry:
— Transaksie
```json
{
prevHash: BD.types.buffer(20),
prevBlock: BD.types.uint24le,
tokenId: BD.types.string(null),
type: BD.types.uint8,
newOwner: BD.types.buffer(20),
dataLength: BD.types.uint24le,
data: BD.types.buffer(({current}) => current.dataLength),
signature: BD.types.buffer(65),
hash: BD.types.buffer(32),
blockNumber: BD.types.uint24le,
timestamp: BD.types.uint48le,
}
```
— Teken
```json
{
id: BD.types.string(null),
owner: BD.types.buffer(20),
block: BD.types.uint24le,
amount: BD.types.string(null),
}
```
— Blokkeer
```json
{
number: BD.types.uint24le,
merkleRootHash: BD.types.buffer(32),
signature: BD.types.buffer(65),
countTx: BD.types.uint24le,
transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
timestamp: BD.types.uint48le,
}
```
Met die gewone opdragte `BD.encode(block, Protocol).slice();` en `BD.decode(buffer, Protocol)` skakel ons die data om in `Buffer` vir stoor in Redis of aanstuur na 'n ander nodus en herwinning van die data terug.
Ons het ook 2 binêre protokolle vir die oordrag van data tussen dienste:
— Protokol vir interaksie met Plasma Node via Unix-sok
```json
{
type: BD.types.uint8,
messageId: BD.types.uint24le,
error: BD.types.uint8,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
waar:
- 'tipe' — die aksie wat uitgevoer moet word, byvoorbeeld, 1 — sendTransaction, 2 — getTransaction;
- `loonvrag` — data wat na die toepaslike funksie oorgedra moet word;
- `boodskap-ID` — boodskap-ID sodat die antwoord geïdentifiseer kan word.
— Protokol vir interaksie tussen nodusse
```json
{
code: BD.types.uint8,
versionProtocol: BD.types.uint24le,
seq: BD.types.uint8,
countChunk: BD.types.uint24le,
chunkNumber: BD.types.uint24le,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
waar:
- `kode` — boodskapkode, byvoorbeeld 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
- `versionProtocol` - protokol weergawe, aangesien nodusse met verskillende weergawes op die netwerk opgewek kan word en hulle anders kan werk;
- `volgende` - boodskap identifiseerder;
- `countChunk` и `chunkNumber` nodig vir die verdeling van groot boodskappe;
- `lengte` и `loonvrag` lengte en die data self.
Aangesien ons die data vooraf getik het, is die finale stelsel baie vinniger as Ethereum se `rlp`-biblioteek. Ongelukkig kon ons dit nog nie weier nie, aangesien dit nodig is om die slim kontrak te finaliseer, wat ons beplan om in die toekoms te doen.
As ons daarin geslaag het om die spoed te bereik 35 000 transaksies per sekonde, moet ons dit ook in die optimale tyd verwerk. Aangesien die benaderde blokvormingstyd 30 sekondes neem, moet ons in die blok insluit 1 000 000 transaksies, wat beteken om meer te stuur 100 MB data.
Aanvanklik het ons die `ethereumjs-devp2p`-biblioteek gebruik om tussen nodusse te kommunikeer, maar dit kon nie soveel data hanteer nie. As gevolg hiervan het ons die `ws`-biblioteek gebruik en die stuur van binêre data via websocket gekonfigureer. Ons het natuurlik ook probleme ondervind met die stuur van groot datapakkies, maar ons het dit in stukke verdeel en nou is hierdie probleme weg.
Vorm ook 'n Merkle-boom en bereken die hash 1 000 000 transaksies vereis oor 10 sekondes van deurlopende berekening. Gedurende hierdie tyd slaag die verbinding met alle nodusse daarin om te breek. Daar is besluit om hierdie berekening na 'n aparte draad te skuif.
Gevolgtrekkings:
Trouens, ons bevindings is nie nuut nie, maar om een of ander rede vergeet baie kenners daarvan wanneer hulle ontwikkel.
- Die gebruik van funksionele programmering in plaas van objekgeoriënteerde programmering verbeter produktiwiteit.
- Die monoliet is erger as 'n diensargitektuur vir 'n produktiewe NodeJS-stelsel.
- Die gebruik van `worker_threads` vir swaar berekeninge verbeter die reaksie van die stelsel, veral wanneer dit met i/o-bewerkings te doen het.
- unix-sok is meer stabiel en vinniger as http-versoeke.
- As jy vinnig groot data oor die netwerk moet oordra, is dit beter om websockets te gebruik en binêre data te stuur, verdeel in stukke, wat aangestuur kan word as hulle nie opdaag nie, en dan in een boodskap gekombineer word.
Ons nooi jou uit om te kom kuier GitHub projek:
Die artikel is saam geskryf deur Alexander Nashivan, senior ontwikkelaar .
Bron: will.com