Hey Habr! ຂ້າ​ພະ​ເຈົ້າ​ນໍາ​ສະ​ເຫນີ​ໃຫ້​ທ່ານ​ສົນ​ໃຈ​ການ​ແປ​ພາ​ສາ​ຂອງ​ບົດ​ຄວາມ​ໄດ້​ "ຍົນຂໍ້ມູນຕາຂ່າຍບໍລິການທຽບກັບຍົນຄວບຄຸມ" ຜູ້ຂຽນ Matt Klein.

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

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

ສະຖານະການແມ່ນສະຫຼຸບໄດ້ດີທີ່ສຸດໂດຍຊຸດ tweets ຕໍ່ໄປນີ້ທີ່ຂ້ອຍຂຽນໃນເດືອນກໍລະກົດ:

ຄວາມສັບສົນຂອງຕາຫນ່າງການບໍລິການ #1: Linkerd ~ = Nginx ~ = Haproxy ~ = ທູດ. ບໍ່ມີພວກມັນເທົ່າກັບ Istio. Istio ແມ່ນບາງສິ່ງບາງຢ່າງທີ່ແຕກຕ່າງກັນຫມົດ. 1/

ທໍາອິດແມ່ນພຽງແຕ່ແຜນການຂໍ້ມູນ. ດ້ວຍ​ຕົວ​ເອງ​ເຂົາ​ເຈົ້າ​ບໍ່​ໄດ້​ເຮັດ​ຫຍັງ. ພວກເຂົາຕ້ອງຢູ່ໃນອາລົມສໍາລັບບາງສິ່ງບາງຢ່າງຫຼາຍ. 2/

Istio ແມ່ນຕົວຢ່າງຂອງຍົນຄວບຄຸມທີ່ເຊື່ອມຕໍ່ພາກສ່ວນຕ່າງໆຮ່ວມກັນ. ນີ້ແມ່ນຊັ້ນອື່ນ. /ສິ້ນສຸດ

tweets ທີ່ຜ່ານມາກ່າວເຖິງໂຄງການທີ່ແຕກຕ່າງກັນຫຼາຍ (Linkerd, NGINX, HAProxy, Envoy, ແລະ Istio), ແຕ່ສໍາຄັນກວ່ານັ້ນແມ່ນແນະນໍາແນວຄວາມຄິດທົ່ວໄປຂອງຍົນຂໍ້ມູນ, ຕາຫນ່າງການບໍລິການ, ແລະຍົນຄວບຄຸມ. ໃນບົດຂຽນນີ້, ຂ້ອຍຈະເອົາບາດກ້າວກັບຄືນໄປບ່ອນແລະເວົ້າກ່ຽວກັບສິ່ງທີ່ຂ້ອຍຫມາຍເຖິງໂດຍຄໍາວ່າ "ຍົນຂໍ້ມູນ" ແລະ "ຍົນຄວບຄຸມ" ໃນລະດັບທີ່ສູງ, ແລະຫຼັງຈາກນັ້ນສົນທະນາກ່ຽວກັບວິທີການນໍາໃຊ້ກັບໂຄງການທີ່ໄດ້ກ່າວມາໃນ tweets.

ຕາຫນ່າງການບໍລິການແມ່ນຫຍັງ, ແທ້?

ຮູບທີ 1: ພາບລວມຂອງຕາໜ່າງການບໍລິການ

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

ຍົນຂໍ້ມູນ

ໃນຕາໜ່າງການບໍລິການ, ເຊີບເວີພຣັອກຊີທີ່ຕັ້ງຢູ່ໃນທ້ອງຖິ່ນສຳລັບແອັບພລິເຄຊັນປະຕິບັດໜ້າວຽກຕໍ່ໄປນີ້:

• ການຄົ້ນພົບການບໍລິການ. ບໍລິການ/ແອັບພລິເຄຊັນໃດແດ່ທີ່ມີໃຫ້ກັບແອັບພລິເຄຊັນຂອງເຈົ້າ?
• ກວດສຸຂະພາບ. ຕົວຢ່າງການບໍລິການທີ່ສົ່ງຄືນໂດຍການຄົ້ນພົບການບໍລິການມີສຸຂະພາບດີແລະພ້ອມທີ່ຈະຍອມຮັບການຈະລາຈອນເຄືອຂ່າຍບໍ? ນີ້ສາມາດປະກອບມີທັງ active (ເຊັ່ນ: ການຕອບສະຫນອງ / ການກວດສອບສຸຂະພາບ) ແລະ passive (ເຊັ່ນ: ການໃຊ້ 3 ຂໍ້ຜິດພາດ 5xx ຕິດຕໍ່ກັນເປັນການຊີ້ບອກເຖິງສະຖານະການບໍລິການທີ່ບໍ່ດີ) ການກວດສອບ.
• ກຳນົດເສັ້ນທາງ. ເມື່ອໄດ້ຮັບການຮ້ອງຂໍໃຫ້ "/foo" ຈາກບໍລິການ REST, ກຸ່ມບໍລິການໃດຄວນຖືກສົ່ງໄປຫາ?
• ການດຸ່ນດ່ຽງການໂຫຼດ. ເມື່ອກຸ່ມບໍລິການຖືກເລືອກໃນລະຫວ່າງການກຳນົດເສັ້ນທາງ, ການຮ້ອງຂໍການບໍລິການຄວນສົ່ງໄປຫາຕົວຢ່າງໃດ? ກັບເວລາໃດ? ດ້ວຍການຕັ້ງຄ່າການທຳລາຍວົງຈອນອັນໃດ? ຖ້າການຮ້ອງຂໍລົ້ມເຫລວ, ມັນຄວນຈະຖືກລອງໃຫມ່ບໍ?
• ການກວດສອບແລະການອະນຸຍາດ. ສໍາລັບການຮ້ອງຂໍທີ່ເຂົ້າມາ, ການບໍລິການໂທຫາສາມາດຖືກລະບຸຕົວລະຫັດລັບ / ອະນຸຍາດໂດຍໃຊ້ mTLS ຫຼືບາງກົນໄກອື່ນໆບໍ? ຖ້າມັນຖືກຮັບຮູ້ / ອະນຸຍາດ, ມັນຖືກອະນຸຍາດໃຫ້ໂທຫາການດໍາເນີນງານທີ່ຮ້ອງຂໍ (ຈຸດສິ້ນສຸດ) ໃນການບໍລິການຫຼືຄວນສົ່ງຄືນຄໍາຕອບທີ່ບໍ່ໄດ້ຮັບການຢືນຢັນບໍ?
• ການສັງເກດການ. ສະຖິຕິລາຍລະອຽດ, ບັນທຶກ / ບັນທຶກ, ແລະຂໍ້ມູນການຕິດຕາມທີ່ແຈກຢາຍຄວນຈະຖືກສ້າງຂື້ນສໍາລັບແຕ່ລະຄໍາຮ້ອງຂໍເພື່ອໃຫ້ຜູ້ປະກອບການສາມາດເຂົ້າໃຈການໄຫຼວຽນຂອງການຈະລາຈອນທີ່ແຈກຢາຍແລະບັນຫາການແກ້ບັນຫາທີ່ເກີດຂື້ນ.

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

ຍົນ​ຄວບ​ຄຸມ

ການ abstraction ເຄືອຂ່າຍທີ່ຕົວແທນທ້ອງຖິ່ນໃຫ້ຢູ່ໃນຍົນຂໍ້ມູນແມ່ນ magical (?). ຢ່າງໃດກໍ່ຕາມ, ຕົວແທນຈະຮູ້ແນວໃດກ່ຽວກັບເສັ້ນທາງ "/foo" ເພື່ອໃຫ້ບໍລິການ B? ຂໍ້​ມູນ​ການ​ຄົ້ນ​ພົບ​ຂອງ​ບໍ​ລິ​ການ​ທີ່​ປະ​ກອບ​ດ້ວຍ​ການ​ຮ້ອງ​ຂໍ​ຕົວ​ແທນ​ຈະ​ຖືກ​ນໍາ​ໃຊ້​ແນວ​ໃດ​? ຕົວກໍານົດການຖືກຕັ້ງຄ່າສໍາລັບການດຸ່ນດ່ຽງການໂຫຼດ, ການຫມົດເວລາ, ການທໍາລາຍວົງຈອນ, ແລະອື່ນໆແນວໃດ? ເຈົ້ານຳໃຊ້ແອັບພລິເຄຊັນໂດຍໃຊ້ວິທີສີຟ້າ/ສີຂຽວ ຫຼືວິທີການປ່ຽນການຈະລາຈອນທີ່ສະຫງ່າງາມແນວໃດ? ໃຜເປັນຜູ້ຕັ້ງຄ່າການພິສູດຢືນຢັນທົ່ວລະບົບ ແລະການຕັ້ງຄ່າການອະນຸຍາດ?

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

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

ຮູບທີ 2: ຍົນຄວບຄຸມມະນຸດ

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

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

ຮູບທີ 3: ຍົນຄວບຄຸມຕາຫນ່າງການບໍລິການຂັ້ນສູງ

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

• ມະນຸດ: ຍັງມີບຸກຄົນ (ຫວັງວ່າຈະໃຈຮ້າຍຫນ້ອຍລົງ) ທີ່ຕັດສິນໃຈໃນລະດັບສູງກ່ຽວກັບລະບົບທັງຫມົດໂດຍລວມ.
• ຄວບຄຸມ UI ຍົນ: ບຸກຄົນໃດຫນຶ່ງພົວພັນກັບບາງປະເພດຂອງການໂຕ້ຕອບຜູ້ໃຊ້ເພື່ອຄວບຄຸມລະບົບ. ນີ້ອາດຈະເປັນເວັບບອດ, ຄໍາຮ້ອງສະຫມັກເສັ້ນຄໍາສັ່ງ (CLI), ຫຼືບາງສ່ວນຕິດຕໍ່ອື່ນໆ. ການ​ນໍາ​ໃຊ້​ການ​ໂຕ້​ຕອບ​ຜູ້​ໃຊ້​, ປະ​ຕິ​ບັດ​ການ​ມີ​ການ​ເຂົ້າ​ເຖິງ​ຕົວ​ກໍາ​ນົດ​ການ​ຕັ້ງ​ຄ່າ​ລະ​ບົບ​ທົ່ວ​ໂລກ​ເຊັ່ນ​:
  • ການຄວບຄຸມການນຳໃຊ້, ສີຟ້າ/ສີຂຽວ ແລະ/ຫຼື ການຫັນປ່ຽນການຈະລາຈອນເທື່ອລະກ້າວ
  • ທາງເລືອກໃນການກວດສອບແລະການອະນຸຍາດ
  • ຕາຕະລາງກໍານົດເສັ້ນທາງ, ຕົວຢ່າງເມື່ອແອັບພລິເຄຊັນ A ຮ້ອງຂໍຂໍ້ມູນກ່ຽວກັບ "/foo" ສິ່ງທີ່ເກີດຂື້ນ
  • ການຕັ້ງຄ່າການດຸ່ນດ່ຽງການໂຫຼດ, ເຊັ່ນວ່າໝົດເວລາ, ລອງໃໝ່, ການຕັ້ງຄ່າການຕັດວົງຈອນ, ແລະອື່ນໆ.
• ຕາຕະລາງວຽກ: ການບໍລິການດໍາເນີນການຢູ່ໃນໂຄງສ້າງພື້ນຖານໂດຍຜ່ານບາງປະເພດຂອງລະບົບການຈັດຕາຕະລາງ / orchestration, ເຊັ່ນ Kubernetes ຫຼື Nomad. ຜູ້ກຳນົດເວລາແມ່ນຮັບຜິດຊອບໃນການໂຫຼດການບໍລິການພ້ອມກັບຕົວແທນທ້ອງຖິ່ນຂອງມັນ.
• ການຄົ້ນພົບການບໍລິການ. ເມື່ອຕົວກໍານົດເວລາເລີ່ມຕົ້ນແລະຢຸດການບໍລິການຕົວຢ່າງ, ມັນຈະລາຍງານສະຖານະການສຸຂະພາບກັບລະບົບການຄົ້ນພົບການບໍລິການ.
• Sidecar proxy configuration APIs : ຕົວແທນທ້ອງຖິ່ນຈະສະກັດສະຖານະແບບໄດນາມິກຈາກອົງປະກອບຂອງລະບົບຕ່າງໆໂດຍໃຊ້ຕົວແບບທີ່ສອດຄ່ອງກັນໃນທີ່ສຸດໂດຍບໍ່ມີການແຊກແຊງຂອງຜູ້ປະຕິບັດງານ. ລະບົບທັງໝົດ, ປະກອບດ້ວຍທຸກບໍລິການທີ່ກຳລັງແລ່ນຢູ່ໃນຂະນະນີ້ ແລະເຊີບເວີພຣັອກຊີທ້ອງຖິ່ນ, ໃນທີ່ສຸດກໍຈະລວມເຂົ້າກັນເປັນລະບົບນິເວດດຽວ. API ຂອງຍົນຂໍ້ມູນສາກົນຂອງ Envoy ແມ່ນຕົວຢ່າງໜຶ່ງຂອງວິທີການເຮັດວຽກໃນພາກປະຕິບັດ.

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

ຍົນຂໍ້ມູນ ແລະຍົນຄວບຄຸມ. ຂໍ້ມູນຍົນທຽບກັບບົດສະຫຼຸບຂອງຍົນຄວບຄຸມ

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

ພູມສັນຖານຂອງໂຄງການປະຈຸບັນ

ໂດຍໄດ້ເຂົ້າໃຈຄໍາອະທິບາຍຂ້າງເທິງ, ໃຫ້ເບິ່ງສະຖານະການປະຈຸບັນຂອງໂຄງການຕາຫນ່າງການບໍລິການ.

• ຍົນຂໍ້ມູນ: Linkerd, NGINX, HAProxy, Envoy, Traefik
• ຄວບຄຸມຍົນ: Istio, Nelson, SmartStack

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

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

Istio ໄດ້ຖືກປະກາດໃນເດືອນພຶດສະພາ 2017. ເປົ້າຫມາຍຂອງໂຄງການ Istio ແມ່ນຄ້າຍຄືກັນກັບຍົນຄວບຄຸມການຂະຫຍາຍທີ່ສະແດງຢູ່ໃນ ຮູບທີ 3. Envoy ສໍາລັບ Istio ແມ່ນຕົວແທນເລີ່ມຕົ້ນ. ດັ່ງນັ້ນ, Istio ແມ່ນຍົນຄວບຄຸມ, ແລະ Envoy ແມ່ນຍົນຂໍ້ມູນ. ໃນເວລາສັ້ນໆ, Istio ສ້າງຄວາມຕື່ນເຕັ້ນຫຼາຍ, ແລະຍົນຂໍ້ມູນອື່ນໆໄດ້ເລີ່ມຕົ້ນປະສົມປະສານເປັນການທົດແທນ Envoy (ທັງ Linkerd ແລະ NGINX ສະແດງໃຫ້ເຫັນການເຊື່ອມໂຍງກັບ Istio). ຄວາມຈິງທີ່ວ່າຍົນຂໍ້ມູນທີ່ແຕກຕ່າງກັນສາມາດຖືກນໍາໃຊ້ພາຍໃນຍົນຄວບຄຸມດຽວກັນຫມາຍຄວາມວ່າຍົນຄວບຄຸມແລະຍົນຂໍ້ມູນບໍ່ຈໍາເປັນຕ້ອງເປັນຄູ່ກັນຢ່າງແຫນ້ນຫນາ. API ເຊັ່ນ API ຂອງຍົນຂໍ້ມູນທົ່ວໄປຂອງ Envoy ສາມາດສ້າງຂົວລະຫວ່າງສອງພາກສ່ວນຂອງລະບົບໄດ້.

Nelson ແລະ SmartStack ຊ່ວຍສະແດງໃຫ້ເຫັນເຖິງການແຍກຕົວຂອງຍົນຄວບຄຸມແລະຍົນຂໍ້ມູນ. Nelson ໃຊ້ Envoy ເປັນຕົວແທນຂອງຕົນແລະສ້າງຍົນຄວບຄຸມທີ່ເຊື່ອຖືໄດ້ສໍາລັບຕາຫນ່າງການບໍລິການໂດຍອີງໃສ່ HashiCorp stack, i.e. Nomad, ແລະອື່ນໆ. SmartStack ບາງທີອາດເປັນຄັ້ງທໍາອິດຂອງຄື້ນໃຫມ່ຂອງຕາຫນ່າງການບໍລິການ. SmartStack ສ້າງຍົນຄວບຄຸມປະມານ HAProxy ຫຼື NGINX, ສະແດງໃຫ້ເຫັນຄວາມສາມາດໃນການແຍກຍົນຄວບຄຸມຈາກຕາຫນ່າງບໍລິການຈາກຍົນຂໍ້ມູນ.

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

ການ​ຮັບ​ເອົາ​ທີ່​ສໍາ​ຄັນ​

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

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