សួស្តី! ឈ្មោះរបស់ខ្ញុំគឺ Vadim Madison ខ្ញុំដឹកនាំការអភិវឌ្ឍន៍កម្មវិធី Avito System Platform ។ វាត្រូវបានគេនិយាយច្រើនជាងម្តងអំពីរបៀបដែលយើងនៅក្នុងក្រុមហ៊ុនកំពុងផ្លាស់ប្តូរពីស្ថាបត្យកម្ម monolithic ទៅជា microservices មួយ។ វាដល់ពេលហើយដើម្បីចែករំលែកពីរបៀបដែលយើងបានផ្លាស់ប្តូរហេដ្ឋារចនាសម្ព័ន្ធរបស់យើងដើម្បីទទួលបានអត្ថប្រយោជន៍ច្រើនបំផុតពីសេវាកម្មខ្នាតតូច និងការពារខ្លួនយើងពីការវង្វេងនៅក្នុងពួកគេ។ របៀបដែល PaaS ជួយយើងនៅទីនេះ របៀបដែលយើងធ្វើឱ្យងាយស្រួលក្នុងការដាក់ពង្រាយ និងកាត់បន្ថយការបង្កើតសេវាមីក្រូទៅមួយចុច - អានបន្ត។ មិនមែនអ្វីៗទាំងអស់ដែលខ្ញុំសរសេរអំពីខាងក្រោមត្រូវបានអនុវត្តយ៉ាងពេញលេញនៅក្នុង Avito នោះទេ វាខ្លះជារបៀបដែលយើងអភិវឌ្ឍវេទិការបស់យើង។

(ហើយនៅចុងបញ្ចប់នៃអត្ថបទនេះ ខ្ញុំនឹងនិយាយអំពីឱកាសដើម្បីចូលរួមសិក្ខាសាលារយៈពេលបីថ្ងៃពីអ្នកជំនាញផ្នែកស្ថាបត្យកម្មមីក្រូសេវាកម្ម Chris Richardson)។

របៀបដែលយើងបានមកសេវាមីក្រូ

Avito គឺជាគេហទំព័រចាត់ថ្នាក់ធំជាងគេមួយក្នុងពិភពលោក ហើយការផ្សាយពាណិជ្ជកម្មថ្មីជាង 15 លានត្រូវបានបោះពុម្ពនៅលើវាក្នុងមួយថ្ងៃ។ ផ្នែកខាងក្រោយរបស់យើងទទួលយកសំណើច្រើនជាង 20 ក្នុងមួយវិនាទី។ បច្ចុប្បន្ននេះយើងមានសេវាមីក្រូជាច្រើនរយ។

យើង​បាន​និង​កំពុង​សាងសង់​ស្ថាបត្យកម្ម​មីក្រូ​សេវា​ជាច្រើន​ឆ្នាំ​មក​ហើយ។ របៀបពិតប្រាកដ - សហការីរបស់យើងនៅក្នុងលម្អិត បានប្រាប់ នៅផ្នែករបស់យើងនៅ RIT ++ 2017 ។ នៅ CodeFest 2017 (សូមមើល។ видео), Sergey Orlov និង Mikhail Prokopchuk បានពន្យល់យ៉ាងលម្អិតអំពីមូលហេតុដែលយើងត្រូវការការផ្លាស់ប្តូរទៅជាសេវាមីក្រូ និងតួនាទីអ្វីដែល Kubernetes បានលេងនៅទីនេះ។ ឥឡូវនេះ យើងកំពុងធ្វើអ្វីគ្រប់យ៉ាងដើម្បីកាត់បន្ថយការចំណាយលើការធ្វើមាត្រដ្ឋានដែលមាននៅក្នុងស្ថាបត្យកម្មបែបនេះ។

ដំបូងឡើយ យើងមិនបានបង្កើតប្រព័ន្ធអេកូដែលអាចជួយយើងអភិវឌ្ឍ និងបើកដំណើរការសេវាមីក្រូបានទូលំទូលាយនោះទេ។ ពួកគេគ្រាន់តែប្រមូលដំណោះស្រាយប្រភពបើកចំហដែលសមរម្យ បើកដំណើរការវានៅផ្ទះ និងអញ្ជើញអ្នកអភិវឌ្ឍន៍ឱ្យដោះស្រាយជាមួយពួកគេ។ ជាលទ្ធផលគាត់បានទៅកន្លែងរាប់សិប (ផ្ទាំងគ្រប់គ្រងសេវាកម្មផ្ទៃក្នុង) បន្ទាប់ពីនោះគាត់កាន់តែរឹងមាំក្នុងបំណងប្រាថ្នារបស់គាត់ក្នុងការកាត់កូដតាមរបៀបចាស់នៅក្នុង monolith ។ ពណ៌បៃតងនៅក្នុងដ្យាក្រាមខាងក្រោមបង្ហាញពីអ្វីដែលអ្នកអភិវឌ្ឍន៍ធ្វើវិធីមួយឬផ្សេងទៀតដោយដៃរបស់គាត់ផ្ទាល់ ហើយពណ៌លឿងបង្ហាញពីស្វ័យប្រវត្តិកម្ម។

ឥឡូវនេះនៅក្នុងឧបករណ៍ប្រើប្រាស់ PaaS CLI សេវាកម្មថ្មីមួយត្រូវបានបង្កើតជាមួយនឹងពាក្យបញ្ជាមួយ ហើយមូលដ្ឋានទិន្នន័យថ្មីត្រូវបានបន្ថែមជាមួយនឹងពីរបន្ថែមទៀត ហើយដាក់ពង្រាយទៅកាន់ដំណាក់កាល។

តើធ្វើដូចម្តេចដើម្បីយកឈ្នះលើយុគសម័យនៃ "ការបែងចែកមីក្រូសេវាកម្ម"

ជាមួយនឹងស្ថាបត្យកម្ម monolithic សម្រាប់ជាប្រយោជន៍នៃភាពជាប់លាប់នៃការផ្លាស់ប្តូរនៅក្នុងផលិតផលអ្នកអភិវឌ្ឍន៍ត្រូវបានបង្ខំឱ្យស្វែងរកអ្វីដែលកំពុងកើតឡើងជាមួយអ្នកជិតខាងរបស់ពួកគេ។ នៅពេលធ្វើការលើស្ថាបត្យកម្មថ្មី បរិបទសេវាកម្មលែងអាស្រ័យលើគ្នាទៅវិញទៅមកទៀតហើយ។

លើសពីនេះ ដើម្បីឱ្យស្ថាបត្យកម្មមីក្រូសេវាកម្មមានប្រសិទ្ធភាព ដំណើរការជាច្រើនចាំបាច់ត្រូវបង្កើតឡើង ដូចជា៖

• ការកាប់ឈើ;
• ស្នើសុំតាមដាន (Jaeger);
• ការប្រមូលផ្តុំកំហុស (Sentry);
• ស្ថានភាព សារ ព្រឹត្តិការណ៍ពី Kubernetes (ដំណើរការស្ទ្រីមព្រឹត្តិការណ៍);
• ដែនកំណត់ប្រណាំង / សៀគ្វីបំបែក (អ្នកអាចប្រើ Hystrix);
• ការគ្រប់គ្រងការតភ្ជាប់សេវា (យើងប្រើ Netramesh);
• ការត្រួតពិនិត្យ (Grafana);
• ការជួបប្រជុំគ្នា (TeamCity);
• ការទំនាក់ទំនង និងការជូនដំណឹង (Slack, email);
• ការតាមដានភារកិច្ច; (ជីរ៉ា)
• ការរៀបចំឯកសារ។

ដើម្បីធានាថាប្រព័ន្ធមិនបាត់បង់ភាពសុចរិតរបស់វា និងនៅតែមានប្រសិទ្ធភាពដូចដែលវាធ្វើមាត្រដ្ឋាន យើងបានគិតឡើងវិញអំពីការរៀបចំសេវាកម្មមីក្រូនៅក្នុង Avito ។

របៀបដែលយើងគ្រប់គ្រងសេវាកម្មមីក្រូ

ជំនួយខាងក្រោមដើម្បីអនុវត្ត "គោលនយោបាយបក្ស" បង្រួបបង្រួមក្នុងចំណោមសេវាមីក្រូ Avito ជាច្រើន៖

• ការបែងចែកហេដ្ឋារចនាសម្ព័ន្ធជាស្រទាប់;
• Platform as a Service (PaaS) concept;
• ត្រួតពិនិត្យអ្វីគ្រប់យ៉ាងដែលកើតឡើងជាមួយសេវាមីក្រូ។

ស្រទាប់អរូបីនៃរចនាសម្ព័ន្ធរួមមានបីស្រទាប់។ តោះពីកំពូលទៅបាត។

A. កំពូល - សំណាញ់សេវាកម្ម។ ដំបូងយើងសាកល្បង Istio ប៉ុន្តែវាបានប្រែក្លាយថាវាប្រើប្រាស់ធនធានច្រើនពេក ដែលមានតម្លៃថ្លៃពេកសម្រាប់បរិមាណរបស់យើង។ ដូច្នេះវិស្វករជាន់ខ្ពស់នៅក្នុងក្រុមស្ថាបត្យកម្ម Alexander Lukyanchenko បានបង្កើតដំណោះស្រាយផ្ទាល់ខ្លួនរបស់គាត់ - ណេត្រាម៉េស (មាននៅក្នុង Open Source) ដែលបច្ចុប្បន្នយើងប្រើប្រាស់ក្នុងផលិតកម្ម ហើយដែលប្រើប្រាស់ធនធានតិចជាង Istio ច្រើនដង (ប៉ុន្តែមិនធ្វើអ្វីគ្រប់យ៉ាងដែល Istio អាចអួតអំពី)។
ខ. មធ្យម - Kubernetes ។ យើងដាក់ពង្រាយ និងដំណើរការសេវាកម្មមីក្រូនៅលើវា។
C. បាត - ដែកទទេ។ យើងមិនប្រើពពក ឬវត្ថុដូចជា OpenStack ទេ ប៉ុន្តែពឹងផ្អែកទាំងស្រុងលើលោហៈទទេ។

ស្រទាប់ទាំងអស់ត្រូវបានបញ្ចូលគ្នាដោយ PaaS ។ ហើយវេទិកានេះ, នៅក្នុងវេន, មានបីផ្នែក។

I. ម៉ាស៊ីនភ្លើងគ្រប់គ្រងតាមរយៈឧបករណ៍ប្រើប្រាស់ CLI ។ វាគឺជានាងដែលជួយអ្នកអភិវឌ្ឍន៍បង្កើតសេវាកម្មមីក្រូក្នុងវិធីត្រឹមត្រូវ និងដោយការខិតខំប្រឹងប្រែងអប្បបរមា។

II. អ្នកប្រមូលរួម ជាមួយនឹងការគ្រប់គ្រងឧបករណ៍ទាំងអស់តាមរយៈផ្ទាំងគ្រប់គ្រងទូទៅ។

III. ការផ្ទុក. ភ្ជាប់ជាមួយអ្នកកំណត់ពេលកំណត់ដែលកំណត់ការកេះដោយស្វ័យប្រវត្តិសម្រាប់សកម្មភាពសំខាន់ៗ។ សូមអរគុណចំពោះប្រព័ន្ធបែបនេះ មិនមែនកិច្ចការតែមួយត្រូវបានខកខាននោះទេ ដោយសារតែមាននរណាម្នាក់ភ្លេចរៀបចំកិច្ចការនៅក្នុង Jira ។ យើងប្រើឧបករណ៍ខាងក្នុងហៅថា Atlas សម្រាប់រឿងនេះ។

ការអនុវត្តសេវាកម្មមីក្រូនៅក្នុង Avito ក៏ត្រូវបានអនុវត្តផងដែរតាមគ្រោងការណ៍តែមួយដែលសម្រួលការគ្រប់គ្រងលើពួកវានៅដំណាក់កាលនីមួយៗនៃការអភិវឌ្ឍន៍ និងការចេញផ្សាយ។

តើ​បំពង់​អភិវឌ្ឍន៍​សេវា​ខ្នាត​តូច​ស្តង់ដារ​ដំណើរការ​យ៉ាង​ដូច​ម្តេច?

ជាទូទៅ ខ្សែសង្វាក់នៃការបង្កើតសេវាកម្មខ្នាតតូចមើលទៅដូចនេះ៖

CLI-push → ការរួមបញ្ចូលជាបន្តបន្ទាប់ → ដុតនំ → ដាក់ពង្រាយ → ការធ្វើតេស្តសិប្បនិម្មិត → ការធ្វើតេស្ត Canary → Squeeze Test → Production → Maintenance ។

ចូរយើងឆ្លងកាត់វាយ៉ាងពិតប្រាកដនៅក្នុងលំដាប់នេះ។

CLI-ជំរុញ

• ការបង្កើតសេវាមីក្រូ.
យើងបានតស៊ូអស់រយៈពេលជាយូរដើម្បីបង្រៀនអ្នកអភិវឌ្ឍន៍គ្រប់រូបពីរបៀបធ្វើសេវាកម្មមីក្រូ។ នេះរួមបញ្ចូលទាំងការសរសេរសេចក្តីណែនាំលម្អិតនៅក្នុង Confluence ។ ប៉ុន្តែគ្រោងការណ៍បានផ្លាស់ប្តូរហើយត្រូវបានបំពេញបន្ថែម។ លទ្ធផលគឺថាបញ្ហាស្ទះបានលេចឡើងនៅដើមដំបូងនៃការធ្វើដំណើរ៖ វាត្រូវចំណាយពេលច្រើនដើម្បីបើកដំណើរការសេវាកម្មមីក្រូ ហើយបញ្ហានៅតែកើតឡើងជាញឹកញាប់ក្នុងអំឡុងពេលបង្កើតរបស់វា។

នៅទីបញ្ចប់ យើងបានសាងសង់ឧបករណ៍ប្រើប្រាស់ CLI ដ៏សាមញ្ញមួយដែលធ្វើស្វ័យប្រវត្តិកម្មជំហានជាមូលដ្ឋាននៅពេលបង្កើតសេវាកម្មមីក្រូ។ តាមពិតទៅ វាជំនួសការជំរុញ git ដំបូង។ នេះជាអ្វីដែលនាងធ្វើ។

- បង្កើតសេវាកម្មមួយតាមគំរូ — មួយជំហានម្តង ៗ ក្នុងរបៀប "អ្នកជំនួយការ" ។ យើងមានគំរូសម្រាប់ភាសាសរសេរកម្មវិធីសំខាន់ៗនៅក្នុងផ្នែកខាងក្រោយរបស់ Avito: PHP, Golang និង Python ។

- ពាក្យបញ្ជាមួយក្នុងពេលតែមួយដាក់ពង្រាយបរិយាកាសសម្រាប់ការអភិវឌ្ឍន៍ក្នុងតំបន់នៅលើម៉ាស៊ីនជាក់លាក់មួយ - Minikube ត្រូវបានបើកដំណើរការ តារាង Helm ត្រូវបានបង្កើត និងចាប់ផ្តើមដោយស្វ័យប្រវត្តិនៅក្នុង kubernetes ក្នុងតំបន់។

- ភ្ជាប់មូលដ្ឋានទិន្នន័យដែលត្រូវការ។ អ្នកអភិវឌ្ឍន៍មិនចាំបាច់ដឹងពី IP ការចូល និងពាក្យសម្ងាត់ដើម្បីទទួលបានការចូលប្រើមូលដ្ឋានទិន្នន័យដែលគាត់ត្រូវការ - មិនថានៅក្នុងស្រុក នៅដំណាក់កាល ឬនៅក្នុងផលិតកម្មនោះទេ។ ជាងនេះទៅទៀត មូលដ្ឋានទិន្នន័យត្រូវបានដាក់ឱ្យប្រើប្រាស់ភ្លាមៗក្នុងការកំណត់រចនាសម្ព័ន្ធដែលអត់ឱនចំពោះកំហុស និងដោយមានតុល្យភាព។

- វាអនុវត្តការជួបប្រជុំគ្នាផ្ទាល់។ ចូរនិយាយថាអ្នកអភិវឌ្ឍន៍បានកែអ្វីមួយនៅក្នុងសេវាកម្មមីក្រូតាមរយៈ IDE របស់គាត់។ ឧបករណ៍ប្រើប្រាស់មើលឃើញការផ្លាស់ប្តូរនៅក្នុងប្រព័ន្ធឯកសារ ហើយផ្អែកលើពួកវា បង្កើតកម្មវិធីឡើងវិញ (សម្រាប់ Golang) ហើយចាប់ផ្តើមឡើងវិញ។ សម្រាប់ PHP យើងគ្រាន់តែបញ្ជូនថតនៅក្នុងគូប ហើយការបន្តផ្ទាល់ត្រូវបានទទួល "ដោយស្វ័យប្រវត្តិ"។

- បង្កើតការធ្វើតេស្តស្វ័យប្រវត្តិ។ នៅក្នុងសំណុំបែបបទនៃការទទេ, ប៉ុន្តែពិតជាសមរម្យសម្រាប់ការប្រើប្រាស់។

• ការដាក់ពង្រាយសេវាកម្មខ្នាតតូច.

ការដាក់ពង្រាយសេវាមីក្រូ ធ្លាប់ជាកិច្ចការតិចតួចសម្រាប់យើង។ ខាងក្រោមនេះត្រូវបានទាមទារ៖

I. Dockerfile ។

II. កំណត់រចនាសម្ព័ន្ធ។
III. គំនូសតាង Helm ដែលខ្លួនវាពិបាក និងរួមបញ្ចូលៈ

- តារាងដោយខ្លួនឯង;
- គំរូ;
- តម្លៃជាក់លាក់ដោយគិតពីបរិយាកាសផ្សេងៗគ្នា។

យើងបានដកការឈឺចាប់ចេញពីការដំណើរការ Kubernetes manifests ឡើងវិញ ដូច្នេះឥឡូវនេះពួកវាត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ។ ប៉ុន្តែសំខាន់បំផុត ពួកគេបានសម្រួលការដាក់ពង្រាយដល់កម្រិតកំណត់។ ចាប់ពីពេលនេះតទៅយើងមាន Dockerfile ហើយអ្នកអភិវឌ្ឍន៍សរសេរការកំណត់ទាំងមូលក្នុងឯកសារ app.toml ខ្លីតែមួយ។

បាទ / ចាសហើយនៅក្នុង app.toml ខ្លួនវាមិនមានអ្វីត្រូវធ្វើសម្រាប់មួយនាទីទេ។ យើងបញ្ជាក់កន្លែង និងចំនួនច្បាប់ចម្លងនៃសេវាកម្មដែលត្រូវលើកឡើង (នៅលើម៉ាស៊ីនមេ dev លើដំណាក់កាល ការផលិត) និងបង្ហាញពីភាពអាស្រ័យរបស់វា។ សូមកត់សម្គាល់ទំហំបន្ទាត់ = "តូច" នៅក្នុងប្លុក [ម៉ាស៊ីន] ។ នេះគឺជាដែនកំណត់ដែលនឹងត្រូវបានបែងចែកទៅសេវាកម្មតាមរយៈ Kubernetes ។

បន្ទាប់មក ដោយផ្អែកលើការកំណត់ គំនូសតាង Helm ចាំបាច់ទាំងអស់ត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ ហើយការតភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យត្រូវបានបង្កើត។

• សុពលភាពមូលដ្ឋាន។ ការត្រួតពិនិត្យបែបនេះក៏ស្វ័យប្រវត្តិដែរ។
ត្រូវការតាមដាន៖
- តើមាន Dockerfile ទេ?
- តើមាន app.toml;
- មានឯកសារទេ?
- តើ​ការ​អាស្រ័យ​នៅ​ក្នុង​លំដាប់?
- ថាតើច្បាប់ជូនដំណឹងត្រូវបានកំណត់។
ដល់ចំណុចចុងក្រោយ៖ ម្ចាស់សេវាកម្មខ្លួនឯងកំណត់ថាតើផលិតផលមួយណាដែលត្រូវត្រួតពិនិត្យ។

• ការរៀបចំឯកសារ។
នៅតែជាតំបន់មានបញ្ហា។ វាហាក់ដូចជាជាក់ស្តែងបំផុត ប៉ុន្តែនៅពេលជាមួយគ្នានេះ វាក៏ជាកំណត់ត្រាមួយ "ជារឿយៗត្រូវបានបំភ្លេចចោល" ផងដែរ ដូច្នេះហើយបានជាតំណភ្ជាប់ងាយរងគ្រោះនៅក្នុងខ្សែសង្វាក់នេះ។
វាចាំបាច់ដែលមានឯកសារសម្រាប់សេវាមីក្រូនីមួយៗ។ វារួមបញ្ចូលប្លុកដូចខាងក្រោម។

I. ការពិពណ៌នាសង្ខេបអំពីសេវាកម្ម. តាមព្យញ្ជនៈពីរបីប្រយោគអំពីអ្វីដែលវាធ្វើ និងហេតុអ្វីបានជាវាត្រូវការ។

II. តំណភ្ជាប់ដ្យាក្រាមស្ថាបត្យកម្ម. វាជារឿងសំខាន់ដែលដោយក្រឡេកមើលវាយ៉ាងរហ័ស វាងាយស្រួលយល់ ឧទាហរណ៍ថាតើអ្នកកំពុងប្រើ Redis សម្រាប់ឃ្លាំងសម្ងាត់ ឬជាឃ្លាំងផ្ទុកទិន្នន័យសំខាន់នៅក្នុងរបៀបជាប់លាប់។ នៅក្នុង Avito សម្រាប់ពេលនេះ នេះគឺជាតំណភ្ជាប់ទៅកាន់ Confluence។

III. សៀវភៅរត់. មគ្គុទ្ទេសក៍ខ្លីស្តីពីការចាប់ផ្តើមសេវាកម្ម និងភាពស្មុគស្មាញនៃការដោះស្រាយវា។

IV. សំណួរគេសួរញឹកញាប់ដែលជាកន្លែងដែលវាជាការល្អក្នុងការប្រមើលមើលបញ្ហាដែលមិត្តរួមការងាររបស់អ្នកអាចជួបប្រទះនៅពេលធ្វើការជាមួយសេវាកម្ម។

V. ការពិពណ៌នាអំពីចំណុចបញ្ចប់សម្រាប់ API. ប្រសិនបើភ្លាមៗនោះអ្នកមិនបានបញ្ជាក់ទិសដៅទេ សហសេវិកដែលសេវាកម្មមីក្រូរបស់វាទាក់ទងនឹងរបស់អ្នកនឹងចំណាយប្រាក់សម្រាប់វា។ ឥឡូវនេះយើងប្រើ Swagger និងដំណោះស្រាយរបស់យើងហៅថាសង្ខេបសម្រាប់រឿងនេះ។

VI. ស្លាក. ឬសញ្ញាសម្គាល់ដែលបង្ហាញពីផលិតផល មុខងារ ឬការបែងចែករចនាសម្ព័ន្ធរបស់ក្រុមហ៊ុនដែលសេវាកម្មជាកម្មសិទ្ធិ។ ពួកគេជួយអ្នកឱ្យយល់បានយ៉ាងឆាប់រហ័ស ជាឧទាហរណ៍ ថាតើអ្នកកំពុងកាត់មុខងារដែលសហការីរបស់អ្នកដាក់ឱ្យដំណើរការសម្រាប់អង្គភាពអាជីវកម្មដូចគ្នាកាលពីមួយសប្តាហ៍មុន។

VII. ម្ចាស់ ឬម្ចាស់សេវាកម្ម. ក្នុងករណីភាគច្រើន វាអាចកំណត់ដោយស្វ័យប្រវត្តិដោយប្រើ PaaS ប៉ុន្តែដើម្បីសុវត្ថិភាព យើងតម្រូវឱ្យអ្នកអភិវឌ្ឍន៍បញ្ជាក់ពួកវាដោយដៃ។

ជាចុងក្រោយ វាជាការអនុវត្តល្អក្នុងការត្រួតពិនិត្យឯកសារ ដែលស្រដៀងនឹងការពិនិត្យមើលកូដ។

សមាហរណកម្មបន្ត

• កំពុងរៀបចំឃ្លាំង។
• ការបង្កើតបំពង់នៅក្នុង TeamCity ។
• ការកំណត់សិទ្ធិ។
• ស្វែងរកម្ចាស់សេវាកម្ម។ មានគ្រោងការណ៍កូនកាត់នៅទីនេះ - ការសម្គាល់ដោយដៃ និងស្វ័យប្រវត្តិកម្មតិចតួចបំផុតពី PaaS ។ គ្រោងការណ៍ដោយស្វ័យប្រវត្តិពេញលេញបរាជ័យនៅពេលដែលសេវាកម្មត្រូវបានផ្ទេរសម្រាប់ការគាំទ្រទៅក្រុមអភិវឌ្ឍន៍ផ្សេងទៀត ឬឧទាហរណ៍ប្រសិនបើអ្នកអភិវឌ្ឍន៍សេវាកម្មឈប់។
• ការចុះឈ្មោះសេវាកម្មនៅអាត្លាស (មើល​ខាងលើ)។ ជាមួយនឹងម្ចាស់ និងភាពអាស្រ័យទាំងអស់របស់វា។
• កំពុងពិនិត្យមើលការធ្វើចំណាកស្រុក។ យើងពិនិត្យមើលថាតើពួកវាណាមួយអាចមានគ្រោះថ្នាក់ឬអត់។ ឧទាហរណ៍ នៅក្នុងមួយក្នុងចំណោមពួកវា តារាងផ្លាស់ប្តូរ ឬអ្វីផ្សេងទៀតលេចឡើងដែលអាចបំបែកភាពឆបគ្នានៃគ្រោងការណ៍ទិន្នន័យរវាងកំណែផ្សេងៗគ្នានៃសេវាកម្ម។ បន្ទាប់មកការធ្វើចំណាកស្រុកមិនត្រូវបានអនុវត្តទេ ប៉ុន្តែត្រូវបានដាក់នៅក្នុងការជាវមួយ - PaaS ត្រូវតែផ្តល់សញ្ញាដល់ម្ចាស់សេវាកម្មនៅពេលដែលវាមានសុវត្ថិភាពក្នុងការប្រើប្រាស់វា។

ដុត

ដំណាក់កាលបន្ទាប់គឺសេវាកម្មវេចខ្ចប់មុនពេលដាក់ពង្រាយ។

• ការកសាងកម្មវិធី។ យោងទៅតាមសៀវភៅបុរាណ - នៅក្នុងរូបភាព Docker ។
• ការបង្កើតគំនូសតាង Helm សម្រាប់សេវាកម្មខ្លួនវា និងធនធានពាក់ព័ន្ធ។ រួមទាំងសម្រាប់មូលដ្ឋានទិន្នន័យ និងឃ្លាំងសម្ងាត់។ ពួកវាត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិស្របតាមការកំណត់រចនាសម្ព័ន្ធ app.toml ដែលត្រូវបានបង្កើតនៅដំណាក់កាល CLI-push ។
• ការបង្កើតសំបុត្រសម្រាប់អ្នកគ្រប់គ្រងដើម្បីបើកច្រក (នៅពេលចាំបាច់) ។
• កំពុងដំណើរការការធ្វើតេស្តឯកតា និងការគណនាការគ្របដណ្តប់លេខកូដ. ប្រសិនបើការគ្របដណ្ដប់នៃលេខកូដគឺទាបជាងកម្រិតដែលបានបញ្ជាក់ នោះទំនងជាសេវាកម្មនឹងមិនបន្តទៅមុខទៀតនោះទេ - ដើម្បីដាក់ពង្រាយ។ ប្រសិនបើវាស្ថិតនៅលើចំណុចដែលអាចទទួលយកបាន នោះសេវាកម្មនឹងត្រូវបានកំណត់ជាមេគុណ "ទុទិដ្ឋិនិយម"៖ បន្ទាប់មក ប្រសិនបើមិនមានការកែលម្អនៅក្នុងសូចនាករតាមពេលវេលាទេ អ្នកអភិវឌ្ឍន៍នឹងទទួលបានការជូនដំណឹងថាមិនមានការរីកចំរើនក្នុងលក្ខខណ្ឌនៃការធ្វើតេស្ត ( ហើយ​អ្វី​មួយ​ត្រូវ​ធ្វើ​អំពី​វា)។
• គណនេយ្យសម្រាប់ការកំណត់អង្គចងចាំ និងស៊ីភីយូ. យើងសរសេរសេវាកម្មខ្នាតតូចជាចម្បងនៅក្នុង Golang ហើយដំណើរការពួកវានៅក្នុង Kubernetes ។ ដូច្នេះ ភាពទន់ភ្លន់មួយដែលត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងភាពប្លែកនៃភាសា Golang៖ តាមលំនាំដើម នៅពេលចាប់ផ្តើម ស្នូលទាំងអស់នៅលើម៉ាស៊ីនត្រូវបានប្រើ ប្រសិនបើអ្នកមិនកំណត់អថេរ GOMAXPROCS ច្បាស់លាស់ទេ ហើយនៅពេលដែលសេវាកម្មបែបនេះជាច្រើនត្រូវបានដាក់ឱ្យដំណើរការនៅលើម៉ាស៊ីនតែមួយ ពួកគេចាប់ផ្តើម ដើម្បីប្រកួតប្រជែងធនធាន ជ្រៀតជ្រែកគ្នាទៅវិញទៅមក។ ក្រាហ្វខាងក្រោមបង្ហាញពីរបៀបដែលពេលវេលាប្រតិបត្តិផ្លាស់ប្តូរ ប្រសិនបើអ្នកដំណើរការកម្មវិធីដោយគ្មានការឈ្លោះប្រកែកគ្នា និងនៅក្នុងការប្រណាំងសម្រាប់របៀបធនធាន។ (ប្រភពនៃក្រាហ្វគឺ នៅទីនេះ).

ពេលវេលាអនុវត្ត តិចគឺល្អជាង។ អតិបរមា៖ ៦៤៣ms អប្បបរមា៖ ៤២ms។ រូបថតអាចចុចបាន។

ដល់​ពេល​វះ​កាត់​តិច​គឺ​ល្អ​ជាង។ អតិបរមា: 14091 ns, អប្បបរមា: 151 ns ។ រូបថតអាចចុចបាន។

នៅដំណាក់កាលរៀបចំការជួបប្រជុំគ្នា អ្នកអាចកំណត់អថេរនេះយ៉ាងច្បាស់ ឬអ្នកអាចប្រើបណ្ណាល័យ automaxprocs ពីបុរសមកពី Uber ។

ដាក់ពង្រាយ

• ពិនិត្យអនុសញ្ញា។ មុនពេលអ្នកចាប់ផ្តើមផ្តល់សេវាដំឡើងទៅបរិយាកាសដែលអ្នកចង់បាន អ្នកត្រូវពិនិត្យមើលដូចខាងក្រោម៖
- ចំណុចបញ្ចប់ API ។
- ការអនុលោមតាមការឆ្លើយតបចំណុចបញ្ចប់ API ជាមួយគ្រោងការណ៍។
- ទម្រង់កំណត់ហេតុ។
- ការកំណត់បឋមកថាសម្រាប់សំណើទៅសេវាកម្ម (បច្ចុប្បន្ននេះត្រូវបានធ្វើដោយ netramesh)
- កំណត់សញ្ញាសម្ងាត់របស់ម្ចាស់នៅពេលផ្ញើសារទៅកាន់ឡានក្រុងព្រឹត្តិការណ៍។ នេះត្រូវការជាចាំបាច់ដើម្បីតាមដានការតភ្ជាប់នៃសេវាកម្មឆ្លងកាត់ឡានក្រុង។ អ្នកអាចផ្ញើទាំងទិន្នន័យ ideempotent ទៅឡានក្រុង ដែលមិនបង្កើនការតភ្ជាប់នៃសេវាកម្ម (ដែលល្អ) និងទិន្នន័យអាជីវកម្មដែលពង្រឹងការតភ្ជាប់នៃសេវាកម្ម (ដែលអាក្រក់ណាស់!) ។ ហើយនៅចំណុចនៅពេលដែលការតភ្ជាប់នេះក្លាយជាបញ្ហា ការយល់ដឹងថាអ្នកណាជាអ្នកសរសេរ និងអានឡានក្រុងជួយបែងចែកសេវាកម្មឱ្យបានត្រឹមត្រូវ។

មិនមានអនុសញ្ញាច្រើននៅក្នុង Avito នៅឡើយទេ ប៉ុន្តែអាងរបស់ពួកគេកំពុងពង្រីក។ កិច្ចព្រមព្រៀងបែបនេះកាន់តែច្រើនមាននៅក្នុងទម្រង់ដែលក្រុមអាចយល់ និងយល់បាន វាកាន់តែងាយស្រួលក្នុងការរក្សាស្ថិរភាពរវាងសេវាមីក្រូ។

ការធ្វើតេស្តសំយោគ

• ការធ្វើតេស្តរង្វិលជុំបិទ។ សម្រាប់បញ្ហានេះឥឡូវនេះយើងកំពុងប្រើប្រភពបើកចំហ Hoverfly.io. ដំបូងវាកត់ត្រាការផ្ទុកពិតប្រាកដនៅលើសេវាកម្មបន្ទាប់មក - គ្រាន់តែនៅក្នុងរង្វិលជុំបិទ - វាត្រាប់តាមវា។

• តេស្តស្ត្រេស។ យើងព្យាយាមនាំយកសេវាកម្មទាំងអស់ទៅកាន់ដំណើរការល្អបំផុត។ ហើយកំណែទាំងអស់នៃសេវាកម្មនីមួយៗត្រូវតែជាកម្មវត្ថុនៃការធ្វើតេស្តផ្ទុក - វិធីនេះយើងអាចយល់ពីដំណើរការបច្ចុប្បន្ននៃសេវាកម្ម និងភាពខុសគ្នាជាមួយនឹងកំណែមុននៃសេវាកម្មដូចគ្នា។ ប្រសិនបើបន្ទាប់ពីការអាប់ដេតសេវាកម្ម ដំណើរការរបស់វាធ្លាក់ចុះមួយដងកន្លះ នេះជាសញ្ញាច្បាស់លាស់សម្រាប់ម្ចាស់របស់វា៖ អ្នកត្រូវជីកកកាយលេខកូដ និងកែតម្រូវស្ថានភាព។
ជាឧទាហរណ៍ យើងប្រើប្រាស់ទិន្នន័យដែលប្រមូលបាន ដើម្បីអនុវត្តការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិយ៉ាងត្រឹមត្រូវ ហើយនៅទីបញ្ចប់ ជាទូទៅយល់ថាតើសេវាកម្មអាចធ្វើមាត្រដ្ឋានបានកម្រិតណា។

កំឡុងពេលសាកល្បងផ្ទុក យើងពិនិត្យមើលថាតើការប្រើប្រាស់ធនធានត្រូវនឹងដែនកំណត់ដែលបានកំណត់។ ហើយ​យើង​ផ្តោត​ជា​ចម្បង​ទៅ​លើ​ភាព​ជ្រុល​និយម។

ក) យើងពិនិត្យមើលបន្ទុកសរុប។
- តូចពេក - ទំនងជាមានអ្វីមួយមិនដំណើរការទាល់តែសោះ ប្រសិនបើបន្ទុកភ្លាមៗធ្លាក់ចុះច្រើនដង។
- ធំពេក - ទាមទារការបង្កើនប្រសិទ្ធភាព។

ខ) យើងពិនិត្យមើលការកាត់ចេញដោយយោងទៅតាម RPS ។
នៅទីនេះយើងពិនិត្យមើលភាពខុសគ្នារវាងកំណែបច្ចុប្បន្ន និងកំណែមុន និងបរិមាណសរុប។ ជាឧទាហរណ៍ ប្រសិនបើសេវាកម្មមួយផលិតបាន 100 rps នោះវាត្រូវបានសរសេរមិនសូវល្អ ឬនេះគឺជាលក្ខណៈជាក់លាក់របស់វា ប៉ុន្តែក្នុងករណីណាក៏ដោយ នេះជាហេតុផលដែលត្រូវមើលសេវាកម្មយ៉ាងដិតដល់។
ប្រសិនបើផ្ទុយទៅវិញ មាន RPS ច្រើនពេក នោះប្រហែលជាមានប្រភេទនៃកំហុស ហើយចំនុចបញ្ចប់មួយចំនួនបានឈប់ដំណើរការបន្ទុក ហើយមួយទៀតគឺគ្រាន់តែកេះ។ return true;

ការធ្វើតេស្ត Canary

បន្ទាប់​ពី​យើង​ឆ្លង​កាត់​ការ​ធ្វើ​តេស្ត​សំយោគ យើង​ធ្វើ​តេស្ត​មីក្រូ​សេវា​លើ​អ្នក​ប្រើ​មួយ​ចំនួន​តូច។ យើងចាប់ផ្តើមដោយប្រុងប្រយ័ត្ន ជាមួយនឹងចំណែកតូចមួយនៃទស្សនិកជនដែលចង់បានរបស់សេវាកម្ម - តិចជាង 0,1% ។ នៅដំណាក់កាលនេះ វាមានសារៈសំខាន់ខ្លាំងណាស់ដែលការវាស់វែងបច្ចេកទេស និងផលិតផលត្រឹមត្រូវត្រូវបានបញ្ចូលក្នុងការត្រួតពិនិត្យ ដូច្នេះពួកគេបង្ហាញបញ្ហានៅក្នុងសេវាកម្មឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។ ពេលវេលាអប្បបរមាសម្រាប់ការធ្វើតេស្ត Canary គឺ 5 នាទីហើយសំខាន់គឺ 2 ម៉ោង។ សម្រាប់សេវាកម្មស្មុគស្មាញ យើងកំណត់ពេលវេលាដោយដៃ។
តោះវិភាគ៖
- ម៉ែត្រជាក់លាក់នៃភាសា ជាពិសេស បុគ្គលិក php-fpm;
- កំហុសនៅក្នុង Sentry;
- ស្ថានភាពឆ្លើយតប;
- ពេលវេលាឆ្លើយតប ពិតប្រាកដ និងមធ្យម។
- ភាពយឺតយ៉ាវ;
- ករណីលើកលែង ដំណើរការ និងមិនបានដោះស្រាយ;
- រង្វាស់ផលិតផល។

ការធ្វើតេស្តច្របាច់

ការធ្វើតេស្ត Squeeze ត្រូវបានគេហៅថា "ការច្របាច់" ផងដែរ។ ឈ្មោះនៃបច្ចេកទេសត្រូវបានណែនាំទៅក្នុង Netflix ។ ខ្លឹមសាររបស់វាគឺថាដំបូងយើងបំពេញឧទាហរណ៍មួយជាមួយនឹងចរាចរណ៍ពិតប្រាកដដល់ចំណុចនៃការបរាជ័យហើយដូច្នេះកំណត់ដែនកំណត់របស់វា។ បន្ទាប់មកយើងបន្ថែមឧទាហរណ៍មួយទៀតហើយផ្ទុកគូនេះ - ម្តងទៀតដល់អតិបរមា។ យើងឃើញពិដាននិងដីសណ្តរបស់ពួកគេជាមួយនឹង "ការច្របាច់" ដំបូង។ ដូច្នេះហើយ យើងភ្ជាប់ឧទាហរណ៍មួយក្នុងពេលតែមួយ ហើយគណនាលំនាំនៃការផ្លាស់ប្តូរ។
ទិន្នន័យសាកល្បងតាមរយៈ "ការច្របាច់" ក៏ហូរចូលទៅក្នុងមូលដ្ឋានទិន្នន័យម៉ែត្រទូទៅផងដែរ ដែលជាកន្លែងដែលយើងបង្កើនលទ្ធផលនៃការផ្ទុកសិប្បនិម្មិតជាមួយពួកគេ ឬសូម្បីតែជំនួស "សំយោគ" ជាមួយពួកគេ។

ផលិតផល

• ការធ្វើមាត្រដ្ឋាន។ នៅពេលយើងដាក់ចេញសេវាកម្មផលិតកម្ម យើងតាមដានថាតើវាធ្វើមាត្រដ្ឋានយ៉ាងដូចម្តេច។ តាមបទពិសោធន៍របស់យើង ការត្រួតពិនិត្យតែសូចនាករស៊ីភីយូគឺគ្មានប្រសិទ្ធភាពទេ។ ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តជាមួយ RPS benchmarking នៅក្នុងទម្រង់សុទ្ធរបស់វាដំណើរការ ប៉ុន្តែសម្រាប់តែសេវាកម្មមួយចំនួនដូចជាការផ្សាយតាមអ៊ីនធឺណិត។ ដូច្នេះ យើង​មើល​ជា​ដំបូង​នៅ​ម៉ែត្រ​ផលិតផល​ជាក់លាក់​កម្មវិធី។

ជាលទ្ធផលនៅពេលធ្វើមាត្រដ្ឋានយើងវិភាគ៖
- សូចនាករ CPU និង RAM,
- ចំនួនសំណើនៅក្នុងជួរ,
- ពេលវេលាឆ្លើយតប,
- ការព្យាករណ៍ផ្អែកលើទិន្នន័យប្រវត្តិសាស្រ្តបង្គរ។

នៅពេលធ្វើមាត្រដ្ឋានសេវាកម្ម វាក៏សំខាន់ផងដែរក្នុងការត្រួតពិនិត្យភាពអាស្រ័យរបស់វា ដើម្បីកុំឱ្យយើងធ្វើមាត្រដ្ឋានសេវាកម្មដំបូងនៅក្នុងខ្សែសង្វាក់ ហើយសេវាកម្មដែលវាចូលដំណើរការមិនដំណើរការ។ ដើម្បីបង្កើតការផ្ទុកដែលអាចទទួលយកបានសម្រាប់សេវាកម្មទាំងមូល យើងមើលទិន្នន័យប្រវត្តិសាស្រ្តនៃសេវាកម្មដែលពឹងផ្អែក "ជិតបំផុត" (ផ្អែកលើការរួមបញ្ចូលនៃសូចនាករ CPU និង RAM រួមជាមួយនឹងរង្វាស់ជាក់លាក់នៃកម្មវិធី) ហើយប្រៀបធៀបពួកវាជាមួយទិន្នន័យប្រវត្តិសាស្រ្ត នៃសេវាកម្មចាប់ផ្តើម ហើយដូច្នេះនៅលើ "ខ្សែសង្វាក់អាស្រ័យ" "ពីកំពូលទៅបាត។

សេវាកម្ម

បន្ទាប់ពីសេវាកម្មមីក្រូត្រូវបានដាក់ឱ្យដំណើរការ យើងអាចភ្ជាប់គន្លឹះទៅវាបាន។

នេះគឺជាស្ថានភាពធម្មតាដែលកេះកើតឡើង។
- បានរកឃើញការធ្វើចំណាកស្រុកដែលមានគ្រោះថ្នាក់។
- បច្ចុប្បន្នភាពសុវត្ថិភាពត្រូវបានចេញផ្សាយ។
- សេវាកម្មខ្លួនវាមិនត្រូវបានធ្វើបច្ចុប្បន្នភាពយូរមកហើយ។
- បន្ទុកលើសេវាកម្មមានការថយចុះគួរឱ្យកត់សម្គាល់ ឬរង្វាស់ផលិតផលខ្លះរបស់វានៅក្រៅជួរធម្មតា។
- សេវាកម្មនេះលែងបំពេញតម្រូវការវេទិកាថ្មីទៀតហើយ។

កេះខ្លះទទួលខុសត្រូវចំពោះស្ថេរភាពនៃប្រតិបត្តិការ ខ្លះជាមុខងារនៃការថែទាំប្រព័ន្ធ - ឧទាហរណ៍ សេវាកម្មខ្លះមិនត្រូវបានដាក់ឱ្យប្រើប្រាស់យូរហើយរូបភាពមូលដ្ឋានរបស់វាបានឈប់ឆ្លងកាត់ការត្រួតពិនិត្យសុវត្ថិភាព។

ផ្ទាំងគ្រប់គ្រង

សរុបមក ផ្ទាំងគ្រប់គ្រងគឺជាផ្ទាំងបញ្ជានៃ PaaS ទាំងមូលរបស់យើង។

• ចំណុចតែមួយនៃព័ត៌មានអំពីសេវាកម្ម ដោយមានទិន្នន័យលើការគ្របដណ្តប់ការសាកល្បងរបស់វា ចំនួនរូបភាពរបស់វា ចំនួននៃការចម្លងផលិតកម្ម កំណែ។ល។
• ឧបករណ៍​សម្រាប់​ត្រង​ទិន្នន័យ​តាម​សេវាកម្ម និង​ស្លាក (សញ្ញាសម្គាល់​នៃ​អង្គភាព​អាជីវកម្ម មុខងារ​ផលិតផល។ល។)
• ឧបករណ៍សម្រាប់ការរួមបញ្ចូលជាមួយឧបករណ៍ហេដ្ឋារចនាសម្ព័ន្ធសម្រាប់ការតាមដាន ការកាប់ឈើ និងការត្រួតពិនិត្យ។
• ចំណុចតែមួយនៃឯកសារសេវាកម្ម។
• ទិដ្ឋភាពតែមួយនៃព្រឹត្តិការណ៍ទាំងអស់នៅទូទាំងសេវាកម្ម។

សរុប

មុនពេលណែនាំ PaaS អ្នកអភិវឌ្ឍន៍ថ្មីអាចចំណាយពេលជាច្រើនសប្តាហ៍ដើម្បីស្វែងយល់អំពីឧបករណ៍ទាំងអស់ដែលចាំបាច់ដើម្បីបើកដំណើរការសេវាកម្មខ្នាតតូចក្នុងផលិតកម្ម៖ Kubernetes, Helm, លក្ខណៈពិសេសខាងក្នុងរបស់ TeamCity របស់យើង ការដំឡើងការតភ្ជាប់ទៅកាន់មូលដ្ឋានទិន្នន័យ និងឃ្លាំងសម្ងាត់ក្នុងលក្ខណៈមិនអត់ឱនចំពោះកំហុស។ល។ ឥឡូវនេះវា ចំណាយពេលពីរបីម៉ោងដើម្បីអានការចាប់ផ្តើមរហ័ស និងបង្កើតសេវាកម្មដោយខ្លួនឯង។

ខ្ញុំបានផ្ដល់របាយការណ៍លើប្រធានបទនេះសម្រាប់ HighLoad++ 2018 អ្នកអាចមើលវាបាន видео и បទ​បង្ហាញ.

បទប្រាក់រង្វាន់សម្រាប់អ្នកដែលអានដល់ចប់

យើងនៅ Avito កំពុងរៀបចំការបណ្តុះបណ្តាលផ្ទៃក្នុងរយៈពេលបីថ្ងៃសម្រាប់អ្នកអភិវឌ្ឍន៍ពី លោក Chris Richardsonអ្នកជំនាញផ្នែកស្ថាបត្យកម្មមីក្រូសេវាកម្ម។ យើង​សូម​ផ្តល់​ឱកាស​ក្នុង​ការ​ចូលរួម​ក្នុង​វា​ដល់​អ្នក​អាន​ម្នាក់​នៃ​ការ​ប្រកាស​នេះ។ វាគឺជាការ កម្មវិធីបណ្តុះបណ្តាលត្រូវបានបង្ហោះ។

ការបណ្តុះបណ្តាលនឹងប្រព្រឹត្តទៅចាប់ពីថ្ងៃទី 5 ដល់ថ្ងៃទី 7 ខែសីហានៅទីក្រុងម៉ូស្គូ។ ទាំងនេះគឺជាថ្ងៃធ្វើការដែលនឹងត្រូវបានកាន់កាប់ទាំងស្រុង។ អាហារថ្ងៃត្រង់ និងការបណ្តុះបណ្តាលនឹងស្ថិតនៅក្នុងការិយាល័យរបស់យើង ហើយអ្នកចូលរួមដែលបានជ្រើសរើសនឹងចំណាយសម្រាប់ការធ្វើដំណើរ និងការស្នាក់នៅដោយខ្លួនឯង។

អ្នកអាចដាក់ពាក្យសុំចូលរួម ក្នុងទម្រង់ Google នេះ។. ពីអ្នក - ចម្លើយចំពោះសំណួរថាហេតុអ្វីបានជាអ្នកត្រូវការចូលរួមវគ្គបណ្តុះបណ្តាល និងព័ត៌មានអំពីរបៀបទាក់ទងអ្នក។ ឆ្លើយ​ជា​ភាសា​អង់គ្លេស ព្រោះ Chris នឹង​ជ្រើសរើស​អ្នក​ចូល​រួម​ដែល​នឹង​ចូល​រួម​វគ្គ​បណ្តុះបណ្តាល​ដោយ​ខ្លួន​ឯង។
យើង​នឹង​ប្រកាស​ឈ្មោះ​អ្នក​ចូល​រួម​វគ្គ​បណ្ដុះបណ្ដាល​នៅ​ក្នុង​ការ​ធ្វើ​បច្ចុប្បន្នភាព​ចំពោះ​ការ​ប្រកាស​នេះ និង​នៅ​លើ​បណ្ដាញ​សង្គម Avito សម្រាប់​អ្នក​អភិវឌ្ឍន៍ (AvitoTech in ហ្វេសប៊ុក, Вконтакте, Twitter) មិនលើសពីថ្ងៃទី 19 ខែកក្កដា។

ប្រភព: www.habr.com