ວິທີທີ່ພວກເຮົາສ້າງ cloud FaaS ພາຍໃນ Kubernetes ແລະຊະນະ Tinkoff hackathon

ເລີ່ມຕົ້ນໃນປີກາຍນີ້, ບໍລິສັດຂອງພວກເຮົາເລີ່ມຈັດຕັ້ງ hackathons. ການແຂ່ງຂັນດັ່ງກ່າວຄັ້ງທໍາອິດແມ່ນປະສົບຜົນສໍາເລັດຫຼາຍ, ພວກເຮົາຂຽນກ່ຽວກັບມັນຢູ່ໃນ ບົດຄວາມ. ການ hackathon ທີສອງໄດ້ຈັດຂຶ້ນໃນເດືອນກຸມພາ 2019 ແລະບໍ່ປະສົບຜົນສໍາເລັດຫນ້ອຍ. ກ່ຽວ​ກັບ​ເປົ້າ​ຫມາຍ​ຂອງ​ການ​ຖື​ຫຼັງ​ບໍ່​ດົນ​ມາ​ນີ້​ wrote ຜູ້ຈັດງານ.

ຜູ້ເຂົ້າຮ່ວມໄດ້ຮັບຫນ້າທີ່ທີ່ຫນ້າສົນໃຈຫຼາຍທີ່ມີອິດສະລະພາບຢ່າງສົມບູນໃນການເລືອກ stack ເຕັກໂນໂລຢີສໍາລັບການຈັດຕັ້ງປະຕິບັດ. ມັນເປັນສິ່ງຈໍາເປັນເພື່ອປະຕິບັດເວທີການຕັດສິນໃຈສໍາລັບການປະຕິບັດຫນ້າທີ່ການໃຫ້ຄະແນນຂອງລູກຄ້າທີ່ສະດວກສະບາຍທີ່ສາມາດເຮັດວຽກກັບການໄຫຼວຽນຂອງຄໍາຮ້ອງສະຫມັກຢ່າງໄວວາ, ທົນທານຕໍ່ການໂຫຼດຫນັກ, ແລະລະບົບຕົວມັນເອງສາມາດຂະຫຍາຍໄດ້ງ່າຍ.

ວຽກງານບໍ່ແມ່ນເລື່ອງເລັກໆນ້ອຍໆແລະສາມາດແກ້ໄຂໄດ້ໃນຫຼາຍວິທີ, ດັ່ງທີ່ພວກເຮົາເຊື່ອຫມັ້ນໃນລະຫວ່າງການສາທິດການນໍາສະເຫນີໂຄງການສຸດທ້າຍຂອງຜູ້ເຂົ້າຮ່ວມ. ມີ 6 ທີມຂອງ 5 ຄົນຢູ່ທີ່ hackathon, ຜູ້ເຂົ້າຮ່ວມທັງຫມົດມີໂຄງການທີ່ດີ, ແຕ່ເວທີຂອງພວກເຮົາໄດ້ກາຍເປັນການແຂ່ງຂັນທີ່ສຸດ. ພວກເຮົາມີໂຄງການທີ່ຫນ້າສົນໃຈຫຼາຍ, ເຊິ່ງຂ້ອຍຢາກເວົ້າກ່ຽວກັບເລື່ອງນີ້.

ການແກ້ໄຂຂອງພວກເຮົາແມ່ນແພລະຕະຟອມທີ່ອີງໃສ່ສະຖາປັດຕະຍະກໍາ Serverless ພາຍໃນ Kubernetes, ເຊິ່ງຫຼຸດຜ່ອນເວລາທີ່ມັນໃຊ້ເວລາເພື່ອນໍາເອົາຄຸນສົມບັດໃຫມ່ມາສູ່ການຜະລິດ. ມັນອະນຸຍາດໃຫ້ນັກວິເຄາະຂຽນລະຫັດໃນສະພາບແວດລ້ອມທີ່ສະດວກສໍາລັບພວກເຂົາແລະນໍາມັນເຂົ້າໄປໃນການຜະລິດໂດຍບໍ່ມີການເຂົ້າຮ່ວມຂອງວິສະວະກອນແລະນັກພັດທະນາ.

ຄະແນນແມ່ນຫຍັງ

Tinkoff.ru, ເຊັ່ນດຽວກັນກັບບໍລິສັດທີ່ທັນສະໄຫມຈໍານວນຫຼາຍ, ມີລູກຄ້າໃຫ້ຄະແນນ. ການໃຫ້ຄະແນນແມ່ນລະບົບການປະເມີນລູກຄ້າໂດຍອີງໃສ່ວິທີການສະຖິຕິຂອງການວິເຄາະຂໍ້ມູນ.

ຕົວຢ່າງ, ລູກຄ້າຫັນໄປຫາພວກເຮົາດ້ວຍການຮ້ອງຂໍໃຫ້ເຂົາອອກເງິນກູ້, ຫຼືເປີດບັນຊີຜູ້ປະກອບການສ່ວນບຸກຄົນກັບພວກເຮົາ. ຖ້າພວກເຮົາວາງແຜນທີ່ຈະອອກເງິນກູ້ໃຫ້ລາວ, ພວກເຮົາຈໍາເປັນຕ້ອງປະເມີນການແກ້ໄຂຂອງລາວ, ແລະຖ້າບັນຊີແມ່ນຜູ້ປະກອບການສ່ວນບຸກຄົນ, ພວກເຮົາຈໍາເປັນຕ້ອງແນ່ໃຈວ່າລູກຄ້າຈະບໍ່ເຮັດທຸລະກໍາທີ່ຫຼອກລວງ.

ພື້ນຖານສໍາລັບການຕັດສິນໃຈດັ່ງກ່າວແມ່ນຕົວແບບທາງຄະນິດສາດທີ່ວິເຄາະທັງຂໍ້ມູນຈາກແອັບພລິເຄຊັນຕົວມັນເອງແລະຂໍ້ມູນຈາກການເກັບຮັກສາຂອງພວກເຮົາ. ນອກເຫນືອຈາກການໃຫ້ຄະແນນ, ວິທີການສະຖິຕິທີ່ຄ້າຍຄືກັນຍັງສາມາດຖືກນໍາໃຊ້ໃນການບໍລິການຂອງການສ້າງຄໍາແນະນໍາສ່ວນບຸກຄົນສໍາລັບຜະລິດຕະພັນໃຫມ່ສໍາລັບລູກຄ້າຂອງພວກເຮົາ.

ວິທີການຂອງການປະເມີນຜົນດັ່ງກ່າວສາມາດຍອມຮັບຄວາມຫລາກຫລາຍຂອງຂໍ້ມູນປ້ອນຂໍ້ມູນ. ແລະໃນບາງຈຸດທີ່ພວກເຮົາສາມາດເພີ່ມພາລາມິເຕີໃຫມ່ໃນການປ້ອນຂໍ້ມູນ, ເຊິ່ງ, ອີງຕາມຜົນຂອງການວິເຄາະຂໍ້ມູນປະຫວັດສາດ, ຈະເພີ່ມອັດຕາການປ່ຽນແປງຂອງການນໍາໃຊ້ບໍລິການ.

ພວກເຮົາຖືຂໍ້ມູນທີ່ອຸດົມສົມບູນກ່ຽວກັບຄວາມສໍາພັນຂອງລູກຄ້າ, ແລະປະລິມານຂອງຂໍ້ມູນນີ້ແມ່ນການຂະຫຍາຍຕົວຢ່າງຕໍ່ເນື່ອງ. ສໍາລັບການໃຫ້ຄະແນນເຮັດວຽກ, ການປະມວນຜົນຂໍ້ມູນຍັງຮຽກຮ້ອງໃຫ້ມີກົດລະບຽບ (ຫຼືແບບຈໍາລອງທາງຄະນິດສາດ) ທີ່ອະນຸຍາດໃຫ້ທ່ານຕັດສິນໃຈຢ່າງໄວວາວ່າໃຜຈະອະນຸມັດຄໍາຮ້ອງສະຫມັກ, ໃຜຈະປະຕິເສດ, ແລະຜູ້ທີ່ຈະສະເຫນີຜະລິດຕະພັນອີກສອງຢ່າງ, ການປະເມີນຄວາມສົນໃຈທີ່ເປັນໄປໄດ້.

ສໍາລັບວຽກງານຢູ່ໃນມື, ພວກເຮົາໃຊ້ລະບົບການຕັດສິນໃຈພິເສດແລ້ວ IBM WebSphere ILOG JRules BRMS, ເຊິ່ງ, ອີງຕາມກົດລະບຽບທີ່ກໍານົດໄວ້ໂດຍນັກວິເຄາະ, ນັກເຕັກໂນໂລຢີແລະນັກພັດທະນາ, ຕັດສິນໃຈວ່າຈະອະນຸມັດຫຼືປະຕິເສດຜະລິດຕະພັນທະນາຄານໂດຍສະເພາະກັບລູກຄ້າ.

ມີຫຼາຍວິທີແກ້ໄຂທີ່ກຽມພ້ອມໃນຕະຫຼາດ, ທັງຮູບແບບການໃຫ້ຄະແນນແລະລະບົບການຕັດສິນໃຈດ້ວຍຕົນເອງ. ພວກເຮົາໃຊ້ຫນຶ່ງໃນລະບົບເຫຼົ່ານີ້ຢູ່ໃນບໍລິສັດຂອງພວກເຮົາ. ແຕ່ທຸລະກິດກໍາລັງເຕີບໂຕ, ມີຄວາມຫຼາກຫຼາຍ, ທັງຈໍານວນລູກຄ້າແລະຈໍານວນຜະລິດຕະພັນທີ່ສະເຫນີແມ່ນເພີ່ມຂຶ້ນ, ແລະຄຽງຄູ່ກັບການນີ້, ແນວຄວາມຄິດກໍ່ເກີດຂື້ນກ່ຽວກັບວິທີການປັບປຸງຂະບວນການຕັດສິນໃຈທີ່ມີຢູ່. ແນ່ນອນ, ຄົນທີ່ເຮັດວຽກກັບລະບົບທີ່ມີຢູ່ແລ້ວມີແນວຄວາມຄິດຫຼາຍຢ່າງກ່ຽວກັບວິທີການເຮັດໃຫ້ມັນງ່າຍດາຍ, ດີກວ່າ, ສະດວກກວ່າ, ແຕ່ບາງຄັ້ງຄວາມຄິດຈາກພາຍນອກກໍ່ເປັນປະໂຫຍດ. New Hackathon ໄດ້ຖືກຈັດຂື້ນໂດຍມີຈຸດປະສົງເພື່ອເກັບກໍາແນວຄວາມຄິດທີ່ດີ.

ວຽກງານ

ງານ​ແຮກ​ກາ​ທອນ​ໄດ້​ຈັດ​ຂຶ້ນ​ໃນ​ວັນ​ທີ 23 ກຸມພາ​ນີ້. ຜູ້ເຂົ້າຮ່ວມໄດ້ຖືກສະເຫນີວຽກງານການຕໍ່ສູ້: ການພັດທະນາລະບົບການຕັດສິນໃຈທີ່ຕ້ອງຕອບສະຫນອງເງື່ອນໄຂຈໍານວນຫນຶ່ງ.

ພວກເຮົາໄດ້ຖືກບອກວິທີການເຮັດວຽກຂອງລະບົບທີ່ມີຢູ່ແລ້ວແລະຄວາມຫຍຸ້ງຍາກອັນໃດເກີດຂື້ນໃນລະຫວ່າງການປະຕິບັດງານຂອງມັນ, ເຊັ່ນດຽວກັນກັບເປົ້າຫມາຍທຸລະກິດທີ່ເວທີທີ່ພັດທະນາຄວນດໍາເນີນການ. ລະບົບຕ້ອງມີເວລາໄວໃນການຕະຫຼາດສໍາລັບການພັດທະນາກົດລະບຽບເພື່ອໃຫ້ລະຫັດການເຮັດວຽກຂອງນັກວິເຄາະເຂົ້າໄປໃນການຜະລິດໄວເທົ່າທີ່ຈະໄວໄດ້. ແລະສໍາລັບການໄຫຼເຂົ້າຂອງຄໍາຮ້ອງສະຫມັກ, ເວລາໃນການຕັດສິນໃຈຄວນຈະມີທ່າອ່ຽງຕໍ່າສຸດ. ນອກຈາກນີ້, ລະບົບທີ່ຖືກພັດທະນາຕ້ອງມີຄວາມສາມາດໃນການຂາຍຂ້າມເພື່ອໃຫ້ລູກຄ້າມີໂອກາດທີ່ຈະຊື້ຜະລິດຕະພັນຂອງບໍລິສັດອື່ນຖ້າພວກເຂົາໄດ້ຮັບການອະນຸມັດຈາກພວກເຮົາແລະມີຄວາມສົນໃຈຈາກລູກຄ້າ.

ມັນເປັນທີ່ຊັດເຈນວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຂຽນໂຄງການທີ່ກຽມພ້ອມໃນຄືນທີ່ແນ່ນອນວ່າຈະເຂົ້າໄປໃນການຜະລິດ, ແລະມັນຂ້ອນຂ້າງຍາກທີ່ຈະກວມເອົາລະບົບທັງຫມົດ, ດັ່ງນັ້ນພວກເຮົາໄດ້ຖືກຂໍໃຫ້ປະຕິບັດຢ່າງຫນ້ອຍສ່ວນຫນຶ່ງຂອງມັນ. ຄວາມຕ້ອງການຈໍານວນຫນຶ່ງໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນທີ່ຕົ້ນແບບຕ້ອງຕອບສະຫນອງ. ມັນເປັນໄປໄດ້ທີ່ຈະພະຍາຍາມທັງສອງເພື່ອໃຫ້ກວມເອົາຄວາມຕ້ອງການທັງຫມົດຂອງພວກເຂົາທັງຫມົດ, ແລະເຮັດວຽກຢ່າງລະອຽດກ່ຽວກັບພາກສ່ວນສ່ວນບຸກຄົນຂອງເວທີທີ່ກໍາລັງພັດທະນາ.

ສໍາລັບເຕັກໂນໂລຢີ, ຜູ້ເຂົ້າຮ່ວມທັງຫມົດໄດ້ຮັບສິດເສລີພາບໃນການເລືອກຢ່າງສົມບູນ. ມັນເປັນໄປໄດ້ທີ່ຈະນໍາໃຊ້ແນວຄວາມຄິດແລະເຕັກໂນໂລຢີໃດໆ: ການຖ່າຍທອດຂໍ້ມູນ, ການຮຽນຮູ້ເຄື່ອງຈັກ, ແຫຼ່ງເຫດການ, ຂໍ້ມູນໃຫຍ່ແລະອື່ນໆ.

ການແກ້ໄຂຂອງພວກເຮົາ

ຫຼັງຈາກການລະດົມສະຫມອງເລັກນ້ອຍ, ພວກເຮົາໄດ້ຕັດສິນໃຈວ່າການແກ້ໄຂ FaaS ຈະເປັນທີ່ເຫມາະສົມສໍາລັບການເຮັດສໍາເລັດຫນ້າວຽກ.

ສໍາລັບການແກ້ໄຂນີ້, ມັນຈໍາເປັນຕ້ອງຊອກຫາກອບ Serverless ທີ່ເຫມາະສົມເພື່ອປະຕິບັດກົດລະບຽບຂອງລະບົບການຕັດສິນໃຈທີ່ຖືກພັດທະນາ. ນັບຕັ້ງແຕ່ Tinkoff ໃຊ້ Kubernetes ຢ່າງຈິງຈັງສໍາລັບການຄຸ້ມຄອງໂຄງສ້າງພື້ນຖານ, ພວກເຮົາໄດ້ເບິ່ງວິທີແກ້ໄຂທີ່ກຽມພ້ອມຫຼາຍໂດຍອີງໃສ່ມັນ; ຂ້ອຍຈະບອກທ່ານເພີ່ມເຕີມກ່ຽວກັບມັນໃນພາຍຫລັງ.

ເພື່ອຊອກຫາວິທີແກ້ໄຂທີ່ມີປະສິດທິພາບທີ່ສຸດ, ພວກເຮົາໄດ້ເບິ່ງຜະລິດຕະພັນທີ່ຖືກພັດທະນາໂດຍຜ່ານສາຍຕາຂອງຜູ້ໃຊ້ຂອງມັນ. ຜູ້ໃຊ້ຕົ້ນຕໍຂອງລະບົບຂອງພວກເຮົາແມ່ນນັກວິເຄາະທີ່ກ່ຽວຂ້ອງກັບການພັດທະນາກົດລະບຽບ. ກົດລະບຽບຈະຕ້ອງຖືກນໍາໄປໃຊ້ກັບເຄື່ອງແມ່ຂ່າຍ, ຫຼື, ເຊັ່ນດຽວກັບໃນກໍລະນີຂອງພວກເຮົາ, ນໍາໃຊ້ໃນຄລາວ, ສໍາລັບການຕັດສິນໃຈຕໍ່ມາ. ຈາກທັດສະນະຂອງນັກວິເຄາະ, ຂະບວນການເຮັດວຽກເບິ່ງຄືວ່າ:

1. ນັກວິເຄາະຂຽນຕົວແບບ, ກົດລະບຽບ, ຫຼື ML ໂດຍອີງໃສ່ຂໍ້ມູນຈາກສາງ. ເປັນສ່ວນຫນຶ່ງຂອງ hackathon, ພວກເຮົາໄດ້ຕັດສິນໃຈໃຊ້ Mongodb, ແຕ່ທາງເລືອກຂອງລະບົບການເກັບຮັກສາຂໍ້ມູນແມ່ນບໍ່ສໍາຄັນຢູ່ທີ່ນີ້.
2. ຫຼັງຈາກການທົດສອບກົດລະບຽບທີ່ພັດທະນາກ່ຽວກັບຂໍ້ມູນປະຫວັດສາດ, ນັກວິເຄາະອັບໂຫລດລະຫັດຂອງລາວໄປຫາກະດານ admin.
3. ເພື່ອຮັບປະກັນການສ້າງເວີຊັນ, ລະຫັດທັງໝົດຈະໄປທີ່ບ່ອນເກັບຂໍ້ມູນ Git.
4. ຜ່ານກະດານ admin ມັນຈະສາມາດປັບໃຊ້ລະຫັດໃນຄລາວເປັນໂມດູນ Serverless ທີ່ເຮັດວຽກແຍກຕ່າງຫາກ.

ຂໍ້ມູນເບື້ອງຕົ້ນຈາກລູກຄ້າຕ້ອງຜ່ານການບໍລິການເສີມສ້າງສະເພາະທີ່ອອກແບບມາເພື່ອເສີມສ້າງການຮ້ອງຂໍເບື້ອງຕົ້ນດ້ວຍຂໍ້ມູນຈາກສາງ. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະຕິບັດການບໍລິການນີ້ໃນລັກສະນະທີ່ມັນຈະເຮັດວຽກກັບບ່ອນເກັບມ້ຽນດຽວ (ຈາກທີ່ນັກວິເຄາະເອົາຂໍ້ມູນໃນເວລາທີ່ກໍາລັງພັດທະນາກົດລະບຽບ) ເພື່ອຮັກສາໂຄງສ້າງຂໍ້ມູນທີ່ເປັນເອກະພາບ.

ເຖິງແມ່ນວ່າກ່ອນທີ່ຈະ hackathon, ພວກເຮົາໄດ້ຕັດສິນໃຈກ່ຽວກັບກອບ Serverless ທີ່ພວກເຮົາຈະໃຊ້. ມື້ນີ້ມີເທກໂນໂລຍີຫຼາຍໃນຕະຫຼາດທີ່ປະຕິບັດວິທີການນີ້. ການແກ້ໄຂທີ່ນິຍົມຫຼາຍທີ່ສຸດພາຍໃນສະຖາປັດຕະຍະກໍາ Kubernetes ແມ່ນ Fission, Open FaaS ແລະ Kubeless. ມີເຖິງແມ່ນວ່າ ບົດຄວາມທີ່ດີທີ່ມີຄໍາອະທິບາຍແລະການວິເຄາະປຽບທຽບຂອງພວກເຂົາ.

ຫຼັງຈາກການຊັ່ງນໍ້າຫນັກຂໍ້ດີແລະຂໍ້ເສຍທັງຫມົດ, ພວກເຮົາເລືອກ ຄວາມຜິດ. ກອບ Serverless ນີ້ແມ່ນຂ້ອນຂ້າງງ່າຍທີ່ຈະຈັດການແລະຕອບສະຫນອງຄວາມຕ້ອງການຂອງວຽກງານ.

ເພື່ອເຮັດວຽກກັບ Fission, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈສອງແນວຄວາມຄິດພື້ນຖານ: ຫນ້າທີ່ແລະສະພາບແວດລ້ອມ. ຟັງຊັນແມ່ນຊິ້ນສ່ວນຂອງລະຫັດທີ່ຂຽນໃນພາສາຫນຶ່ງທີ່ມີສະພາບແວດລ້ອມ Fission. ບັນຊີລາຍຊື່ຂອງສະພາບແວດລ້ອມທີ່ປະຕິບັດຢູ່ໃນກອບນີ້ ປະກອບມີ Python, JS, Go, JVM ແລະຫຼາຍພາສາແລະເຕັກໂນໂລຢີທີ່ນິຍົມອື່ນໆ.

Fission ຍັງສາມາດປະຕິບັດຫນ້າທີ່ແບ່ງອອກເປັນຫຼາຍໄຟລ໌, ບັນຈຸໄວ້ລ່ວງຫນ້າເຂົ້າໄປໃນບ່ອນເກັບມ້ຽນ. ການດໍາເນີນງານຂອງ Fission ໃນກຸ່ມ Kubernetes ແມ່ນຮັບປະກັນໂດຍຝັກພິເສດ, ເຊິ່ງຖືກຄຸ້ມຄອງໂດຍກອບຂອງມັນເອງ. ເພື່ອໂຕ້ຕອບກັບ cluster pods, ແຕ່ລະຟັງຊັນຕ້ອງຖືກມອບຫມາຍເສັ້ນທາງຂອງຕົນເອງ, ແລະເພື່ອໃຫ້ທ່ານສາມາດຜ່ານ GET parameters ຫຼື request body ໃນກໍລະນີຂອງຄໍາຮ້ອງຂໍ POST.

ດັ່ງນັ້ນ, ພວກເຮົາຈຶ່ງວາງແຜນທີ່ຈະໄດ້ຮັບການແກ້ໄຂທີ່ຈະຊ່ວຍໃຫ້ນັກວິເຄາະສາມາດນຳໃຊ້ສະຄຣິບກົດລະບຽບທີ່ພັດທະນາແລ້ວ ໂດຍບໍ່ມີການເຂົ້າຮ່ວມຂອງວິສະວະກອນ ແລະນັກພັດທະນາ. ວິທີການອະທິບາຍຍັງລົບລ້າງຄວາມຕ້ອງການສໍາລັບນັກພັດທະນາທີ່ຈະຂຽນລະຫັດນັກວິເຄາະໃຫມ່ເປັນພາສາອື່ນ. ຕົວຢ່າງເຊັ່ນ, ສໍາລັບລະບົບການຕັດສິນໃຈໃນປະຈຸບັນທີ່ພວກເຮົາໃຊ້, ພວກເຮົາຕ້ອງຂຽນກົດລະບຽບໃນເຕັກໂນໂລຢີແລະພາສາທີ່ມີຄວາມຊ່ຽວຊານສູງ, ຂອບເຂດຈໍາກັດທີ່ສຸດ, ແລະຍັງມີການເພິ່ງພາອາໄສທີ່ເຂັ້ມແຂງກັບເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ, ນັບຕັ້ງແຕ່ຮ່າງກົດລະບຽບທະນາຄານທັງຫມົດ. ຖືກ ນຳ ໃຊ້ໃນສະພາບແວດລ້ອມດຽວ. ດັ່ງນັ້ນ, ເພື່ອປະຕິບັດກົດລະບຽບໃຫມ່, ມັນຈໍາເປັນຕ້ອງປ່ອຍລະບົບທັງຫມົດ.

ໃນການແກ້ໄຂທີ່ສະເຫນີຂອງພວກເຮົາ, ບໍ່ຈໍາເປັນຕ້ອງປ່ອຍກົດລະບຽບ; ລະຫັດສາມາດຖືກນໍາໄປໃຊ້ໄດ້ງ່າຍໂດຍການຄລິກປຸ່ມຫນຶ່ງ. ນອກຈາກນີ້, ການຈັດການພື້ນຖານໂຄງລ່າງໃນ Kubernetes ຊ່ວຍໃຫ້ທ່ານບໍ່ຄິດກ່ຽວກັບການໂຫຼດແລະຂະຫນາດ; ບັນຫາດັ່ງກ່າວຖືກແກ້ໄຂອອກຈາກກ່ອງ. ແລະການນໍາໃຊ້ຄັງເກັບຂໍ້ມູນດຽວລົບລ້າງຄວາມຕ້ອງການທີ່ຈະປຽບທຽບຂໍ້ມູນໃນເວລາຈິງກັບຂໍ້ມູນປະຫວັດສາດ, ເຊິ່ງເຮັດໃຫ້ວຽກງານຂອງນັກວິເຄາະງ່າຍຂຶ້ນ.

ສິ່ງທີ່ພວກເຮົາໄດ້ຮັບ

ນັບຕັ້ງແຕ່ພວກເຮົາມາຮອດ hackathon ດ້ວຍການແກ້ໄຂທີ່ກຽມພ້ອມ (ໃນຈິນຕະນາການຂອງພວກເຮົາ), ທັງຫມົດທີ່ພວກເຮົາຕ້ອງເຮັດຄືການປ່ຽນຄວາມຄິດຂອງພວກເຮົາທັງຫມົດເຂົ້າໄປໃນລະຫັດ.

ກຸນແຈເພື່ອຄວາມສໍາເລັດໃນ hackathon ໃດກໍ່ຕາມແມ່ນການກະກຽມແລະແຜນການທີ່ຂຽນໄດ້ດີ. ດັ່ງນັ້ນ, ສິ່ງທໍາອິດທີ່ພວກເຮົາເຮັດແມ່ນຕັດສິນໃຈວ່າໂມດູນໃດທີ່ສະຖາປັດຕະຍະກໍາລະບົບຂອງພວກເຮົາຈະປະກອບດ້ວຍແລະເຕັກໂນໂລຢີທີ່ພວກເຮົາຈະໃຊ້.

ສະຖາປັດຕະຍະກຳຂອງໂຄງການຂອງພວກເຮົາມີດັ່ງນີ້:

ແຜນວາດນີ້ສະແດງໃຫ້ເຫັນສອງຈຸດເຂົ້າ, ນັກວິເຄາະ (ຜູ້ໃຊ້ຕົ້ນຕໍຂອງລະບົບຂອງພວກເຮົາ) ແລະລູກຄ້າ.

ຂະບວນການເຮັດວຽກແມ່ນມີໂຄງສ້າງເຊັ່ນນີ້. ນັກວິເຄາະພັດທະນາຫນ້າທີ່ກົດລະບຽບແລະຫນ້າທີ່ເພີ່ມຂໍ້ມູນສໍາລັບຕົວແບບຂອງລາວ, ເກັບຮັກສາລະຫັດຂອງລາວຢູ່ໃນບ່ອນເກັບມ້ຽນ Git, ແລະນໍາໃຊ້ຕົວແບບຂອງລາວໄປສູ່ຄລາວໂດຍຜ່ານຄໍາຮ້ອງສະຫມັກຂອງຜູ້ບໍລິຫານ. ໃຫ້ພິຈາລະນາວິທີການປະຕິບັດຫນ້າທີ່ຖືກເອີ້ນແລະເຮັດການຕັດສິນໃຈກ່ຽວກັບການຮ້ອງຂໍທີ່ເຂົ້າມາຈາກລູກຄ້າ:

1. ລູກຄ້າຕື່ມແບບຟອມຢູ່ໃນເວັບໄຊທ໌ແລະສົ່ງຄໍາຮ້ອງຂໍຂອງລາວໄປຫາຜູ້ຄວບຄຸມ. ຄໍາຮ້ອງສະຫມັກທີ່ຕ້ອງຕັດສິນໃຈເຂົ້າມາໃນລະບົບແລະຖືກບັນທຶກໄວ້ໃນຖານຂໍ້ມູນໃນຮູບແບບຕົ້ນສະບັບຂອງມັນ.
2. ຕໍ່ໄປ, ການຮ້ອງຂໍວັດຖຸດິບຖືກສົ່ງສໍາລັບການເສີມສ້າງ, ຖ້າຈໍາເປັນ. ທ່ານສາມາດເສີມການຮ້ອງຂໍເບື້ອງຕົ້ນດ້ວຍຂໍ້ມູນທັງຈາກການບໍລິການພາຍນອກແລະຈາກການເກັບຮັກສາ. ການສອບຖາມທີ່ອຸດົມສົມບູນຜົນໄດ້ຮັບຍັງຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນ.
3. ຟັງຊັນນັກວິເຄາະຖືກເປີດຕົວ, ເຊິ່ງໃຊ້ເວລາການສອບຖາມທີ່ອຸດົມສົມບູນເປັນການປ້ອນຂໍ້ມູນແລະຜະລິດການແກ້ໄຂ, ເຊິ່ງຖືກຂຽນໄວ້ໃນບ່ອນເກັບມ້ຽນ.

ພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະໃຊ້ MongoDB ເປັນການເກັບຮັກສາໃນລະບົບຂອງພວກເຮົາເນື່ອງຈາກການເກັບຮັກສາເອກະສານທີ່ເນັ້ນໃສ່ຂໍ້ມູນໃນຮູບແບບຂອງເອກະສານ JSON, ນັບຕັ້ງແຕ່ການບໍລິການເສີມ, ລວມທັງຄໍາຮ້ອງຂໍຕົ້ນສະບັບ, ໄດ້ລວບລວມຂໍ້ມູນທັງຫມົດໂດຍຜ່ານຕົວຄວບຄຸມ REST.

ດັ່ງນັ້ນ, ພວກເຮົາມີເວລາ XNUMX ຊົ່ວໂມງເພື່ອປະຕິບັດເວທີ. ພວກ​ເຮົາ​ໄດ້​ແຈກ​ຢາຍ​ພາ​ລະ​ບົດ​ບາດ​ຢ່າງ​ສໍາ​ເລັດ​ຜົນ​, ສະ​ມາ​ຊິກ​ທີມ​ງານ​ແຕ່​ລະ​ຄົນ​ມີ​ພື້ນ​ທີ່​ຄວາມ​ຮັບ​ຜິດ​ຊອບ​ຂອງ​ຕົນ​ເອງ​ໃນ​ໂຄງ​ການ​ຂອງ​ພວກ​ເຮົາ​:

1. ແຜງຄວບຄຸມດ້ານຫນ້າສໍາລັບວຽກງານຂອງນັກວິເຄາະ, ໂດຍຜ່ານທີ່ລາວສາມາດດາວໂຫລດກົດລະບຽບຈາກລະບົບການຄວບຄຸມເວີຊັນຂອງສະຄິບທີ່ຂຽນ, ເລືອກທາງເລືອກສໍາລັບການເພີ່ມຂໍ້ມູນການປ້ອນຂໍ້ມູນແລະແກ້ໄຂສະຄິບກົດລະບຽບອອນໄລນ໌.
2. Backend admin, ລວມທັງ REST API ສໍາລັບດ້ານຫນ້າແລະການເຊື່ອມໂຍງກັບ VCS.
3. ຕັ້ງຄ່າໂຄງສ້າງພື້ນຖານໃນ Google Cloud ແລະພັດທະນາການບໍລິການເພື່ອເສີມສ້າງຂໍ້ມູນແຫຼ່ງ.
4. ໂມດູນສໍາລັບການລວມຄໍາຮ້ອງສະຫມັກ admin ກັບກອບ Serverless ສໍາລັບການປະຕິບັດກົດລະບຽບຕໍ່ໄປ.
5. scripts ຂອງກົດລະບຽບສໍາລັບການທົດສອບການປະຕິບັດຂອງລະບົບທັງຫມົດແລະການລວບລວມການວິເຄາະກ່ຽວກັບຄໍາຮ້ອງສະຫມັກທີ່ເຂົ້າມາ (ການຕັດສິນໃຈເຮັດ) ສໍາລັບການສາທິດສຸດທ້າຍ.

ໃຫ້ເລີ່ມຕົ້ນເປັນລະບຽບ.

ດ້ານໜ້າຂອງພວກເຮົາຖືກຂຽນໄວ້ໃນ Angular 7 ໂດຍໃຊ້ຊຸດ UI ທະນາຄານ. ສະບັບສຸດທ້າຍຂອງກະດານ admin ເບິ່ງຄືດັ່ງນີ້:

ເນື່ອງຈາກມີເວລາຫນ້ອຍ, ພວກເຮົາພະຍາຍາມປະຕິບັດພຽງແຕ່ຫນ້າທີ່ທີ່ສໍາຄັນເທົ່ານັ້ນ. ເພື່ອປັບໃຊ້ຟັງຊັນໃນກຸ່ມ Kubernetes, ມັນຈໍາເປັນຕ້ອງເລືອກເຫດການ (ການບໍລິການທີ່ກົດລະບຽບຈໍາເປັນຕ້ອງຖືກນໍາໄປໃຊ້ໃນຄລາວ) ແລະລະຫັດຂອງຟັງຊັນທີ່ປະຕິບັດເຫດຜົນການຕັດສິນໃຈ. ສໍາລັບແຕ່ລະການນໍາໃຊ້ກົດລະບຽບສໍາລັບການບໍລິການທີ່ເລືອກ, ພວກເຮົາໄດ້ຂຽນບັນທຶກຂອງເຫດການນີ້. ໃນກະດານ admin ທ່ານສາມາດເບິ່ງບັນທຶກຂອງເຫດການທັງຫມົດ.

ລະຫັດຟັງຊັນທັງໝົດຖືກເກັບໄວ້ໃນບ່ອນເກັບມ້ຽນ Git ຫ່າງໄກສອກຫຼີກ, ເຊິ່ງຕ້ອງຖືກຕັ້ງຢູ່ໃນກະດານ admin. ເພື່ອສະບັບລະຫັດ, ຟັງຊັນທັງຫມົດຖືກເກັບໄວ້ໃນສາຂາທີ່ແຕກຕ່າງກັນຂອງ repository. ກະດານ admin ຍັງສະຫນອງຄວາມສາມາດໃນການປັບຕົວກັບສະຄິບທີ່ເປັນລາຍລັກອັກສອນ, ດັ່ງນັ້ນກ່ອນທີ່ຈະນໍາໃຊ້ຫນ້າທີ່ໃນການຜະລິດ, ທ່ານບໍ່ພຽງແຕ່ສາມາດກວດສອບລະຫັດລາຍລັກອັກສອນ, ແຕ່ຍັງເຮັດການປ່ຽນແປງທີ່ຈໍາເປັນ.

ນອກ ເໜືອ ໄປຈາກ ໜ້າ ທີ່ກົດລະບຽບ, ພວກເຮົາຍັງໄດ້ປະຕິບັດຄວາມສາມາດໃນການປັບປຸງຂໍ້ມູນແຫຼ່ງເທື່ອລະກ້າວໂດຍໃຊ້ຟັງຊັນ Enrichment, ລະຫັດທີ່ເປັນສະຄິບທີ່ມັນເປັນໄປໄດ້ທີ່ຈະໄປທີ່ຄັງຂໍ້ມູນ, ໂທຫາບໍລິການຂອງພາກສ່ວນທີສາມແລະປະຕິບັດການຄິດໄລ່ເບື້ອງຕົ້ນ. . ເພື່ອສະແດງໃຫ້ເຫັນການແກ້ໄຂຂອງພວກເຮົາ, ພວກເຮົາໄດ້ຄິດໄລ່ເຄື່ອງຫມາຍ zodiac ຂອງລູກຄ້າທີ່ອອກຈາກຄໍາຮ້ອງຂໍແລະກໍານົດຜູ້ໃຫ້ບໍລິການມືຖືຂອງລາວໂດຍໃຊ້ບໍລິການ REST ຂອງພາກສ່ວນທີສາມ.

backend ຂອງເວທີໄດ້ຖືກຂຽນໃນ Java ແລະປະຕິບັດເປັນຄໍາຮ້ອງສະຫມັກ Spring Boot. ໃນເບື້ອງຕົ້ນພວກເຮົາໄດ້ວາງແຜນທີ່ຈະໃຊ້ Postgres ເພື່ອເກັບຂໍ້ມູນ admin, ແຕ່ເປັນສ່ວນຫນຶ່ງຂອງ hackathon, ພວກເຮົາໄດ້ຕັດສິນໃຈຈໍາກັດຕົວເອງກັບ H2 ງ່າຍໆເພື່ອປະຫຍັດເວລາ. ໃນດ້ານຫຼັງ, ການເຊື່ອມໂຍງກັບ Bitbucket ໄດ້ຖືກປະຕິບັດເພື່ອສະບັບຂອງຟັງຊັນການເສີມສ້າງແບບສອບຖາມແລະສະຄິບກົດລະບຽບ. ສໍາລັບການເຊື່ອມໂຍງກັບ repositories Git ຫ່າງໄກສອກຫຼີກ, ພວກເຮົາໄດ້ນໍາໃຊ້ ຫ້ອງສະຫມຸດ JGit, ຊຶ່ງເປັນປະເພດຂອງ wrapper ໃນໄລຍະຄໍາສັ່ງ CLI, ອະນຸຍາດໃຫ້ທ່ານສາມາດປະຕິບັດຄໍາແນະນໍາ git ໃດຫນຶ່ງໂດຍໃຊ້ການໂຕ້ຕອບຊອບແວທີ່ສະດວກ. ດັ່ງນັ້ນພວກເຮົາມີສອງ repositories ແຍກຕ່າງຫາກສໍາລັບຫນ້າທີ່ enrichment ແລະກົດລະບຽບ, ແລະ scripts ທັງຫມົດໄດ້ຖືກແບ່ງອອກເປັນ directory. ໂດຍຜ່ານ UI ມັນເປັນໄປໄດ້ທີ່ຈະເລືອກເອົາຄໍາຫມັ້ນສັນຍາຫລ້າສຸດຂອງ script ຂອງສາຂາ arbitrary ຂອງ repository. ເມື່ອເຮັດການປ່ຽນແປງລະຫັດຜ່ານກະດານ admin, commits ຂອງລະຫັດການປ່ຽນແປງໄດ້ຖືກສ້າງຂື້ນໃນ repositories ຫ່າງໄກສອກຫຼີກ.

ເພື່ອປະຕິບັດແນວຄວາມຄິດຂອງພວກເຮົາ, ພວກເຮົາຕ້ອງການໂຄງສ້າງພື້ນຖານທີ່ເຫມາະສົມ. ພວກເຮົາໄດ້ຕັດສິນໃຈນຳໃຊ້ກຸ່ມ Kubernetes ຂອງພວກເຮົາໃນຄລາວ. ທາງເລືອກຂອງພວກເຮົາແມ່ນ Google Cloud Platform. Fission serverless framework ໄດ້ຖືກຕິດຕັ້ງຢູ່ໃນກຸ່ມ Kubernetes, ເຊິ່ງພວກເຮົາໃຊ້ໃນ Gcloud. ໃນເບື້ອງຕົ້ນ, ການບໍລິການເສີມສ້າງຂໍ້ມູນແຫຼ່ງໄດ້ຖືກປະຕິບັດເປັນແອັບພລິເຄຊັນ Java ແຍກຕ່າງຫາກທີ່ຫໍ່ຢູ່ໃນ Pod ພາຍໃນກຸ່ມ k8s. ແຕ່ຫຼັງຈາກການສາທິດເບື້ອງຕົ້ນຂອງໂຄງການຂອງພວກເຮົາໃນກາງ hackathon, ພວກເຮົາໄດ້ຖືກແນະນໍາໃຫ້ເຮັດໃຫ້ການບໍລິການ Enrichment ມີຄວາມຍືດຫຍຸ່ນຫຼາຍເພື່ອໃຫ້ໂອກາດທີ່ຈະເລືອກເອົາວິທີການເພີ່ມຂໍ້ມູນດິບຂອງຄໍາຮ້ອງສະຫມັກທີ່ເຂົ້າມາ. ແລະ​ພວກ​ເຮົາ​ບໍ່​ມີ​ທາງ​ເລືອກ​ນອກ​ຈາກ​ການ​ເຮັດ​ໃຫ້​ການ​ບໍ​ລິ​ການ​ເພີ່ມ​ເຕີມ​ຍັງ Serverless​.

ເພື່ອເຮັດວຽກກັບ Fission, ພວກເຮົາໄດ້ໃຊ້ Fission CLI, ເຊິ່ງຕ້ອງໄດ້ຕິດຕັ້ງຢູ່ເທິງ Kubernetes CLI. ການປະຕິບັດຫນ້າທີ່ເຂົ້າໄປໃນກຸ່ມ k8s ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ; ທ່ານພຽງແຕ່ຕ້ອງການກໍານົດເສັ້ນທາງພາຍໃນແລະ ingress ໄປຫາຟັງຊັນເພື່ອໃຫ້ການຈະລາຈອນເຂົ້າມາຖ້າການເຂົ້າເຖິງພາຍນອກກຸ່ມແມ່ນຈໍາເປັນ. ການນຳໃຊ້ໜຶ່ງຟັງຊັນປົກກະຕິຈະໃຊ້ເວລາບໍ່ເກີນ 10 ວິນາທີ.

ການນໍາສະເຫນີໂຄງການສຸດທ້າຍແລະສະຫຼຸບ

ເພື່ອສະແດງໃຫ້ເຫັນວິທີການເຮັດວຽກຂອງລະບົບຂອງພວກເຮົາ, ພວກເຮົາໄດ້ວາງແບບຟອມງ່າຍໆຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກທີ່ທ່ານສາມາດສົ່ງຄໍາຮ້ອງສະຫມັກສໍາລັບຫນຶ່ງໃນຜະລິດຕະພັນຂອງທະນາຄານ. ເພື່ອຮ້ອງຂໍ, ທ່ານຕ້ອງໃສ່ຊື່ເບື້ອງຕົ້ນ, ວັນເດືອນປີເກີດແລະເບີໂທລະສັບ.

ຂໍ້ມູນຈາກແບບຟອມລູກຄ້າໄດ້ໄປຫາຕົວຄວບຄຸມ, ເຊິ່ງພ້ອມໆກັນສົ່ງຄໍາຮ້ອງຂໍສໍາລັບກົດລະບຽບທີ່ມີຢູ່ທັງຫມົດ, ກ່ອນຫນ້ານີ້ໄດ້ປັບປຸງຂໍ້ມູນຕາມເງື່ອນໄຂທີ່ລະບຸໄວ້, ແລະບັນທຶກພວກມັນໄວ້ໃນບ່ອນເກັບມ້ຽນທົ່ວໄປ. ໃນຈໍານວນທັງຫມົດ, ພວກເຮົາໄດ້ນໍາໃຊ້ສາມຫນ້າທີ່ຕັດສິນໃຈກ່ຽວກັບຄໍາຮ້ອງສະຫມັກທີ່ເຂົ້າມາແລະ 4 ການບໍລິການເສີມສ້າງຂໍ້ມູນ. ຫຼັງ​ຈາກ​ການ​ສົ່ງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​, ລູກ​ຄ້າ​ໄດ້​ຮັບ​ການ​ຕັດ​ສິນ​ໃຈ​ຂອງ​ພວກ​ເຮົາ​:

ນອກເຫນືອຈາກການປະຕິເສດຫຼືການອະນຸມັດ, ລູກຄ້າຍັງໄດ້ຮັບບັນຊີລາຍຊື່ຂອງຜະລິດຕະພັນອື່ນໆ, ການຮ້ອງຂໍທີ່ພວກເຮົາສົ່ງໃນຂະຫນານ. ນີ້ແມ່ນວິທີທີ່ພວກເຮົາສະແດງໃຫ້ເຫັນເຖິງຄວາມເປັນໄປໄດ້ຂອງການຂາຍຂ້າມໃນເວທີຂອງພວກເຮົາ.

ມີທັງໝົດ 3 ຜະລິດຕະພັນຂອງທະນາຄານປອມທີ່ມີຢູ່:

• ສິນເຊື່ອ.
• ຂອງຫຼິ້ນ
• ຈໍານອງ.

ໃນ​ລະ​ຫວ່າງ​ການ​ສາ​ທິດ, ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ຫນ້າ​ທີ່​ທີ່​ໄດ້​ກະ​ກຽມ​ແລະ​ການ​ເສີມ​ຂະ​ຫຍາຍ​ຕົວ​ອັກ​ສອນ​ສໍາ​ລັບ​ການ​ບໍ​ລິ​ການ​ແຕ່​ລະ​ຄົນ.

ແຕ່ລະກົດລະບຽບຕ້ອງການຊຸດຂໍ້ມູນການປ້ອນຂໍ້ມູນຂອງຕົນເອງ. ດັ່ງນັ້ນ, ເພື່ອອະນຸມັດການຈໍານອງ, ພວກເຮົາຄິດໄລ່ສັນຍາລັກຂອງ zodiac ຂອງລູກຄ້າແລະເຊື່ອມຕໍ່ນີ້ກັບເຫດຜົນຂອງປະຕິທິນ lunar. ເພື່ອອະນຸມັດເຄື່ອງຫຼິ້ນ, ພວກເຮົາໄດ້ກວດເບິ່ງວ່າລູກຄ້າໄດ້ບັນລຸອາຍຸສ່ວນໃຫຍ່, ແລະເພື່ອອອກເງິນກູ້, ພວກເຮົາໄດ້ສົ່ງຄໍາຮ້ອງຂໍໃຫ້ການບໍລິການເປີດພາຍນອກສໍາລັບການກໍານົດຜູ້ປະຕິບັດການໂທລະສັບມືຖື, ແລະການຕັດສິນໃຈແມ່ນເຮັດ.

ພວກເຮົາພະຍາຍາມເຮັດໃຫ້ການສາທິດຂອງພວກເຮົາມີຄວາມຫນ້າສົນໃຈແລະໂຕ້ຕອບ, ທຸກຄົນທີ່ນໍາສະເຫນີສາມາດໄປຫາແບບຟອມຂອງພວກເຮົາແລະກວດເບິ່ງການມີບໍລິການ fictional ຂອງພວກເຮົາໃຫ້ກັບພວກເຂົາ. ແລະໃນຕອນທ້າຍຂອງການນໍາສະເຫນີ, ພວກເຮົາໄດ້ສະແດງໃຫ້ເຫັນການວິເຄາະຂອງຄໍາຮ້ອງສະຫມັກທີ່ໄດ້ຮັບ, ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າມີຈໍານວນຄົນທີ່ໃຊ້ການບໍລິການຂອງພວກເຮົາ, ຈໍານວນການອະນຸມັດແລະການປະຕິເສດ.

ເພື່ອເກັບກຳການວິເຄາະທາງອິນເຕີເນັດ, ພວກເຮົາຍັງໄດ້ນຳໃຊ້ເຄື່ອງມື BI ແຫຼ່ງເປີດ ເມຕາເບດ ແລະ screwed ມັນກັບຫນ່ວຍບໍລິການເກັບຮັກສາຂອງພວກເຮົາ. Metabase ຊ່ວຍໃຫ້ທ່ານສ້າງຫນ້າຈໍດ້ວຍການວິເຄາະຂໍ້ມູນທີ່ພວກເຮົາສົນໃຈ; ທ່ານພຽງແຕ່ຕ້ອງການລົງທະບຽນການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ, ເລືອກຕາຕະລາງ (ໃນກໍລະນີຂອງພວກເຮົາ, ການລວບລວມຂໍ້ມູນ, ນັບຕັ້ງແຕ່ພວກເຮົາໃຊ້ MongoDB), ແລະລະບຸຂົງເຂດທີ່ສົນໃຈກັບພວກເຮົາ. .

ດ້ວຍເຫດນີ້, ພວກເຮົາຈຶ່ງໄດ້ມີຕົ້ນແບບທີ່ດີຂອງເວທີການຕັດສິນໃຈ, ແລະໃນລະຫວ່າງການສາທິດ, ຜູ້ຟັງແຕ່ລະຄົນສາມາດກວດສອບປະສິດທິພາບຂອງຕົນເອງໄດ້. ການແກ້ໄຂທີ່ຫນ້າສົນໃຈ, ແບບຕົ້ນແບບສໍາເລັດຮູບແລະການສາທິດທີ່ປະສົບຜົນສໍາເລັດໄດ້ອະນຸຍາດໃຫ້ພວກເຮົາຊະນະ, ເຖິງວ່າຈະມີການແຂ່ງຂັນທີ່ເຂັ້ມແຂງຈາກທີມອື່ນໆ. ຂ້າພະເຈົ້າແນ່ໃຈວ່າບົດຄວາມທີ່ຫນ້າສົນໃຈກໍ່ສາມາດຂຽນຢູ່ໃນໂຄງການຂອງແຕ່ລະທີມ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com