|
|
Julkaistu 11.4.2018 17.33.18
|
|
|
|
Jotta tämän artikkelin sisältö olisi helpompi ymmärtää, aloitetaan Stack Overflow'n keskimääräisen päivittäisen tilaston muutoksesta. Seuraavat luvut ovat tilastoista 12. marraskuuta 2013 tilanteen mukaan:
- Kuormantasapainotin hyväksyi 148 084 833 HTTP-pyyntöä
- Näistä 36 095 312 oli sivulatauksia
- 833 992 982 627 tavua (776 GB) HTTP-liikennettä käytetään lähettämiseen
- Yhteensä vastaanotettiin 286 574 644 032 tavua (267 GB) dataa
- Lähetettiin yhteensä 1 125 992 557 312 tavua (1 048 GB) dataa
- 334,572,103 SQL-kyselyä (mukaan lukien vain HTTP-pyynnöistä)
- 412 865 051 Redis-pyyntöä
- 3 603 418 Tag Engine -pyyntöä
- SQL-kyselyissä kesti 558 224 585 ms (155 tuntia)
- Redis-pyyntöihin meni 99 346 916 ms (27 tuntia)
- Käytti 132 384 059 ms (36 tuntia) tag-moottoripyyntöön
- ASP.Net prosessointi kesti 2 728 177 045 ms (757 tuntia)
Seuraavat tiedot osoittavat tilastojen muutokset 9. helmikuuta 2016 mennessä, joten voit verrata:
- Kuormantasapainottimen vastaanottamat HTTP-pyynnöt: 209 420 973 (+61 336 090)
- 66 294 789 (+30 199 477), joista sivu latautuu
- HTTP-data lähetetty: 1,240,266,346,053 (+406,273,363,426) tavua (1,24 TB)
- Vastaanotettujen tietojen kokonaismäärä: 569 449 470 023 (+282 874 825 991) tavua (569 GB)
- Lähetettyjen tietojen kokonaismäärä: 3 084 303 599 266 (+1 958 311 041 954) tavua (3,08 TB)
- SQL-kyselyt (vain HTTP-pyynnöistä): 504,816,843 (+170,244,740)
- Redis Cache -osumat: 5 831 683 114 (+5 418 818 063)
- Elastiset haut: 17 158 874 (ei seurattu vuonna 2013)
- Tag-moottoripyyntöjä: 3 661 134 (+57 716)
- Kumulatiivinen aika, joka kuluu SQL-kyselyiden suorittamiseen: 607,073,066 (+48,848,481) ms (168 tuntia)
- Redis-välimuistin käyttöaika: 10 396 073 (-88 950 843) ms (2,8 tuntia)
- Tag-moottoripyyntöjen kuluttama aika: 147 018 571 (+14 634 512) ms (40,8 tuntia)
- ASP.Net käsittelyssä käytetty aika: 1 609 944 301 (-1 118 232 744) ms (447 tuntia)
- 22,71 (-5,29) ms 49 180 275 numerosivua Keskimääräinen renderöintiaika (josta 19,12 ms kuluu ASP.Net)
- 11,80 (-53,2) ms 6 370 076 ensimmäistä sivua keskimääräinen renderöintiaika (josta 8,81 ms kuluu ASP.Net)
Saatat miettiä, miksi ASP.Net käsittelee 61 miljoonaa pyyntöä päivässä, mutta lyhentää käsittelyaikaa 757 tunnilla (verrattuna vuoteen 2013). Tämä johtuu pääasiassa palvelimiemme päivityksistä vuoden 2015 alussa sekä monista sovelluksen sisäisistä suorituskyvyn optimointitöistä. Älä unohda: suorituskyky on edelleen myyntivaltti. Jos olet kiinnostuneempi laitteiston yksityiskohdista, älä huoli, annan seuraavassa artikkelissa liitteenä niiden palvelimien laitteistotiedot (päivitän tämän linkin, kun sen aika tulee).
Mitä sitten on muuttunut viimeisen kahden vuoden aikana? Ei paljoa, vaihdan vain joitakin palvelimia ja verkkolaitteita. Tässä on yleiskatsaus palvelimista, joilla verkkosivustosi pyörii tänään (huomaa, miten ne ovat muuttuneet vuodesta 2013)
- 4 Microsoft SQL Server -palvelinta (joista 2 käyttää uutta laitteistoa)
- 11 IIS-verkkopalvelinta (uusi laitteisto)
- 2 Redis-palvelinta (uusi laitteisto)
- 3 Tag Engine -palvelinta (joista 2 käyttää uutta laitteistoa)
- 3 Elasticsearch-palvelinta (sama kuin yllä)
- 4 HAProxy-kuormantasauspalvelinta (2 lisätty tukemaan CloudFlarea)
- 2 verkkolaitetta (Nexus 5596 core + 2232TM Fabric Extender, kaikki laitteet päivitetty 10Gbps kaistanleveyteen)
- 2 x Fortinet 800C -palomuuria (korvaa Cisco 5525-X ASA -palomuurit)
- 2 Cisco ASR-1001 -reititintä (korvaa Cisco 3945 -reitittimet)
- 2 Cisco ASR-1001-x -reititintä (UUSI!) ）
Mitä tarvitsemme, jotta Stack Overflow toimisi? Vuoden 2013 jälkeen ei ole paljoa muuttunut, mutta kiitos yllä mainittujen optimointien ja uuden laitteiston, tarvitsemme nyt vain yhden web-palvelimen. Olemme jo testanneet tätä tilannetta vahingossa, onnistuneesti useita kertoja. Huomioithan: sanoin juuri, että se toimii, en sanonut, että se on hyvä idea. Mutta joka kerta kun näin tapahtuu, se on varsin mielenkiintoista.
Nyt kun meillä on perustiedot palvelinskaalausideoista, katsotaanpa, miten teimme nämä siistit verkkosivut. Harvat järjestelmät ovat olemassa täysin itsenäisesti (eikä meidän järjestelmämme ole poikkeus), ja ilman kokonaisvaltaista näkemystä, joka yhdistää nämä osat, arkkitehtuurin suunnittelun merkitys vähenee huomattavasti. Tavoitteemme on ymmärtää kokonaisvaltainen tilanne. Tulevaisuudessa tulee paljon artikkeleita, jotka käsittelevät kutakin tiettyä alaa syvällisesti. Tämä artikkeli on vain yhteenveto avainlaitteiston loogisesta rakenteesta, ja seuraava artikkeli sisältää tarkempia tietoja näistä laitteistoista.
Jos haluat nähdä, miltä tämä laitteisto näyttää tänään, tässä on muutama kuva, jotka otin kaapista A (kaappi B on täsmälleen samanlainen kuin se), kun päivitin palvelimen helmikuussa 2015:
Nyt sukelletaan arkkitehtuurin pohjaratkaisuun. Seuraavassa on yhteenveto pääjärjestelmien loogisesta arkkitehtuurista:
Perusperiaatteet
Tässä on joitakin yleisiä periaatteita, joita ei tarvitse ottaa käyttöön vuorotellen:
- Kaikessa on päällekkäiset varmuuskopiot.
- Kaikilla palvelimilla ja verkkolaitteilla on vähintään kaksi 10Gbps:n kaistanleveysyhteyttä.
- Kaikissa palvelimissa on kaksi virtalähdettä, jotka tuottavat virtaa kahden UPS-yksikkösarjan, kahden generaattorin takana ja kahden verkkojännitteen eteenpäin syötön kautta.
- Kaikilla palvelimilla on redundantti varmuuskopio, joka sijaitsee Rack A:ssa ja Rack B:ssä.
- Kaikilla palvelimilla ja palveluilla on kaksinkertaiset varmuuskopiot erillisessä datakeskuksessa (Coloradossa), vaikka pääasiassa raportoin New Yorkista.
- Kaikessa on päällekkäiset varmuuskopiot.
internet
Ensiksi sinun täytyy löytää verkkosivustomme, joka on DNS-juttu. Verkkosivustojen löytäminen on nopeaa, joten annamme sen nyt CloudFlareille, koska heillä on DNS-palvelimia joka kolkassa maailmassa. Päivitämme DNS-tietueita API:n kautta, ja ne vastaavat DNS:n "hallinnasta". Kuitenkin pahantahtoisissa mielissämme meillä on yhä omat DNS-palvelimemme syvälle juurtuneiden luottamusongelmien vuoksi. Kun maailmanloppu on apokalyptinen – ehkä GPL:n, Punyonin tai välimuistiongelmien takia – ja ihmiset haluavat edelleen ohjelmoida harhauttaakseen huomionsa, vaihdamme omiin DNS-palvelimiimme.
Kun selaimesi löytää piilopaikkamme, HTTP-liikenne neljältä ISP:ltämme (Level 3, Zayo, Cogent ja Lightower New Yorkissa) saapuu johonkin neljästä kehittyneestä reitittimestämme. Käytämme Border Gateway Protocolia (BGP, hyvin standardi protokolla) vertaisverkon tarjoajien vertaisliikenteen hallintaan ja tehokkaimman tavan käyttää palveluitamme. ASR-1001- ja ASR-1001-X-reitittimet on jaettu kahteen ryhmään, joista kumpikin käyttää aktiivi-/aktiivista tilaa molempien verkkopalveluntarjoajien liikenteen käsittelyyn – tässä on päällekkäiset varmuuskopiot. Vaikka kaikilla on sama fyysinen kaistanleveys 10 Gbps, ulkopuolelta tuleva liikenne on silti riippumatonta ulkoisen VLANin liikenteestä ja on kytketty kuormantasapainotukseen erikseen. Kun liikenne kulkee reitittimen läpi, siirryt kuormanjakajalle.
Luulen, että olisi aika mainita, että meillä on MPLS, jossa kahden datakeskuksen välillä on 10Gbps kaistanleveys, vaikka tämä ei oikeastaan liity suoraan verkkosivustopalveluihin. Käytämme tätä teknologiaa ulkopuoliseen replikointiin ja nopeaan datan palautukseen tiettyjen hätätilanteiden ratkaisemiseksi. "Mutta Nick, tässä ei ole toistetta!" Teknisestä näkökulmasta olet oikeassa (positiivisessa mielessä), tällä tasolla kyse on oikeastaan yksittäisestä epäonnistumispisteestä. Mutta odota! Verkkopalveluntarjoajan kautta meillä on myös kaksi lisäospf-varareittiä (MPLS on ensimmäinen vaihtoehto, ja nämä ovat toinen ja kolmas vaihtoehto kustannussyistä). Jokainen aiemmin mainituista laiteryhmistä yhdistetään Coloradon datakeskukseen kuormantasapainotuksen mukaisesti verkkoliikenteen kuormituksen mukaisesti vikasion sattuessa. Tietenkin olisimme voineet yhdistää nämä kaksi laitesarjaa toisiinsa, jolloin olisi neljä reittisarjaa, mutta unohda se, mennään eteenpäin.
Kuormantasaus (HAProxy)
Kuormantasaus toteutetaan HAProxy 1.5.15:llä, joka toimii CentOS 7:llä (suosikkiversiomme Linuxista). Ja lisää TLS (SSL) turvallinen siirtoprotokolla HAProxyyn. Seuraamme myös HAProxy 1.7:ää, joka tukee HTTP/2-protokollaa heti.
Toisin kuin muilla palvelimilla, joissa on kaksi 10Gbps LACP-verkkoyhteyttä, jokaisella kuormantasapainottimella on kaksi 10Gbps-yhteyttä: toinen ulkoiselle verkolle ja toinen DMZ:lle. Näissä palvelimissa on 64GB tai enemmän muistia, jotta SSL-protokollakerros voidaan käsitellä tehokkaammin. Kun voimme välimuistittaa ja käyttää enemmän TLS-istuntoja muistissa, kulutamme vähemmän laskentaresursseja yhdistäessämme samaan asiakkaaseen. Tämä tarkoittaa, että voimme palauttaa sessiot nopeammin ja edullisemmin. Muisti on niin halpaa, että se on helppo valinta.
Kuormantasaus itsessään on helppo ottaa käyttöön. Kuuntelemme eri verkkosivustoja useilla eri IP-osoitteilla (pääasiassa sertifikaattien ja DNS-hallinnan vuoksi) ja ohjaamme liikennettä eri taustalle (pääasiassa isäntäotsikoiden perusteella). Ainoa mitä tässä teemme, on rajoittaa nopeutta ja kerätä otsikkotietoja (web-kerroksesta) kirjautuaksemme HAProxyn järjestelmälokiviesteihin, näin voimme tallentaa suorituskyvyn mittarit jokaiselle pyynnölle. Kerromme tästä tarkemmin myöhemmin.
Verkkokerros (IIS 8.5, ASP.Net MVC 5.2.3 ja .Net 4.6.1)
Kuormantasaus jakaa liikenteen yhdeksän, niin sanotun ensisijaisen web-palvelimen (01-09) ja kahden kehitysverkkopalvelimen (10-11, testiympäristömme) kesken. Pääpalvelin pyörittää Stack Overflow'ta, Careersia ja kaikkia Stack Exchange -sivustoja, kun taas meta.stackoverflow.com ja meta.stackexchange.com pyörivät kahdella muulla palvelimella. Pääasiallinen Q&A-sovellus itsessään on monivuokralainen, eli yksi sovellus hoitaa kaikki Q&A-sivuston pyynnöt. Toisin sanoen, voimme ajaa koko Q&A-sovelluksen yhdellä sovelluspoolilla yhdellä palvelimella. Muut sovellukset, kuten Careers, API v2, Mobile API jne., ovat itsenäisiä. Tässä mitä näet IIS:ssä master- ja dev-palvelimilla:
Tässä on Stack Overflow'n web-tason jakauma, kuten Opserverissa (sisäinen valvontapaneelimme) näkyy:
Ja tässä on näiden verkkopalvelimien resurssien kulutus:
Kerron tarkemmin seuraavassa artikkelissa siitä, miksi tarjoamme niin paljon resursseja liikaa, keskittyen rullaavaan rakentamiseen, liikkumavaraan ja redundanssiin.
Palvelukerros (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 ja HTTP. SYS)
Web-kerroksen vieressä on palvelukerros. Ne toimivat myös IIS 2012:n päällä Windows 8.5R2:ssa. Tämä kerros pyörittää joitakin sisäisiä palveluita, jotka tukevat verkkokerrosta ja muita tuotantoympäristön sisäisiä järjestelmiä. Kaksi pääpalvelua ovat: "Stack Server", joka ajaa tag-moottoria ja perustuu http.sys:ään (ei IIS); Providence API (perustuu IIS:ään). Mielenkiintoinen fakta: jouduin yhdistämään kaksi prosessia yhdistääkseni eri soketteihin, koska Stack Server käytti L2- ja L3-välimuistia hyvin usein päivittäessään ongelmia kahden minuutin välein.
Näitä palveluita ajavat koneet ovat kriittisiä tag-moottorille ja taustarajapinnoille, joten niiden täytyy olla redundantteja, mutta eivät 9x redundantteja. Esimerkiksi lataamme kaikki artikkelit ja niiden tagit tietokannasta n minuutin välein (tällä hetkellä 2 minuuttia), mikä ei ole pieni. Emme halua toistaa tätä latausoperaatiota yhdeksän kertaa web-kerroksessa, kolme kertaa riittää meille turvalliseksi. Käytämme myös erilaisia laitteistokonfiguraatioita näille palvelimille, jotta voimme optimoida paremmin tag-moottorin ja elastisten indeksitöiden laskennallisia ja datan latausominaisuuksia (jotka toimivat myös tässä kerroksessa). "Tag-moottori" itsessään on suhteellisen monimutkainen aihe, jota käsitellään omassa artikkelissa. Perusperiaate on, että kun pääset osoitteeseen /questions/tagged/java, käyt tagausmoottorilla saadaksesi siihen sopivat kysymykset. Moottori hoitaa kaikki tagien sovitukset paitsi /search, joten kaikkialla, myös uusi navigointi, saa dataa tämän palvelun kautta.
Välimuisti ja julkaiseminen/tilaaminen (Redis)
Käytimme Redisiä joissain kohdissa, ja se on kivenvakaa vakaus. Vaikka kuukausittaisia operaatioita on jopa 160 miljardia, suorittimen osuus per instanssi ei ylitä 2 %, mikä on yleensä pienempi:
Käytämme Redisiä L1/L2-tason välimuistijärjestelmiin. "L1"-taso on HTTP-välimuisti, joka toimii web-palvelimessa tai vastaavassa sovelluksessa. "L2"-taso tarkoittaa datan keräämistä Redisin kautta edellisen tason välimuistin epäonnistumisen jälkeen. Tietomme tallennetaan Protobuf-muodossa, joka toteutetaan protobuf-dot-netin kautta, jonka on kirjoittanut Marc Gravel. Redis-asiakasohjelmassa käytimme StackExchange.Redis-kirjastoa, joka on avoimen lähdekoodin kirjasto, kehitetty itse. Jos web-palvelin ei osu sekä L1- että L2-välimuistiin, se hakee dataa tietolähteistään (tietokantakyselyt, API-kutsut jne.) ja tallentaa tulokset paikalliseen välimuistiin ja Redisiin. Seuraava palvelin saattaa puuttua L1-välimuistista, kun haetaan samaa dataa, mutta se hakee tiedot L2/Redisissä, jolloin tietokantakyselyt tai API-kutsut puuttuvat.
Meillä on myös paljon kysymys- ja vastaussivustoja, joilla jokaisella on oma L1/L2-välimuistinsa: avain etuliitteenä L1-välimuistissa ja tietokanta-ID L2/Redis-välimuistissa. Perehdymme tähän aiheeseen tulevissa artikkeleissa.
Kahden pääasiallisen Redis-palvelimen (yksi master ja yksi slave) lisäksi kaikki sivuston instanssit ovat käytössä, ja perustimme myös koneoppimisen instanssin (lähinnä muistin vuoksi) käyttäen kahta muuta omistettua slave-palvelinta. Tätä palvelinryhmää käytetään tarjoamaan palveluita, kuten ehdottamaan kysymyksiä etusivulla ja tekemään parempia työpaikkojen yhdistämistä. Tämä alusta on nimeltään Providence, ja Kevin Montrose kirjoitti siitä.
Pää-Redis-palvelimella on 256GB RAM-muistia (noin 90GB käytetty), ja Providence-palvelimella 384GB muistia (noin 125GB käytetty).
Redis ei ole tarkoitettu pelkästään välimuistiin, vaan siinä on myös julkaisu- ja tilausmekanismi, jossa yksi palvelin voi julkaista viestin ja muut tilaajat voivat vastaanottaa viestin (mukaan lukien Redis palvelimen alavirran asiakkailta). Käytämme tätä mekanismia tyhjentämään L1-välimuistin muista palveluista ylläpitääksemme välimuistin johdonmukaisuutta web-palvelimella. Mutta sillä on toinenkin tärkeä käyttötarkoitus: websocketit.
Websocketit (NetGain)
Käytämme websocketseja reaaliaikaisten päivitysten lähettämiseen käyttäjille, kuten ilmoituksia yläpalkissa, ääniä, uutta navigointia, uusia vastauksia, kommentteja ja paljon muuta.
Socket-palvelin toimii web-kerroksella käyttäen natiiveja soketteja. Tämä on hyvin pieni sovellus, joka perustuu avoimen lähdekoodin kirjaston toteutukseen: StackExchange.NetGain. Ruuhka-aikoina meillä oli noin 500 000 samanaikaista websocket-yhteyttä, mikä on paljon selaimia. Hauska fakta: jotkut näistä selaimista ovat olleet avoinna yli 18 kuukautta, ja sinun täytyy löytää joku nähdäksesi, ovatko kehittäjät vielä elossa. Seuraava kaavio näyttää websocket-rinnakkaisuuden mallin tällä viikolla:
Miksi käyttää websocketeja? Meidän mittakaavassamme se on paljon tehokkaampaa kuin mielipidemittaukset. Näin voimme yksinkertaisesti lähettää enemmän dataa vähemmillä resursseilla ja olla käyttäjille reaaliaikaisempia. Tämä lähestymistapa ei kuitenkaan ole ongelmaton: väliaikaiset portit, kuormituksen tasapainottimien loppuun kuluneet tiedostokahvat ovat erittäin mielenkiintoisia ongelmia, ja niistä puhumme myöhemmin.
Haku (Elasticsearch)
Spoileri: Tässä ei ole paljon innostumisen aiheita. Verkkokerros käyttää Elasticsearch 1.4:ää ja toteuttaa erittäin kevyen, tehokkaan StackExchange.Elastic-asiakasohjelman. Toisin kuin useimmissa muissa, emme aio avata tätä osaa, koska se paljastaa hyvin pienen osan API-rajapinnoista, joita tarvitsemme. Olen varma, että julkistaminen painaa enemmän kuin menetys ja vain hämmentää kehittäjiä. Käytämme näissä paikoissa elastic:/search-toimintoa laskeaksemme aiheeseen liittyviä kysymyksiä ja antaaksemme ehdotuksia kysymyksiä esittäessämme.
Jokainen elastinen klusteri (yksi jokaiselle datakeskukselle) sisältää 3 solmua, joilla jokaisella on oma indeksinsä. Urasivustolla on myös joitakin lisähakemistoja. Hieman vähemmän tavallinen osa joustavien ympyröiden konfiguraatiota on, että kolmen palvelimen klusteri on hieman tehokkaampi kuin tavallinen kokoonpano: jokainen palvelin käyttää SSD-tallennustilaa, 192 Gt muistia ja kaksoisverkkoa 10 Gbps kaistanleveydellä.
Sama sovellusalue kuin Stack Server (kyllä, meidät heitettiin tässä paikassa .Net Corella) ylläpitää myös tag-moottoria, joka käyttää Elasticsearchia jatkuvaan indeksointiin. Tässä käytämme pientä niksiä, kuten käyttämällä ROWVERSIONia SQL Serverissä (tietolähde) vertaillaksemme Elasticin "viimeinen paikka" -dokumenttiin. Koska se on ilmeisesti peräkkäinen, on helppo indeksoida ja indeksoida sisältöä, jos sitä muokataan viimeisen käynnin jälkeen.
Pääsyy siihen, miksi käytämme Elasticsearchia SQL-kokotekstihaun kaltaisten teknologioiden sijaan, on sen skaalautuvuus ja kustannustehokkuus. SQL on suhteellisen kallista suorittimilla, kun taas Elastic on paljon halvempi ja siinä on viime aikoina paljon uusia ominaisuuksia. Miksi et käyttäisi Solria? Meidän täytyy hakea verkon eri puolilta (useilla indekseillä samanaikaisesti), eikä Solr tue tätä skenaariota päätöstemme hetkellä. Syynä siihen, ettemme ole vielä käyttäneet 2.x:ää, on se, että tyypit ovat muuttuneet paljon 2.x:ssä, mikä tarkoittaa, että meidän täytyy indeksoida kaikki uudelleen, jos haluamme päivittää. Minulla ei vain ole tarpeeksi aikaa suunnitella vaatimusten muutoksia ja siirtymiä.
Tietokanta (SQL Server)
Käytämme SQL Serveriä yhtenä totuuden lähteenä. Kaikki Elasticin ja Redisin tiedot tulevat SQL Serveristä. Meillä on kaksi SQL Server -klusteria ja olemme konfiguroitu AlwaysOn-saatavuusryhmillä. Jokaisella klusterilla on pääpalvelin New Yorkissa (joka vie lähes kaiken kuorman) ja replikapalvelin, lisäksi replikapalvelin Coloradossa (meidän katastrofipalautusdatakeskus). Kaikki kopiointitoiminnot ovat asynkronisia.
Ensimmäinen klusteri on joukko Dell R720xd -palvelimia, joista jokaisessa on 384GB muistia, PCIe SSD, jossa on 4TB tilaa, sekä kaksi 12-ytimistä suoritinta. Se sisältää Stack Overflown, Sitesin (se on huono nimi, selitän sen myöhemmin), PRIZM ja Mobilen tietokanta.
Toinen klusteri on joukko Dell R730xd -palvelimia, joissa kummassakin on 768 Gt muistia, PCIe SSD, jossa on 6 Tt tilaa, sekä kaksi 8-ytimistä suoritinta. Tämä klusteri sisältää kaikki muut tietokannat, mukaan lukien Careers, Open ID, Chat, poikkeuslokit ja muut kysymys- ja vastaussivustot (esim. Super User, Server Fault jne.).
Tietokantatasolla haluamme pitää suorittimen käytön hyvin alhaisena, vaikka käytännössä suorittimen käyttö on hieman korkeampaa, kun suunniteltuja välimuistiongelmia ilmenee (joita parhaillaan vianmäärityksessä). Tällä hetkellä NY-SQL02 ja 04 ovat pääpalvelimet ja 01 ja 03 replikapalvelimet, ja käynnistimme ne uudelleen tänään SSD-päivityksen vuoksi. Näin he suoriutuivat viimeisen 24 tunnin aikana:
SQL:n käyttö on hyvin yksinkertaista. Yksinkertainen tarkoittaa nopeaa. Vaikka jotkut kyselylauseet voivat olla vääristyneitä, vuorovaikutuksemme SQL:n kanssa tapahtuu melko natiivisti. Meillä on joitakin perinteisiä Linq2SQL-malleja, mutta kaikki uudet kehityksemme käyttävät Dapperia, avoimen lähdekoodin mikro-ORM-kehystä, joka hyödyntää POCO:ta. Selitän asian toisin: Stack Overflowlla on vain yksi tallennettu proseduuri tietokannassaan, ja aion lopettaa tämän viimeisen tallennetun proseduurin ja korvata sen koodilla.
Kirjasto
No, muutetaan mielemme, tässä on asioita, jotka voivat auttaa sinua suoremmin. Olen maininnut joitakin niistä aiemminkin, mutta annan sinulle listan monista avoimen lähdekoodin .Net-kirjastoista, joita ylläpidämme ja joita kaikki käyttävät. Me avaamme ne avoimen lähdekoodin, koska niillä ei ole ydinliiketoimintaa mukana, mutta ne voivat auttaa kehittäjiä ympäri maailmaa. Toivon, että voit käyttää niitä nyt:
- Dapper (.Net Core) – Korkean suorituskyvyn mikro-ORM-kehys ADO.Net
- StackExchange.Redis – Korkean suorituskyvyn Redis-asiakasohjelma
- MiniProfiler – kevyt profilointi, jota käytämme jokaisella sivulla (tukee myös Rubyä, Go:ta ja Nodea)
- Poikkeuksellinen – Virheiden lokimiseen SQL:ssä, JSON:ssa, MySQL:ssä jne
- Jil – Korkean suorituskyvyn JSON-serialisointi ja purkaja
- Sigil – .Net CIL -generointiapulainen (käytetään, kun C# ei ole tarpeeksi nopea)
- NetGain – Korkean suorituskyvyn websocket-palvelin
- Opserver – Valvontapaneeli, joka kyselyy useimmista järjestelmistä suoraan ja voi hakea tietoja Orionista, Bosunista tai WMI:stä
- Bosun – Taustalla oleva valvontajärjestelmä, kirjoitettu Go-kielellä
|
Edellinen:enum enum tarkistaa, sisältyykö arvo enumiinSeuraava:Miten löydän MB:n nopeasti
|
