🥇 Mikhail Salosin ។ កិច្ចប្រជុំ Golang ។ ការប្រើប្រាស់ Go នៅក្នុងផ្នែកខាងក្រោយនៃកម្មវិធី Look+

Mikhail Salosin (តទៅនេះ - MS)៖ - សួស្តីអ្នកទាំងអស់គ្នា! ខ្ញុំឈ្មោះមៃខឡ។ ខ្ញុំធ្វើការជាអ្នកអភិវឌ្ឍន៍ផ្នែកខាងក្រោយនៅកម្មវិធី MC2 ហើយខ្ញុំនឹងនិយាយអំពីការប្រើប្រាស់ Go នៅក្នុងផ្នែកខាងក្រោយនៃកម្មវិធីទូរស័ព្ទ Look+។

តើមាននរណាម្នាក់នៅទីនេះចូលចិត្តវាយកូនគោលទេ?

បន្ទាប់មកកម្មវិធីនេះគឺសម្រាប់អ្នក។ វាគឺសម្រាប់ Android និង iOS ហើយត្រូវបានប្រើដើម្បីមើលការផ្សាយនៃព្រឹត្តិការណ៍កីឡាផ្សេងៗតាមអ៊ីនធឺណិត និងថតទុក។ កម្មវិធីនេះក៏មានស្ថិតិផ្សេងៗ ការផ្សាយជាអត្ថបទ តារាងសម្រាប់សន្និសីទ ការប្រកួត និងព័ត៌មានផ្សេងទៀតដែលមានប្រយោជន៍សម្រាប់អ្នកគាំទ្រ។

ផងដែរនៅក្នុងកម្មវិធីមានរឿងដូចជាពេលវីដេអូ ពោលគឺអ្នកអាចមើលពេលវេលាដ៏សំខាន់បំផុតនៃការប្រកួត (គ្រាប់បាល់ ការប្រយុទ្ធ ការស៊ុតបាល់បញ្ចូលទី។ល។)។ ប្រសិនបើអ្នកមិនចង់មើលការផ្សាយទាំងមូលទេ អ្នកអាចមើលតែរឿងដែលគួរឱ្យចាប់អារម្មណ៍បំផុត។

តើអ្នកបានប្រើអ្វីក្នុងការអភិវឌ្ឍន៍?

ផ្នែកសំខាន់ត្រូវបានសរសេរនៅក្នុង Go ។ API ដែលអតិថិជនទូរស័ព្ទបានទាក់ទងជាមួយត្រូវបានសរសេរនៅក្នុង Go ។ សេវាកម្មសម្រាប់ផ្ញើការជូនដំណឹងរុញទៅទូរស័ព្ទចល័តក៏ត្រូវបានសរសេរនៅក្នុង Go ផងដែរ។ យើងក៏ត្រូវសរសេរ ORM របស់យើងផងដែរ ដែលយើងអាចនិយាយអំពីថ្ងៃណាមួយ។ ជាការប្រសើរណាស់ សេវាកម្មតូចៗមួយចំនួនត្រូវបានសរសេរនៅក្នុង Go៖ ផ្លាស់ប្តូរទំហំ និងផ្ទុករូបភាពសម្រាប់អ្នកកែសម្រួល...

យើងបានប្រើ PostgreSQL ជាមូលដ្ឋានទិន្នន័យ។ ចំណុចប្រទាក់កម្មវិធីនិពន្ធត្រូវបានសរសេរនៅក្នុង Ruby on Rails ដោយប្រើ ActiveAdmin gem ។ ការនាំចូលស្ថិតិពីអ្នកផ្តល់ស្ថិតិក៏ត្រូវបានសរសេរជា Ruby ផងដែរ។

សម្រាប់ការធ្វើតេស្ត API ប្រព័ន្ធ យើងបានប្រើ Python unittest ។ Memcached ត្រូវបានប្រើដើម្បីបិទការហៅទូរសព្ទទូទាត់ API, ចុងភៅត្រូវបានប្រើដើម្បីគ្រប់គ្រងការកំណត់, Zabbix ត្រូវបានប្រើដើម្បីប្រមូល និងត្រួតពិនិត្យស្ថិតិប្រព័ន្ធខាងក្នុង។ Graylog2 គឺសម្រាប់ការប្រមូលកំណត់ហេតុ Slate គឺជាឯកសារ API សម្រាប់អតិថិជន។

ការជ្រើសរើសពិធីការ

បញ្ហាដំបូងដែលយើងជួបប្រទះ៖ យើងត្រូវជ្រើសរើសពិធីការសម្រាប់អន្តរកម្មរវាង backend និងអតិថិជនទូរស័ព្ទ ដោយផ្អែកលើចំណុចខាងក្រោម...

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

ផ្អែកលើនេះ យើងមានជម្រើសពិធីការពីរ៖

រន្ធបណ្តាញ។ ប៉ុន្តែយើងមិនត្រូវការឆានែលពីអតិថិជនទៅម៉ាស៊ីនមេទេ។ យើងគ្រាន់តែត្រូវការដើម្បីផ្ញើការអាប់ដេតពីម៉ាស៊ីនមេទៅម៉ាស៊ីនភ្ញៀវ ដូច្នេះ websocket គឺជាជម្រើសដែលមិនត្រូវការឡើងវិញ។
Server-Sent Events (SSE) បានមកដល់ហើយ! វាគឺសាមញ្ញណាស់ ហើយជាមូលដ្ឋានបំពេញអ្វីគ្រប់យ៉ាងដែលយើងត្រូវការ។

ព្រឹត្តិការណ៍ដែលបានផ្ញើដោយម៉ាស៊ីនមេ

ពាក្យពីរបីអំពីរបៀបដែលរឿងនេះដំណើរការ ...

វាដំណើរការនៅលើតំណភ្ជាប់ http ។ ម៉ាស៊ីនភ្ញៀវផ្ញើសំណើមួយ ម៉ាស៊ីនមេឆ្លើយតបជាមួយមាតិកា-ប្រភេទ៖ អត្ថបទ/ព្រឹត្តិការណ៍-ស្ទ្រីម និងមិនបិទការតភ្ជាប់ជាមួយម៉ាស៊ីនភ្ញៀវ ប៉ុន្តែបន្តសរសេរទិន្នន័យទៅការតភ្ជាប់៖

ទិន្នន័យអាចត្រូវបានផ្ញើជាទម្រង់ដែលបានព្រមព្រៀងជាមួយអតិថិជន។ ក្នុងករណីរបស់យើង យើងបានផ្ញើវាតាមទម្រង់នេះ៖ ឈ្មោះនៃរចនាសម្ព័ន្ធដែលបានផ្លាស់ប្តូរ (មនុស្ស អ្នកលេង) ត្រូវបានផ្ញើទៅកាន់វាលព្រឹត្តិការណ៍ ហើយ JSON ជាមួយនឹងវាលដែលបានផ្លាស់ប្តូរថ្មីសម្រាប់អ្នកលេងត្រូវបានផ្ញើទៅកាន់វាលទិន្នន័យ។

ឥឡូវនេះសូមនិយាយអំពីរបៀបដែលអន្តរកម្មខ្លួនវាដំណើរការ។

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

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

តើការភ្ជាប់បន្តផ្ទាល់ត្រូវបានផ្តល់សេវាយ៉ាងដូចម្តេច?

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

បញ្ហាដំបូងដែលយើងជួបប្រទះមានដូចខាងក្រោម៖ សម្រាប់ការតភ្ជាប់នីមួយៗដែលបើកជាមួយអតិថិជន យើងបានបង្កើតកម្មវិធីកំណត់ម៉ោងដែលគូសម្តងរៀងរាល់ 15 វិនាទី - វាប្រែថាប្រសិនបើយើងមានការតភ្ជាប់ 6 ពាន់បើកជាមួយម៉ាស៊ីនមួយ (ជាមួយម៉ាស៊ីនមេ API មួយ) 6 កម្មវិធីកំណត់ម៉ោងមួយពាន់ត្រូវបានបង្កើតឡើង។ នេះនាំឱ្យម៉ាស៊ីនមិនផ្ទុកបន្ទុកដែលត្រូវការ។ បញ្ហានេះមិនច្បាស់សម្រាប់យើងទេ ប៉ុន្តែយើងបានទទួលជំនួយបន្តិចបន្តួច ហើយបានជួសជុលវា។

ជាលទ្ធផល ឥឡូវនេះ ping របស់យើងបានមកពីឆានែលដូចគ្នាដែលការអាប់ដេតមកដល់។

ដូច្នោះហើយ មានកម្មវិធីកំណត់ពេលវេលាតែមួយគត់ដែលគូសម្តងរៀងរាល់ 15 វិនាទី។

មានមុខងារជំនួយជាច្រើននៅទីនេះ - បញ្ជូនបឋមកថា ភីង និងរចនាសម្ព័ន្ធខ្លួនឯង។ នោះគឺឈ្មោះតារាង (មនុស្ស ការប្រកួត រដូវកាល) និងព័ត៌មានអំពីធាតុនេះត្រូវបានបញ្ជូននៅទីនេះ៖

យន្តការបញ្ជូនព័ត៌មានថ្មីៗ

ឥឡូវនេះបន្តិចអំពីកន្លែងដែលការផ្លាស់ប្តូរមកពីណា។ យើងមានមនុស្សជាច្រើន ជាអ្នកកែសម្រួល ដែលមើលការផ្សាយក្នុងពេលពិតប្រាកដ។ ពួកគេបង្កើតព្រឹត្តិការណ៍ទាំងអស់៖ នរណាម្នាក់ត្រូវបានបណ្តេញចេញ, នរណាម្នាក់ត្រូវបានរងរបួស, ប្រភេទមួយចំនួននៃការជំនួស ...

ដោយប្រើ CMS ទិន្នន័យចូលទៅក្នុងមូលដ្ឋានទិន្នន័យ។ បន្ទាប់ពីនេះ មូលដ្ឋានទិន្នន័យជូនដំណឹងដល់ម៉ាស៊ីនមេ API អំពីបញ្ហានេះដោយប្រើយន្តការស្តាប់/ជូនដំណឹង។ ម៉ាស៊ីនមេ API ផ្ញើព័ត៌មាននេះទៅអតិថិជនរួចហើយ។ ដូច្នេះ យើងពិតជាមានម៉ាស៊ីនមេមួយចំនួនដែលតភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ ហើយមិនមានការផ្ទុកពិសេសនៅលើមូលដ្ឋានទិន្នន័យទេ ពីព្រោះម៉ាស៊ីនភ្ញៀវមិនមានអន្តរកម្មដោយផ្ទាល់ជាមួយមូលដ្ឋានទិន្នន័យតាមមធ្យោបាយណាមួយឡើយ៖

PostgreSQL៖ ស្តាប់/ជូនដំណឹង

យន្តការស្តាប់/ជូនដំណឹងនៅក្នុង Postgres អនុញ្ញាតឱ្យអ្នកជូនដំណឹងដល់អ្នកជាវព្រឹត្តិការណ៍ថាព្រឹត្តិការណ៍មួយចំនួនបានផ្លាស់ប្តូរ - កំណត់ត្រាមួយចំនួនត្រូវបានបង្កើតនៅក្នុងមូលដ្ឋានទិន្នន័យ។ ដើម្បីធ្វើដូច្នេះ យើងបានសរសេរគន្លឹះ និងមុខងារសាមញ្ញមួយ៖

នៅពេលបញ្ចូល ឬផ្លាស់ប្តូរកំណត់ត្រា យើងហៅមុខងារជូនដំណឹងនៅលើឆានែល data_updates ដោយឆ្លងកាត់ទីនោះឈ្មោះតារាង និងការកំណត់អត្តសញ្ញាណនៃកំណត់ត្រាដែលត្រូវបានផ្លាស់ប្តូរ ឬបញ្ចូល។

សម្រាប់តារាងទាំងអស់ដែលត្រូវតែធ្វើសមកាលកម្មជាមួយម៉ាស៊ីនភ្ញៀវ យើងកំណត់គន្លឹះមួយ ដែលបន្ទាប់ពីផ្លាស់ប្តូរ / ធ្វើបច្ចុប្បន្នភាពកំណត់ត្រា ហៅមុខងារដែលបានបង្ហាញនៅលើស្លាយខាងក្រោម។
តើ API ចុះឈ្មោះក្នុងការផ្លាស់ប្តូរទាំងនេះដោយរបៀបណា?

យន្តការ Fanout ត្រូវបានបង្កើតឡើង - វាផ្ញើសារទៅកាន់អតិថិជន។ វាប្រមូលបណ្តាញអតិថិជនទាំងអស់ ហើយផ្ញើព័ត៌មានថ្មីៗដែលវាបានទទួលតាមរយៈបណ្តាញទាំងនេះ៖

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

បន្ទាប់មក យើងកំណត់ Ticker ដោយមិនសមកាលកម្ម ដែលនឹងផ្ញើ ping រៀងរាល់ 15 វិនាទី ហើយចាប់ផ្តើមស្តាប់ឆានែលដែលយើងបានជាវ។ ប្រសិនបើយើងទទួលបាន ping យើងបោះពុម្ពផ្សាយ ping នេះ។ ប្រសិនបើយើងទទួលបានប្រភេទមួយចំនួន នោះយើងបោះផ្សាយធាតុនេះទៅកាន់អតិថិជនទាំងអស់នៃ Fanout នេះ។

តើ Fan-out ដំណើរការយ៉ាងដូចម្តេច?

នៅក្នុងភាសារុស្ស៊ីវាប្រែថា "បំបែក" ។ យើងមានវត្ថុមួយដែលចុះឈ្មោះអ្នកជាវដែលចង់ទទួលបានព័ត៌មានថ្មីៗមួយចំនួន។ ហើយភ្លាមៗនៅពេលដែលការអាប់ដេតមកដល់វត្ថុនេះ វាចែកចាយការអាប់ដេតនេះទៅកាន់អតិថិជនទាំងអស់របស់វា។ សាមញ្ញគ្រប់គ្រាន់៖

របៀបដែលវាត្រូវបានអនុវត្តនៅក្នុង Go:

មានរចនាសម្ព័ន្ធមួយ វាត្រូវបានធ្វើសមកាលកម្មដោយប្រើ Mutexes ។ វាមានវាលដែលរក្សាទុកស្ថានភាពនៃការតភ្ជាប់របស់ Fanout ទៅមូលដ្ឋានទិន្នន័យ ពោលគឺវាកំពុងស្តាប់ ហើយនឹងទទួលការអាប់ដេត ក៏ដូចជាបញ្ជីនៃឆានែលដែលមានទាំងអស់ - ផែនទី ដែលជាគន្លឹះនៃឆានែល និងរចនាសម្ព័ន្ធក្នុងទម្រង់ជា តម្លៃ (សំខាន់វាមិនត្រូវបានប្រើក្នុងវិធីណាមួយទេ) ។

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

ក៏មានវិធីសាស្រ្តជាវដែលបន្ថែមឆានែលទៅ "អ្នកស្តាប់"៖

មានវិធីសាស្ត្រ Unsubscribe ដែលដកឆានែលចេញពីអ្នកស្តាប់ ប្រសិនបើអតិថិជនផ្តាច់ ក៏ដូចជាវិធីសាស្ត្រ Publish ដែលអនុញ្ញាតឱ្យអ្នកផ្ញើសារទៅកាន់អ្នកជាវទាំងអស់។

សំណួរ: - តើអ្វីត្រូវបានបញ្ជូនតាមរយៈឆានែលនេះ?

MS៖ - គំរូដែលបានផ្លាស់ប្តូរ ឬ ping ត្រូវបានបញ្ជូន (សំខាន់គ្រាន់តែជាលេខ ចំនួនគត់)។

MS៖ - អ្នកអាចផ្ញើអ្វីក៏បាន ផ្ញើរចនាសម្ព័ន្ធណាមួយ បោះផ្សាយវា - វាគ្រាន់តែប្រែទៅជា JSON ហើយនោះជាវា។

MS៖ - យើងទទួលបានការជូនដំណឹងពី Postgres - វាមានឈ្មោះតារាង និងអត្តសញ្ញាណ។ ដោយផ្អែកលើឈ្មោះតារាង និងការកំណត់អត្តសញ្ញាណ យើងទទួលបានកំណត់ត្រាដែលយើងត្រូវការ ហើយបន្ទាប់មកយើងផ្ញើរចនាសម្ព័ន្ធនេះសម្រាប់ការបោះពុម្ពផ្សាយ។

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

តើនេះមើលទៅដូចម្ដេចពីទិដ្ឋភាពហេដ្ឋារចនាសម្ព័ន្ធ? យើងមានម៉ាស៊ីនមេផ្នែករឹងចំនួន 7៖ មួយក្នុងចំណោមពួកវាត្រូវបានឧទ្ទិសទាំងស្រុងចំពោះមូលដ្ឋានទិន្នន័យ ហើយម៉ាស៊ីននិម្មិតប្រាំមួយផ្សេងទៀតដំណើរការ។ មាន 6 ច្បាប់ចម្លងនៃ API៖ ម៉ាស៊ីននិម្មិតនីមួយៗដែលមាន API ដំណើរការលើម៉ាស៊ីនមេផ្នែករឹងដាច់ដោយឡែក - នេះគឺសម្រាប់ភាពជឿជាក់។

យើងមានផ្នែកខាងមុខពីរជាមួយ Keepalived ដែលបានដំឡើងដើម្បីកែលម្អភាពងាយស្រួល ដូច្នេះប្រសិនបើមានអ្វីកើតឡើង ផ្នែកខាងមុខមួយអាចជំនួសកន្លែងផ្សេងទៀត។ ផងដែរ - ច្បាប់ចម្លងពីរនៃ CMS ។

ក៏មានអ្នកនាំចូលស្ថិតិផងដែរ។ មាន DB Slave ដែលការបម្រុងទុកត្រូវបានធ្វើឡើងជាទៀងទាត់។ មាន Pigeon Pusher ដែលជាកម្មវិធីដែលផ្ញើការជូនដំណឹងជំរុញដល់អតិថិជន ក៏ដូចជាហេដ្ឋារចនាសម្ព័ន្ធផងដែរ៖ Zabbix, Graylog2 និង Chef ។

តាមការពិត ហេដ្ឋារចនាសម្ព័ន្ធនេះគឺមិនអាចខ្វះបាន ព្រោះ 100 អាចត្រូវបានបម្រើដោយម៉ាស៊ីនមេតិចជាងមុន។ ប៉ុន្តែមានជាតិដែក - យើងបានប្រើវា (យើងត្រូវបានគេប្រាប់ថាវាអាចទៅរួច - ហេតុអ្វីបានជាមិនមាន) ។

គុណសម្បត្តិរបស់ Go

បន្ទាប់ពីយើងធ្វើការលើកម្មវិធីនេះ អត្ថប្រយោជន៍ជាក់ស្តែងបែបនេះរបស់ Go បានលេចចេញមក។

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

យើងកំពុងស្វែងរកអ្នកអភិវឌ្ឍន៍! ប្រសិនបើអ្នកណាចង់បានសូម។

សំណួរ

សំណួរពីទស្សនិកជន (តទៅនេះ – ខ)៖ – វាហាក់ដូចជាខ្ញុំថា អ្នកបានខកខានចំណុចសំខាន់មួយទាក់ទងនឹង Fan-out។ តើខ្ញុំយល់ថាត្រឹមត្រូវទេដែលពេលអ្នកផ្ញើការឆ្លើយតបទៅអតិថិជន អ្នករារាំងប្រសិនបើអតិថិជនមិនចង់អាន?

MS៖ - ទេយើងមិនរារាំងទេ។ ទីមួយ យើងមានអ្វីៗទាំងអស់នេះនៅពីក្រោយ nginx ពោលគឺមិនមានបញ្ហាជាមួយអតិថិជនយឺតទេ។ ទីពីរ អតិថិជនមានឆានែលមួយដែលមានសតិបណ្ដោះអាសន្ន - តាមពិតយើងអាចដាក់ការអាប់ដេតដល់ទៅមួយរយនៅទីនោះ... ប្រសិនបើយើងមិនអាចសរសេរទៅឆានែលបានទេ នោះវានឹងលុបវាចោល។ ប្រសិនបើយើងឃើញថាប៉ុស្តិ៍ត្រូវបានរារាំង នោះយើងនឹងបិទប៉ុស្តិ៍ ហើយនោះហើយជាវា - ម៉ាស៊ីនភ្ញៀវនឹងភ្ជាប់ឡើងវិញប្រសិនបើមានបញ្ហាណាមួយកើតឡើង។ ដូច្នេះជាគោលការណ៍មិនមានការទប់ស្កាត់នៅទីនេះទេ។

ក្នុង៖ - មិនអាចផ្ញើកំណត់ត្រាភ្លាមៗទៅ Listen/Notify ហើយមិនមែនជាតារាងកំណត់អត្តសញ្ញាណបានទេ?

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

ក្នុង៖ - តើអតិថិជនទទួលបានព័ត៌មានថ្មីៗអំពីការប្រកួតដែលពួកគេមិនចាប់អារម្មណ៍ទេ?

MS៖ - ជាទូទៅបាទ។ តាមក្បួនមានការប្រកួត 2-3 ដែលកំពុងដំណើរការស្របគ្នា ហើយសូម្បីតែពេលនោះកម្រណាស់។ ប្រសិនបើអតិថិជនកំពុងមើលអ្វីមួយ នោះជាធម្មតាគាត់កំពុងមើលការប្រកួតដែលកំពុងបន្ត។ បន្ទាប់មក ម៉ាស៊ីនភ្ញៀវមានមូលដ្ឋានទិន្នន័យក្នុងស្រុក ដែលការអាប់ដេតទាំងអស់នេះត្រូវបានបន្ថែម ហើយសូម្បីតែគ្មានការតភ្ជាប់អ៊ីធឺណិតក៏ដោយ អតិថិជនអាចមើលការប្រកួតកន្លងមកទាំងអស់ដែលគាត់បានធ្វើបច្ចុប្បន្នភាព។ ជាសំខាន់ យើងធ្វើសមកាលកម្មមូលដ្ឋានទិន្នន័យរបស់យើងនៅលើម៉ាស៊ីនមេជាមួយនឹងមូលដ្ឋានទិន្នន័យមូលដ្ឋានរបស់អតិថិជន ដូច្នេះគាត់អាចធ្វើការក្រៅបណ្តាញបាន។

ក្នុង៖ - ហេតុអ្វីបានជាអ្នកបង្កើត ORM របស់អ្នក?

Alexey (អ្នកអភិវឌ្ឍន៍ម្នាក់នៃ Look+)៖ - នៅពេលនោះ (វាគឺកាលពីមួយឆ្នាំមុន) មាន ORMs តិចជាងឥឡូវនេះ នៅពេលដែលវាមានច្រើនណាស់។ រឿងដែលខ្ញុំចូលចិត្តបំផុតអំពី ORMs ភាគច្រើននៅទីនោះគឺថាពួកគេភាគច្រើនដំណើរការលើចំណុចប្រទាក់ទទេ។ នោះគឺជាវិធីសាស្រ្តនៅក្នុង ORMs ទាំងនេះគឺត្រៀមខ្លួនជាស្រេចដើម្បីទទួលយកអ្វីទាំងអស់: រចនាសម្ព័ន្ធ, ទ្រនិចរចនាសម្ព័ន្ធ, លេខ, អ្វីមួយដែលមិនពាក់ព័ន្ធទាំងស្រុង ...

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

ក្នុង៖ - តើមានមនុស្សប៉ុន្មាននាក់បានចូលរួម?

MS៖ - នៅដំណាក់កាលដំបូងមនុស្សពីរនាក់បានចូលរួម។ យើងបានចាប់ផ្តើមនៅកន្លែងណាមួយនៅក្នុងខែមិថុនា ហើយនៅក្នុងខែសីហា ផ្នែកសំខាន់គឺរួចរាល់ (កំណែដំបូង) ។ មានការចេញផ្សាយនៅក្នុងខែកញ្ញា។

ក្នុង៖ - កន្លែងដែលអ្នកពិពណ៌នាអំពី SSE អ្នកមិនប្រើអស់ពេលទេ។ ហេតុអ្វីបានជាអញ្ចឹង?

MS៖ - និយាយឱ្យត្រង់ទៅ SSE នៅតែជាពិធីការ html5៖ ស្តង់ដារ SSE ត្រូវបានរចនាឡើងដើម្បីទាក់ទងជាមួយកម្មវិធីរុករកតាមអ៊ីនធឺណិត តាមដែលខ្ញុំយល់។ វាមានមុខងារបន្ថែមដើម្បីឱ្យកម្មវិធីរុករកអាចភ្ជាប់ឡើងវិញបាន (ហើយដូច្នេះនៅលើ) ប៉ុន្តែយើងមិនត្រូវការវាទេ ព្រោះយើងមានអតិថិជនដែលអាចអនុវត្តតក្កវិជ្ជាណាមួយសម្រាប់ភ្ជាប់ និងទទួលព័ត៌មាន។ យើងមិនបានបង្កើត SSE ទេ ប៉ុន្តែជាអ្វីដែលស្រដៀងនឹង SSE។ នេះមិនមែនជាពិធីការខ្លួនឯងទេ។
មិនមានតម្រូវការទេ។ តាមខ្ញុំយល់ អតិថិជនបានអនុវត្តយន្តការនៃការតភ្ជាប់ស្ទើរតែពីដំបូង។ ពួកគេពិតជាមិនខ្វល់ទេ។

ក្នុង៖ - តើអ្នកបានប្រើឧបករណ៍បន្ថែមអ្វីខ្លះ?

MS៖ - យើងបានប្រើប្រាស់យ៉ាងសកម្មបំផុតនូវ govet និង golint ដើម្បីធ្វើឱ្យរចនាប័ទ្មបង្រួបបង្រួម ក៏ដូចជា gofmt ។ គ្មានអ្វីផ្សេងទៀតត្រូវបានប្រើទេ។

ក្នុង៖ - តើអ្នកប្រើអ្វីដើម្បីបំបាត់កំហុស?

MS៖ - ការបំបាត់កំហុសត្រូវបានអនុវត្តយ៉ាងទូលំទូលាយដោយប្រើការធ្វើតេស្ត។ យើងមិនបានប្រើកម្មវិធីបំបាត់កំហុស ឬ GOP ទេ។

ក្នុង៖ – តើអ្នកអាចត្រឡប់ស្លាយដែលមុខងារបោះពុម្ពត្រូវបានអនុវត្តបានទេ? តើឈ្មោះអថេរដែលមានអក្សរតែមួយច្រឡំអ្នកទេ?

MS៖ - ទេ។ ពួកគេមានវិសាលភាព "តូចចង្អៀត" នៃភាពមើលឃើញ។ ពួកវាមិនត្រូវបានប្រើនៅកន្លែងផ្សេងទៀតទេលើកលែងតែនៅទីនេះ (លើកលែងតែផ្នែកខាងក្នុងនៃថ្នាក់នេះ) ហើយវាតូចណាស់ - វាត្រូវការត្រឹមតែ 7 ជួរប៉ុណ្ណោះ។

ក្នុង៖ - ដូចម្ដេចវានៅតែមិនវិចារណញាណ ...

MS៖ - អត់ទេ នេះជាលេខកូដពិត! វាមិនមែននិយាយអំពីរចនាប័ទ្មទេ។ វាគ្រាន់តែជា utilitarian, ថ្នាក់តូចណាស់ - មានតែ 3 វាលនៅក្នុងថ្នាក់ ...

MS៖ - ជាទូទៅ ទិន្នន័យទាំងអស់ដែលធ្វើសមកាលកម្មជាមួយអតិថិជន (ការប្រកួតតាមរដូវកាល អ្នកលេង) មិនផ្លាស់ប្តូរទេ។ និយាយដោយប្រយោល ប្រសិនបើយើងបង្កើតកីឡាមួយផ្សេងទៀតដែលយើងត្រូវការផ្លាស់ប្តូរការប្រកួត យើងនឹងយកអ្វីគ្រប់យ៉ាងទៅក្នុងគណនីកំណែថ្មីរបស់អតិថិជន ហើយកំណែចាស់របស់អតិថិជននឹងត្រូវបានហាមឃាត់។

ក្នុង៖ - តើមានកញ្ចប់គ្រប់គ្រងភាពអាស្រ័យរបស់ភាគីទីបីទេ?

MS៖ - យើងបានប្រើ go dep ។

ក្នុង៖ - មានអ្វីមួយអំពីវីដេអូនៅក្នុងប្រធានបទនៃរបាយការណ៍ ប៉ុន្តែមិនមានអ្វីនៅក្នុងរបាយការណ៍អំពីវីដេអូនោះទេ។

MS៖ - ទេ ខ្ញុំមិនមានអ្វីនៅក្នុងប្រធានបទអំពីវីដេអូនោះទេ។ វាត្រូវបានគេហៅថា "Look+" - នោះគឺជាឈ្មោះនៃកម្មវិធី។

ក្នុង៖ - អ្នកបាននិយាយថាវាត្រូវបានចាក់ទៅអតិថិជន? ..

MS៖ – យើងមិនបានពាក់ព័ន្ធនឹងការផ្សាយវីដេអូទេ។ នេះត្រូវបានធ្វើទាំងស្រុងដោយ Megafon ។ បាទ ខ្ញុំមិនបាននិយាយថាកម្មវិធីគឺ MegaFon ទេ។

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

ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, cloud VPS សម្រាប់អ្នកអភិវឌ្ឍន៍ចាប់ពី $4.99, analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ ការពិតទាំងមូលអំពី VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ចាប់ពី $19 ឬរបៀបចែករំលែកម៉ាស៊ីនមេ? (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។

Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ចាប់ពី $199 នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អានអំពី របៀបបង្កើតក្រុមហ៊ុនហេដ្ឋារចនាសម្ព័ន្ធ ថ្នាក់ជាមួយនឹងការប្រើប្រាស់ម៉ាស៊ីនមេ Dell R730xd E5-2650 v4 ដែលមានតម្លៃ 9000 អឺរ៉ូសម្រាប់មួយកាក់?

ប្រភព: www.habr.com

លោក Mikhail Salosin ។ កិច្ចប្រជុំ Golang ។ ការប្រើប្រាស់ Go នៅក្នុងផ្នែកខាងក្រោយនៃកម្មវិធី Look+