Helo bawb!
Mae Nikita mewn cysylltiad - peiriannydd systemau o'r cwmni SEMrush. Heddiw dywedaf wrthych am sut yr oeddem yn wynebu'r dasg o sicrhau sefydlogrwydd ein gwasanaeth semrush.com yn Tsieina, a pha broblemau y daethom ar eu traws yn ystod ei weithrediad (o ystyried lleoliad ein canolfan ddata ar arfordir dwyreiniol yr Unol Daleithiau).
Bydd hon yn stori fawr, wedi'i rhannu'n sawl erthygl. Fe ddywedaf wrthych sut y digwyddodd y cyfan i ni: o wasanaeth cwbl anweithredol o Tsieina, i ddangosyddion perfformiad y gwasanaeth ar lefel ei fersiwn Americanaidd ar gyfer Americanwyr. Rwy'n addo y bydd yn ddiddorol ac yn ddefnyddiol. Felly, gadewch i ni fynd.
Problemau'r Rhyngrwyd Tsieineaidd
Mae hyd yn oed y person pellaf o fanylion gweinyddiaeth rhwydwaith wedi clywed amdano Mur Tân Mawr Tsieina. Waw, swnio'n cŵl, iawn? Ond mae beth ydyw a sut mae'n gweithio mewn gwirionedd yn gwestiwn eithaf cymhleth. Gallwch ddod o hyd i lawer o erthyglau ar y Rhyngrwyd wedi'u neilltuo i hyn, ond o safbwynt technegol, nid yw strwythur y wal dân hon yn cael ei ddisgrifio yn unrhyw le. Sydd, fodd bynnag, nid yw'n syndod. Byddaf yn cyfaddef ar unwaith, yn seiliedig ar ganlyniadau blwyddyn o waith, na fyddaf yn gallu dweud yn union sut mae'n gweithio, ond gallaf ddweud wrthych am fy sylwadau a chasgliadau ymarferol. A byddwn yn dechrau gyda sibrydion am y wal dân hon.
Mae yna lawer o sibrydion am yr union wal dân hon. Gadewch i ni gasglu'r prif a mwyaf diddorol ohonynt mewn un rhestr:
- Mae Google, Facebook, Twitter a gwasanaethau tebyg eraill wedi'u rhwystro ac nid ydynt yn gweithio yn Tsieina.
- Mae unrhyw draffig sy'n mynd Y TU ALLAN i Tsieina ac INTO China yn cael ei ddosrannu a'i gyfyngu gan ddefnyddio dysgu peiriannau (yn achos traffig amheus), sy'n arafu'n fawr (traffig) sy'n mynd trwy'r ffin.
- Bydd asiantaethau cudd-wybodaeth Tsieineaidd yn hacio unrhyw draffig wedi'i amgryptio sy'n mynd trwy eu wal dân.
- Mae twneli VPN, twneli IPSEC yn ansefydlog, yn chwalu ac yn cael eu rhwystro'n gyson.
- Po symlaf yw'r amgryptio, y symlaf yw'r ymadrodd pas a ddefnyddir i ddilysu / amgryptio traffig, y cyflymaf y mae'n mynd trwy'r wal dân Tsieineaidd.
Dyma beth wnaethon ni ddarganfod am y sibrydion hyn:
- Mae Google, Facebook, Twitter a gwasanaethau tebyg eraill yn wir wedi'u rhwystro (eich KO), ond nid yw llawer o barthau technegol Google, er enghraifft, yn cael eu gwahardd ac yn gweithio (yr un gstatic.com). Mae'r casgliad yn dilyn o hyn: ni ddylech dorri allan yn ddi-hid yr holl adnoddau Google ac eraill sy'n ymddangos fel pe baent wedi'u rhwystro.
- Mae unrhyw draffig sy'n mynd heibio i'r ffin wir yn ychwanegu oedi difrifol at ei amser. Edrychwch ar y ddau ganlyniad. Un safle, un dudalen, GET syml cyrlio'om. Daeth y mesuriad cyntaf o Tsieina ei hun (dinas hardd Shenzhen). Mesurwyd yr ail un o'r tu allan i Hong Kong (mae ganddi sofraniaeth, ac nid oes wal dân rhyngddo a'r byd). Y pellter rhwng dinasoedd mewn llinell syth yw tua 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sRhowch sylw i amser_connect. Ac yn gyffredinol, fe welwch y canlyniad: mae'r wal dân yn ychwanegu 4 eiliad ychwanegol, sy'n hynod o hir.
- Mae twneli VPN ac IPSEC yn methu'n aml. Byddaf yn siarad am hyn ychydig yn ddiweddarach ac yn fanylach. Mae gweinyddwyr VPN a ddefnyddir gan ddefnyddwyr yn cael eu rhwystro dros amser (fel arfer o fewn diwrnod ar ôl dechrau'r defnydd).
- Mae barn a dderbyniwyd gan bobl sy'n byw yn Tsieina mai'r symlaf yw amgryptio traffig, y cyflymaf y mae'n mynd trwy'r ffin, oherwydd mae'n hawdd deall nad oes dim byd anghyfreithlon yn ei gylch. Ac yn yr un modd, mae traffig “glân” yn derbyn mwy o led band a chyflymder teithio, tra bod traffig “budr”, lle na ellir deall dim, yn cael taith arafach i'r gwrthwyneb. Er enghraifft, byddaf yn defnyddio cyrl i ifconfig.co trwy brotocol HTTPS a HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sGwahaniaeth o 5 eiliad am gyfanswm amser llwytho i lawr o 13 beit. Ar ben hynny, wrth wneud prawf o'r fath sawl gwaith, gallwch sylwi bod GET ar HTTP yn cael ei gwblhau yn gyffredinol yr un amser bob tro, tra ar HTTPS mae'r wefan weithiau'n ymateb mewn 3, 5, 10 a hyd yn oed 17 eiliad. Weithiau mae gwallau SSL yn digwydd:
Unknown SSL protocol error in connection to ifconfig.co:443.
Felly beth sydd gennym ni:
- Disgrifir y problemau a grëwyd gan y wal dân Tsieineaidd uchod.
- Mae pinnau ar adnoddau allanol a thu mewn twneli yn diflannu o bryd i'w gilydd.
- Mae hwyrni rhwng dau bwynt yn newid yn gyson, ac yn aml mae'n anrhagweladwy. Wrth gysylltu gwahanol ddinasoedd/rhanbarthau, rydych chi'n disgwyl, yn seiliedig ar leoliad daearyddol y rhanbarthau, y bydd yr oedi yn llai, ond fe gewch chi'r union sefyllfa i'r gwrthwyneb.
- Mae'r Rhyngrwyd a sianeli cyfathrebu naill ai'n gyflym neu'n araf. Mae ychydig o ddibyniaeth ar yr amser o'r dydd a diwrnod yr wythnos, ond nid bob amser.
- Weithiau mae ceisiadau DNS i'r byd y tu allan o Tsieina yn fwy na'r terfyn amser a ganiateir.
Mae'r darlun sy'n dod i'r amlwg yn syml yn “rhagorol.”
Mae'r ganolfan ddata, fel y dywedais eisoes, yn nwyrain yr Unol Daleithiau, ac mae'r SEMrush cyfan yn cynnwys dwsinau o gynhyrchion rhyng-gysylltiedig, backends, frontends, cronfeydd data, a hyn i gyd yn y DC a'r cymylau. Cawsom ni, fel tîm o weinyddwyr systemau, y dasg o ddechrau gweithio'n gyflym yn Tsieina heb fawr o ymdrech.
Roedd yn rhaid i ni ateb cwestiwn pwysig: a yw'n bosibl mynd heibio heb fawr o gost a datrys yr holl broblemau sy'n gysylltiedig â'r Rhyngrwyd Tsieineaidd a wal dân ar lefel rhwydwaith / cwmwl / gweinydd?
Dechreuasom trwy dderbyn .
Trwydded ICP
Er mwyn gallu cynnal eich gwasanaeth yn Tsieina (Tir mawr Tsieina) a chynnal profion, rhaid i chi yn gyntaf gael trwydded ICP ar gyfer y parth.
Os daw traffig defnyddwyr eich gwefan i ben o fewn Mainland China, ac os nad oes gan eich parth drwydded ICP, bydd eich traffig yn cael ei rwystro ar yr ochr ISP/cynnal. Yn ddiddorol, mae trwydded ICP yn cynnwys darparwr penodol, boed yn Cloudflare neu Alibaba Cloud. Felly, os cawsoch drwydded ICP ar gyfer Cloudflare a chynnal eich gwefan gyda nhw, ni fyddwch yn gallu symud yn “ddi-dor” i Alibaba Cloud. Bydd angen i chi ychwanegu gwesteiwr arall at y drwydded hon.
Ar ôl derbyn trwydded ICP ar gyfer y parth, roeddem yn gallu meddwl am syniadau ac atebion technegol penodol a'u rhoi ar waith.
Profi datrysiadau
Ond cyn i chi greu opsiynau llwyfannu yn uniongyrchol, troi'r nobiau, gwneud y gorau o berfformiad y wefan a'i gyflymder, mae angen i chi ddewis offeryn i'w brofi er mwyn gweld pa rai o'n gweithredoedd sy'n gwella neu, i'r gwrthwyneb, yn gwaethygu perfformiad y wefan.
Roedd yn rhaid i'n hofferyn profi fodloni dau brif ofyniad:
- dylai allu rhedeg profion o Tsieina,
- rhaid iddo gael profion porwr.
Felly daethom o hyd ! Mae ganddyn nhw sylw rhagorol o leoliadau profi ledled y byd. Yn Tsieina, gellir rhedeg profion hefyd o 100500 o daleithiau trwy'r offeryn hwn. Mae gan bob un sawl darparwr gwahanol + y gallu i wneud Asgwrn cefn-profion (rhywbeth fel peiriant rhithwir mewn canolfan ddata) a Milltir olaf-profion (mor agos â phosibl i amodau defnyddwyr, aka gweithfan). Mae'r math olaf o brofion yn ddrutach.
Ar ôl cwblhau contract blynyddol (nad yw llai na hynny'n bosibl), dechreuwyd astudio'r offeryn. A dweud y gwir, cawsom ein synnu ar yr ochr orau gan ei ymarferoldeb. Gallwch chi redeg:
- profion DNS,
- Profion gwe (profion porwr, GET / POST syml, efelychu cleient symudol, ac ati),
- Gwiriadau trafodion (er enghraifft, mewngofnodi),
- Profion API,
- Ping, traceroute, NTP, ac ati.
Ni allwch restru popeth. Ac yn bwysicaf oll, gellir addasu pob prawf yn eithaf da trwy ychwanegu criw o benawdau a pharamedrau eraill. Mae'r allbwn yn swm enfawr o wybodaeth sy'n disgrifio'ch prawf yn llawn. Os byddwn yn siarad am y pethau mwyaf diddorol i ni (profion porwr), mae'r canlyniad yn cynnwys:
- Cysylltu, Aros, Llwytho, SSL, amser DNS,
- TTFB, TTLB, Dogfen wedi'i chwblhau, amser rendrad, llwyth DOM,
- Ymateb (rhywbeth sy'n agos at Time To First Byte), Webpage Response (rhywbeth yn agos at Time To Last Byte),
- Unrhyw ganradd, cyfartaledd, amser canolrif
- Etc.
Yn unol â hynny, mae'r holl fetrigau hyn yn wych ar gyfer gweld newidiadau a deall a yw pethau wedi gwella. Edrychasom yn bennaf ar Ymateb, Ymateb Tudalen We, Canolrif, 75 a 95 Canraddau.
Cwestiwn pwysig oedd yn yr awyr o’r cychwyn cyntaf: Allwch chi ymddiried yn Catchpoint?? A yw'r offeryn hwn yn adlewyrchu'r cyflymder llwytho safle go iawn yn Tsieina o wahanol ddinasoedd, neu ai dim ond rhyw fath o brawf mewn gwactod nad oes ganddo unrhyw beth i'w wneud â phrofiad defnyddiwr go iawn?
Mae hon yn broblem fawr, oherwydd oherwydd bod yn Rwsia mae bron yn amhosibl darganfod yn ddibynadwy sut mae safle o Tsieina yn gweithio. Trwy wneud dirprwy sanau trwy beiriant rhithwir, y canlyniad terfynol yw bod y wefan yn llwytho o fewn ychydig funudau, sy'n annerbyniol ar gyfer profion, felly yr unig opsiwn ar gyfer profi â llaw yw cyrlio a GET syml o'r consol gydag amserydd . Mae hyn yn helpu oherwydd bod y prawf hwn yn adlewyrchu cyflymder y datrysiad rhwydwaith yn dda, ac os oes profion porwr hefyd, yna mae'n dda iawn.
Yn ddiweddarach aethom ni ein hunain i Tsieina ac roeddem yn argyhoeddedig hynny Gallwch ymddiried yn Catchpoint; mae'n adlewyrchu dangosyddion perfformiad gwirioneddol yn eithaf cywir.
Rhwydwaith Cloudflare Tsieina
Gan ein bod yn defnyddio Cloudflare yn llwyddiannus ar gyfer y prif barth semrush.com, fe wnaethom benderfynu rhoi cynnig ar eu nodwedd o'r enw ar unwaith . Mae'r opsiwn hwn wedi'i alluogi ar gyfer safleoedd Menter yn unig ar gais ar wahân ac am ffi ychwanegol. Mae hefyd ar gael i safleoedd sydd â thrwydded ICP briodol sy'n rhestru Cloudflare fel y darparwr yn unig. Ar ôl ei alluogi, mae'r “CDN Tsieineaidd” o Cloudflare ar gael ar gyfer y wefan - mae traffig o ranbarthau Tsieineaidd yn glanio yn y PoP (Pwyntiau Presenoldeb) CF agosaf, ac yna trwy ei rwydweithiau neu'r rhwydweithiau o ddarparwyr / partneriaid y mae'n cael ei gyflwyno i'r tarddiad .
Cyflwynir diagram y fainc brawf hon isod.
Mae hwn yn opsiwn gwych i ni. Mae'n ymddangos y bydd yr ail barth hefyd ar gyfer CF, nad yw'n ychwanegu at nifer yr atebion a ddefnyddir yn y cwmni, a hefyd yn ymarferol nid yw'n cymhlethu'r seilwaith.
Fe wnaethon ni gynnal profion porwr a dyma beth ddigwyddodd:
Mae diemwntau coch yn fethiannau prawf. Mae'r ffeiliau isod yn wallau DNS (datrys terfyn amser). Goramser yw'r methiannau ar y brig.
Uptime: 86.6
Canolrif: 18s
75 Canradd: 29.3s
95 Canradd: 60s
Canolrif, ar ôl llwytho dileu reCaptcha (Gwasanaeth Google wedi'i rwystro yn Tsieina) wedi gostwng o 28 i 18 eiliad. Ond mae'r rhain yn dal i fod yn ganlyniadau ofnadwy, gan ystyried bod yr un prawf ar gyfer semrush.com (o'r Unol Daleithiau) wedi rhoi llai na 10 eiliad i 95% o ddefnyddwyr (o'r Unol Daleithiau) ar yr un dudalen (statig + deinamig).
Gallwch chi fynd i mewn i bob prawf ac edrych Rhaeadr a pharamedrau manylach eraill. Dechreuon ni ymchwilio i'r rhesymau dros y gwallau, ac os yw popeth fwy neu lai'n glir ar gyfer seibiannau: mae'r Rhyngrwyd yn Tsieina yn “symud i mewn ac allan”, oherwydd hyn mae cyflymder cysylltu a llwytho adnoddau o dramor yn ansefydlog ac yn anwastad, yna fe wnaeth y gwallau DNS ein synnu'n fawr. Daethom o hyd i hynny Po Mae Cloudflare wedi'u lleoli mewn gwirionedd yn Tsieina, mae cyfeiriad y wefan yn cyd-fynd ag un IP anycast, ond mae'r gweinyddwyr DNS yn America, a dyna pam mae ceisiadau DNS yn cael eu gorfodi i fynd dros y ffin, felly weithiau maen nhw'n methu.
Ar ôl egluro'r cwestiwn hwn gyda CF, daeth hynny i'r amlwg Nid oes ganddynt eu gweinyddwyr DNS eu hunain yn Tsieina, a phryd y bydd yn dal yn anhysbys.
Felly, fe wnaethom benderfynu profi Cloudflare DNS yn unig a newid mecanwaith gweithredu Cloudflare ar gyfer ein gwefan i'r “DNS yn unig" Mae hwn yn fodd pan nad yw Cloudflare yn traffig dirprwyol trwyddo'i hun, sy'n golygu nad yw'n darparu amddiffyniad DDoS, CDN a nodweddion eraill, ac mae'n gweithredu yn y modd gweinydd DNS rheolaidd.
Dangosir y stand hwn yn sgematig yn y ffigur canlynol. Mae'r ffigur yn ystyried y wybodaeth sy'n dod i'r amlwg bod gweinyddwyr DNS Cloudflare y tu ôl i wal dân.
Yn Catchpoint cynhaliom brofion GET syml (nid profion porwr), a ddangosodd lawer o fethiannau. Cawsant eu hachosi gan yr un gwallau DNS.
Dechreuon ni ddadfygio'r gwallau hyn gan ddefnyddio cloddio a chanfuwyd bod y cyfeiriad yn cael ei benderfynu'n gywir ar y cais cyntaf, ac ar gais ailadroddus rydym yn ei dderbyn bob tro SERVFAIL и heb ei darganfod. Pam fod hyn yn digwydd yn sydyn?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Nid oes unrhyw wallau o'r fath wrth gwestiynu gweinyddwyr Cloudflare NS yn uniongyrchol:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192Mae hyn yn golygu bod y broblem ar ochr y gweinydd DNS “lleol” neu weinydd y darparwr.
Datgelodd ymchwiliad pellach hynny SERVFAIL rydym yn dod ymlaen i ddatrys aaaa- cofnodion.
Mae'n troi allan bod wrth wneud cais gan Cloudflare AAA-record nad yw'n bodoli yn y parth, ymatebodd Cloudflare А-cofnod sy'n wall ac yn ddiffyg cydymffurfio â'r Clwb Rygbi. Pam mae'r datryswr lleol (xxxx) Doeddwn i ddim yn ei hoffi, ac atebodd SERVFAIL. Mae'r ymddygiad hwn i'w weld yn glir yn y log isod:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE rcvd: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; ANSWER SECTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Fe wnaethon ni gyflwyno adroddiad nam i Cloudflare, ac fe wnaethon nhw ei drwsio ar ôl peth amser. Daeth yn ddiddorol: ar hyn o bryd nid oes cefnogaeth IPv6 yn Tsieina o hyd, felly ni allai Cloudflare gyhoeddi ei gyfeiriad IPv6 yno mewn ymateb i gais AAA- cofnodion. Yn y diwedd, datryswyd popeth yn y fath fodd fel y dechreuodd Cloudflare ateb ar gyfer Tsieina NODATA i geisiadau o'r fath.
Felly, gostyngodd gwallau DNS mewn profion Catchpoint yn sydyn, ond nid yn llwyr. Mae seibiannau yn dal yma:
Ac fe ddechreuon ni chwilio am ateb arall.
Yn y rhan nesaf byddaf yn dweud wrthych sut y gwnaethom brofi'r cwmwl Tsieineaidd Alibaba Cloud, sut, gyda chymorth ychydig o “hud” Nginx, roeddem yn gallu creu atebion PoC (Proof of Concept) yn gyflym, sut y gwnaethom greu datrysiadau Aml-Cloud, yr oedd un ohonynt yn y pen draw wedi helpu i gyflymu gwaith y gwasanaeth yn fawr o Tsieina.
Arhoswch tuned!
Rhannau nesaf
Ffynhonnell: hab.com
