როგორ გავარღვიეთ დიდი ჩინური Firewall (ნაწილი 3)

Hi!
ყველა კარგი ამბავი მთავრდება. და ჩვენი ამბავი იმის შესახებ, თუ როგორ მოვიძიეთ გამოსავალი, რომ სწრაფად გადავლახოთ ჩინური Firewall, გამონაკლისი არ არის. ამიტომ, მე მეჩქარება გაგიზიაროთ ბოლო, დასკვნითი ნაწილი ამ თემაზე.

წინა ნაწილში ვისაუბრეთ ბევრ სატესტო სკამზე, რომელიც ჩვენ გამოვიარეთ და რა შედეგები მოგვცეს. და ჩვენ გადავწყვიტეთ, რისი დამატებაც კარგი იქნებოდა CDN! ჩვენს სქემაში სიბლანტისთვის.

მე გეტყვით, როგორ გამოვცადეთ Alibaba Cloud CDN, Tencent Cloud CDN და Akamai და რა დავასრულეთ. და, რა თქმა უნდა, შევაჯამოთ.

Alibaba Cloud CDN

ჩვენ მასპინძლობს Alibaba Cloud-ზე და ვიყენებთ მათგან IPSEC და CEN. ლოგიკური იქნებოდა, პირველ რიგში მათი გადაწყვეტილებები სცადოთ.

Alibaba Cloud-ს აქვს ორი სახის პროდუქტი, რომელიც შეიძლება მოგვწონდეს: CDN и DCDN. პირველი ვარიანტი არის კლასიკური CDN კონკრეტული დომენისთვის (ქვედომენი). მეორე ვარიანტი დგას დინამიური მარშრუტი CDN-სთვის (მე მას დინამიურ CDN-ს ვეძახი), მისი ჩართვა შესაძლებელია Full-site რეჟიმში (მალდკარტის დომენებისთვის), ასევე ქეშირებს სტატიკურ შინაარსს და აჩქარებს დინამიურ შინაარსს თავის თავზე, ანუ გვერდის დინამიკა ასევე იტვირთება პროვაიდერის საშუალებით. სწრაფი ქსელები. ეს ჩვენთვის მნიშვნელოვანია, რადგან ძირითადად ჩვენი საიტი დინამიურია, ის იყენებს ბევრ ქვედომენს და უფრო მოსახერხებელია CDN-ის ერთხელ დაყენება „ვარსკვლავისთვის“ - *.semrushchina.cn.

ჩვენ უკვე ვნახეთ ეს პროდუქტი ჩვენი ჩინური პროექტის ადრეულ ეტაპზე, მაგრამ მაშინ ის ჯერ არ მუშაობდა და დეველოპერები დაგვპირდნენ, რომ პროდუქტი მალე გახდება ხელმისაწვდომი ყველა მომხმარებლისთვის. და მან გააკეთა.

DCDN-ში შეგიძლიათ:

• SSL შეწყვეტის კონფიგურაცია თქვენი სერთიფიკატით,
• დინამიური შინაარსის დაჩქარების ჩართვა,
• სტატიკური ფაილების ქეშირების მოქნილად კონფიგურაცია,
• ქეშის გასუფთავება,
• წინა ვებ სოკეტები,
• ჩართეთ შეკუმშვა და თუნდაც HTML Beautifier.

ზოგადად, ყველაფერი იგივეა, რაც მოზრდილებში და დიდ CDN პროვაიდერებთან.

Origin-ის (ადგილი, სადაც წავა CDN edge სერვერები) მითითებულია, რჩება მხოლოდ CNAME-ის შექმნა ვარსკვლავისთვის, მითითებით. all.semrushchina.cn.w.kunluncan.com (ეს CNAME მიღებულია Alibaba Cloud კონსოლში) და CDN იმუშავებს.

ტესტის შედეგებზე დაყრდნობით, ეს CDN ძალიან დაგვეხმარა. სტატისტიკა ნაჩვენებია ქვემოთ.

გადაწყვეტილება
Uptime
მედიანი
75 პროცენტული
95 პროცენტული

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

Ali CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s

ეს ძალიან კარგი შედეგებია, განსაკუთრებით თუ შევადარებთ მათ, რაც იყო დასაწყისში. მაგრამ ჩვენ ვიცოდით, რომ ბრაუზერის ტესტი ჩვენი ვებსაიტის ამერიკული ვერსიის www.semrush.com გადის აშშ-დან საშუალოდ 8.3 წამში (ძალიან მიახლოებითი მნიშვნელობა). გაუმჯობესების ადგილია. უფრო მეტიც, იყო ასევე CDN პროვაიდერები, რომლებიც საინტერესო იყო შესამოწმებლად.

ასე რომ, ჩვენ შეუფერხებლად გადავდივართ სხვა გიგანტზე ჩინეთის ბაზარზე - Tencent.

Tencent Cloud

Tencent ახლახან ავითარებს თავის ღრუბელს - ეს ჩანს მცირე რაოდენობით პროდუქტებიდან. მისი გამოყენებისას ჩვენ გვინდოდა გამოგვემოწმებინა არა მხოლოდ მათი CDN, არამედ მთლიანად მათი ქსელის ინფრასტრუქტურა:

• აქვთ რამე CEN-ის მსგავსი?
• როგორ მუშაობს IPSEC მათთვის? სწრაფია, რა არის დრო?
• აქვთ Anycast?

მოდით განვიხილოთ ეს კითხვები ცალკე.

ანალოგი CEN

Tencent-ს აქვს პროდუქტი Cloud Connect ქსელი (CCN), რომელიც საშუალებას გაძლევთ დააკავშიროთ VPC სხვადასხვა რეგიონებიდან, მათ შორის რეგიონებში ჩინეთის შიგნით და გარეთ. პროდუქტი ახლა შიდა ბეტა რეჟიმშია და თქვენ უნდა შექმნათ ბილეთი მასთან დაკავშირების თხოვნით. მხარდაჭერით გავიგეთ, რომ გლობალურ ანგარიშებს (ჩვენ არ ვსაუბრობთ ჩინეთის მოქალაქეებზე ან იურიდიულ პირებზე) არ შეუძლიათ მონაწილეობა მიიღონ ბეტა ტესტირების პროგრამაში და, ზოგადად, დააკავშირონ რეგიონი ჩინეთის შიგნით რეგიონის გარეთ. 1-0 ალი კლუდის სასარგებლოდ

IPSEC

Tencent-ის ყველაზე სამხრეთ რეგიონია გუანჯოუ. ჩვენ ავაწყეთ გვირაბი და დავაკავშირეთ იგი ჰონგ კონგის რეგიონთან GCP-ში (მაშინ ეს რეგიონი უკვე ხელმისაწვდომი გახდა). ამავე დროს აშენდა მეორე გვირაბი ალი ღრუბელში შენჟენიდან ჰონგ კონგამდე. აღმოჩნდა, რომ Tencent-ის ქსელის მეშვეობით, ჰონკონგში შეყოვნება ზოგადად უკეთესია (10 ms), ვიდრე შენჟენიდან ჰონკონგიდან ალიმდე (120 ms - რა?). მაგრამ ამან არანაირად არ დააჩქარა საიტის მუშაობა, რომელიც მიზნად ისახავს Tencent-სა და ამ გვირაბში მუშაობას, რაც თავისთავად საოცარი ფაქტი იყო და კიდევ ერთხელ დაამტკიცა შემდეგი: შეყოვნება - ჩინეთისთვის ეს არ არის ის მაჩვენებელი, რომელიც ნამდვილად ღირს. ყურადღება მიაქციეთ ჩინური ფეიერვოლზე გადასვლის გადაწყვეტის შემუშავებისას.

Anycast ინტერნეტის დაჩქარება

კიდევ ერთი პროდუქტი, რომელიც საშუალებას გაძლევთ იმუშაოთ anycast IP-ით AIA. მაგრამ ის ასევე არ არის ხელმისაწვდომი გლობალური ანგარიშებისთვის, ამიტომ არ გეტყვით ამის შესახებ, მაგრამ იმის ცოდნა, რომ ასეთი პროდუქტი არსებობს, შეიძლება სასარგებლო იყოს.

მაგრამ CDN ტესტმა საკმაოდ საინტერესო შედეგი აჩვენა. Tencent-ის CDN-ის ჩართვა შეუძლებელია სრულ საიტზე, მხოლოდ კონკრეტულ დომენებზე. ჩვენ შევქმენით დომენები და გავუგზავნეთ ტრაფიკი მათ:

აღმოჩნდა, რომ ამ CDN-ს აქვს შემდეგი ფუნქცია: ტრანსსასაზღვრო მოძრაობის ოპტიმიზაცია. ამ მახასიათებელმა უნდა შეამციროს ხარჯები, როდესაც ტრაფიკი გადის ჩინურ ფეიერვოლზე. როგორც წარმოშობა მითითებული იყო Google GLB-ის IP მისამართი (GLB anycast). ამრიგად, ჩვენ გვინდოდა პროექტის არქიტექტურის გამარტივება.

შედეგები ძალიან კარგი იყო - Ali Cloud CDN-ის დონეზე და ზოგან უკეთესიც. ეს გასაკვირია, რადგან თუ ტესტები წარმატებული იქნება, შეგიძლიათ მიატოვოთ ინფრასტრუქტურის მნიშვნელოვანი ნაწილი, გვირაბები, CEN, ვირტუალური მანქანები და ა.შ.

დიდხანს არ გვიხარია, რადგან პრობლემა გამოვლინდა: Catchpoint-ში ტესტები ჩაიშალა ინტერნეტ პროვაიდერ China Mobile-სთვის. ნებისმიერი ადგილიდან მივიღეთ ტაიმაუტი Tencent-ის CDN-ის მეშვეობით. ტექნიკურ მხარდაჭერასთან მიმოწერას არაფერი მოჰყოლია. დაახლოებით ერთი დღე ვცდილობდით ამ პრობლემის მოგვარებას, მაგრამ არაფერი გამოგვივიდა.

მე ვიყავი ჩინეთში იმ მომენტში, მაგრამ ვერ ვიპოვე საჯარო Wi-Fi ამ პროვაიდერის ქსელში, რომ პირადად გადამემოწმებინა პრობლემა. თორემ ყველაფერი სწრაფად და კარგად გამოიყურებოდა.
თუმცა, იმის გამო, რომ China Mobile არის სამ უმსხვილეს ოპერატორს შორის, ჩვენ იძულებული გავხდით ტრაფიკი დაგვებრუნებინა Ali CDN-ში.
მაგრამ მთლიანობაში, ეს იყო საკმაოდ საინტერესო გამოსავალი, რომელიც იმსახურებს ამ პრობლემის უფრო ხანგრძლივ ტესტირებას და პრობლემების მოგვარებას.

Akamai

ბოლო CDN პროვაიდერი, რომელიც ჩვენ გამოვცადეთ, იყო Akamai. ეს არის უზარმაზარი პროვაიდერი, რომელსაც აქვს თავისი ქსელი ჩინეთში. რასაკვირველია, ამას ვერ გავცდით.

თავიდანვე შევთანხმდით Akamai-სთან საცდელ პერიოდზე, რათა შეგვეძლო დომენის შეცვლა და ვნახოთ, როგორ იმუშავებს ის მათ ქსელში. ყველა ტესტის შედეგს აღვწერ "რა მომეწონა" და "რა არ მომეწონა" სახით და ასევე მივცემ ტესტის შედეგებს.

რაც მომეწონა:

• აკამაის ბიჭები ძალიან გვეხმარებოდნენ ყველა კითხვაში და თან გვახლდნენ ტესტირების ყველა ეტაპზე. ჩვენ მუდმივად ვცდილობდით რაღაცის გაუმჯობესებას. მათ კარგი ტექნიკური რჩევა მისცეს.
• Akamai არის დაახლოებით 10-15% ნელი ვიდრე ჩვენი გამოსავალი Ali Cloud CDN-ის საშუალებით. შთამბეჭდავი ის არის, რომ Akamai-სთვის Origin-ში ჩვენ დავაზუსტეთ GLB-ის IP მისამართი, რაც იმას ნიშნავს, რომ ტრაფიკი არ გადიოდა ჩვენს გადაწყვეტაში (პოტენციურად შეგვეძლო ინფრასტრუქტურის ნაწილის მიტოვება). მაგრამ მაინც, ტესტის შედეგებმა აჩვენა, რომ ეს გამოსავალი უფრო უარესია ვიდრე ჩვენი ამჟამინდელი ვერსია (შედარებითი შედეგები ქვემოთ).
• ტესტირებულია როგორც Origin GLB, ასევე Origin ჩინეთში. ორივე ვარიანტი დაახლოებით იგივეა.
• არსებობს დარწმუნებული მარშრუტი (ავტომატური მარშრუტიზაციის ოპტიმიზაცია). თქვენ შეგიძლიათ სატესტო ობიექტის ჰოსტინგი Origin-ზე და Akamai Edge სერვერები შეეცდებიან მის არჩევას (ჩვეულებრივი GET). ამ მოთხოვნებისთვის იზომება სიჩქარე და სხვა მეტრიკა, რის საფუძველზეც Akamai ქსელი ახდენს მარშრუტების ოპტიმიზაციას ისე, რომ ტრაფიკი უფრო სწრაფად წავიდეს ჩვენი საიტისთვის და ცხადი იყო, რომ ამ ფუნქციის ჩართვამ მართლაც დიდი გავლენა მოახდინა საიტის სიჩქარეზე.
• ვებ ინტერფეისში კონფიგურაციის ვერსია მაგარია. შეგიძლიათ გააკეთოთ შედარება ვერსიებისთვის, შეხედეთ განსხვავებას. იხილეთ წინა ვერსიები.
• თქვენ შეგიძლიათ განათავსოთ ახალი ვერსია ჯერ მხოლოდ Akamai Staging ქსელში - იგივე ქსელი, როგორც წარმოება, მხოლოდ ამ გზით არ იმოქმედებს რეალურ მომხმარებლებზე. ამ ტესტისთვის, თქვენ უნდა გააფუჭოთ DNS ჩანაწერები თქვენს ადგილობრივ აპარატზე.
• ძალიან სწრაფი ჩამოტვირთვის სიჩქარე მათი ქსელის საშუალებით დიდი სტატიკური ფაილებისთვის და, როგორც ჩანს, ნებისმიერი სხვა ფაილისთვის. ფაილი "ცივი" ქეშიდან ბევრჯერ უფრო სწრაფად არის აღებული, ვიდრე იგივე ფაილი Ali CDN-ის "ცივი" ქეშიდან. "ცხელი" ქეშიდან, სიჩქარე უკვე იგივეა, პლუს ან მინუს.

Ali CDN ტესტი:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0   513k      0 --:--:--  0:00:11 --:--:--  526k
time_namelookup:  0.004286
time_connect:  0.030107
time_appconnect:  0.117525
time_pretransfer:  0.117606
time_redirect:  0.000000
time_starttransfer:  0.840348
----------
time_total:  11.208119
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

Akamai ტესტი:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0  1824k      0 --:--:--  0:00:03 --:--:-- 1825k
time_namelookup:  0.509005
time_connect:  0.528261
time_appconnect:  0.577235
time_pretransfer:  0.577324
time_redirect:  0.000000
time_starttransfer:  1.327013
----------
time_total:  3.154850
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

ჩვენ შევამჩნიეთ, რომ ზემოთ მოცემულ მაგალითში არსებული სიტუაცია დამოკიდებულია სხვადასხვა ფაქტორზე. ამ პუნქტის დაწერის დროს ისევ ჩავაბარე ტესტი. ორივე პლატფორმის შედეგები დაახლოებით იგივე იყო. ეს გვეუბნება, რომ ინტერნეტი ჩინეთში, თუნდაც მსხვილი ოპერატორებისა და ღრუბლოვან პროვაიდერებისთვის, დროდადრო განსხვავებულად იქცევა.

წინა პუნქტს დავამატებ Akamai-ს დიდ პლიუსს: თუ ალი აჩვენებს მსგავს ციმციმებს მაღალი და ძალიან დაბალი მაჩვენებლების მქონე (ეს ეხება Ali CDN, Ali CEN და Ali IPSEC), მაშინ Akamai, ყოველ ჯერზე, არ აქვს მნიშვნელობა. როგორ ვამოწმებ მათ ქსელს, ყველაფერი სტაბილურად მუშაობს.
Akamai-ს აქვს ბევრი გაშუქება ჩინეთში და მუშაობს მრავალი პროვაიდერის საშუალებით.

რაც არ მომეწონა:

• მე არ მომწონს ვებ ინტერფეისი და მისი მუშაობის წესი - ის ძალიან ცუდია. მაგრამ ძირითადად შეჩვევა (ალბათ).
• ტესტის შედეგები ჩვენს საიტზე უარესია.
• ტესტების დროს უფრო მეტი შეცდომაა, ვიდრე ჩვენს საიტზე (ქვემოთ განახლების დრო).
• ჩვენ არ გვაქვს საკუთარი DNS სერვერები ჩინეთში. ამიტომ, ტესტებში ბევრი შეცდომაა DNS-ის გადაწყვეტის დროის ამოწურვის გამო.
• ისინი არ აწვდიან თავიანთ IP დიაპაზონებს -> არ არსებობს სწორი დარეგისტრირების საშუალება set_real_ip_from ჩვენს სერვერებზე.

მეტრიკა (~3626 გაშვება; ყველა მეტრიკა Uptime-ის გარდა, ms-ში; სტატისტიკა ერთი პერიოდისთვის):

CDN პროვაიდერი
მედიანი
75%
95%
რეაგირების
ვებგვერდის პასუხი
Uptime
DNS
დაკავშირება
დაელოდეთ
Load
SSL

ალი CDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

განაწილება პროცენტული მნიშვნელობით (ms):

პროცენტული
Akamai
ალი CDN

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

დასკვნა ასეთია: Akamai ვარიანტი სიცოცხლისუნარიანია, მაგრამ არ იძლევა იგივე სტაბილურობას და სიჩქარეს, როგორც ჩვენი გადაწყვეტა Ali CDN-თან ერთად.

პატარა ნოტები

ზოგიერთი მომენტი არ იყო მოთხრობაში ჩართული, მაგრამ მათზეც მინდა დავწერო.

პეკინი + ტოკიო და ჰონგ კონგი

როგორც ზემოთ ვთქვი, ჩვენ გამოვცადეთ IPSEC გვირაბი ჰონგ კონგში (HK). მაგრამ ჩვენ ასევე გამოვცადეთ CEN HK-ზე. ცოტა ნაკლები ღირს და მაინტერესებდა როგორ იმუშავებდა ~100 კმ მანძილზე ქალაქებს შორის. საინტერესო აღმოჩნდა, რომ ამ ქალაქებს შორის შეყოვნება 100 მმ-ით მეტია, ვიდრე ჩვენს თავდაპირველ ვერსიაში (ტაივანში). სიჩქარე, სტაბილურობა ასევე უკეთესი იყო ტაივანისთვის. შედეგად, ჩვენ დავტოვეთ HK, როგორც სარეზერვო IPSEC რეგიონი.

გარდა ამისა, ჩვენ ვცადეთ შემდეგი ინსტალაციის დაყენება:

• კლიენტების შეწყვეტა პეკინში,
• IPSEC და CEN ტოკიოში,
• Ali CDN-ში წარმომავლად მითითებული იყო სერვერი პეკინში.

ეს სქემა არც თუ ისე სტაბილური იყო, თუმცა სიჩქარით ის ზოგადად არ ჩამოუვარდებოდა ჩვენს გადაწყვეტას. გვირაბთან დაკავშირებით მე მინახავს პერიოდული ვარდნა CEN-ისთვისაც კი, რომელიც სტაბილური უნდა ყოფილიყო. ამიტომ, ძველ სქემას დავუბრუნდით და ეს დადგმა დავშალეთ.

ქვემოთ მოცემულია სტატისტიკა შეყოვნების შესახებ სხვადასხვა რეგიონებს შორის სხვადასხვა არხისთვის. იქნებ ვინმე დაინტერესდეს ამით.

IPsec
Ali cn-peijing <—> GCP აზია-ჩრდილო-აღმოსავლეთი1 — 193ms
Ali cn-shenzhen <—> GCP asia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

CEN
Ali cn-peijing <—> Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms

ზოგადი ინფორმაცია ჩინეთში ინტერნეტის შესახებ

როგორც ინტერნეტთან დაკავშირებული პრობლემების დამატება, რომელიც აღწერილია თავიდანვე, სტატიის პირველ ნაწილში.

• ინტერნეტი ჩინეთში საკმაოდ სწრაფია შიგნით.
  • დასკვნა გაკეთდა საჯარო Wi-Fi ქსელების ტესტირების საფუძველზე სხვადასხვა ლოკაციებზე, სადაც ამ ქსელებს უამრავი ადამიანი იყენებს.
  • ჩინეთის შიგნით სერვერებზე ჩამოტვირთვისა და ატვირთვის სიჩქარე იყო დაახლოებით 20 მბიტ/წმ და 5-10 მბიტ/წმ, შესაბამისად.
  • ჩინეთის გარეთ სერვერების სიჩქარე უბრალოდ მწირია, 1 მბიტ/წმ-ზე ნაკლები.
• ჩინეთში ინტერნეტი არც თუ ისე სტაბილურია.
  • ზოგჯერ საიტები შეიძლება გაიხსნას სწრაფად, ზოგჯერ ნელა (დღის ერთსა და იმავე დროს სხვადასხვა დღეებში), იმ პირობით, რომ კონფიგურაცია არ შეიცვლება. ამას დავაკვირდით semrushchina.cn-ის მაგალითზე. ეს შეიძლება მივაწეროთ Ali CDN-ს, რომელიც ასევე მუშაობს ასე და ისე, რაც დამოკიდებულია დღის დროზე, ვარსკვლავების პოზიციაზე და ა.შ.
• მობილური ინტერნეტი თითქმის ყველგან არის 4G ან 4G+. დაიჭირე მეტროში, ლიფტები - მოკლედ ყველგან.
• მითია, რომ ჩინელი მომხმარებლები ენდობიან მხოლოდ დომენებს .cn ზონაში. ეს პირდაპირ მომხმარებლებისგან ვისწავლეთ.
  • ხედავთ როგორ http://baidu.cn გადამისამართება www.baidu.com-ზე (მატერიკულ ჩინეთშიც).
• ბევრი რესურსი მართლაც დაბლოკილია. პრიმიტიული: google.com, Facebook, Twitter. მაგრამ Google-ის მრავალი რესურსი მუშაობს (რა თქმა უნდა, ყველა Wi-Fi-ზე არ არის გამოყენებული და VPN არ გამოიყენება (როუტერის მხარესაც, ეს ნამდვილად არის).
• ასევე მუშაობს დაბლოკილი კორპორაციების მრავალი „ტექნიკური“ დომენი. ეს ნიშნავს, რომ ყოველთვის დაუფიქრებლად არ უნდა ამოჭრათ ყველა Google და სხვა ერთი შეხედვით დაბლოკილი რესურსი. თქვენ უნდა მოძებნოთ აკრძალული დომენების სია.
• მათ აქვთ მხოლოდ სამი ძირითადი ინტერნეტ ოპერატორი: China Unicom, China Telecom, China Mobile. არის კიდევ უფრო მცირე, მაგრამ მათი წილი ბაზარზე უმნიშვნელოა

ბონუსი: საბოლოო გადაწყვეტის დიაგრამა

სულ

პროექტის დაწყებიდან ერთი წელი გავიდა. ჩვენ დავიწყეთ იმით, რომ ჩვენმა საიტმა ზოგადად უარი თქვა ჩინეთიდან ნორმალურად მუშაობაზე და უბრალოდ GET curl-ს 5.5 წამი დასჭირდა.

შემდეგ, ამ მაჩვენებლებით პირველ ხსნარში (Cloudflare):

გადაწყვეტილება
Uptime
მედიანი
75 პროცენტული
95 პროცენტული

CloudFlare
86.6
18s
30s
60s

ჩვენ საბოლოოდ მივაღწიეთ შემდეგ შედეგებს (სტატისტიკა ბოლო თვის განმავლობაში):

გადაწყვეტილება
Uptime
მედიანი
75 პროცენტული
95 პროცენტული

Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

როგორც ხედავთ, ჩვენ ჯერ ვერ მივაღწიეთ 100%-იან მუშაობას, მაგრამ რაღაცას მოვიფიქრებთ და შემდეგ ახალ სტატიაში მოგიყვებით შედეგებზე :)

პატივისცემა მათ ვინც სამივე ნაწილს ბოლომდე წაიკითხავს. იმედი მაქვს, რომ ეს ყველაფერი ისეთივე საინტერესო აღმოჩნდა, როგორც მე მაშინ, როცა ეს გავაკეთე.

PS წინა ნაწილები

Часть 1
Часть 2

წყარო: www.habr.com