ទិដ្ឋភាពទូទៅនៃស្ថាបត្យកម្មសេវាកម្មសម្រាប់ការវាយតម្លៃរូបរាងដោយផ្អែកលើបណ្តាញសរសៃប្រសាទ

ធាតុ

ជំរាបសួរ!

នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងចែករំលែកបទពិសោធន៍របស់ខ្ញុំក្នុងការកសាងស្ថាបត្យកម្ម microservice សម្រាប់គម្រោងដោយប្រើបណ្តាញសរសៃប្រសាទ។

ចូរនិយាយអំពីតម្រូវការស្ថាបត្យកម្ម មើលដ្យាក្រាមរចនាសម្ព័ន្ធផ្សេងៗ វិភាគធាតុផ្សំនីមួយៗនៃស្ថាបត្យកម្មដែលបានបញ្ចប់ និងវាយតម្លៃម៉ែត្របច្ចេកទេសនៃដំណោះស្រាយផងដែរ។

រីករាយអាន!

ពាក្យពីរបីអំពីបញ្ហា និងដំណោះស្រាយរបស់វា។

គំនិតចម្បងគឺដើម្បីវាយតម្លៃភាពទាក់ទាញរបស់មនុស្សនៅលើមាត្រដ្ឋានដប់ចំណុចដោយផ្អែកលើរូបថត។

នៅក្នុងអត្ថបទនេះ យើងនឹងផ្លាស់ទីឆ្ងាយពីការពិពណ៌នាទាំងបណ្តាញសរសៃប្រសាទដែលបានប្រើ និងដំណើរការនៃការរៀបចំទិន្នន័យ និងការបណ្តុះបណ្តាល។ ទោះជាយ៉ាងណាក៏ដោយ នៅក្នុងការបោះពុម្ពផ្សាយមួយខាងក្រោមនេះ យើងពិតជានឹងត្រលប់ទៅការវិភាគបំពង់បង្ហូរការវាយតម្លៃនៅកម្រិតស៊ីជម្រៅមួយ។

ឥឡូវនេះយើងនឹងឆ្លងកាត់បំពង់វាយតម្លៃនៅកម្រិតកំពូល ហើយនឹងផ្តោតលើអន្តរកម្មនៃសេវាកម្មខ្នាតតូចនៅក្នុងបរិបទនៃស្ថាបត្យកម្មគម្រោងទាំងមូល។ 

នៅពេលធ្វើការលើបំពង់វាយតម្លៃភាពទាក់ទាញ កិច្ចការត្រូវបានបំបែកទៅជាសមាសធាតុដូចខាងក្រោមៈ

1. ការជ្រើសរើសមុខនៅក្នុងរូបថត
2. ការវាយតម្លៃរបស់មនុស្សម្នាក់ៗ
3. បង្ហាញលទ្ធផល

ទីមួយត្រូវបានដោះស្រាយដោយកងកម្លាំងនៃការបណ្តុះបណ្តាលជាមុន MTCNN. សម្រាប់ទីពីរ បណ្តាញសរសៃប្រសាទ convolutional ត្រូវបានបណ្តុះបណ្តាលនៅលើ PyTorch ដោយប្រើ ResNet ៥០ - ពីតុល្យភាព "គុណភាព / ល្បឿននៃការសន្និដ្ឋាននៅលើស៊ីភីយូ"

ដ្យាក្រាមមុខងារនៃបំពង់បង្ហូរវាយតម្លៃ

ការវិភាគតម្រូវការស្ថាបត្យកម្មគម្រោង

នៅក្នុងវដ្តជីវិត ML ដំណាក់កាលគម្រោងនៃការងារលើស្ថាបត្យកម្ម និងស្វ័យប្រវត្តិកម្មនៃការដាក់ពង្រាយគំរូ ជារឿយៗស្ថិតក្នុងចំណោមការចំណាយពេលវេលាច្រើនបំផុត និងប្រើប្រាស់ធនធាន។

វដ្តជីវិតនៃគម្រោង ML

គម្រោងនេះមិនមានករណីលើកលែងនោះទេ - ការសម្រេចចិត្តត្រូវបានធ្វើឡើងដើម្បីរុំបំពង់ការវាយតម្លៃទៅក្នុងសេវាកម្មអនឡាញ ដែលតម្រូវឱ្យបញ្ចូលខ្លួនយើងនៅក្នុងស្ថាបត្យកម្ម។ តម្រូវការមូលដ្ឋានខាងក្រោមត្រូវបានកំណត់៖

1. ការផ្ទុកកំណត់ហេតុបង្រួបបង្រួម - សេវាកម្មទាំងអស់គួរតែសរសេរកំណត់ហេតុនៅកន្លែងតែមួយ ពួកគេគួរតែងាយស្រួលក្នុងការវិភាគ
2. លទ្ធភាពនៃការធ្វើមាត្រដ្ឋានផ្តេកនៃសេវាវាយតម្លៃ - ជា Bottleneck ទំនងបំផុត
3. ចំនួនដូចគ្នានៃធនធានដំណើរការគួរតែត្រូវបានបែងចែកដើម្បីវាយតម្លៃរូបភាពនីមួយៗ ដើម្បីជៀសវាងការហួសប្រមាណក្នុងការចែកចាយពេលវេលាសម្រាប់ការសន្និដ្ឋាន
4. ការដាក់ពង្រាយឡើងវិញនូវសេវាកម្មជាក់លាក់ និងជង់ទាំងមូល
5. សមត្ថភាពក្នុងការប្រើប្រាស់វត្ថុទូទៅនៅក្នុងសេវាកម្មផ្សេងៗ ប្រសិនបើចាំបាច់

ស្ថាបត្យកម្ម

បន្ទាប់​ពី​ការ​វិភាគ​តម្រូវ​ការ វា​បាន​ក្លាយ​ជា​ច្បាស់​ថា​ស្ថាបត្យកម្ម​មីក្រូ​សេវា​សម​ស្ទើរ​តែ​ឥតខ្ចោះ។

ដើម្បីកម្ចាត់ការឈឺក្បាលដែលមិនចាំបាច់នោះ Telegram API ត្រូវបានជ្រើសរើសជាផ្នែកខាងមុខ។

ជាដំបូង សូមក្រឡេកមើលដ្យាក្រាមរចនាសម្ព័ននៃស្ថាបត្យកម្មដែលបានបញ្ចប់ បន្ទាប់មកបន្តទៅការពិពណ៌នានៃធាតុផ្សំនីមួយៗ ហើយថែមទាំងធ្វើបែបបទនៃដំណើរការរូបភាពដែលទទួលបានជោគជ័យផងដែរ។

ដ្យាក្រាមរចនាសម្ព័ន្ធនៃស្ថាបត្យកម្មដែលបានបញ្ចប់

ចូរ​យើង​និយាយ​លម្អិត​បន្ថែម​ទៀត​អំពី​ធាតុផ្សំ​នីមួយៗ​នៃ​ដ្យាក្រាម ដោយ​បញ្ជាក់​ពី​ទំនួល​ខុស​ត្រូវ​តែ​មួយ​ក្នុង​ដំណើរ​ការ​វាយ​តម្លៃ​រូបភាព។

សេវាមីក្រូ "attrai-telegram-bot"

សេវាមីក្រូនេះគ្របដណ្តប់អន្តរកម្មទាំងអស់ជាមួយ Telegram API ។ មានសេណារីយ៉ូសំខាន់ៗចំនួន 2៖ ធ្វើការជាមួយរូបភាពផ្ទាល់ខ្លួន និងធ្វើការជាមួយលទ្ធផលនៃបំពង់បង្ហូរវាយតម្លៃ។ សូមក្រឡេកមើលសេណារីយ៉ូទាំងពីរក្នុងន័យទូទៅ។

នៅពេលទទួលបានសារផ្ទាល់ខ្លួនជាមួយរូបភាព៖

1. ការត្រងត្រូវបានអនុវត្ត ដោយមានការត្រួតពិនិត្យដូចខាងក្រោមៈ
   • ភាពអាចរកបាននៃទំហំរូបភាពល្អបំផុត
   • ចំនួនរូបភាពអ្នកប្រើប្រាស់រួចហើយនៅក្នុងជួរ
2. នៅពេលឆ្លងកាត់ការត្រងដំបូង រូបភាពត្រូវបានរក្សាទុកក្នុងកម្រិតសំឡេង docker
3. ភារកិច្ចមួយត្រូវបានផលិតនៅក្នុងជួរ "to_estimate" ដែលរួមមានផ្លូវទៅកាន់រូបភាពដែលមាននៅក្នុងបរិមាណរបស់យើង
4. ប្រសិនបើជំហានខាងលើត្រូវបានបញ្ចប់ដោយជោគជ័យ អ្នកប្រើប្រាស់នឹងទទួលបានសារជាមួយនឹងពេលវេលាដំណើរការរូបភាពប្រហាក់ប្រហែល ដែលត្រូវបានគណនាដោយផ្អែកលើចំនួនកិច្ចការក្នុងជួរ។ ប្រសិនបើមានកំហុសកើតឡើង អ្នកប្រើប្រាស់នឹងត្រូវបានជូនដំណឹងយ៉ាងច្បាស់តាមរយៈការផ្ញើសារជាមួយនឹងព័ត៌មានអំពីអ្វីដែលអាចនឹងខុស។

ផងដែរ សេវាមីក្រូនេះ ដូចជាកម្មករ celery ស្តាប់ជួរ "after_estimate" ដែលមានបំណងសម្រាប់កិច្ចការដែលបានឆ្លងកាត់បំពង់វាយតម្លៃ។

នៅពេលទទួលបានកិច្ចការថ្មីពី “after_estimate”៖

1. ប្រសិនបើរូបភាពត្រូវបានដំណើរការដោយជោគជ័យ យើងផ្ញើលទ្ធផលទៅអ្នកប្រើប្រាស់ ប្រសិនបើមិនមានទេ យើងជូនដំណឹងអំពីបញ្ហា។
2. ការដករូបភាពដែលជាលទ្ធផលនៃបំពង់បង្ហូរវាយតម្លៃ

សេវាវាយតម្លៃខ្នាតតូច "អ្នកប៉ាន់ប្រមាណ"

microservice នេះ​គឺ​ជា​បុគ្គលិក celery និង​រុំ​ព័ទ្ធ​គ្រប់​យ៉ាង​ដែល​ទាក់​ទង​នឹង​បំពង់​បង្ហូរ​ការ​វាយ​តម្លៃ​រូបភាព។ មានក្បួនដោះស្រាយតែមួយគត់ដែលធ្វើការនៅទីនេះ - តោះវិភាគវា។

នៅពេលទទួលបានកិច្ចការថ្មីពី “to_estimate”៖

1. ចូរដំណើរការរូបភាពតាមរយៈបំពង់វាយតម្លៃ៖
   1. កំពុងផ្ទុករូបភាពទៅក្នុងអង្គចងចាំ
   2. យើងនាំយករូបភាពទៅទំហំដែលត្រូវការ
   3. ស្វែងរកមុខទាំងអស់ (MTCNN)
   4. យើងវាយតម្លៃមុខទាំងអស់ (យើងរុំមុខដែលរកឃើញក្នុងជំហានចុងក្រោយទៅជាបណ្តុំ និងការសន្និដ្ឋាន ResNet34)
   5. បង្ហាញរូបភាពចុងក្រោយ
      1. ចូរយើងគូរប្រអប់ដែលមានព្រំដែន
      2. គូរការវាយតម្លៃ
2. ការលុបរូបភាពផ្ទាល់ខ្លួន (ដើម)
3. ការរក្សាទុកទិន្នផលពីបំពង់វាយតម្លៃ
4. យើងដាក់ភារកិច្ចនៅក្នុងជួរ "after_estimate" ដែលត្រូវបានស្តាប់ដោយ "attrai-telegram-bot" microservice ដែលបានពិភាក្សាខាងលើ។

Graylog (+ mongoDB + Elasticsearch)

ប្រផេះ គឺជាដំណោះស្រាយសម្រាប់ការគ្រប់គ្រងកំណត់ហេតុកណ្តាល។ នៅក្នុងគម្រោងនេះ វាត្រូវបានប្រើប្រាស់សម្រាប់គោលបំណងដែលបានគ្រោងទុក។

ជម្រើស​បាន​ធ្លាក់​មក​លើ​គាត់ ហើយ​មិន​មែន​លើ​ជម្រើស​ធម្មតា​ទេ។ ELK stack ដោយសារតែភាពងាយស្រួលនៃការធ្វើការជាមួយវាពី Python ។ អ្វីដែលអ្នកត្រូវធ្វើដើម្បីចូល Graylog គឺបន្ថែម GELFTCPHandler ពីកញ្ចប់ ប្រផេះ ទៅកាន់អ្នកដោះស្រាយការកាប់ឈើជា root ដែលនៅសល់នៃសេវាកម្មមីក្រូ python របស់យើង។

ក្នុងនាមជាមនុស្សម្នាក់ដែលធ្លាប់ធ្វើការតែជាមួយ ELK stack ពីមុនមក ខ្ញុំមានបទពិសោធន៍វិជ្ជមានជារួមនៅពេលធ្វើការជាមួយ Graylog ។ រឿងតែមួយគត់ដែលធ្វើឱ្យធ្លាក់ទឹកចិត្តគឺឧត្តមភាពនៅក្នុងលក្ខណៈពិសេសរបស់ Kibana លើចំណុចប្រទាក់បណ្តាញ Graylog ។

RabbitMQ

RabbitMQ គឺជាឈ្មួញកណ្តាលសារដែលមានមូលដ្ឋានលើពិធីការ AMQP ។

នៅក្នុងគម្រោងនេះវាត្រូវបានគេប្រើជា ស្ថេរភាពបំផុតនិងពេលវេលាសាកល្បង ឈ្មួញកណ្តាលសម្រាប់ Celery និងធ្វើការនៅក្នុងរបៀបប្រើប្រាស់បានយូរ។

Redis

Redis គឺជា NoSQL DBMS ដែលធ្វើការជាមួយរចនាសម្ព័ន្ធទិន្នន័យតម្លៃគន្លឹះ

ជួនកាលមានតម្រូវការប្រើប្រាស់វត្ថុទូទៅដែលអនុវត្តរចនាសម្ព័ន្ធទិន្នន័យជាក់លាក់នៅក្នុងមីក្រូសេវា Python ផ្សេងៗគ្នា។

ឧទាហរណ៍ Redis រក្សាទុក hashmap នៃទម្រង់ “telegram_user_id => ចំនួននៃកិច្ចការសកម្មនៅក្នុងជួរ” ដែលអនុញ្ញាតឱ្យអ្នកកំណត់ចំនួនសំណើពីអ្នកប្រើប្រាស់ម្នាក់ទៅតម្លៃជាក់លាក់មួយ ហើយដោយហេតុនេះ ការពារការវាយប្រហារ DoS ។

ចូរយើងរៀបចំដំណើរការនៃដំណើរការរូបភាពដែលទទួលបានជោគជ័យជាផ្លូវការ

1. អ្នកប្រើប្រាស់ផ្ញើរូបភាពទៅកាន់ Telegram bot
2. "attrai-telegram-bot" ទទួលសារពី Telegram API ហើយញែកវា។
3. ភារកិច្ចដែលមានរូបភាពត្រូវបានបន្ថែមទៅជួរអសមកាល "to_estimate"
4. អ្នកប្រើប្រាស់ទទួលបានសារជាមួយនឹងពេលវេលាវាយតម្លៃដែលបានគ្រោងទុក
5. "attrai-estimator" យកភារកិច្ចពីជួរ "to_estimate" ដំណើរការការប៉ាន់ប្រមាណតាមរយៈបំពង់បង្ហូរប្រេង និងផលិតកិច្ចការទៅក្នុងជួរ "after_estimate"
6. "attrai-telegram-bot" ស្តាប់ជួរ "after_estimate" ផ្ញើលទ្ធផលទៅអ្នកប្រើប្រាស់

DevOps

ជាចុងក្រោយ បន្ទាប់ពីពិនិត្យមើលស្ថាបត្យកម្ម អ្នកអាចបន្តទៅផ្នែកគួរឱ្យចាប់អារម្មណ៍ដូចគ្នា - DevOps

Docker Swarm

 

Docker Swarm  - ប្រព័ន្ធចង្កោម មុខងារដែលត្រូវបានអនុវត្តនៅខាងក្នុង Docker Engine ហើយមាននៅក្រៅប្រអប់។

ដោយប្រើ "swarm" ថ្នាំងទាំងអស់នៅក្នុងចង្កោមរបស់យើងអាចត្រូវបានបែងចែកជា 2 ប្រភេទ - កម្មករ និងអ្នកគ្រប់គ្រង។ នៅលើម៉ាស៊ីនប្រភេទទីមួយ ក្រុមកុងតឺន័រ (ជង់) ត្រូវបានដាក់ពង្រាយ ម៉ាស៊ីននៃប្រភេទទីពីរ ទទួលខុសត្រូវចំពោះការធ្វើមាត្រដ្ឋាន តុល្យភាព និង លក្ខណៈពិសេសត្រជាក់ផ្សេងទៀត។. អ្នកគ្រប់គ្រងក៏ជាកម្មករតាមលំនាំដើមផងដែរ។

ចង្កោម​ដែល​មាន​អ្នក​គ្រប់​គ្រង​ថ្នាក់​ដឹក​នាំ​ម្នាក់ និង​កម្មករ​បី​នាក់។

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

សម្លឹងទៅមុខ ខ្ញុំនឹងនិយាយថា ចាប់តាំងពីការចែកចាយផលិតកម្មលើកដំបូង ដែលធ្វើឡើងនៅពាក់កណ្តាលខែមិថុនា មិនមានបញ្ហាទាក់ទងនឹងអង្គការចង្កោមនេះទេ (ប៉ុន្តែនេះមិនមែនមានន័យថា អង្គការបែបនេះអាចទទួលយកបានក្នុងកម្រិតមធ្យមណាមួយនោះទេ។ គម្រោង​ដែល​ជា​កម្មវត្ថុ​តម្រូវ​ការ​អត់​ឱន​កំហុស​) ។

ជង់ Docker

នៅក្នុងរបៀប swarm គាត់ទទួលខុសត្រូវលើការដាក់ពង្រាយ stacks (សំណុំនៃសេវាកម្ម docker) ជង់ docker

វាគាំទ្រការកំណត់រចនាសម្ព័ន្ធ docker-compose ដែលអនុញ្ញាតឱ្យអ្នកបន្ថែមប៉ារ៉ាម៉ែត្រដាក់ពង្រាយ។  

ឧទាហរណ៍ ដោយប្រើប៉ារ៉ាម៉ែត្រទាំងនេះ ធនធានសម្រាប់ករណី microservice វាយតម្លៃនីមួយៗត្រូវបានកំណត់ (យើងបែងចែក N cores សម្រាប់ N instances នៅក្នុង microservice យើងកំណត់ចំនួនស្នូលដែលប្រើដោយ PyTorch ទៅមួយ)

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

វាជាការសំខាន់ក្នុងការកត់សម្គាល់ថា Redis, RabbitMQ និង Graylog គឺជាសេវាកម្មដែលមានលក្ខណៈរដ្ឋ ហើយពួកគេមិនអាចធ្វើមាត្រដ្ឋានបានយ៉ាងងាយស្រួលដូច "attrai-estimator" នោះទេ។

ទាយសំណួរ - ហេតុអ្វីមិន Kubernetes?

វាហាក់បីដូចជាការប្រើប្រាស់ Kubernetes នៅក្នុងគម្រោងខ្នាតតូច និងមធ្យមគឺជាការចំណាយលើសមួយ មុខងារចាំបាច់ទាំងអស់អាចទទួលបានពី Docker Swarm ដែលងាយស្រួលប្រើសម្រាប់អ្នកវង់ភ្លេងកុងតឺន័រ ហើយក៏មានឧបសគ្គទាបក្នុងការចូលផងដែរ។

ហេដ្ឋារចនាសម្ព័ន្ធ

ទាំងអស់នេះត្រូវបានដាក់ពង្រាយនៅលើ VDS ដែលមានលក្ខណៈដូចខាងក្រោមៈ

• ស៊ីភីយូ៖ ស៊ីភីយូ Intel® Xeon® Gold 4 ចំនួន 5120 ស្នូល @ 2.20GHz
• អង្គចងចាំ: 8 GB
• SSD៖ ១២៨ ជីកាបៃ

បន្ទាប់ពីការធ្វើតេស្តផ្ទុកក្នុងស្រុក វាហាក់ដូចជាថាជាមួយនឹងការហូរចូលយ៉ាងធ្ងន់ធ្ងរនៃអ្នកប្រើប្រាស់ម៉ាស៊ីននេះនឹងគ្រប់គ្រាន់ហើយ។

ប៉ុន្តែភ្លាមៗបន្ទាប់ពីការដាក់ឱ្យប្រើប្រាស់ ខ្ញុំបានបង្ហោះតំណភ្ជាប់ទៅកាន់ផ្ទាំងរូបភាពដ៏ពេញនិយមបំផុតមួយនៅក្នុង CIS (បាទ នោះដូចគ្នា) បន្ទាប់ពីនោះមនុស្សចាប់អារម្មណ៍ ហើយក្នុងរយៈពេលពីរបីម៉ោង សេវាកម្មបានដំណើរការរូបភាពរាប់ម៉ឺនរូបភាពដោយជោគជ័យ។ ក្នុងពេលជាមួយគ្នានេះ នៅគ្រាកំពូល ធនធាន CPU និង RAM មិនត្រូវបានគេប្រើប្រាស់សូម្បីតែពាក់កណ្តាល។

ក្រាហ្វិកមួយចំនួនទៀត។

ចំនួនអ្នកប្រើប្រាស់ពិសេស និងសំណើវាយតម្លៃចាប់តាំងពីការដាក់ឱ្យប្រើប្រាស់ អាស្រ័យលើថ្ងៃ

ការចែកចាយពេលវេលាការសន្និដ្ឋាននៃបំពង់វាយតម្លៃ

ការរកឃើញ

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

ខ្ញុំគិតថាគម្រោងខ្នាតតូច និងមធ្យមដែលប្រើការសន្និដ្ឋានតាមពេលវេលាជាក់ស្តែងនៃបណ្តាញសរសៃប្រសាទនៅលើ CPU ក្នុងដំណើរការរបស់ពួកគេអាចទទួលយកការអនុវត្តដែលបានពិពណ៌នានៅក្នុងអត្ថបទនេះដោយជោគជ័យ។

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

អ្នកអាចចាក់ bot នៅលើ Telegram - @AttraiBot វានឹងដំណើរការយ៉ាងហោចណាស់រហូតដល់ចុងរដូវស្លឹកឈើជ្រុះឆ្នាំ 2020។ ខ្ញុំសូមរំលឹកអ្នកថា គ្មានទិន្នន័យអ្នកប្រើប្រាស់ត្រូវបានរក្សាទុកទេ - ទាំងរូបភាពដើម ឬលទ្ធផលនៃបំពង់បង្ហូរការវាយតម្លៃ - អ្វីគ្រប់យ៉ាងត្រូវបានបំផ្លាញបន្ទាប់ពីដំណើរការ។

ប្រភព: www.habr.com