ក្រឡាចត្រង្គសេវាកម្មបញ្ឆេះ - ចាប់ផ្ដើមឡើងវិញ

នៅថ្ងៃទី 26 ខែកុម្ភៈ យើងបានរៀបចំកិច្ចប្រជុំ Apache Ignite GreenSource ដែលជាកន្លែងដែលអ្នករួមចំណែកដល់គម្រោងប្រភពបើកចំហបាននិយាយ កម្មវិធី Apache Ignite. ព្រឹត្តិការណ៍ដ៏សំខាន់មួយនៅក្នុងជីវិតរបស់សហគមន៍នេះគឺការរៀបចំរចនាសម្ព័ន្ធឡើងវិញនៃសមាសភាគ បណ្តាញសេវាកម្មបញ្ឆេះដែលអនុញ្ញាតឱ្យអ្នកដាក់ពង្រាយសេវាកម្មមីក្រូផ្ទាល់ខ្លួនដោយផ្ទាល់ទៅក្នុងចង្កោម Ignite ។ គាត់បាននិយាយអំពីដំណើរការដ៏លំបាកនេះនៅឯកិច្ចប្រជុំ Vyacheslav Daradurវិស្វករកម្មវិធី និងជាអ្នករួមចំណែក Apache Ignite អស់រយៈពេលជាងពីរឆ្នាំ។

ចូរចាប់ផ្តើមជាមួយនឹងអ្វីដែល Apache Ignite ជាទូទៅ។ នេះគឺជាឃ្លាំងផ្ទុកទិន្នន័យដែលចែកចាយ Key/Value ដោយមានការគាំទ្រសម្រាប់ SQL ប្រតិបត្តិការ និងឃ្លាំងសម្ងាត់។ លើសពីនេះទៀត Ignite អនុញ្ញាតឱ្យអ្នកដាក់ពង្រាយសេវាកម្មផ្ទាល់ខ្លួនដោយផ្ទាល់ទៅក្នុងចង្កោម Ignite ។ អ្នកអភិវឌ្ឍន៍មានសិទ្ធិចូលប្រើឧបករណ៍ទាំងអស់ដែល Ignite ផ្តល់ឲ្យ - រចនាសម្ព័ន្ធទិន្នន័យចែកចាយ ការផ្ញើសារ ការស្ទ្រីម ការគណនា និងបណ្តាញទិន្នន័យ។ ជាឧទាហរណ៍ នៅពេលប្រើប្រាស់ Data Grid បញ្ហានៃការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធដាច់ដោយឡែកសម្រាប់ការផ្ទុកទិន្នន័យ ហើយជាលទ្ធផល ការចំណាយលើសត្រូវបាត់ទៅវិញ។

ដោយប្រើ Service Grid API អ្នកអាចដាក់ឱ្យប្រើប្រាស់សេវាកម្មមួយដោយគ្រាន់តែបញ្ជាក់គ្រោងការណ៍នៃការដាក់ពង្រាយ ហើយតាមនោះ សេវាកម្មខ្លួនវានៅក្នុងការកំណត់រចនាសម្ព័ន្ធ។

ជាធម្មតា គ្រោងការណ៍ដាក់ពង្រាយគឺជាការបង្ហាញពីចំនួននៃករណីដែលគួរតែត្រូវបានដាក់ឱ្យប្រើប្រាស់នៅលើថ្នាំងចង្កោម។ មានគ្រោងការណ៍ដាក់ពង្រាយធម្មតាពីរ។ ទីមួយគឺ Cluster Singleton៖ នៅពេលវេលាណាមួយ វត្ថុមួយនៃសេវាកម្មអ្នកប្រើប្រាស់ត្រូវបានធានាថាមាននៅក្នុងចង្កោម។ ទីពីរគឺ Node Singleton៖ សេវាកម្មមួយត្រូវបានដាក់ពង្រាយនៅលើ node cluster នីមួយៗ។

អ្នក​ប្រើ​ក៏​អាច​បញ្ជាក់​ចំនួន​នៃ​សេវាកម្ម​ក្នុង​ចង្កោម​ទាំងមូល និង​កំណត់​ព្យាករណ៍​សម្រាប់​ត្រង​ថ្នាំង​ដែល​សមរម្យ។ នៅក្នុងសេណារីយ៉ូនេះ Service Grid ខ្លួនវានឹងគណនាការចែកចាយដ៏ប្រសើរបំផុតសម្រាប់ការដាក់ពង្រាយសេវាកម្ម។

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

ឥឡូវ​យើង​បាន​រក​ឃើញ​ថា​អ្វី​ជា​សោភ័ណភាព​នៃ Service Grid សូម​និយាយ​អំពី​ប្រវត្តិ​នៃ​ការ​អភិវឌ្ឍ​របស់​វា។

តើមានអ្វីកើតឡើងពីមុន

ការអនុវត្តពីមុននៃ Service Grid គឺផ្អែកលើឃ្លាំងសម្ងាត់ប្រព័ន្ធចម្លងប្រតិបត្តិការរបស់ Ignite ។ ពាក្យ "ឃ្លាំងសម្ងាត់" នៅក្នុង Ignite សំដៅលើការផ្ទុក។ នោះ​គឺ នេះ​មិន​មែន​ជា​រឿង​បណ្ដោះអាសន្ន ដូច​ដែល​អ្នក​គិត​នោះ​ទេ។ ទោះបីជាការពិតដែលថាឃ្លាំងសម្ងាត់ត្រូវបានចម្លងហើយថ្នាំងនីមួយៗមានសំណុំទិន្នន័យទាំងមូលក៏ដោយនៅខាងក្នុងឃ្លាំងសម្ងាត់វាមានតំណាងចែក។ នេះគឺដោយសារតែការបង្កើនប្រសិទ្ធភាពការផ្ទុក។

តើមានអ្វីកើតឡើង នៅពេលដែលអ្នកប្រើប្រាស់ចង់ដាក់ឱ្យប្រើប្រាស់សេវាកម្មនេះ?

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

អ្វីដែលមិនសមនឹងយើង

នៅចំណុចខ្លះយើងបានឈានដល់ការសន្និដ្ឋាន: នេះមិនមែនជាវិធីដើម្បីធ្វើការជាមួយសេវាកម្មទេ។ មានហេតុផលជាច្រើន។

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

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

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

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

បញ្ហា

តើអ្វីជាការផ្លាស់ប្តូរសកលដោយគ្មានបញ្ហា? ទីមួយនៃទាំងនេះគឺជាការផ្លាស់ប្តូរនៅក្នុង topology ។ អ្នក​ត្រូវ​យល់​ថា នៅ​ពេល​ណា​មួយ សូម្បី​តែ​នៅ​ពេល​នៃ​ការ​ដាក់​ឱ្យ​ប្រើ​សេវា ថ្នាំង​អាច​ចូល ឬ​ចាក​ចេញ​ពី​ចង្កោម។ លើសពីនេះទៅទៀត ប្រសិនបើនៅពេលដាក់ពង្រាយ node ចូលរួមជាមួយ cluster វានឹងចាំបាច់ក្នុងការផ្ទេរព័ត៌មានទាំងអស់អំពីសេវាកម្មទៅកាន់ node ថ្មី។ ហើយ​យើង​កំពុង​និយាយ​មិន​ត្រឹម​តែ​អំពី​អ្វី​ដែល​ត្រូវ​បាន​ដាក់​ពង្រាយ​រួច​ហើយ​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​ក៏​អំពី​ការ​ដាក់​ពង្រាយ​បច្ចុប្បន្ន និង​អនាគត​ផង​ដែរ។

នេះគ្រាន់តែជាបញ្ហាមួយប៉ុណ្ណោះដែលអាចប្រមូលបានក្នុងបញ្ជីដាច់ដោយឡែកមួយ៖

• តើធ្វើដូចម្តេចដើម្បីដាក់ពង្រាយសេវាកម្មដែលបានកំណត់រចនាសម្ព័ន្ធឋិតិវន្តនៅពេលចាប់ផ្តើមថ្នាំង?
• ការចាកចេញពី node ពី cluster - អ្វីដែលត្រូវធ្វើប្រសិនបើ node host services?
• អ្វីដែលត្រូវធ្វើប្រសិនបើអ្នកសម្របសម្រួលបានផ្លាស់ប្តូរ?
• អ្វីដែលត្រូវធ្វើប្រសិនបើម៉ាស៊ីនភ្ញៀវភ្ជាប់ទៅចង្កោមឡើងវិញ?
• តើ​ការ​ធ្វើ​ឱ្យ​សកម្ម/ការ​បិទ​សំណើ​ត្រូវ​ដំណើរការ​ហើយ​ដោយ​របៀប​ណា?
• ចុះប្រសិនបើពួកគេអំពាវនាវឱ្យមានការបំផ្លាញឃ្លាំងសម្ងាត់ ហើយយើងមានសេវាកម្មទាក់ទងគ្នានឹងវា?

ហើយនោះមិនមែនទាំងអស់ទេ។

ការសម្រេចចិត្ត

ជាគោលដៅ យើងបានជ្រើសរើសវិធីសាស្រ្តជំរុញព្រឹត្តិការណ៍ជាមួយនឹងការអនុវត្តទំនាក់ទំនងដំណើរការដោយប្រើសារ។ Ignite បានអនុវត្តសមាសធាតុពីររួចហើយដែលអនុញ្ញាតឱ្យថ្នាំងបញ្ជូនសារក្នុងចំណោមពួកគេ - ទំនាក់ទំនង-spi និង discovery-spi ។

Communication-spi អនុញ្ញាតឱ្យថ្នាំងទំនាក់ទំនងដោយផ្ទាល់ និងបញ្ជូនសារ។ វា​ស័ក្តិសម​សម្រាប់​ការ​ផ្ញើ​ទិន្នន័យ​ក្នុង​បរិមាណ​ដ៏ច្រើន​។ Discovery-spi អនុញ្ញាតឱ្យអ្នកផ្ញើសារទៅកាន់ថ្នាំងទាំងអស់នៅក្នុងចង្កោម។ នៅក្នុងការអនុវត្តស្ដង់ដារ នេះត្រូវបានធ្វើដោយប្រើ ring topology ។ វាក៏មានការរួមបញ្ចូលជាមួយ Zookeeper ផងដែរក្នុងករណីនេះ topology ផ្កាយត្រូវបានប្រើ។ ចំណុចសំខាន់មួយទៀតដែលគួរកត់សម្គាល់នោះគឺថា discovery-spi ផ្តល់នូវការធានាថា សារនឹងពិតជាត្រូវបានបញ្ជូនតាមលំដាប់ត្រឹមត្រូវទៅកាន់គ្រប់ថ្នាំងទាំងអស់។

សូមក្រឡេកមើលពិធីការដាក់ពង្រាយ។ សំណើរបស់អ្នកប្រើប្រាស់ទាំងអស់សម្រាប់ការដាក់ពង្រាយ និងការមិនដាក់ឱ្យដំណើរការត្រូវបានផ្ញើតាមរយៈ discovery-spi ។ នេះផ្តល់ឱ្យដូចខាងក្រោម ការធានា:

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

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

សំណើទាំងអស់ពីជួរត្រូវបានដំណើរការដោយអ្នកគ្រប់គ្រងការដាក់ពង្រាយ។ វា​មាន​បុគ្គលិក​ពិសេស​ម្នាក់​ដែល​ទាញ​កិច្ចការ​ពី​ជួរ​នេះ ហើយ​ចាប់ផ្តើម​វា​ដើម្បី​ចាប់​ផ្តើម​ដាក់​ពង្រាយ។ បន្ទាប់ពីនេះសកម្មភាពដូចខាងក្រោមកើតឡើង:

1. ថ្នាំងនីមួយៗគណនាការបែងចែកដោយឯករាជ្យដោយអរគុណចំពោះមុខងារកំណត់ការកំណត់ថ្មី។
2. ថ្នាំងបង្កើតសារជាមួយនឹងលទ្ធផលនៃការដាក់ពង្រាយ ហើយផ្ញើវាទៅអ្នកសម្របសម្រួល។
3. អ្នកសម្របសម្រួលប្រមូលផ្តុំសារទាំងអស់ និងបង្កើតលទ្ធផលនៃដំណើរការដាក់ពង្រាយទាំងមូល ដែលត្រូវបានផ្ញើតាមរយៈ discovery-spi ទៅកាន់ថ្នាំងទាំងអស់នៅក្នុងចង្កោម។
4. នៅពេលទទួលបានលទ្ធផល ដំណើរការដាក់ពង្រាយត្រូវបញ្ចប់ បន្ទាប់ពីនោះកិច្ចការត្រូវបានដកចេញពីជួរ។

ការរចនាដែលជំរុញដោយព្រឹត្តិការណ៍ថ្មី៖ org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

ប្រសិនបើកំហុសកើតឡើងកំឡុងពេលដាក់ពង្រាយ ថ្នាំងភ្លាមៗរួមបញ្ចូលកំហុសនេះនៅក្នុងសារដែលវាផ្ញើទៅអ្នកសម្របសម្រួល។ បន្ទាប់ពីការប្រមូលផ្តុំសារ អ្នកសម្របសម្រួលនឹងមានព័ត៌មានអំពីកំហុសទាំងអស់ក្នុងអំឡុងពេលដាក់ឱ្យប្រើប្រាស់ ហើយនឹងផ្ញើសារនេះតាមរយៈ discovery-spi ។ ព័ត៌មានអំពីបញ្ហានឹងមាននៅលើថ្នាំងណាមួយនៅក្នុងចង្កោម។

ព្រឹត្តិការណ៍សំខាន់ៗទាំងអស់នៅក្នុង Service Grid ត្រូវបានដំណើរការដោយប្រើក្បួនដោះស្រាយប្រតិបត្តិការនេះ។ ឧទាហរណ៍ ការផ្លាស់ប្តូរ topology ក៏ជាសារតាមរយៈ discovery-spi ផងដែរ។ ហើយជាទូទៅ បើប្រៀបធៀបជាមួយនឹងអ្វីដែលពីមុន ពិធីការបានប្រែទៅជាស្រាល និងអាចទុកចិត្តបាន។ គ្រប់គ្រាន់ដើម្បីដោះស្រាយស្ថានភាពណាមួយក្នុងអំឡុងពេលដាក់ពង្រាយ។

តើនឹងមានអ្វីកើតឡើងបន្ទាប់

ឥឡូវនេះអំពីផែនការ។ ការផ្លាស់ប្តូរដ៏សំខាន់ណាមួយចំពោះគម្រោង Ignite ត្រូវបានបញ្ចប់ជាគំនិតផ្តួចផ្តើមកែលម្អ Ignite ដែលហៅថា IEP ។ ការរចនាក្រឡាចត្រង្គសេវាកម្មឡើងវិញក៏មាន IEP ផងដែរ - IEP #17 ជាមួយនឹងចំណងជើងចំអកថា "ការផ្លាស់ប្តូរប្រេងនៅក្នុងក្រឡាចត្រង្គសេវាកម្ម" ។ ប៉ុន្តែ​តាម​ពិត យើង​មិន​បាន​ប្តូរ​ប្រេង​ម៉ាស៊ីន​ទេ ប៉ុន្តែ​ជា​ម៉ាស៊ីន​ទាំងមូល។

យើងបានបែងចែកភារកិច្ចនៅក្នុង IEP ជា 2 ដំណាក់កាល។ ទីមួយគឺជាដំណាក់កាលសំខាន់មួយ ដែលរួមមានការដំណើរការឡើងវិញនូវពិធីការដាក់ពង្រាយ។ វាត្រូវបានរួមបញ្ចូលនៅក្នុងមេរួចហើយ អ្នកអាចសាកល្បង Service Grid ថ្មីដែលនឹងបង្ហាញនៅក្នុងកំណែ 2.8។ ដំណាក់កាលទី ២ រួមមានការងារជាច្រើនទៀត៖

• ការដាក់ឱ្យដំណើរការឡើងវិញក្តៅ
• កំណែសេវាកម្ម
• បង្កើនការអត់ធ្មត់ចំពោះកំហុស
• អតិថិជនស្តើង
• ឧបករណ៍សម្រាប់ត្រួតពិនិត្យ និងគណនាម៉ែត្រផ្សេងៗ

ជាចុងក្រោយ យើងអាចណែនាំអ្នកអំពី Service Grid សម្រាប់ការកសាងប្រព័ន្ធដែលមានភាពធន់នឹងកំហុស និងមានភាពអាចរកបានខ្ពស់។ យើងក៏សូមអញ្ជើញអ្នកឱ្យមកលេងយើងនៅ dev-បញ្ជី и បញ្ជីអ្នកប្រើប្រាស់ ចែករំលែកបទពិសោធន៍របស់អ្នក។ បទពិសោធន៍របស់អ្នកពិតជាមានសារៈសំខាន់សម្រាប់សហគមន៍ វានឹងជួយអ្នកឱ្យយល់ពីកន្លែងដែលត្រូវផ្លាស់ទីបន្ទាប់ របៀបអភិវឌ្ឍសមាសធាតុនាពេលអនាគត។

ប្រភព: www.habr.com