សន្និសីទ QCon ។ ភាពវឹកវរ Mastering: មគ្គុទ្ទេស Netflix ទៅកាន់ Microservices ។ ផ្នែកទី 4

Josh Evans និយាយអំពីពិភពដ៏ច្របូកច្របល់ និងចម្រុះពណ៌នៃសេវាកម្មមីក្រូ Netflix ដោយចាប់ផ្តើមពីមូលដ្ឋានគ្រឹះ - កាយវិភាគសាស្ត្រនៃសេវាកម្មខ្នាតតូច បញ្ហាប្រឈមដែលទាក់ទងនឹងប្រព័ន្ធចែកចាយ និងអត្ថប្រយោជន៍របស់វា។ ដោយផ្អែកលើមូលដ្ឋាននេះ គាត់ស្វែងយល់ពីការអនុវត្តវប្បធម៌ ស្ថាបត្យកម្ម និងប្រតិបត្តិការដែលនាំទៅដល់ជំនាញផ្នែកសេវាកម្មខ្នាតតូច។

សន្និសីទ QCon ។ ភាពវឹកវរ Mastering: មគ្គុទ្ទេស Netflix ទៅកាន់ Microservices ។ ផ្នែកទី 1
សន្និសីទ QCon ។ ភាពវឹកវរ Mastering: មគ្គុទ្ទេស Netflix ទៅកាន់ Microservices ។ ផ្នែកទី 2
សន្និសីទ QCon ។ ភាពវឹកវរ Mastering: មគ្គុទ្ទេស Netflix ទៅកាន់ Microservices ។ ផ្នែកទី 3

មិនដូចការរសាត់នៃប្រតិបត្តិការទេ ការដាក់ឱ្យប្រើប្រាស់ភាសាថ្មីសម្រាប់សេវាអន្តរជាតិភាវូបនីយកម្ម និងបច្ចេកវិទ្យាថ្មីៗដូចជាកុងតឺន័រ គឺជាការសម្រេចចិត្តដោយមនសិការដើម្បីបន្ថែមភាពស្មុគស្មាញថ្មីដល់បរិស្ថាន។ ក្រុមប្រតិបត្តិការរបស់ខ្ញុំបានធ្វើស្តង់ដារលើផែនទីបង្ហាញផ្លូវបច្ចេកវិទ្យាល្អបំផុតសម្រាប់ Netflix ដែលត្រូវបានបញ្ចូលទៅក្នុងការអនុវត្តល្អបំផុតដែលបានកំណត់ជាមុនដោយផ្អែកលើ Java និង EC2 ប៉ុន្តែនៅពេលដែលអាជីវកម្មរីកចម្រើន អ្នកអភិវឌ្ឍន៍បានចាប់ផ្តើមបន្ថែមសមាសធាតុថ្មីដូចជា Python, Ruby, Node-JS និង Docker ។

ខ្ញុំពិតជាមានមោទនភាពណាស់ដែលពួកយើងជាអ្នកតស៊ូមតិដំបូងដើម្បីអោយផលិតផលរបស់យើងដំណើរការបានល្អដោយមិនរង់ចាំការតវ៉ារបស់អតិថិជន។ វាទាំងអស់បានចាប់ផ្តើមដោយសាមញ្ញគ្រប់គ្រាន់ - យើងមានកម្មវិធីប្រតិបត្តិការនៅក្នុង Python និងកម្មវិធី back-office មួយចំនួននៅក្នុង Ruby ប៉ុន្តែអ្វីដែលកាន់តែចាប់អារម្មណ៍នៅពេលដែលអ្នកបង្កើតគេហទំព័ររបស់យើងបានប្រកាសថាពួកគេនឹងបោះបង់ចោល JVM ហើយនឹងផ្លាស់ទីគេហទំព័រ។ កម្មវិធីទៅកាន់ Node software platform. js. បន្ទាប់ពីការណែនាំ Docker អ្វីៗកាន់តែស្មុគស្មាញ។ យើងបានធ្វើតាមតក្កវិជ្ជា ហើយបច្ចេកវិទ្យាដែលយើងបង្កើតមកបានក្លាយជាការពិត នៅពេលដែលយើងអនុវត្តវាសម្រាប់អតិថិជន ព្រោះវាមានប្រយោជន៍ច្រើន។ ខ្ញុំ​នឹង​ប្រាប់​អ្នក​ថា​ហេតុ​អ្វី​បាន​ជា​ដូច្នេះ។

API Gateway ពិតជាមានសមត្ថភាពក្នុងការរួមបញ្ចូលស្គ្រីបដ៏អស្ចារ្យដែលអាចដើរតួជាចំណុចបញ្ចប់សម្រាប់អ្នកអភិវឌ្ឍន៍ UI ។ ពួកគេបានបំប្លែងស្គ្រីបទាំងនេះនីមួយៗតាមរបៀបដែលបន្ទាប់ពីធ្វើការផ្លាស់ប្តូរ ពួកគេអាចដាក់ពង្រាយពួកវាទៅផលិតកម្ម ហើយបន្ទាប់មកទៅកាន់ឧបករណ៍អ្នកប្រើប្រាស់ ហើយការផ្លាស់ប្តូរទាំងអស់នេះត្រូវបានធ្វើសមកាលកម្មជាមួយនឹងចំណុចបញ្ចប់ដែលដំណើរការនៅក្នុង API gateway។

ទោះជាយ៉ាងណាក៏ដោយ នេះបានកើតឡើងម្តងទៀតនូវបញ្ហានៃការបង្កើត monolith ថ្មីដែលសេវា API ត្រូវបានផ្ទុកលើសទម្ងន់ជាមួយនឹងកូដតាមរបៀបដែលសេណារីយ៉ូបរាជ័យផ្សេងៗបានកើតឡើង។ ឧទាហរណ៍ ចំណុចបញ្ចប់មួយចំនួនត្រូវបានដកចេញ ឬស្គ្រីបបានបង្កើតដោយចៃដន្យនូវកំណែជាច្រើននៃអ្វីមួយដែលកំណែទាំងនោះយកអង្គចងចាំដែលមានទាំងអស់នៃសេវាកម្ម API ។

វាសមហេតុផលក្នុងការយកចំណុចបញ្ចប់ទាំងនេះ ហើយទាញវាចេញពីសេវាកម្ម API ។ ដើម្បីធ្វើដូច្នេះ យើងបានបង្កើតសមាសធាតុ Node.js ដែលដំណើរការជាកម្មវិធីតូចៗនៅក្នុង Docker containers។ វាអនុញ្ញាតឱ្យយើងញែកបញ្ហា និងការគាំងណាមួយដែលបណ្តាលមកពីកម្មវិធីថ្នាំងទាំងនេះ។

តម្លៃនៃការផ្លាស់ប្តូរទាំងនេះគឺធំណាស់ ហើយមានកត្តាដូចខាងក្រោមៈ

• ឧបករណ៍ផលិតភាព។ ការគ្រប់គ្រងបច្ចេកវិជ្ជាថ្មី ទាមទារឧបករណ៍ថ្មី ពីព្រោះក្រុម UI ប្រើស្គ្រីបល្អៗ ដើម្បីបង្កើតគំរូប្រកបដោយប្រសិទ្ធភាព មិនចាំបាច់ចំណាយពេលច្រើនក្នុងការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធទេ ពួកគេគ្រាន់តែសរសេរស្គ្រីប និងពិនិត្យមើលមុខងាររបស់វា។
  Opportunity Insight and Sorting - ឧទាហរណ៍សំខាន់គឺឧបករណ៍ថ្មីដែលត្រូវការដើម្បីបង្ហាញព័ត៌មានអំពីដំណើរការកម្មវិធីបញ្ជា។ វាចាំបាច់ក្នុងការដឹងពីចំនួន processor ត្រូវបានកាន់កាប់ របៀបដែលអង្គចងចាំត្រូវបានប្រើប្រាស់ និងការប្រមូលព័ត៌មាននេះតម្រូវឱ្យមានឧបករណ៍ផ្សេងៗ។
• ការបែកខ្ញែកនៃរូបភាពមូលដ្ឋាន - AMI មូលដ្ឋានសាមញ្ញបានក្លាយទៅជាការបែងចែក និងឯកទេសកាន់តែច្រើន។
• ការគ្រប់គ្រងថ្នាំង។ មិនមានស្ថាបត្យកម្ម ឬបច្ចេកវិទ្យាក្រៅធ្នើដែលអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងថ្នាំងក្នុងពពកទេ ដូច្នេះយើងបានបង្កើត Titus ដែលជាវេទិកាគ្រប់គ្រងកុងតឺន័រដែលផ្តល់នូវការដាក់ពង្រាយកុងតឺន័រដែលអាចទុកចិត្តបាន និងអាចទុកចិត្តបាន និងការរួមបញ្ចូលពពកជាមួយ Amazon AWS ។
• ការចម្លងនៃបណ្ណាល័យ ឬវេទិកា។ ការផ្តល់បច្ចេកវិទ្យាថ្មីជាមួយនឹងមុខងារស្នូលដូចគ្នានៃវេទិកាតម្រូវឱ្យចម្លងវាទៅក្នុងឧបករណ៍អ្នកអភិវឌ្ឍន៍ Node.js ដែលមានមូលដ្ឋានលើពពក។
• ខ្សែកោងការសិក្សា និងបទពិសោធន៍ឧស្សាហកម្ម។ ការណែនាំអំពីបច្ចេកវិទ្យាថ្មីៗ បង្កើតនូវបញ្ហាប្រឈមថ្មីៗដែលត្រូវតែជំនះ និងរៀនពីវា។

ដូច្នេះហើយ យើងមិនអាចដាក់កម្រិតខ្លួនយើងចំពោះ "ផ្លូវក្រាលកៅស៊ូ" មួយបានទេ ហើយត្រូវបង្កើតវិធីថ្មីៗជានិច្ច ដើម្បីជំរុញបច្ចេកវិទ្យារបស់យើង។ ដើម្បីរក្សាការចំណាយធ្លាក់ចុះ យើងបានកំណត់ការគាំទ្រផ្នែកកណ្តាល ហើយផ្តោតលើ JVM ថ្នាំងថ្មី និង Docker ។ យើងបានផ្តល់អាទិភាពដល់ផលប៉ះពាល់ប្រកបដោយប្រសិទ្ធភាព ជូនដំណឹងដល់ក្រុមអំពីតម្លៃនៃការសម្រេចចិត្តរបស់ពួកគេ និងបានលើកទឹកចិត្តពួកគេឱ្យស្វែងរកមធ្យោបាយដើម្បីប្រើប្រាស់ឡើងវិញនូវដំណោះស្រាយដែលមានឥទ្ធិពលខ្ពស់ដែលពួកគេបានបង្កើតរួចហើយ។ យើងបានប្រើវិធីសាស្រ្តនេះនៅពេលបកប្រែសេវាកម្មទៅជាភាសាបរទេសដើម្បីចែកចាយផលិតផលទៅកាន់អតិថិជនអន្តរជាតិ។ ឧទាហរណ៍រួមមាន បណ្ណាល័យម៉ាស៊ីនភ្ញៀវសាមញ្ញ ដែលអាចត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ ដូច្នេះវាងាយស្រួលក្នុងការបង្កើតកំណែ Python កំណែ Ruby កំណែ Java ជាដើម។

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

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

តើយើងអាចសម្រេចបាននូវល្បឿនខ្ពស់នៃការអនុវត្តការច្នៃប្រឌិតផ្នែកទន់ ពោលគឺធ្វើការផ្លាស់ប្តូរថ្មីឥតឈប់ឈរចំពោះប្រព័ន្ធ ដោយមិនបង្កឱ្យមានការរំខានក្នុងការផ្តល់សេវា និងដោយមិនបង្កើតការរអាក់រអួលដល់អតិថិជនរបស់យើងដោយរបៀបណា? ក្រុមហ៊ុន Netflix សម្រេចបានវាតាមរយៈការប្រើប្រាស់ Spinnaker ដែលជាប្រព័ន្ធគ្រប់គ្រងលើពពកសកលថ្មី និងការចែកចាយបន្ត (ស៊ីឌី) ។

ជាការរិះគន់ Spinnaker ត្រូវបានរចនាឡើងដើម្បីរួមបញ្ចូលការអនុវត្តល្អបំផុតរបស់យើង ដូច្នេះនៅពេលយើងដាក់ពង្រាយសមាសធាតុទៅក្នុងផលិតកម្ម យើងអាចបញ្ចូលលទ្ធផលដោយផ្ទាល់ទៅក្នុងបច្ចេកវិទ្យាចែកចាយប្រព័ន្ធផ្សព្វផ្សាយរបស់យើង។

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

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

នៅចុងបញ្ចប់នៃកិច្ចពិភាក្សា ខ្ញុំនឹងនិយាយដោយសង្ខេបអំពីអង្គការ និងស្ថាបត្យកម្មរបស់ក្រុមហ៊ុន Netflix Inc ។ នៅដើមដំបូង យើងមានគ្រោងការណ៍មួយហៅថា Electronic Delivery ដែលជាកំណែដំបូងនៃ NRDP 1.x media streaming ។ ពាក្យ "backstream" អាចត្រូវបានប្រើនៅទីនេះ ពីព្រោះដំបូងឡើយ អ្នកប្រើប្រាស់អាចទាញយកតែមាតិកាសម្រាប់ការចាក់សារថ្មីនៅពេលក្រោយនៅលើឧបករណ៍ប៉ុណ្ណោះ។ វេទិកាចែកចាយឌីជីថលដំបូងបង្អស់របស់ Netflix ត្រឡប់មកវិញក្នុងឆ្នាំ 2009 មើលទៅដូចនេះ។

ឧបករណ៍អ្នកប្រើប្រាស់មានកម្មវិធី Netflix ដែលមានចំណុចប្រទាក់ UI ម៉ូឌុលសុវត្ថិភាព ការបើកដំណើរការសេវាកម្ម និងការចាក់សារថ្មី ដោយផ្អែកលើវេទិកា NRDP - Netflix Ready Device Platform ។

នៅពេលនោះចំណុចប្រទាក់អ្នកប្រើគឺសាមញ្ញណាស់។ វាផ្ទុកនូវអ្វីដែលហៅថា Queque Reader ហើយអ្នកប្រើប្រាស់នឹងចូលទៅកាន់គេហទំព័រដើម្បីបន្ថែមអ្វីមួយទៅ Queque ហើយបន្ទាប់មកមើលមាតិកាដែលបានបន្ថែមនៅលើឧបករណ៍របស់ពួកគេ។ ភាពវិជ្ជមានគឺថាក្រុមខាងមុខ និងក្រុមខាងក្រោយជាកម្មសិទ្ធិរបស់អង្គការចែកចាយអេឡិចត្រូនិកដូចគ្នា ហើយមានទំនាក់ទំនងការងារជិតស្និទ្ធ។ បន្ទុកត្រូវបានបង្កើតឡើងដោយផ្អែកលើ XML ។ ក្នុងពេលជាមួយគ្នានេះដែរ Netflix API សម្រាប់អាជីវកម្មឌីវីឌីត្រូវបានបង្កើតឡើង ដែលជំរុញឱ្យកម្មវិធីភាគីទីបីដឹកនាំចរាចរទៅកាន់សេវាកម្មរបស់យើង។

ទោះជាយ៉ាងណាក៏ដោយ Netflix API ត្រូវបានរៀបចំយ៉ាងល្អដើម្បីជួយយើងជាមួយនឹងចំណុចប្រទាក់អ្នកប្រើប្រកបដោយភាពច្នៃប្រឌិត ដែលមានផ្ទុកទិន្នន័យមេតានៃមាតិកាទាំងអស់ ព័ត៌មានអំពីភាពយន្តដែលអាចរកបាន ដែលបង្កើតសមត្ថភាពក្នុងការបង្កើតបញ្ជីមើល។ វាមាន REST API ទូទៅដោយផ្អែកលើគ្រោងការណ៍ JSON, HTTP Response Code, ដូចគ្នាដែលប្រើក្នុងស្ថាបត្យកម្មទំនើប និងគំរូសុវត្ថិភាព OAuth ដែលជាអ្វីដែលត្រូវបានទាមទារនៅពេលនោះសម្រាប់កម្មវិធីផ្នែកខាងមុខ។ វាធ្វើឱ្យវាអាចផ្លាស់ទីពីគំរូសាធារណៈនៃការចែកចាយមាតិកាស្ទ្រីមទៅជាឯកជនមួយ។

បញ្ហាជាមួយការផ្លាស់ប្តូរគឺការបែកខ្ញែក ដោយសារឥឡូវនេះប្រព័ន្ធរបស់យើងដំណើរការសេវាកម្មពីរដោយផ្អែកលើគោលការណ៍ផ្សេងគ្នាទាំងស្រុងនៃប្រតិបត្តិការ - មួយនៅលើ Rest, JSON និង OAuth មួយទៀតនៅលើ RPC, XML និងយន្តការសុវត្ថិភាពអ្នកប្រើប្រាស់ដោយផ្អែកលើប្រព័ន្ធសញ្ញាសម្ងាត់ NTBA ។ នេះគឺជាស្ថាបត្យកម្មកូនកាត់ដំបូងគេ។

វាមានជញ្ជាំងភ្លើងសំខាន់រវាងក្រុមទាំងពីររបស់យើង ពីព្រោះដំបូង API មិនបានធ្វើមាត្រដ្ឋានបានល្អជាមួយ NCCP ហើយនេះនាំឱ្យមានការកកិតរវាងក្រុម។ ភាពខុសគ្នាគឺនៅក្នុងសេវាកម្ម ពិធីការ សៀគ្វី ម៉ូឌុលសុវត្ថិភាព ហើយអ្នកអភិវឌ្ឍន៍ជារឿយៗត្រូវប្តូររវាងបរិបទខុសគ្នាទាំងស្រុង។

ក្នុងន័យនេះ ខ្ញុំបានសន្ទនាជាមួយវិស្វករជាន់ខ្ពស់ម្នាក់របស់ក្រុមហ៊ុន ដែលខ្ញុំបានសួរសំណួរថា "តើអ្វីទៅជាស្ថាបត្យកម្មរយៈពេលវែងត្រឹមត្រូវ?" ហើយគាត់បានសួរសំណួរតបវិញថា "អ្នកប្រហែលជាព្រួយបារម្ភជាងនេះទៅទៀត។ អំពីផលវិបាកនៃការរៀបចំ - តើមានអ្វីកើតឡើងប្រសិនបើយើងរួមបញ្ចូលរបស់ទាំងនេះ ហើយពួកគេបំបែកនូវអ្វីដែលយើងបានរៀនដើម្បីធ្វើបានល្អ? វិធីសាស្រ្តនេះគឺពាក់ព័ន្ធយ៉ាងខ្លាំងទៅនឹងច្បាប់របស់ Conway: "អង្គការដែលប្រព័ន្ធរចនាត្រូវបានរារាំងដោយការរចនាដែលចម្លងរចនាសម្ព័ន្ធទំនាក់ទំនងនៃអង្គការនោះ" ។ នេះ​ជា​និយមន័យ​អរូបី​ណាស់ ដូច្នេះ​ខ្ញុំ​ចូល​ចិត្ត​អ្វី​ដែល​ជាក់លាក់​ជាង​នេះ៖ "ផ្នែក​ណាមួយ​នៃ​កម្មវិធី​ដែល​ឆ្លុះ​បញ្ចាំង​ពី​រចនាសម្ព័ន្ធ​ស្ថាប័ន​ដែល​បាន​បង្កើត​វា"។ នេះជាសម្រង់ដែលខ្ញុំចូលចិត្តបំផុតពី Eric Raymond៖ "ប្រសិនបើអ្នកមានក្រុមអ្នកអភិវឌ្ឍន៍ចំនួនបួនដែលធ្វើការលើអ្នកចងក្រង នោះអ្នកនឹងបញ្ចប់ជាមួយនឹងកម្មវិធីចងក្រង 4-pass"។ ជាការប្រសើរណាស់ ក្រុមហ៊ុន Netflix មានកម្មវិធីចងក្រង 4-pass ហើយនោះជារបៀបដែលយើងធ្វើការ។

យើងអាចនិយាយបានថាក្នុងករណីនេះកន្ទុយកំពុងគ្រវីឆ្កែ។ អាទិភាពទីមួយរបស់យើងមិនមែនជាដំណោះស្រាយទេ ប៉ុន្តែជាអង្គការ វាគឺជាអង្គការដែលជំរុញស្ថាបត្យកម្មដែលយើងមាន។ បន្តិចម្ដងៗ ពីសេវាកម្ម hodgepodge យើងបានប្តូរទៅស្ថាបត្យកម្មដែលយើងហៅថា Blade Runner ពីព្រោះនៅទីនេះយើងកំពុងនិយាយអំពីសេវាកម្មគែម និងសមត្ថភាពរបស់ NCCP ក្នុងការបំបែក និងបញ្ចូលដោយផ្ទាល់ទៅក្នុងប្រូកស៊ី Zuul ច្រក API និងមុខងារដែលត្រូវគ្នា។ "បំណែក" ត្រូវ​បាន​ប្រែ​ក្លាយ​ទៅ​ជា​សេវា​ខ្នាត​តូច​ថ្មី​ដែល​មាន​សុវត្ថិភាព​កម្រិត​ខ្ពស់​ជាង​មុន ការ​ចាក់​ឡើងវិញ ការ​តម្រៀប​ទិន្នន័យ​ជាដើម។

ដូច្នេះ គេអាចនិយាយបានថា រចនាសម្ព័ន្ធនាយកដ្ឋាន និងសក្ដានុពលរបស់ក្រុមហ៊ុនដើរតួនាទីយ៉ាងសំខាន់ក្នុងការរៀបចំរចនាសម្ព័ន្ធប្រព័ន្ធ និងជាកត្តាជំរុញ ឬរារាំងការផ្លាស់ប្តូរ។ ស្ថាបត្យកម្ម Microservices មានលក្ខណៈស្មុគស្មាញ និងមានលក្ខណៈសរីរាង្គ ហើយសុខភាពរបស់វាគឺផ្អែកលើវិន័យ និងភាពវឹកវរដែលបានណែនាំ។

ការផ្សាយពាណិជ្ជកម្មតិចតួច

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, 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