Kad būtų lengviau suprasti, apie ką šis straipsnis, pradėkime nuo "Stack Overflow" vidutinės dienos statistikos pakeitimo. Šie skaičiai yra iš 2013 m. lapkričio 12 d. statistikos:
- Apkrovos balansavimo priemonė priėmė 148 084 833 HTTP užklausas
- Iš jų 36 095 312 buvo įkelti puslapiai
- 833 992 982 627 baitų (776 GB) HTTP srauto
- Iš viso gauta 286 574 644 032 baitų (267 GB) duomenų
- Iš viso buvo išsiųsta 1 125 992 557 312 baitų (1 048 GB) duomenų
- 334 572 103 SQL užklausos (įskaitant tik HTTP užklausas)
- 412 865 051 Redis užklausos
- 3 603 418 Žymių variklio užklausos
- SQL užklausoms prireikė 558 224 585 ms (155 valandų)
- "Redis" užklausoms prireikė 99 346 916 ms (27 valandų)
- Išleido 132 384 059 ms (36 valandas) žymės variklio užklausai
- ASP.Net proceso apdorojimas užtruko 2 728 177 045 ms (757 valandas)
Toliau pateikiami duomenys rodo statistikos pokyčius nuo 2016 m. vasario 9 d., kad galėtumėte palyginti:
- HTTP užklausos, gautos apkrovos balansavimo priemonės: 209 420 973 (+61 336 090)
- 66 294 789 (+30 199 477), iš kurių įkeliami puslapiai
- Išsiųsti HTTP duomenys: 1 240 266 346 053 (+406 273 363 426) baitai (1,24 TB)
- Bendras gautų duomenų kiekis: 569 449 470 023 (+282 874 825 991) baitai (569 GB)
- Bendras išsiųstų duomenų kiekis: 3 084 303 599 266 (+1 958 311 041 954) baitai (3,08 TB)
- SQL užklausos (tik iš HTTP užklausų): 504 816 843 (+170 244 740)
- "Redis" talpyklos peržiūros: 5 831 683 114 (+5 418 818 063)
- Elastinės paieškos: 17 158 874 (nesekama 2013 m.)
- Žymos variklio užklausos: 3,661,134 (+57,716)
- Bendras laikas, sunaudotas SQL užklausoms vykdyti: 607 073 066 (+48 848 481) ms (168 valandos)
- Redis talpyklos paspaudimų laikas: 10 396 073 (-88 950 843) ms (2,8 valandos)
- Žymų variklio užklausų sunaudotas laikas: 147 018 571 (+14 634 512) ms (40,8 valandos)
- ASP.Net apdorojimo laikas: 1 609 944 301 (-1 118 232 744) ms (447 valandos)
- 22,71 (-5,29) 49 180 275 numerio puslapių vidutinis atvaizdavimo laikas (iš jų 19,12 ms sunaudojama ASP.Net)
- 11,80 (-53,2) ms 6 370 076 pirmųjų puslapių vidutinis atvaizdavimo laikas (iš jų 8,81 ms sunaudojama ASP.Net)
Jums gali kilti klausimas, kodėl ASP.Net apdoroja 61 milijoną daugiau užklausų per dieną, bet sutrumpina apdorojimo laiką 757 valandomis (palyginti su 2013 m.). Taip yra daugiausia dėl 2015 m. pradžioje atliktų serverių atnaujinimų, taip pat dėl daugybės našumo optimizavimo programoje darbų. Nepamirškite: našumas vis dar yra pardavimo taškas. Jei jums labiau įdomu apie konkrečią aparatūros informaciją, nesijaudinkite, kitame straipsnyje pateiksiu konkrečią aparatinės įrangos informaciją apie serverius, naudojamus šioms svetainėms paleisti priede (atnaujinsiu šią nuorodą, kai ateis laikas).
Taigi, kas pasikeitė per pastaruosius dvejus metus? Nedaug, tik pakeičiant kai kuriuos serverius ir tinklo įrangą. Štai serverių, naudojamų jūsų svetainei paleisti šiandien, apžvalga (atkreipkite dėmesį, kaip jie pasikeitė nuo 2013 m.)
- 4 "Microsoft SQL Server" serveriai (iš kurių 2 naudoja naują aparatinę įrangą)
- 11 IIS žiniatinklio serveriai (nauja aparatinė įranga)
- 2 Redis serveriai (nauja aparatūra)
- 3 "Tag Engine" serveriai (2 iš jų naudoja naują aparatinę įrangą)
- 3 "Elasticsearch" serveriai (tokie patys kaip aukščiau)
- 4 HAProxy apkrovos balansavimo serveriai (2 pridėti palaikyti CloudFlare)
- 2 tinklo įrenginiai ("Nexus 5596 core + 2232TM Fabric Extender", visi įrenginiai atnaujinti iki 10 Gbps pralaidumo)
- 2 x Fortinet 800C ugniasienė (pakeičia Cisco 5525-X ASA)
- 2 Cisco ASR-1001 maršrutizatoriai (pakeičia Cisco 3945 maršrutizatorius)
- 2 Cisco ASR-1001-x maršrutizatoriai (NAUJIENA!) ）
Ko mums reikia, kad "Stack Overflow" veiktų? Nuo 2013 m. nedaug kas pasikeitė, tačiau dėl aukščiau paminėtų optimizacijų ir naujos aparatinės įrangos dabar mums reikia tik vieno žiniatinklio serverio. Šią situaciją jau išbandėme netyčia, kelis kartus sėkmingai. Atkreipkite dėmesį: aš ką tik sakiau, kad tai veikia, aš nesakiau, kad tai gera idėja. Bet kiekvieną kartą, kai tai atsitinka, tai yra gana įdomu.
Dabar, kai turime keletą bazinių serverio mastelio idėjų skaičių, pažiūrėkime, kaip sukūrėme šiuos šaunius tinklalapius. Nedaug sistemų egzistuoja visiškai savarankiškai (ir mūsiškės nėra išimtis), o be holistinio požiūrio, integruojančio šias dalis, architektūros planavimo prasmė labai sumažėja. Mūsų tikslas – suvokti bendrą situaciją. Ateityje bus daug straipsnių, kurie gilinasi į kiekvieną konkrečią sritį. Šis straipsnis yra tik pagrindinės aparatinės įrangos loginės struktūros santrauka, o kitame straipsnyje bus pateikta konkreti informacija apie šią aparatinę įrangą.
Jei norite pamatyti, kaip ši aparatinė įranga atrodo šiandien, čia yra keletas nuotraukų, kurias padariau iš A kabineto (B kabinetas yra lygiai toks pat), kai atnaujinau serverį 2015 m. vasario mėn.:
Dabar pasinerkime į architektūros išdėstymą. Toliau pateikiama pagrindinių esamų sistemų loginės architektūros santrauka:
Pagrindiniai principai
Štai keletas bendrų principų, kurių nereikia įvesti paeiliui:
- Viskas turi nereikalingas atsargines kopijas.
- Visi serveriai ir tinklo įrenginiai turi bent du 10 Gbps pralaidumo ryšius.
- Visi serveriai turi du maitinimo šaltinius, kurie tiekia energiją per du UPS įrenginių rinkinius, du generatorius už jų ir du tinklo įtampos tiekimo šaltinius.
- Visi serveriai turi perteklinę atsarginę kopiją, esančią Rack A ir Rack B.
- Visi serveriai ir paslaugos turi dvigubas atsargines kopijas atskirame duomenų centre (Kolorade), nors daugiausia aprėpiu Niujorką.
- Viskas turi nereikalingas atsargines kopijas.
internetas
Pirmiausia turite rasti mūsų svetainę, kuri yra DNS dalykas. Svetainių paieška yra greita, todėl dabar atiduodame ją "CloudFlare", nes jie turi DNS serverius kiekviename pasaulio kampelyje. Mes atnaujiname DNS įrašus per API, ir jie yra atsakingi už DNS "valdymą". Tačiau mūsų piktadarių mintyse vis dar turime savo DNS serverius dėl giliai įsišaknijusių pasitikėjimo problemų. Kai apokalipsė yra apokaliptinė – galbūt dėl GPL, Punyon ar talpyklos problemų – ir žmonės vis dar nori programuoti, kad nukreiptų savo dėmesį, mes pereiname prie savo DNS serverių.
Kai jūsų naršyklė randa mūsų slėptuvę, HTTP srautas iš mūsų keturių IPT (Level 3, Zayo, Cogent ir Lightower Niujorke) patenka į vieną iš keturių mūsų pažangių maršrutizatorių. Mes naudojame "Border Gateway Protocol" (BGP, labai standartinį protokolą) lygiaverčiam srautui iš tinklo tiekėjų, kad jį valdytume ir suteiktume efektyviausią būdą pasiekti mūsų paslaugas. ASR-1001 ir ASR-1001-X maršrutizatoriai yra suskirstyti į dvi grupes, kurių kiekviena turėtų naudoti aktyvųjį/aktyvųjį režimą, kad apdorotų srautą iš abiejų tinklo tiekėjų – čia yra perteklinės atsarginės kopijos. Nors jie visi turi tą patį fizinį 10 Gbps pralaidumą, srautas iš išorės vis tiek nepriklauso nuo išorinio VLAN srauto ir yra atskirai prijungtas prie apkrovos balansavimo. Kai srautas praeis per maršrutizatorių, pateksite į apkrovos balansavimo priemonę.
Manau, kad galbūt laikas paminėti, kad tarp dviejų duomenų centrų turime MPLS su 10 Gbps pralaidumu, nors tai tikrai nėra tiesiogiai susiję su svetainės paslaugomis. Šią technologiją naudojame replikacijai už svetainės ribų ir greitam duomenų atkūrimui, kad galėtume susidoroti su tam tikromis ekstremaliomis situacijomis. "Bet Nikai, čia nėra jokio pertekliaus!" Na, techniniu požiūriu esate teisus (teigiama prasme), tai iš tikrųjų yra vienas nesėkmės taškas šiame lygmenyje. Bet palaukite! Per tinklo teikėją taip pat turime du papildomus OSPF perjungimo maršrutus (MPLS yra pirmasis pasirinkimas, o tai yra antrasis ir trečiasis pasirinkimai dėl išlaidų). Kiekvienas iš anksčiau minėtų įrenginių rinkinių bus atitinkamai prijungtas prie Kolorado duomenų centro, kad būtų galima subalansuoti tinklo srautą perjungimo atveju. Žinoma, galėjome sujungti šiuos du įrenginių rinkinius tarpusavyje, kad būtų keturi kelių rinkiniai, bet pamirškite tai, judėkime toliau.
Apkrovos balansavimas (HAProxy)
Apkrovos balansavimas įgyvendinamas naudojant HAProxy 1.5.15, veikiančią CentOS 7 (mūsų mėgstamiausia Linux versija). Ir pridėkite TLS (SSL) saugaus perdavimo protokolą HAProxy. Taip pat stebime HAProxy 1.7, kuri iš karto palaikys HTTP/2 protokolą.
Skirtingai nuo kitų serverių su dviem 10 Gbps LACP tinklo ryšiais, kiekvienas apkrovos balansavimo įrenginys turi du 10 Gbps ryšius: vieną išoriniam tinklui, kitą DMZ. Šie serveriai turi 64 GB ar daugiau atminties, kad būtų galima efektyviau valdyti SSL protokolo sluoksnį. Kai galime talpykloje ir pakartotinai naudoti daugiau TLS seansų atmintyje, prisijungdami prie to paties kliento sunaudojame mažiau skaičiavimo išteklių. Tai reiškia, kad galime greičiau ir pigiau atkurti seansus. Atmintis yra tokia pigi, kad tai lengvas pasirinkimas.
Patį apkrovos balansavimą lengva nustatyti. Mes klausome skirtingų svetainių keliuose skirtinguose IP adresuose (daugiausia dėl sertifikatų ir DNS valdymo priežasčių) ir tada nukreipiame srautą į skirtingas backends (daugiausia pagal pagrindinio kompiuterio antraštes). Vienintelis dalykas, kurį čia darome, yra apriboti greitį ir nuskaityti tam tikrą antraštės informaciją (iš žiniatinklio sluoksnio), kad galėtume prisijungti prie HAProxy sistemos žurnalo pranešimų, tokiu būdu galime įrašyti kiekvienos užklausos našumo metriką. Tai išsamiai paminėsime vėliau.
Žiniatinklio sluoksnis (IIS 8.5, ASP.Net MVC 5.2.3 ir .Net 4.6.1)
Apkrovos balansavimas paskirsto srautą tarp 9 vadinamųjų pirminių žiniatinklio serverių (01-09) ir 2 kūrimo žiniatinklio serverių (10-11, mūsų bandymo aplinka). Pagrindiniame serveryje veikia "Stack Overflow", "Careers" ir visos "Stack Exchange" svetainės, o "meta.stackoverflow.com" ir "meta.stackexchange.com" veikia kituose dviejuose serveriuose. Pati pagrindinė klausimų ir atsakymų programa yra kelių nuomotojų, o tai reiškia, kad viena programa apdoroja visas užklausas iš klausimų ir atsakymų svetainės. Kitaip tariant, visą klausimų ir atsakymų programą galime paleisti viename programų telkinyje viename serveryje. Kitos programos, tokios kaip karjera, API v2, mobilioji API ir kt., yra nepriklausomos. Štai ką matote IIS pagrindiniams ir kūrėjų serveriams:
Štai "Stack Overflow" žiniatinklio pakopos pasiskirstymas, kaip matyti "Opserver" (mūsų vidinis stebėjimo prietaisų skydelis):
Štai šių žiniatinklio serverių išteklių suvartojimas:
Kitame straipsnyje išsamiau aptarsiu, kodėl mes per daug teikiame tiek daug išteklių, sutelkdami dėmesį į slenkančią konstrukciją, laisvę ir perteklių.
Aptarnavimo lygmuo (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 ir HTTP. SYS)
Šalia žiniatinklio sluoksnio yra paslaugų sluoksnis. Jie taip pat veikia kartu su IIS 2012 sistemoje "Windows 8.5R2". Šiame sluoksnyje veikia kai kurios vidinės tarnybos, palaikančios žiniatinklio sluoksnį ir kitas vidines gamybos aplinkos sistemas. Dvi pagrindinės paslaugos yra: "Stack Server", kuris paleidžia žymų variklį ir yra pagrįstas http.sys (ne IIS); Apvaizdos API (remiantis IIS). Įdomus faktas: turėjau susieti du procesus, kad galėčiau prisijungti prie skirtingų lizdų, nes "Stack Server" labai dažnai pasiekdavo L2 ir L3 talpyklas, kai atnaujindavo problemų sąrašą kas dvi minutes.
Mašinos, kuriose veikia šios paslaugos, yra labai svarbios žymų varikliui ir vidinėms API, todėl jos turi būti nereikalingos, bet ne 9 kartus perteklinės. Pavyzdžiui, visus straipsnius ir jų žymas iš duomenų bazės įkeliame kas n minučių (šiuo metu 2 minutes), o tai nėra mažai. Mes nenorime kartoti šios apkrovos operacijos 9 kartus žiniatinklio sluoksnyje, 3 kartus mums yra pakankamai saugu. Šiems serveriams taip pat naudojame skirtingas aparatūros konfigūracijas, kad geriau optimizuotume žymų variklio ir elastinio indekso užduočių skaičiavimo ir duomenų įkėlimo charakteristikas (taip pat veikiančias šiame sluoksnyje). Pats "žymų variklis" yra gana sudėtinga tema, kuri bus aptarta specialiame straipsnyje. Pagrindinis principas yra tas, kad kai pasiekiate adresą /questions/tagged/java, apsilankote žymėjimo variklyje, kad gautumėte jį atitinkančius klausimus. Variklis tvarko visus žymų atitikimą, išskyrus /search, todėl visur, įskaitant naują navigaciją, gauna duomenis per šią paslaugą.
Talpykla ir publikavimas / prenumerata (Redis)
Kai kuriose vietose naudojome "Redis" ir jis turi tvirtą stabilumą. Nors per mėnesį atliekama net 160 milijardų operacijų, procesorius vienam egzemplioriui neviršija 2%, o tai paprastai yra mažesnis:
Mes naudojame Redis L1/L2 lygio talpyklos sistemoms. "L1" lygis yra HTTP talpykla, veikianti žiniatinklio serveryje ar bet kurioje panašioje programoje. "L2" lygis skirtas gauti duomenis per "Redis" po to, kai sugenda ankstesnio lygio talpykla. Mūsų duomenys saugomi Protobuf formatu, įgyvendinamu per protobuf-dot-net, kurį parašė Marc Gravel. "Redis" klientui naudojome "StackExchange.Redis" biblioteką, kuri yra atvirojo kodo biblioteka, sukurta įmonėje. Jei žiniatinklio serveris nepataiko į L1 ir L2 talpyklas, jis gauna duomenis iš savo duomenų šaltinių (duomenų bazės užklausų, API iškvietimų ir pan.) ir išsaugo rezultatus vietinėje talpykloje ir Redis. Nuskaitant tuos pačius duomenis L1 talpykloje gali trūkti kito serverio, tačiau jis nuskaitys duomenis L2/Redis, todėl nereikės duomenų bazės užklausų ar API iškvietimų.
Taip pat paleidžiame daug klausimų ir atsakymų svetainių, kurių kiekviena turi savo L1/L2 talpyklą: raktas kaip priešdėlis L1 talpykloje ir duomenų bazės ID L2/Redis talpykloje. Mes gilinsimės į šią temą būsimuose straipsniuose.
Be dviejų pagrindinių Redis serverių (vienas pagrindinis ir vienas vergas), kuriuose veikia visi svetainės egzemplioriai, mes taip pat sukūrėme mašininio mokymosi egzempliorių (daugiausia dėl atminties priežasčių) naudodami du kitus dedikuotus vergų serverius. Ši serverių grupė naudojama teikti tokias paslaugas kaip klausimų rekomendavimas pagrindiniame puslapyje ir geresnis darbo atitikimas. Ši platforma vadinasi "Providence", apie kurią rašė Kevinas Montrose'as.
Pagrindiniame "Redis" serveryje yra 256 GB RAM (naudojama apie 90 GB), o "Providence" serveryje - 384 GB atminties (naudojama apie 125 GB).
"Redis" skirta ne tik talpyklai, bet ir publikavimo ir prenumeratos mechanizmui, kai vienas serveris gali paskelbti pranešimą, o kiti prenumeratoriai gali gauti pranešimą (įskaitant "Redis" iš serverio klientų). Šį mechanizmą naudojame norėdami išvalyti L1 talpyklą kitose paslaugose, kad išlaikytume talpyklos nuoseklumą žiniatinklio serveryje. Tačiau jis turi dar vieną svarbų panaudojimą: žiniatinklio lizdus.
Žiniatinklio lizdai (NetGain)
Mes naudojame žiniatinklio lizdus, kad vartotojams siųstume atnaujinimus realiuoju laiku, pvz., pranešimus viršutinėje juostoje, balsus, naują naršymą, naujus atsakymus, komentarus ir kt.
Pats lizdo serveris veikia žiniatinklio sluoksnyje, naudodamas vietinius lizdus. Tai labai maža programa, pagrįsta mūsų atvirojo kodo bibliotekos įgyvendinimu: StackExchange.NetGain. Piko metu turėjome apie 500 000 vienu metu internetinių lizdų ryšių, o tai yra daug naršyklių. Įdomus faktas: kai kurios iš šių naršyklių buvo atidarytos daugiau nei 18 mėnesių, todėl turėsite rasti ką nors, kad pamatytumėte, ar tie kūrėjai vis dar gyvi. Toliau pateiktoje diagramoje parodytas šios savaitės žiniatinklio lizdo sutapimo modelis:
Kodėl verta naudoti žiniatinklio lizdus? Mūsų mastu tai daug efektyviau nei apklausos. Tokiu būdu galime tiesiog perkelti daugiau duomenų su mažiau išteklių ir būti daugiau realiuoju laiku vartotojams. Tačiau šis požiūris nėra be problemų: laikini prievadai, išnaudotos apkrovos balansavimo įrenginių failų rankenėlės yra labai įdomios problemos, apie kurias kalbėsime vėliau.
Paieška (Elasticsearch)
Spoileris: Čia nėra daug ko džiaugtis. Žiniatinklio sluoksnis naudoja "Elasticsearch 1.4" ir įdiegia itin lengvą, didelio našumo "StackExchange.Elastic" klientą. Skirtingai nuo daugelio dalykų, mes neplanuojame atvirojo kodo šios dalies, tiesiog todėl, kad ji atskleidžia labai mažą API poaibį, kurį turime naudoti. Esu įsitikinęs, kad viešinimas nusveria nuostolius ir tik suklaidins kūrėjus. Šiose vietose naudojame elastic:/search, kad apskaičiuotume susijusius klausimus ir pateiktume pasiūlymus užduodami klausimus.
Kiekviename "Elastic" klasteryje (po vieną kiekvienam duomenų centrui) yra 3 mazgai, kurių kiekvienas turi savo indeksą. Karjeros svetainėje taip pat yra keletas papildomų rodyklių. Šiek tiek mažiau standartinė mūsų konfigūracijos elastiniuose ratuose dalis yra ta, kad mūsų 3 serverių klasteris yra šiek tiek galingesnis nei įprasta konfigūracija: kiekvienas serveris naudoja SSD saugyklą, 192 GB atminties, dvigubą 10 Gbps pralaidumo tinklą.
Tame pačiame "Stack Server" programos domene (taip, šioje vietoje mus mėtė .Net Core) taip pat yra žymų variklis, kuris taip pat naudoja "Elasticsearch" nuolatiniam indeksavimui. Čia naudojame nedidelį triuką, pvz., naudodami ROWVERSION SQL serveryje (duomenų šaltinis), kad palygintume su "paskutinės vietos" dokumentu "Elastic". Kadangi jis yra akivaizdžiai nuoseklus, mums lengva nuskaityti ir indeksuoti turinį, jei jis modifikuojamas po paskutinio apsilankymo.
Pagrindinė priežastis, kodėl naudojame "Elasticsearch" vietoj tokių technologijų kaip SQL viso teksto paieška, yra jos mastelio keitimas ir ekonomiškumas. SQL procesoriuose yra palyginti brangus, o "Elastic" yra daug pigesnis ir pastaruoju metu turi daug naujų funkcijų. Kodėl gi nepasinaudojus Solr? Mums reikia ieškoti visame tinkle (su keliais indeksais tuo pačiu metu), o Solr nepalaiko šio scenarijaus mūsų sprendimų metu. Priežastis, kodėl mes dar nenaudojome 2.x, yra ta, kad tipai labai pasikeitė 2.x, o tai reiškia, kad mes turime iš naujo indeksuoti viską, jei norime atnaujinti. Tiesiog neturiu pakankamai laiko planuoti reikalavimų pakeitimus ir perkėlimus.
Duomenų bazė (SQL serveris)
Mes naudojame SQL serverį kaip vieną tiesos šaltinį. Visi "Elastic" ir "Redis" duomenys gaunami iš "SQL Server". Turime du "SQL Server" klasterius ir esame sukonfigūruoti su "AlwaysOn" pasiekiamumo grupėmis. Kiekvienas klasteris turi pagrindinį serverį Niujorke (kuris užima beveik visą apkrovą) ir replikos serverį, be replikos serverio Kolorade (mūsų avarinio atkūrimo duomenų centras). Visos kopijavimo operacijos yra asinchroninės.
Pirmasis klasteris yra "Dell R720xd" serverių rinkinys, kiekvienas su 384 GB atminties, PCIe SSD su 4 TB vietos ir dviem 12 branduolių procesoriais. Tai apima "Stack Overflow", "Sites" (tai blogas pavadinimas, paaiškinsiu vėliau), PRIZM ir "Mobile" duomenų bazę.
Antrasis klasteris yra "Dell R730xd" serverių rinkinys, kiekvienas su 768 GB atminties, PCIe SSD su 6 TB vietos ir dviem 8 branduolių procesoriais. Šiame klasteryje yra visos kitos duomenų bazės, įskaitant karjerą, atvirą ID, pokalbius, išimčių žurnalus ir kitas klausimų ir atsakymų svetaines (pvz., Super vartotojas, serverio gedimas ir kt.).
Duomenų bazės lygmenyje norime, kad procesoriaus naudojimas būtų labai žemas, nors praktiškai procesoriaus naudojimas bus šiek tiek didesnis, kai atsiranda tam tikrų suplanuotų talpyklos problemų (kurias šaliname). Šiuo metu NY-SQL02 ir 04 yra pagrindiniai serveriai, o 01 ir 03 yra replikų serveriai, ir mes juos tiesiog perkrovėme šiandien dėl SSD atnaujinimo. Štai kaip jie pasirodė per pastarąsias 24 valandas:
Mūsų SQL naudojimas yra labai paprastas. Paprasta reiškia greitai. Nors kai kurie užklausos teiginiai gali būti iškreipti, mūsų sąveika su SQL pati yra daroma gana vietiniu būdu. Turime šiek tiek senojo Linq2Sql, tačiau visi mūsų nauji kūriniai naudoja Dapper, mūsų atvirojo kodo mikro-ORM sistemą, kuri naudoja POCO. Leiskite man paaiškinti kitaip: Stack Overflow turi tik vieną saugomą procedūrą savo duomenų bazėje, ir aš ketinu nužudyti šią paskutinę likusią saugomą procedūrą ir pakeisti ją kodu.
biblioteka
Na, pakeiskime savo nuomonę, čia yra dalykų, kurie gali jums padėti tiesiogiai. Kai kuriuos iš jų jau minėjau anksčiau, bet pateiksiu daugelio atvirojo kodo .Net bibliotekų, kurias prižiūrime ir kuriomis naudojasi visi, sąrašą. Mes juos atvirojo kodo, nes jie neturi pagrindinės verslo vertės, tačiau jie gali padėti kūrėjams visame pasaulyje. Tikiuosi, kad galėsite juos naudoti dabar:
- Dapper (.Net Core) – didelio našumo mikro-ORM sistema, skirta ADO.Net
- StackExchange.Redis – didelio našumo Redis klientas
- "MiniProfiler" – lengvas profiliavimo įrankis, kurį naudojame kiekviename puslapyje (taip pat palaiko "Ruby", "Go" ir "Node")
- Išskirtinis – klaidų registravimui SQL, JSON, MySQL ir kt.
- Jil – didelio našumo JSON serializavimas ir deserializatorius
- Sigil – .Net CIL kartos pagalbininkas (naudojamas, kai C# nėra pakankamai greitas)
- NetGain – didelio našumo žiniatinklio lizdo serveris
- "Opserver" – stebėjimo prietaisų skydelis, kuris tiesiogiai apklausia daugumą sistemų ir gali gauti informaciją iš "Orion", "Bosun" ar WMI
- Bosun – Stebėjimo sistema fone, parašyta Go
|
Paskelbta 2018-04-11 17:33:18
|
|
|
|
