Lai būtu vieglāk saprast, par ko ir šis raksts, sāksim ar izmaiņām Stack Overflow vidējā dienas statistikā. Šādi skaitļi ir no statistikas uz 2013. gada 12. novembri:
- Slodzes balansētājs pieņēma 148 084 833 HTTP pieprasījumus
- No tiem 36 095 312 bija lapu ielādes
- Nosūtīšanai tiek izmantoti 833 992 982 627 baiti (776 GB) HTTP datplūsmas
- Kopumā tika saņemti 286 574 644 032 baiti (267 GB) datu
- Kopumā tika nosūtīti 1 125 992 557 312 baiti (1 048 GB) datu
- 334 572 103 SQL vaicājumi (ieskaitot tikai no HTTP pieprasījumiem)
- 412 865 051 Redis pieprasījumi
- 3,603,418 Tag Engine pieprasījumi
- SQL vaicājumiem bija nepieciešamas 558 224 585 ms (155 stundas)
- Redis pieprasījumiem bija nepieciešamas 99 346 916 ms (27 stundas)
- Pavadījis 132 384 059 ms (36 stundas) taga dzinēja pieprasījumam
- ASP.Net procesa apstrādei bija nepieciešamas 2 728 177 045 ms (757 stundas)
Tālāk sniegtie dati parāda statistikas izmaiņas 2016. gada 9. februārī, lai jūs varētu salīdzināt:
- HTTP pieprasījumi, ko saņem slodzes balansētājs: 209 420 973 (+61 336 090)
- 66 294 789 (+30 199 477), no tiem lapas ielādes
- Nosūtītie HTTP dati: 1 240 266 346 053 (+406 273 363 426) baiti (1,24 TB)
- Kopējais saņemto datu apjoms: 569 449 470 023 (+282 874 825 991) baiti (569 GB)
- Kopējais nosūtīto datu apjoms: 3 084 303 599 266 (+1 958 311 041 954) baiti (3,08 TB)
- SQL vaicājumi (tikai no HTTP pieprasījumiem): 504 816 843 (+170 244 740)
- Redis kešatmiņas trāpījumi: 5,831,683,114 (+5,418,818,063)
- Elastīgie meklējumi: 17,158,874 (nav izsekoti 2013. gadā)
- Tag dzinēja pieprasījumi: 3,661,134 (+57,716)
- Kumulatīvais laiks, kas patērēts SQL vaicājumu izpildei: 607 073 066 (+48 848 481) ms (168 stundas)
- Redis kešatmiņas trāpījuma laiks patērēts: 10,396,073 (-88,950,843) ms (2,8 stundas)
- Laiks, ko patērē tagu programmas pieprasījumi: 147,018,571 (+14,634,512) ms (40,8 stundas)
- ASP.Net apstrādē patērētais laiks: 1,609,944,301 (-1,118,232,744) ms (447 stundas)
- 22,71 (-5,29) 49 180 275 izdevumu lappušu vidējais renderēšanas laiks (no kuriem 19,12 ms tiek patērēti ASP.Net)
- 11,80 (-53,2) ms 6 370 076 pirmās lappuses vidējais renderēšanas laiks (no kuriem 8,81 ms tiek patērēts ASP.Net)
Jums var rasties jautājums, kāpēc ASP.Net apstrādā par 61 miljonu vairāk pieprasījumu dienā, bet samazina apstrādes laiku par 757 stundām (salīdzinājumā ar 2013. gadu). Tas galvenokārt ir saistīts ar mūsu serveru jauninājumiem 2015. gada sākumā, kā arī lielu veiktspējas optimizācijas darbu lietotnē. Neaizmirstiet: veiktspēja joprojām ir pārdošanas punkts. Ja jūs interesē konkrētās aparatūras detaļas, neuztraucieties, nākamajā rakstā pielikumā sniegšu specifisku informāciju par serveriem, kas tiek izmantoti šo vietņu palaišanai (es atjaunināšu šo saiti, kad pienāks laiks).
Tātad, kas ir mainījies pēdējo divu gadu laikā? Nav daudz, tikai nomainot dažus serverus un tīkla aprīkojumu. Šeit ir pārskats par serveriem, kas tiek izmantoti jūsu vietnes darbībai šodien (ņemiet vērā, kā tie ir mainījušies kopš 2013. gada)
- 4 Microsoft SQL Server serveri (2 no tiem izmanto jaunu aparatūru)
- 11 IIS tīmekļa serveri (jauna aparatūra)
- 2 Redis serveri (jauna aparatūra)
- 3 Tag Engine serveri (2 no tiem izmanto jaunu aparatūru)
- 3 Elasticsearch serveri (tādi paši kā iepriekš)
- 4 HAProxy slodzes balansēšanas serveri (2 pievienoti, lai atbalstītu CloudFlare)
- 2 tīkla ierīces (Nexus 5596 kodols + 2232TM auduma paplašinātājs, visas ierīces jauninātas uz 10 Gb/s joslas platumu)
- 2 x Fortinet 800C ugunsmūris (aizstāj Cisco 5525-X ASA)
- 2 Cisco ASR-1001 maršrutētāji (aizstāj Cisco 3945 maršrutētājus)
- 2 Cisco ASR-1001-x maršrutētāji (JAUNUMS!) ）
Kas mums nepieciešams, lai Stack Overflow darbotos? Kopš 2013. gada nav daudz mainījies, bet, pateicoties iepriekš minētajām optimizācijām un jaunajai aparatūrai, mums tagad ir nepieciešams tikai viens tīmekļa serveris. Mēs jau vairākas reizes esam pārbaudījuši šo situāciju netīši, ar panākumiem. Lūdzu, ņemiet vērā: es tikko teicu, ka tas darbojas, es neteicu, ka tā ir laba ideja. Bet katru reizi, kad tas notiek, tas ir diezgan interesanti.
Tagad, kad mums ir daži bāzes skaitļi par servera mērogošanas idejām, redzēsim, kā mēs izveidojām šīs foršās tīmekļa lapas. Dažas sistēmas pastāv pilnīgi neatkarīgi (un mūsu nav izņēmums), un bez holistiska skatījuma, kas integrē šīs daļas, arhitektūras plānošanas nozīme ir ievērojami samazināta. Mūsu mērķis ir aptvert kopējo situāciju. Nākotnē būs daudz rakstu, kas dziļi iedziļināsies katrā konkrētajā jomā. Šis raksts ir tikai galvenās aparatūras loģiskās struktūras kopsavilkums, un nākamajā rakstā būs konkrēta informācija par šo aparatūru.
Ja vēlaties redzēt, kā šī aparatūra izskatās šodien, šeit ir dažas fotogrāfijas, ko es uzņēmu no A kabineta (B kabinets ir tieši tāds pats kā tas), kad es jaunināju serveri 2015. gada februārī:
Tagad ienirsim arhitektūras izkārtojumā. Tālāk ir sniegts galveno esošo sistēmu loģiskās arhitektūras kopsavilkums:
Pamatprincipi
Šeit ir daži kopīgi principi, kas nav jāievieš pēc kārtas:
- Visam ir lieki dublējumi.
- Visiem serveriem un tīkla ierīcēm ir vismaz divi 10 Gbps joslas platuma savienojumi.
- Visiem serveriem ir divi barošanas avoti, kas nodrošina enerģiju caur diviem UPS bloku komplektiem, diviem ģeneratoriem aiz tiem un diviem tīkla sprieguma padeves uz priekšu.
- Visiem serveriem ir lieka dublēšana, kas atrodas Rack A un Rack B.
- Visiem serveriem un pakalpojumiem ir dubulti dublējumi atsevišķā datu centrā (Kolorādo), lai gan es galvenokārt aptveru Ņujorku.
- Visam ir lieki dublējumi.
Interneta
Vispirms jums jāatrod mūsu vietne, kas ir DNS lieta. Vietņu atrašana ir ātra, tāpēc mēs tagad to dodam CloudFlare, jo viņiem ir DNS serveri katrā pasaules malā. Mēs atjauninām DNS ierakstus, izmantojot API, un viņi ir atbildīgi par DNS "pārvaldību". Tomēr mūsu ļaundaru prātos mums joprojām ir savi DNS serveri dziļi iesakņojušos uzticības problēmu dēļ. Kad apokalipse ir apokaliptiska - varbūt GPL, Punyon vai kešatmiņas problēmu dēļ - un cilvēki joprojām vēlas programmēt, lai novirzītu savu uzmanību, mēs pārslēdzamies uz mūsu pašu DNS serveriem.
Kad jūsu pārlūkprogramma atrod mūsu slēptuvi, HTTP datplūsma no mūsu četriem ISP (Level 3, Zayo, Cogent un Lightower Ņujorkā) nonāk vienā no mūsu četriem uzlabotajiem maršrutētājiem. Mēs izmantojam Border Gateway Protocol (BGP, ļoti standarta protokolu), lai vienādranga datplūsmu no tīkla pakalpojumu sniedzējiem, lai to kontrolētu un nodrošinātu visefektīvāko veidu, kā piekļūt mūsu pakalpojumiem. ASR-1001 un ASR-1001-X maršrutētāji ir sadalīti divās grupās, no kurām katrai jāizmanto aktīvais / aktīvais režīms, lai apstrādātu trafiku no abiem tīkla pakalpojumu sniedzējiem - šeit ir lieki dublējumi. Lai gan tiem visiem ir vienāds fiziskais joslas platums 10 Gbps, trafiks no ārpuses joprojām ir neatkarīgs no ārējā VLAN trafika un ir savienots ar slodzes balansēšanu atsevišķi. Pēc tam, kad satiksme šķērso maršrutētāju, jūs nonāksiet pie slodzes balansētāja.
Es domāju, ka varētu būt pienācis laiks pieminēt, ka mums ir MPLS ar 10 Gbps joslas platumu starp abiem datu centriem, lai gan tas nav tieši saistīts ar vietnes pakalpojumiem. Mēs izmantojam šo tehnoloģiju, lai veiktu neklātienes replicēšanu un ātru datu atgūšanu, lai risinātu noteiktas ārkārtas situācijas. "Bet Nik, šajā ziņā nav nekādas atlaišanas!" Nu, no tehniskā viedokļa jums ir taisnība (pozitīvā nozīmē), tas patiešām ir viens neveiksmes punkts šajā līmenī. Bet pagaidiet! Izmantojot tīkla pakalpojumu sniedzēju, mums ir arī divi papildu OSPF failover maršruti (MPLS ir pirmā izvēle, un šī ir otrā un trešā izvēle izmaksu apsvērumu dēļ). Katrs no iepriekš minētajiem ierīču komplektiem tiks attiecīgi savienots ar Kolorādo datu centru, lai līdzsvarotu slodzes tīkla trafiku kļūmju gadījumā. Protams, mēs būtu varējuši savienot šos divus ierīču komplektus viens ar otru, lai būtu četri ceļu komplekti, bet aizmirstiet to, ejam tālāk.
Slodzes balansēšana (HAProxy)
Slodzes balansēšana tiek īstenota ar HAProxy 1.5.15, kas darbojas uz CentOS 7 (mūsu iecienītākā Linux versija). Un pievienojiet TLS (SSL) drošu pārraides protokolu HAProxy. Mēs arī sekojam līdzi HAProxy 1.7, kas uzreiz nodrošinās atbalstu HTTP/2 protokolam.
Atšķirībā no citiem serveriem ar diviem 10Gbps LACP tīkla savienojumiem, katram slodzes balansētājam ir divi 10Gbps savienojumi: viens ārējam tīklam un otrs DMZ. Šiem serveriem ir 64 GB vai vairāk atmiņas, lai efektīvāk apstrādātu SSL protokola slāni. Kad mēs varam kešatmiņā saglabāt un atkārtoti izmantot vairāk TLS sesiju, mēs patērējam mazāk skaitļošanas resursu, izveidojot savienojumu ar to pašu klientu. Tas nozīmē, ka mēs varam atjaunot sesijas ātrāk un lētāk. Atmiņa ir tik lēta, ka tā ir viegla izvēle.
Slodzes balansēšanu ir viegli iestatīt. Mēs klausāmies dažādas vietnes vairākos dažādos IP (galvenokārt sertifikātu un DNS pārvaldības nolūkos) un pēc tam novirzām trafiku uz dažādiem aizmugures elementiem (galvenokārt pamatojoties uz resursdatora galvenēm). Vienīgais, ko mēs šeit darām, ir ierobežot ātrumu un nokasīt galvenes informāciju (no tīmekļa slāņa), lai pieteiktos HAProxy sistēmas žurnāla ziņojumos, tādā veidā mēs varam ierakstīt katra pieprasījuma veiktspējas rādītājus. Mēs to sīkāk pieminēsim vēlāk.
Tīmekļa slānis (IIS 8.5, ASP.Net MVC 5.2.3 un .Net 4.6.1)
Slodzes balansēšana sadala datplūsmu starp 9 no tā saucamajiem primārajiem tīmekļa serveriem (01-09) un 2 izstrādes tīmekļa serveriem (10-11, mūsu testa vide). Galvenais serveris darbojas Stack Overflow, Careers un visas Stack Exchange vietnes, bet meta.stackoverflow.com un meta.stackexchange.com darbojas divos citos serveros. Galvenā jautājumu un atbilžu programma pati par sevi ir vairāku nomnieku, kas nozīmē, ka viena programma apstrādā visus pieprasījumus no jautājumu un atbilžu vietnes. Citiem vārdiem sakot, mēs varam palaist visu jautājumu un atbilžu lietotni vienā lietojumprogrammu pūlā vienā serverī. Citas lietotnes, piemēram, karjera, API v2, mobilā API utt., ir neatkarīgas. Lūk, ko redzat IIS galvenajiem un izstrādātāju serveriem:
Šeit ir Stack Overflow tīmekļa līmeņa sadalījums, kā redzams Opserver (mūsu iekšējais uzraudzības informācijas panelis):
Un šeit ir šo tīmekļa serveru resursu patēriņš:
Es sīkāk iedziļināšos nākamajā rakstā par to, kāpēc mēs pārmērīgi nodrošinām tik daudz resursu, koncentrējoties uz ritošo būvēšanu, rīcības brīvību un atlaišanu.
Servisa slānis (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 un HTTP. SYS)
Blakus tīmekļa slānim ir pakalpojumu slānis. Tie darbojas arī uz IIS 2012 operētājsistēmā Windows 8.5R2. Šajā slānī darbojas daži iekšējie pakalpojumi, kas atbalsta tīmekļa slāni un citas ražošanas vides iekšējās sistēmas. Divi galvenie pakalpojumi ir: "Stack Server", kas darbojas tagu dzinējs un ir balstīts uz http.sys (nevis IIS); Providence API (pamatojoties uz IIS). Interesants fakts: man bija jākorelē divi procesi, lai izveidotu savienojumu ar dažādām ligzdām, jo Stack Server ļoti bieži piekļūtu L2 un L3 kešatmiņām, atsvaidzinot problēmu sarakstu ar divu minūšu intervālu.
Mašīnas, kurās darbojas šie pakalpojumi, ir kritiski svarīgas tagu dzinējam un aizmugursistēmas API, tāpēc tām jābūt liekām, bet ne 9x liekām. Piemēram, mēs ielādējam visus rakstus un to tagus no datu bāzes ik pēc n minūtēm (pašlaik 2 minūtes), kas nav zems. Mēs nevēlamies atkārtot šo slodzes operāciju 9 reizes tīmekļa slānī, 3 reizes mums ir pietiekami droši. Mēs arī izmantojam dažādas aparatūras konfigurācijas šiem serveriem, lai labāk optimizētu tagu dzinēja un elastīgā indeksa darbu skaitļošanas un datu ielādes raksturlielumus (kas darbojas arī šajā slānī). Pats "tagu dzinējs" ir salīdzinoši sarežģīta tēma, kas tiks aplūkota īpašā rakstā. Pamatprincips ir tāds, ka, piekļūstot adresei /questions/tagged/java, jūs apmeklējat marķēšanas dzinēju, lai iegūtu tai atbilstošos jautājumus. Dzinējs apstrādā visu tagu atbilstību, izņemot /search, tāpēc visur, ieskaitot jauno navigāciju, iegūst datus caur šo pakalpojumu.
Kešatmiņa un publicēšana / abonēšana (Redis)
Dažās vietās mēs izmantojām Redis, un tam ir stabila stabilitāte. Lai gan mēnesī tiek veikti pat 160 miljardi operāciju, CPU vienā instancē nepārsniedz 2%, kas parasti ir zemāks:
Mēs izmantojam Redis L1/L2 līmeņa kešatmiņas sistēmām. "L1" līmenis ir HTTP kešatmiņa, kas darbojas tīmekļa serverī vai jebkurā līdzīgā lietojumprogrammā. "L2" līmenis ir iegūt datus caur Redis pēc iepriekšējā līmeņa kešatmiņas neveiksmes. Mūsu dati tiek glabāti Protobuf formātā, kas tiek īstenots, izmantojot protobuf-dot-net, ko rakstījis Marc Gravel. Redis klientam mēs izmantojām StackExchange.Redis bibliotēku, kas ir atvērtā koda bibliotēka, kas izstrādāta pašu spēkiem. Ja tīmekļa serveris nenonāk gan L1, gan L2 kešatmiņās, tas iegūst datus no saviem datu avotiem (datu bāzes vaicājumiem, API izsaukumiem utt.) un saglabā rezultātus vietējā kešatmiņā un Redis. Nākamais serveris var nebūt L1 kešatmiņā, izgūstot tos pašus datus, bet tas izgūs datus L2 / Redis, novēršot nepieciešamību pēc datu bāzes vaicājumiem vai API izsaukumiem.
Mēs arī palaižam daudz jautājumu un atbilžu vietņu, katrai no tām ir sava L1/L2 kešatmiņa: atslēga kā prefikss L1 kešatmiņā un datu bāzes ID L2/Redis kešatmiņā. Mēs iedziļināsimies šajā tēmā turpmākajos rakstos.
Papildus diviem galvenajiem Redis serveriem (viens galvenais un viens vergs), kas darbojas visās vietnes instancēs, mēs izveidojām arī mašīnmācīšanās instanci (galvenokārt atmiņas nolūkos), izmantojot divus citus īpašus vergu serverus. Šī serveru grupa tiek izmantota, lai sniegtu tādus pakalpojumus kā jautājumu ieteikšana mājaslapā un labāka darba saskaņošana. Šo platformu sauc par Providence, un Kevins Montrozs par to rakstīja.
Galvenajam Redis serverim ir 256 GB RAM (izmantoti aptuveni 90 GB), un Providence serverī ir 384 GB atmiņas (izmantoti aptuveni 125 GB).
Redis nav paredzēts tikai kešatmiņai, tam ir arī publicēšanas un abonēšanas mehānisms, kurā viens serveris var publicēt ziņojumu un citi abonenti var saņemt ziņojumu (ieskaitot Redis no servera pakārtotajiem klientiem). Mēs izmantojam šo mehānismu, lai notīrītu L1 kešatmiņu citos pakalpojumos, lai saglabātu kešatmiņas konsekvenci tīmekļa serverī. Bet tam ir vēl viens svarīgs pielietojums: tīmekļa ligzdas.
Tīmekļa ligzdas (NetGain)
Mēs izmantojam tīmekļa ligzdas, lai lietotājiem sniegtu reāllaika atjauninājumus, piemēram, paziņojumus augšējā joslā, balsojumus, jaunu navigāciju, jaunas atbildes, komentārus un daudz ko citu.
Pats ligzdas serveris darbojas tīmekļa slānī, izmantojot vietējās ligzdas. Šī ir ļoti maza lietojumprogramma, kuras pamatā ir mūsu atvērtā koda bibliotēkas ieviešana: StackExchange.NetGain. Pīķa laikā mums bija aptuveni 500 000 vienlaicīgu tīmekļa ligzdas savienojumu, kas ir daudz pārlūkprogrammu. Interesants fakts: dažas no šīm pārlūkprogrammām ir atvērtas vairāk nekā 18 mēnešus, un jums būs jāatrod kāds, lai redzētu, vai šie izstrādātāji joprojām ir dzīvi. Nākamajā diagrammā parādīts websocket vienlaicīguma modelis šonedēļ:
Kāpēc izmantot tīmekļa ligzdas? Mūsu mērogā tas ir daudz efektīvāk nekā aptaujas. Tādā veidā mēs varam vienkārši virzīt vairāk datu ar mazāk resursu un būt lietotājiem reāllaikā. Tomēr šī pieeja nav bez problēmām: pagaidu porti, izsmelti failu rokturi slodzes balansētājos ir ļoti interesantas problēmas, un mēs par tām runāsim vēlāk.
Meklēšana (Elasticsearch)
Spoileris: Šeit nav daudz par ko sajūsmināties. Tīmekļa slānis izmanto Elasticsearch 1.4 un ievieš īpaši vieglu, augstas veiktspējas StackExchange.Elastic klientu. Atšķirībā no vairuma lietu, mēs neplānojam atvērt šo daļu, vienkārši tāpēc, ka tā atklāj ļoti nelielu API apakškopu, kas mums jāizmanto. Esmu pārliecināts, ka tā publiskošana atsver zaudējumus un tikai mulsinās izstrādātājus. Mēs izmantojam elastic:/search šajās vietās, lai aprēķinātu saistītos jautājumus un sniegtu ieteikumus, uzdodot jautājumus.
Katrs Elastic klasteris (viens katram datu centram) satur 3 mezglus, katram ar savu indeksu. Karjeras vietnē ir arī daži papildu indeksi. Nedaudz mazāk standarta mūsu konfigurācijas elastīgajos apļos daļa ir tā, ka mūsu 3 serveru klasteris ir nedaudz jaudīgāks nekā parastā konfigurācija: katrs serveris izmanto SSD krātuvi, 192 GB atmiņu, dubultu tīklu ar 10 Gbps joslas platumu.
Tajā pašā Stack Server lietojumprogrammu domēnā (jā, šajā vietā mūs izmeta .Net Core) ir arī tagu dzinējs, kas arī izmanto Elasticsearch nepārtrauktai indeksēšanai. Šeit mēs izmantojam nelielu triku, piemēram, izmantojot ROWVERSION SQL Server (datu avots), lai salīdzinātu ar "pēdējās vietas" dokumentu Elastic. Tā kā tas ir acīmredzami secīgs, mums ir viegli pārmeklēt un indeksēt saturu, ja tas tiek modificēts pēc pēdējā apmeklējuma.
Galvenais iemesls, kāpēc mēs izmantojam Elasticsearch, nevis tādas tehnoloģijas kā SQL pilnteksta meklēšana, ir tā mērogojamība un rentabilitāte. SQL ir salīdzinoši dārgs CPU, savukārt Elastic ir daudz lētāks un pēdējā laikā tam ir daudz jaunu funkciju. Kāpēc neizmantot Solr? Mums ir jāmeklē visā tīklā (ar vairākiem indeksiem vienlaikus), un Solr neatbalsta šo scenāriju mūsu lēmumu pieņemšanas laikā. Iemesls, kāpēc mēs vēl neesam izmantojuši 2.x, ir tas, ka 2.x veidi ir ļoti mainījušies, kas nozīmē, ka mums viss ir jāindeksē atkārtoti, ja mēs vēlamies jaunināt. Man vienkārši nav pietiekami daudz laika, lai plānotu prasību izmaiņas un migrācijas.
Datu bāze (SQL Server)
Mēs izmantojam SQL Server kā vienotu patiesības avotu. Visi dati Elastic un Redis nāk no SQL Server. Mums ir divi SQL Server klasteri, un tie ir konfigurēti ar AlwaysOn pieejamības grupām. Katram klasterim ir primārais serveris Ņujorkā (kas aizņem gandrīz visu slodzi) un replikas serveris, papildus replikas serverim Kolorādo (mūsu katastrofu atkopšanas datu centrs). Visas kopēšanas operācijas ir asinhronas.
Pirmais klasteris ir Dell R720xd serveru komplekts, katrs ar 384 GB atmiņu, PCIe SSD ar 4 TB vietu un diviem 12 kodolu procesoriem. Tas ietver Stack Overflow, Sites (tas ir slikts vārds, es to paskaidrošu vēlāk), PRIZM un Mobile datu bāzi.
Otrais klasteris ir Dell R730xd serveru komplekts, katrs ar 768 GB atmiņu, PCIe SSD ar 6 TB vietu un diviem 8 kodolu procesoriem. Šajā klasterī ir visas pārējās datu bāzes, ieskaitot karjeru, Open ID, tērzēšanu, izņēmumu žurnālus un citas jautājumu un atbilžu vietnes (piemēram, Super User, Server Fault utt.).
Datu bāzes slānī mēs vēlamies saglabāt CPU izmantošanu ļoti zemā līmenī, lai gan praksē CPU lietojums būs nedaudz lielāks, ja rodas dažas plānotas kešatmiņas problēmas (kuras mēs novēršam). Pašlaik NY-SQL02 un 04 ir primārie serveri, un 01 un 03 ir repliku serveri, un mēs tos šodien vienkārši pārstartējām SSD jaunināšanas dēļ. Lūk, kā viņi darbojās pēdējo 24 stundu laikā:
Mūsu SQL izmantošana ir ļoti vienkārša. Vienkārši nozīmē ātri. Lai gan daži vaicājuma apgalvojumi var būt izkropļoti, mūsu mijiedarbība ar pašu SQL tiek veikta diezgan vietējā veidā. Mums ir daži mantoti Linq2Sql, bet visi mūsu jaunie notikumi izmanto Dapper, mūsu atvērtā koda mikro-ORM ietvaru, kas izmanto POCO. Ļaujiet man to paskaidrot citādi: Stack Overflow datu bāzē ir tikai viena saglabāta procedūra, un es nogalināšu šo pēdējo atlikušo saglabāto procedūru un aizstāšu to ar kodu.
bibliotēka
Nu, mainīsim savas domas, šeit ir lietas, kas var jums palīdzēt tiešāk. Es esmu pieminējis dažus no tiem iepriekš, bet es jums sniegšu sarakstu ar daudzajām atvērtā koda .Net bibliotēkām, kuras mēs uzturam un kuras visi izmanto. Mēs tos atveram pirmkodam, jo tiem nav pamata biznesa vērtības, bet tie var palīdzēt izstrādātājiem visā pasaulē. Es ceru, ka jūs varat tos izmantot tagad:
- Dapper (.Net Core) - augstas veiktspējas mikro-ORM sistēma ADO.Net
- StackExchange.Redis – augstas veiktspējas Redis klients
- MiniProfiler – viegls profilētājs, ko mēs izmantojam katrā lapā (atbalsta arī Ruby, Go un Node)
- Ārkārtas - kļūdu reģistrēšanai SQL, JSON, MySQL utt
- Jil - augstas veiktspējas JSON serializācija un deserializators
- Sigil - .Net CIL paaudzes palīgs (izmanto, ja C# nav pietiekami ātrs)
- NetGain – augstas veiktspējas websocket serveris
- Opserver - Uzraudzības informācijas panelis, kas tieši aptaujā lielāko daļu sistēmu un var iegūt informāciju no Orion, Bosun vai WMI
- Bosun – Monitoringa sistēma fonā, rakstīts Go
|
Publicēts 11.04.2018 17:33:18
|
|
|
|
