Service Mesh: ສິ່ງທີ່ນັກວິສະວະກອນຊອບແວທຸກຄົນຕ້ອງຮູ້ກ່ຽວກັບເຕັກໂນໂລຢີທີ່ຮ້ອນທີ່ສຸດ

ຫມາຍ​ເຫດ​. ແປ.: ຕາໜ່າງການບໍລິການແມ່ນປະກົດການທີ່ຍັງບໍ່ທັນມີການແປທີ່ໝັ້ນຄົງເປັນພາສາລັດເຊຍ (ຫຼາຍກວ່າ 2 ປີກ່ອນພວກເຮົາໄດ້ສະເໜີທາງເລືອກ “ຕາໜ່າງສຳລັບການບໍລິການ”, ແລະ ຕໍ່ມາໜ້ອຍໜຶ່ງ, ເພື່ອນຮ່ວມງານບາງຄົນກໍ່ເລີ່ມສົ່ງເສີມການລວມເຂົ້າກັນ “sieve ບໍລິການ”). . ການສົນທະນາຢ່າງຕໍ່ເນື່ອງກ່ຽວກັບເທກໂນໂລຍີນີ້ໄດ້ນໍາໄປສູ່ສະຖານະການທີ່ອົງປະກອບດ້ານກາລະຕະຫຼາດແລະດ້ານວິຊາການມີຄວາມກ່ຽວຂ້ອງກັນຢ່າງໃກ້ຊິດເກີນໄປ. ເອກະສານທີ່ປະເສີດນີ້ຈາກຫນຶ່ງໃນຜູ້ຂຽນຂອງຄໍາສັບຕົ້ນສະບັບແມ່ນມີຈຸດປະສົງເພື່ອເຮັດໃຫ້ຄວາມຊັດເຈນກັບວິສະວະກອນແລະບໍ່ພຽງແຕ່.

ຄອມຈາກ Sebastian Caceres

ການນໍາສະເຫນີ

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

ຕາໜ່າງບໍລິການເກີດຢູ່ໃນນ້ຳທີ່ຂີ້ມູກ, ທ່າອຽງຂອງລະບົບນິເວດພື້ນເມືອງຂອງເມຄ. ແຕ່ຫນ້າເສຍດາຍ, ນີ້ຫມາຍຄວາມວ່າຫຼາຍຂອງການຂັດແຍ້ງທີ່ອ້ອມຮອບມັນຕັ້ງແຕ່ "ການສົນທະນາທີ່ມີແຄລໍລີ່ຕ່ໍາ" ຫາ - ການນໍາໃຊ້ຄໍາສັບດ້ານວິຊາການ - bullshit blatant. ແຕ່ຖ້າທ່ານກັ່ນຕອງສິ່ງລົບກວນທັງຫມົດ, ທ່ານສາມາດຊອກຫາວ່າຕາຫນ່າງການບໍລິການມີຫນ້າທີ່ທີ່ແທ້ຈິງ, ແນ່ນອນແລະສໍາຄັນ.

ໃນບົດຂຽນນີ້, ຂ້ອຍຈະພະຍາຍາມເຮັດແນວນັ້ນ: ໃຫ້ຄໍາແນະນໍາດ້ານວິສະວະກອນທີ່ມີຄວາມຊື່ສັດ, ເລິກເຊິ່ງ, ຮັດກຸມກັບຕາຫນ່າງການບໍລິການ. ຂ້ອຍຈະຕອບຫຼາຍກວ່າຄໍາຖາມ: "ມັນ​ແມ່ນ​ຫຍັງ?", - ແຕ່ຍັງ "ເປັນຫຍັງ?"ແລະ "ເປັນຫຍັງຕອນນີ້?". ສຸດທ້າຍ, ຂ້ອຍຈະພະຍາຍາມອະທິບາຍວ່າເປັນຫຍັງ (ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ) ເຕັກໂນໂລຢີສະເພາະນີ້ເຮັດໃຫ້ເກີດການ hype Crazy, ເຊິ່ງໃນຕົວຂອງມັນເອງເປັນເລື່ອງທີ່ຫນ້າສົນໃຈ.

ຂ້ອຍ​ແມ່ນ​ໃຜ?

ສະບາຍດີທຸກຄົນ! ຊື່​ຂອງ​ຂ້ອຍ​ແມ່ນ William Morgan. ຂ້ອຍເປັນຫນຶ່ງໃນຜູ້ສ້າງ Linkerd - ໂຄງການຕາຫນ່າງການບໍລິການທໍາອິດທີ່ສຸດແລະໂຄງການທີ່ຈະຕໍານິຕິຕຽນຮູບລັກສະນະຂອງໄລຍະ ຕາຫນ່າງການບໍລິການ ດັ່ງ​ນັ້ນ (ຂໍ​ອະ​ໄພ guys!). (ຫມາຍເຫດ transl.: ໂດຍວິທີທາງການ, ໃນອາລຸນຂອງຮູບລັກສະນະຂອງຄໍາສັບນີ້, ຫຼາຍກວ່າ 2,5 ປີກ່ອນຫນ້ານີ້, ພວກເຮົາໄດ້ແປເອກະສານໃນຕອນຕົ້ນຂອງຜູ້ຂຽນດຽວກັນເອີ້ນວ່າ ".ຕາໜ່າງບໍລິການແມ່ນຫຍັງ ແລະເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງການມັນ [ສຳລັບແອັບພລິເຄຊັນຄລາວກັບບໍລິການຈຸລະພາກ]?".) ຂ້າພະເຈົ້າຍັງນໍາພາ ລອຍນ້ ຳ ເປັນການເລີ່ມຕົ້ນທີ່ສ້າງຕາຫນ່າງການບໍລິການທີ່ເຢັນເຊັ່ນ Linkerd ແລະ Dive.

ເຈົ້າອາດຈະເດົາໄດ້ວ່າຂ້ອຍມີຄວາມຄິດເຫັນທີ່ລຳອຽງ ແລະເປັນຫົວຂໍ້ຫຼາຍກ່ຽວກັບເລື່ອງນີ້. ແນວໃດກໍ່ຕາມ, ຂ້ອຍຈະພະຍາຍາມຮັກສາຄວາມລຳອຽງໃຫ້ໜ້ອຍທີ່ສຸດ (ຍົກເວັ້ນພາກສ່ວນໜຶ່ງ: "ເປັນຫຍັງມີການເວົ້າຫຼາຍກ່ຽວກັບຕາຫນ່າງການບໍລິການ?", - ໃນທີ່ຂ້າພະເຈົ້າຈະແບ່ງປັນແນວຄວາມຄິດ preconceived ຂອງຂ້າພະເຈົ້າ). ຂ້າ​ພະ​ເຈົ້າ​ຍັງ​ຈະ​ເຮັດ​ໃຫ້​ດີ​ທີ່​ສຸດ​ເພື່ອ​ເຮັດ​ໃຫ້​ຄໍາ​ແນະ​ນໍາ​ນີ້​ເປັນ​ຈຸດ​ປະ​ສົງ​ທີ່​ເປັນ​ໄປ​ໄດ້​. ໃນຕົວຢ່າງສະເພາະ, ຂ້ອຍຈະອີງໃສ່ປະສົບການຂອງ Linkerd ສ່ວນໃຫຍ່, ໃນຂະນະທີ່ຊີ້ໃຫ້ເຫັນຄວາມແຕກຕ່າງ (ຖ້າມີ) ທີ່ຂ້ອຍຮູ້ໃນການປະຕິບັດຕາຫນ່າງການບໍລິການປະເພດອື່ນໆ.

ຕົກລົງ, ມັນເຖິງເວລາແລ້ວທີ່ຈະກ້າວໄປສູ່ການປິ່ນປົວ.

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

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

ຕົວແທນນີ້ແມ່ນຫຍັງ? ນີ້ແມ່ນ TCP proxy ຂອງໝວດ "Layer 7-aware". (i.e. "ຄໍານຶງເຖິງ" ຊັ້ນທີ 7 ຂອງຮູບແບບ OSI) ເຊັ່ນ HAProxy ແລະ NGINX. ທ່ານສາມາດເລືອກຕົວແທນຕາມຄວາມມັກຂອງທ່ານ; Linkerd ໃຊ້ຕົວແທນ Rust, ຊື່ທີ່ບໍ່ສັບສົນ linkerd-proxy. ພວກເຮົາໄດ້ລວບລວມມັນໂດຍສະເພາະສໍາລັບຕາຫນ່າງການບໍລິການ. ຕາຫນ່າງອື່ນໆມັກຕົວແທນອື່ນໆ (Envoy ແມ່ນທາງເລືອກທົ່ວໄປ). ຢ່າງໃດກໍ່ຕາມ, ການເລືອກຕົວແທນແມ່ນພຽງແຕ່ເປັນເລື່ອງຂອງການປະຕິບັດ.

ເຊີບເວີພຣັອກຊີເຫຼົ່ານີ້ເຮັດຫຍັງ? ແນ່ນອນ, ພວກເຂົາໂທຫາຕົວແທນໄປຫາແລະຈາກການບໍລິການ (ເວົ້າຢ່າງເຂັ້ມງວດ, ພວກເຂົາເຮັດຫນ້າທີ່ເປັນຕົວແທນແລະຕົວແທນ reverse, ຈັດການທັງການໂທເຂົ້າແລະໂທອອກ). ແລະພວກເຂົາປະຕິບັດຊຸດຄຸນນະສົມບັດທີ່ສຸມໃສ່ການໂທ ລະຫວ່າງ ການບໍລິການ. ຈຸດສຸມນີ້ກ່ຽວກັບການຈະລາຈອນລະຫວ່າງການບໍລິການແມ່ນສິ່ງທີ່ຈໍາແນກການບໍລິການຕາຫນ່າງຕົວແທນຈາກ, ເວົ້າ, API gateways ຫຼື ingress proxies (ອັນສຸດທ້າຍແມ່ນສຸມໃສ່ການໂທເຂົ້າມາໃນກຸ່ມຈາກໂລກພາຍນອກ). (ຫມາຍ​ເຫດ​. ແປ.: ສໍາລັບການປຽບທຽບຕົວຄວບຄຸມ Kubernetes Ingress ທີ່ມີຢູ່ແລ້ວ, ຈໍານວນຫຼາຍທີ່ໃຊ້ Envoy ທີ່ໄດ້ກ່າວມາແລ້ວ, ເບິ່ງ ບົດຂຽນນີ້.)

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

ຂ້າງລຸ່ມນີ້ແມ່ນແຜນວາດຂອງຍົນຄວບຄຸມແລະຍົນຂໍ້ມູນໃນ Linkerd. ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ຍົນຄວບຄຸມປະກອບມີອົງປະກອບທີ່ແຕກຕ່າງກັນຫຼາຍ, ລວມທັງຕົວຢ່າງ Prometheus ທີ່ເກັບກໍາ metrics ຈາກເຄື່ອງແມ່ຂ່າຍຂອງຕົວແທນ, ເຊັ່ນດຽວກັນກັບອົງປະກອບອື່ນໆເຊັ່ນ: destination (ການ​ຄົ້ນ​ພົບ​ການ​ບໍ​ລິ​ການ​)​, identity (ອຳນາດການຢັ້ງຢືນ, CA) ແລະ public-api (ຈຸດສິ້ນສຸດສໍາລັບເວັບ ແລະ CLI). ໃນທາງກົງກັນຂ້າມ, ຍົນຂໍ້ມູນແມ່ນ linkerd-proxy ງ່າຍໆທີ່ຢູ່ຕິດກັບຕົວຢ່າງຂອງແອັບພລິເຄຊັນ. ນີ້ແມ່ນພຽງແຕ່ແຜນວາດເຫດຜົນ; ໃນ​ການ​ນໍາ​ໃຊ້​ໃນ​ໂລກ​ທີ່​ແທ້​ຈິງ​, ທ່ານ​ອາດ​ຈະ​ມີ​ສາມ replicas ຂອງ​ແຕ່​ລະ​ອົງ​ປະ​ກອບ​ຍົນ​ຄວບ​ຄຸມ​ແລະ​ຫຼາຍ​ຮ້ອຍ​ຫຼື​ເປັນ​ພັນ​ຕົວ​ແທນ​ຂອງ​ຍົນ​ຂໍ້​ມູນ​.

(ກ່ອງສີຟ້າໃນແຜນວາດນີ້ສະແດງເຖິງຂອບຂອງຝັກ Kubernetes. ທ່ານສາມາດເຫັນໄດ້ວ່າກ່ອງບັນຈຸທີ່ມີ linkerd-proxy ຢູ່ໃນຝັກດຽວກັນກັບກ່ອງບັນຈຸຂອງແອັບພລິເຄຊັນ. ໂຄງການນີ້ເອີ້ນວ່າ: ຕູ້ຄອນເທນເນີ sidecar.)

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

ຜົນສະທ້ອນທີ່ສໍາຄັນອີກອັນຫນຶ່ງແມ່ນວ່າຕາຫນ່າງການບໍລິການຕ້ອງການ ໃຫຍ່ ຈໍານວນຂອງຕົວແທນ. ໃນຄວາມເປັນຈິງ, Linkerd chains linkerd-proxy ກັບທຸກໆຕົວຢ່າງຂອງທຸກໆການບໍລິການ (ການປະຕິບັດອື່ນໆເພີ່ມຕົວແທນໃຫ້ກັບທຸກໆ host / host / VM. ນັ້ນແມ່ນຫຼາຍແລ້ວ). ການໃຊ້ຕົວແທນດັ່ງກ່າວຢ່າງຫ້າວຫັນໃນຕົວຂອງມັນເອງເຮັດໃຫ້ເກີດອາການແຊກຊ້ອນເພີ່ມເຕີມຈໍານວນຫນຶ່ງ:

1. ຕົວແທນໃນຍົນຂໍ້ມູນຄວນຈະເປັນ ໄວ, ເນື່ອງຈາກວ່າແຕ່ລະການໂທມີສອງສາມການໂທກັບຕົວແທນ: ຫນຶ່ງຢູ່ໃນຝ່າຍລູກຄ້າ, ຫນຶ່ງຢູ່ຂ້າງເຊີຟເວີ.
2. ນອກຈາກນັ້ນ, ຕົວແທນຈະຕ້ອງເປັນ ຂະຫນາດນ້ອຍ и ນ້ຳໜັກເບົາ. ແຕ່ລະຄົນຈະບໍລິໂພກຊັບພະຍາກອນຂອງຫນ່ວຍຄວາມຈໍາແລະ CPU, ແລະການບໍລິໂພກນີ້ຈະເຕີບໂຕຂຶ້ນກັບຄໍາຮ້ອງສະຫມັກ.
3. ທ່ານຈະຕ້ອງມີກົນໄກເພື່ອປັບໃຊ້ ແລະອັບເດດຕົວແທນຈຳນວນຫຼວງຫຼາຍ. ການເຮັດມັນດ້ວຍຕົນເອງບໍ່ແມ່ນທາງເລືອກ.

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

ມັນເຖິງເວລາສໍາລັບຄໍາຖາມ "ເປັນຫຍັງ?"

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

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

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

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

ຕົວຢ່າງ, ໃນ Linkerd (ເຊັ່ນດຽວກັບຕາຫນ່າງສ່ວນໃຫຍ່) ຫນ້າທີ່ເຮັດວຽກແມ່ນສຸມໃສ່ການໂທ HTTP ຕົ້ນຕໍ, ລວມທັງ HTTP/2 ແລະ gRPC*. ການທໍາງານແມ່ນຂ້ອນຂ້າງອຸດົມສົມບູນ - ມັນສາມາດແບ່ງອອກເປັນສາມຫ້ອງຮຽນ:

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

* ຈາກທັດສະນະຂອງ Linkerd, gRPC ແມ່ນບໍ່ແຕກຕ່າງຈາກ HTTP/2: ມັນພຽງແຕ່ໃຊ້ protobuf ໃນ payload. ຈາກທັດສະນະຂອງນັກພັດທະນາ, ສອງສິ່ງນີ້ແມ່ນ, ແນ່ນອນ, ແຕກຕ່າງກັນ.

ກົນໄກເຫຼົ່ານີ້ຈໍານວນຫຼາຍດໍາເນີນການຢູ່ໃນລະດັບການຮ້ອງຂໍ (ເພາະສະນັ້ນ "ຕົວແທນ L7"). ຕົວຢ່າງ, ຖ້າບໍລິການ Foo ເຮັດການໂທ HTTP ໄປຫາແຖບບໍລິການ, linkerd-proxy ຢູ່ຂ້າງຂອງ Foo ສາມາດອັດສະລິຍະ Load-balance ແລະເສັ້ນທາງການໂທຈາກ Foo ໄປຫາ Bar instances ໂດຍອີງໃສ່ latency ທີ່ສັງເກດເຫັນ; ມັນ​ສາ​ມາດ​ເຮັດ​ເລ​ື້ມ​ຄືນ​ການ​ຮ້ອງ​ຂໍ​ຖ້າ​ຫາກ​ວ່າ​ມີ​ຄວາມ​ຈໍາ​ເປັນ (ແລະ​ຖ້າ​ຫາກ​ວ່າ​ມັນ​ແມ່ນ​ບໍ່​ມີ​ອໍາ​ນາດ​)​; ລາວສາມາດບັນທຶກລະຫັດຕອບສະຫນອງແລະການຫມົດເວລາ, ແລະອື່ນໆ. ເຊັ່ນດຽວກັນ, linkerd-proxy ຢູ່ຂ້າງແຖບສາມາດປະຕິເສດຄໍາຮ້ອງຂໍຖ້າມັນບໍ່ໄດ້ຮັບອະນຸຍາດຫຼືຖ້າກໍານົດຂອບເຂດການຮ້ອງຂໍແມ່ນເກີນ; ສາມາດແກ້ໄຂຄວາມລ່າຊ້າໃນສ່ວນຂອງມັນ, ແລະອື່ນໆ.

ຕົວແທນສາມາດ "ເຮັດບາງສິ່ງບາງຢ່າງ" ໃນລະດັບການເຊື່ອມຕໍ່ເຊັ່ນກັນ. ຕົວຢ່າງ, linkerd-proxy ໃນດ້ານ Foo ສາມາດລິເລີ່ມການເຊື່ອມຕໍ່ TLS, ແລະ linkerd-proxy ຢູ່ຂ້າງ Bar ສາມາດຢຸດມັນໄດ້, ແລະທັງສອງຝ່າຍສາມາດກວດສອບໃບຢັ້ງຢືນ TLS ຂອງກັນແລະກັນ*. ນີ້ສະຫນອງບໍ່ພຽງແຕ່ການເຂົ້າລະຫັດລະຫວ່າງການບໍລິການ, ແຕ່ຍັງເປັນວິທີການທີ່ປອດໄພ cryptographically ເພື່ອກໍານົດການບໍລິການ: Foo ແລະ Bar ສາມາດ "ພິສູດ" ວ່າພວກເຂົາແມ່ນໃຜທີ່ພວກເຂົາເວົ້າວ່າພວກເຂົາເປັນ.

* "ເພື່ອນຂອງເພື່ອນ" ຫມາຍຄວາມວ່າໃບຢັ້ງຢືນຂອງລູກຄ້າຍັງຖືກກວດສອບ (TLS ເຊິ່ງກັນແລະກັນ). ສໍາລັບຕົວຢ່າງ, ໃນ "ຄລາສສິກ" TLS, ລະຫວ່າງຕົວທ່ອງເວັບແລະເຄື່ອງແມ່ຂ່າຍ, ໃບຢັ້ງຢືນພຽງແຕ່ຂ້າງຫນຶ່ງ (ເຄື່ອງແມ່ຂ່າຍ) ປົກກະຕິແລ້ວແມ່ນການກວດສອບ.

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

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

ເປັນຫຍັງຕາໜ່າງບໍລິການຈຶ່ງເປັນຄວາມຄິດທີ່ດີ

ໃນຂະນະທີ່ຄວາມສາມາດຂອງຕາຫນ່າງການບໍລິການແມ່ນເປັນທີ່ຈັບໃຈ, ມູນຄ່າຕົ້ນຕໍຂອງມັນບໍ່ໄດ້ນອນຢູ່ໃນລັກສະນະ. ໃນທີ່ສຸດພວກເຮົາ ສາ​ມາດ ປະຕິບັດໃຫ້ເຂົາເຈົ້າໂດຍກົງໃນຄໍາຮ້ອງສະຫມັກ (ຕໍ່ມາພວກເຮົາຈະເຫັນວ່ານີ້ແມ່ນຕົ້ນກໍາເນີດຂອງຕາຫນ່າງການບໍລິການ). ເພື່ອເຮັດໃຫ້ມັນຢູ່ໃນປະໂຫຍກຫນຶ່ງ, ມູນຄ່າຂອງຕາຫນ່າງການບໍລິການແມ່ນ: ມັນສະຫນອງການເຮັດວຽກທີ່ສໍາຄັນຕໍ່ການເຮັດວຽກຊອບແວເຄື່ອງແມ່ຂ່າຍທີ່ທັນສະໄຫມໃນລັກສະນະທີ່ສອດຄ່ອງ, stack-wide, application-code-agnostic..

ໃຫ້ວິເຄາະຂໍ້ສະເຫນີນີ້.

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

(Okay, ຄວາມເຊື່ອຫມັ້ນຂອງຂ້ອຍວ່າວິທີການນີ້ແມ່ນວິທີການທີ່ທັນສະໄຫມໃນການສ້າງຊອບແວເຊີຟເວີໄດ້ເຂົ້າໄປໃນວັກກ່ອນຫນ້າ. ຄົນອື່ນມັກພັດທະນາ monoliths, "reactive microservices" ແລະສິ່ງອື່ນໆທີ່ບໍ່ຢູ່ພາຍໃຕ້ຄໍານິຍາມຂ້າງເທິງ. ຄົນເຫຼົ່ານີ້ອາດຈະເປັນ. ຄວາມຄິດເຫັນທີ່ແຕກຕ່າງຈາກຂ້ອຍ, ແລະໃນທາງກັບກັນ, ຂ້ອຍເຊື່ອວ່າພວກເຂົາ "ຜິດ" - ເຖິງແມ່ນວ່າໃນກໍລະນີໃດກໍ່ຕາມ, ຕາຫນ່າງການບໍລິການບໍ່ມີປະໂຫຍດຫຼາຍສໍາລັບພວກເຂົາ).

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

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

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

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

ໃຜເປັນຕາຫນ່າງບໍລິການຊ່ວຍ?

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

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

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

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

ມູນຄ່າການຈັດຕັ້ງຂອງການແບ່ງປັນດັ່ງກ່າວລະຫວ່າງເຈົ້າຂອງແພລະຕະຟອມແລະການບໍລິການບໍ່ສາມາດຖືກຄາດຄະເນເກີນ. ຂ້າພະເຈົ້າຄິດວ່ານາງປະກອບສ່ວນ ຕົ້ນຕໍ ການປະກອບສ່ວນກັບມູນຄ່າຂອງຕາຫນ່າງການບໍລິການ.

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

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

ຕາຫນ່າງການບໍລິການຈະແກ້ໄຂບັນຫາຂອງຂ້ອຍທັງຫມົດບໍ?

ແມ່ນແລ້ວ. ຂ້ອຍຫມາຍຄວາມວ່າ, ບໍ່!

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

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

1. ເອກະລາດຂອງເຫດຜົນທາງທຸລະກິດ. ວິທີການທີ່ໂທ histograms ຖືກສ້າງຂຶ້ນລະຫວ່າງ Foo ແລະ Bar ແມ່ນເອກະລາດຢ່າງສົມບູນ ເປັນຫຍັງ Foo ໂທ Bar.
2. ຍາກທີ່ຈະປະຕິບັດຢ່າງຖືກຕ້ອງ. ໃນ Linkerd, retry ແມ່ນ parameterized ກັບທຸກປະເພດຂອງສິ່ງທີ່ fancy ເຊັ່ນ: retry ງົບປະມານ. (ລອງໃຊ້ງົບປະມານໃໝ່), ນັບຕັ້ງແຕ່ວິທີການທີ່ມີຈິດໃຈທີ່ງ່າຍດາຍຕໍ່ການຈັດຕັ້ງປະຕິບັດສິ່ງດັ່ງກ່າວແນ່ນອນຈະນໍາໄປສູ່ການເກີດຂື້ນຂອງອັນທີ່ເອີ້ນວ່າ "ການຮ້ອງຂໍຂອງ avalanche" (ລອງພະຍຸໃໝ່) ແລະບັນຫາອື່ນໆສະເພາະຂອງລະບົບແຈກຢາຍ.
3. ມີປະສິດທິພາບຫຼາຍທີ່ສຸດເມື່ອນໍາໃຊ້ຢ່າງຕໍ່ເນື່ອງ. ກົນໄກ TLS ພຽງແຕ່ເຮັດໃຫ້ມີຄວາມຮູ້ສຶກຖ້າຫາກວ່ານໍາໃຊ້ຢູ່ທົ່ວທຸກແຫ່ງ.

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

ຕົວຢ່າງຂອງຄວາມສາມາດໃນການບໍລິການຕາຫນ່າງ

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

ເປັນຫຍັງຕາໜ່າງບໍລິການຈຶ່ງກາຍເປັນທີ່ນິຍົມໃນຕອນນີ້?

ເຈົ້າອາດຈະສົງໄສໃນຕອນນີ້: ຕົກລົງ, ຖ້າຕາໜ່າງການບໍລິການດີຫຼາຍ, ເປັນຫຍັງພວກເຮົາຈຶ່ງບໍ່ເລີ່ມນຳໃຊ້ຕົວແທນຫຼາຍລ້ານຕົວໃສ່ໃນ stack ສິບປີກ່ອນ?

ມີຄໍາຕອບ banal ສໍາລັບຄໍາຖາມນີ້: ສິບປີທີ່ຜ່ານມາທຸກຄົນກໍ່ສ້າງ monoliths, ແລະບໍ່ມີໃຜຕ້ອງການຕາຫນ່າງບໍລິການ. ນີ້ແມ່ນຄວາມຈິງ, ແຕ່ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ຄໍາຕອບນີ້ຂາດຈຸດ. ເຖິງແມ່ນວ່າສິບປີທີ່ຜ່ານມາ, ແນວຄວາມຄິດຂອງການບໍລິການຈຸລະພາກເປັນວິທີທີ່ດີທີ່ຈະສ້າງລະບົບຂະຫນາດໃຫຍ່ໄດ້ຖືກປຶກສາຫາລືແລະນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນບໍລິສັດເຊັ່ນ Twitter, Facebook, Google ແລະ Netflix. ຄວາມຮັບຮູ້ທົ່ວໄປ - ຢ່າງຫນ້ອຍໃນພາກສ່ວນຂອງອຸດສາຫະກໍາທີ່ຂ້ອຍໄດ້ຕິດຕໍ່ - ແມ່ນວ່າ microservices ແມ່ນ "ວິທີທີ່ຖືກຕ້ອງ" ໃນການສ້າງລະບົບຂະຫນາດໃຫຍ່, ເຖິງແມ່ນວ່າມັນເປັນເລື່ອງຍາກ.

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

Netflix ມີ Hysterix, Google ມີ Stubby, Twitter ມີຫ້ອງສະຫມຸດ Finagle. Finagle, ສໍາລັບການຍົກຕົວຢ່າງ, ໄດ້ຖືກບັງຄັບສໍາລັບທຸກໆບໍລິການໃຫມ່ໃນ Twitter. ມັນຈັດການທັງສອງຝ່າຍລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍຂອງການເຊື່ອມຕໍ່, ອະນຸຍາດໃຫ້ສໍາລັບການຮ້ອງຂໍຊ້ໍາ, ສະຫນັບສະຫນູນເສັ້ນທາງການຮ້ອງຂໍ, ການດຸ່ນດ່ຽງການໂຫຼດ, ແລະການວັດແທກ. ມັນສະຫນອງຊັ້ນຄວາມຫນ້າເຊື່ອຖືແລະການສັງເກດການທີ່ສອດຄ່ອງໃນທົ່ວ stack Twitter ທັງຫມົດ, ບໍ່ວ່າການບໍລິການກໍາລັງເຮັດຫຍັງ. ແນ່ນອນ, ມັນເຮັດວຽກພຽງແຕ່ສໍາລັບພາສາ JVM ແລະອີງໃສ່ຮູບແບບການຂຽນໂປລແກລມທີ່ຕ້ອງໃຊ້ສໍາລັບຄໍາຮ້ອງສະຫມັກທັງຫມົດ. ຢ່າງໃດກໍຕາມ, ການເຮັດວຽກຂອງມັນແມ່ນເກືອບຄືກັນກັບຂອງຕາຫນ່າງການບໍລິການ. (ຕົວຈິງແລ້ວ, ຮຸ່ນທໍາອິດຂອງ Linkerd ແມ່ນພຽງແຕ່ Finagle ຫໍ່ຢູ່ໃນແບບຟອມຕົວແທນ.)

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

ແລະນີ້ແມ່ນບ່ອນທີ່ຄໍາຕອບທີ່ເລິກເຊິ່ງ, ເຊື່ອງໄວ້ໃນການປ່ຽນແປງອື່ນທີ່ເກີດຂຶ້ນໃນໄລຍະ 10 ປີທີ່ຜ່ານມາ: ມີການຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຂອງຄ່າໃຊ້ຈ່າຍໃນການນໍາໃຊ້ microservices. ບໍລິສັດທີ່ໄດ້ກ່າວມາຂ້າງເທິງທີ່ນໍາໃຊ້ການບໍລິການຈຸນລະພາກໃນທົດສະວັດກ່ອນຫນ້ານີ້ - Twitter, Netflix, Facebook, Google - ແມ່ນບໍລິສັດທີ່ມີຂະຫນາດແລະຊັບພະຍາກອນອັນມະຫາສານ. ພວກເຂົາບໍ່ພຽງແຕ່ມີຄວາມຕ້ອງການ, ແຕ່ຍັງມີຄວາມສາມາດສ້າງ, ນໍາໃຊ້, ແລະປະຕິບັດຄໍາຮ້ອງສະຫມັກຂະຫນາດໃຫຍ່ໂດຍອີງໃສ່ microservices. ພະລັງງານແລະຄວາມພະຍາຍາມທີ່ວິສະວະກອນ Twitter ໄດ້ເອົາໃຈໃສ່ໃນການເຄື່ອນຍ້າຍຈາກ monolithic ໄປສູ່ວິທີການ microservices ແມ່ນຫນ້າປະຫລາດໃຈ. (ດ້ວຍຄວາມຊື່ສັດ, ຄືກັບຄວາມຈິງທີ່ວ່າມັນເຮັດວຽກ.) ປະເພດຂອງການຫຼອກລວງໂຄງສ້າງພື້ນຖານນີ້ແມ່ນເປັນໄປບໍ່ໄດ້ສໍາລັບບໍລິສັດຂະຫນາດນ້ອຍ.

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

1500 microservices ໃນ Monzo; ແຕ່ລະສາຍແມ່ນກົດລະບຽບເຄືອຂ່າຍທີ່ກໍານົດໄວ້ທີ່ອະນຸຍາດໃຫ້ການຈະລາຈອນ

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

ເປັນຫຍັງ? ດີ, Docker ແກ້ໄຂບັນຫາໃຫຍ່ຫນຶ່ງ - ບັນຫາຂອງການຫຸ້ມຫໍ່. ໂດຍການຫຸ້ມຫໍ່ແອັບພລິເຄຊັ່ນ ແລະຄວາມເພິ່ງພາອາໄສເວລາແລ່ນ (ທີ່ບໍ່ແມ່ນເຄືອຂ່າຍ) ຢູ່ໃນຖັງບັນຈຸ, Docker ປ່ຽນແອັບພລິເຄຊັ່ນໃຫ້ເປັນໜ່ວຍທີ່ສາມາດເກັບມ້ຽນ ແລະ ແລ່ນໄດ້ທຸກບ່ອນ. ໃນເວລາດຽວກັນ, ມັນເຮັດໃຫ້ການດໍາເນີນງານງ່າຍດາຍຫຼາຍ. ຫຼາຍພາສາ stack: ເນື່ອງຈາກ container ເປັນຫນ່ວຍງານປະລໍາມະນູຂອງການປະຕິບັດ, ມັນບໍ່ສໍາຄັນສິ່ງທີ່ຢູ່ໃນ, ບໍ່ວ່າຈະເປັນຄໍາຮ້ອງສະຫມັກ JVM, Node, Go, Python, ຫຼື Ruby, ສໍາລັບການນໍາໃຊ້ແລະຈຸດປະສົງປະຕິບັດງານ. ທ່ານພຽງແຕ່ແລ່ນມັນແລະນັ້ນແມ່ນມັນ.

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

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

ດັ່ງນັ້ນ, ພວກເຮົາມາກັບຄໍາຕອບຂອງຄໍາຖາມວ່າເປັນຫຍັງແນວຄວາມຄິດຂອງຕາຫນ່າງການບໍລິການໄດ້ກາຍເປັນທີ່ນິຍົມໃນປັດຈຸບັນ: ເອກະພາບທີ່ Kubernetes ໃຫ້ບໍລິການແມ່ນນໍາໃຊ້ໂດຍກົງກັບວຽກງານປະຕິບັດງານທີ່ກໍາລັງປະເຊີນກັບຕາຫນ່າງການບໍລິການ. ທ່ານຫຸ້ມຫໍ່ proxies ໃນບັນຈຸ, ໃຫ້ Kubernetes ວຽກງານທີ່ຈະຕິດໃຫ້ເຂົາເຈົ້າບ່ອນໃດກໍ່ຕາມທີ່ເປັນໄປໄດ້, ແລະ voila! ດັ່ງນັ້ນ, ທ່ານໄດ້ຮັບຕາຫນ່າງການບໍລິການ, ໃນຂະນະທີ່ Kubernetes ຄວບຄຸມກົນໄກທັງຫມົດຂອງການນໍາໃຊ້ຂອງມັນ. (ຢ່າງ​ຫນ້ອຍ​ຈາກ​ການ​ເບິ່ງ​ຕາ​ຂອງ​ນົກ​. ແນ່​ນອນ​, ມີ nuances ຫຼາຍ​ໃນ​ຂະ​ບວນ​ການ​ນີ້​.)

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

ເປັນຫຍັງມີການເວົ້າຫຼາຍກ່ຽວກັບຕາຫນ່າງການບໍລິການ?

ການປ້ອງກັນ: ໃນ​ພາກ​ນີ້​, ຂ້າ​ພະ​ເຈົ້າ​ອີງ​ໃສ່​ການ​ຄັດ​ເລືອກ​ທັງ​ຫມົດ​ຂອງ​ສົມ​ມຸດ​ຕິ​ຖານ​, ການ​ຄາດ​ຄະ​ເນ​, fabrications ແລະ​ຂໍ້​ມູນ​ພາຍ​ໃນ​.

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

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

(ສາມບໍລິສັດເຫຼົ່ານີ້ມີບົດບາດແຕກຕ່າງກັນຫຼາຍ: ການມີສ່ວນຮ່ວມຂອງ Lyft ເບິ່ງຄືວ່າຖືກຈໍາກັດພຽງແຕ່ຊື່ເທົ່ານັ້ນ; ພວກເຂົາຂຽນ Envoy ແຕ່ບໍ່ໄດ້ໃຊ້ຫຼືມີສ່ວນຮ່ວມໃນການພັດທະນາ Istio. IBM ມີສ່ວນຮ່ວມໃນການພັດທະນາ Istio ແລະໃຊ້ Google ຢ່າງຫຼວງຫຼາຍ. ມີສ່ວນຮ່ວມໃນການພັດທະນາ Istio, ແຕ່ເທົ່າທີ່ຂ້ອຍສາມາດບອກໄດ້, ບໍ່ໄດ້ໃຊ້ມັນແທ້ໆ.)

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

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

ການປະຖິ້ມທິດສະດີຂອງຂ້ອຍກ່ຽວກັບວ່າເປັນຫຍັງນີ້ເກີດຂຶ້ນ, ຂ້ອຍເຊື່ອວ່າການ hype off-scale ປະມານຕາຫນ່າງການບໍລິການແມ່ນຍ້ອນການມີສ່ວນຮ່ວມຂອງ Google. ນັ້ນແມ່ນ, ການປະສົມປະສານຂອງສາມປັດໃຈຕໍ່ໄປນີ້:

1. ການສົ່ງເສີມການ obsessive ຂອງ Istio ໂດຍ Google;
2. ບໍ່ເຫັນດີເຫັນພ້ອມ, ທັດສະນະວິພາກວິຈານຕໍ່ໂຄງການ;
3. ຄວາມນິຍົມເພີ່ມຂຶ້ນຢ່າງໄວວາຂອງ Kubernetes, ຄວາມຊົງຈໍາທີ່ຍັງສົດຊື່ນ.

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

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

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

ຈົນກ່ວານັ້ນ, ພວກເຮົາທຸກຄົນຈະຕ້ອງມີຄວາມອົດທົນ.

ຕາຫນ່າງການບໍລິການຈະເປັນປະໂຫຍດກັບຂ້ອຍ, ວິສະວະກອນຊອບແວທີ່ອ່ອນໂຍນບໍ?

ແບບສອບຖາມຕໍ່ໄປນີ້ຈະຊ່ວຍຕອບຄໍາຖາມນີ້:

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

ທ່ານຮັກສາເວທີໃນບໍລິສັດທີ່ໃຊ້ Kubernetes ບໍ? ແມ່ນແລ້ວ, ໃນກໍລະນີນີ້ທ່ານຕ້ອງການຕາຫນ່າງການບໍລິການ (ແນ່ນອນ, ຖ້າທ່ານບໍ່ໄດ້ໃຊ້ K8s ພຽງແຕ່ດໍາເນີນການ monolith ຫຼືການປຸງແຕ່ງ batch - ແຕ່ຫຼັງຈາກນັ້ນຂ້າພະເຈົ້າຢາກຖາມວ່າເປັນຫຍັງທ່ານຕ້ອງການ K8s). ສ່ວນຫຼາຍອາດຈະ, ທ່ານຈະພົບເຫັນຕົວທ່ານເອງຢູ່ໃນສະຖານະການທີ່ມີ microservices ຫຼາຍລາຍລັກອັກສອນໂດຍປະຊາຊົນທີ່ແຕກຕ່າງກັນ. ພວກເຂົາທັງຫມົດພົວພັນກັບກັນແລະກັນແລະຖືກຜູກມັດເຂົ້າໄປໃນຄວາມເຄັ່ງຕຶງຂອງການຂຶ້ນກັບ runtime, ແລະທ່ານຈໍາເປັນຕ້ອງຊອກຫາວິທີທີ່ຈະຈັດການກັບສິ່ງທັງຫມົດນີ້. ການນໍາໃຊ້ Kubernetes ຊ່ວຍໃຫ້ທ່ານສາມາດເລືອກຕາຫນ່າງການບໍລິການ "ສໍາລັບຕົວທ່ານເອງ". ເພື່ອເຮັດສິ່ງນີ້, ເຮັດຄວາມຄຸ້ນເຄີຍກັບຄວາມສາມາດແລະລັກສະນະຂອງເຂົາເຈົ້າແລະຕອບຄໍາຖາມວ່າໂຄງການໃດໆທີ່ມີຢູ່ເຫມາະສົມກັບທ່ານທັງຫມົດ (ຂ້າພະເຈົ້າແນະນໍາໃຫ້ເລີ່ມຕົ້ນການຄົ້ນຄວ້າຂອງທ່ານກັບ Linkerd).

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

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

ສະຫລຸບ

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

ຂ້ອຍຢາກໃຫ້ເຈົ້າລອງ Linkerd - ຕິດຕັ້ງມັນຢູ່ໃນກຸ່ມ Kubernetes (ຫຼືແມ້ກະທັ້ງ Minikube ໃນແລັບທັອບ) ໃຊ້ເວລາປະມານ 60 ວິນາທີແລະເຈົ້າສາມາດເຫັນຕົວເຈົ້າເອງໄດ້ວ່າຂ້ອຍກຳລັງເວົ້າເຖິງຫຍັງ.

FAQ

- ຖ້າຂ້ອຍບໍ່ສົນໃຈຕາຫນ່າງບໍລິການ, ມັນຈະຫາຍໄປບໍ?
- ຂ້ອຍຕ້ອງຜິດຫວັງເຈົ້າ: ຕາຫນ່າງການບໍລິການຢູ່ກັບພວກເຮົາເປັນເວລາດົນນານ.

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

— ມັນ​ບໍ່​ແມ່ນ ESB/middleware ເກົ່າ​ທີ່​ດີ​ທີ່​ມີ​ຊອດ​ໃຫມ່​?
- ຕາຫນ່າງການບໍລິການຈັດການກັບເຫດຜົນການດໍາເນີນງານ, ບໍ່ແມ່ນ semantic. ນີ້ແມ່ນຂໍ້ເສຍປຽບຕົ້ນຕໍ ລົດເມບໍລິການວິສາຫະກິດ (ສບ). ການຮັກສາການແຍກນີ້ຈະຊ່ວຍໃຫ້ຕາຫນ່າງການບໍລິການຫລີກລ້ຽງຊະຕາກໍາດຽວກັນ.

- ຕາຫນ່າງການບໍລິການແຕກຕ່າງຈາກ API gateways ແນວໃດ?
ມີ​ໜຶ່ງ​ລ້ານ​ບົດ​ກ່ຽວ​ກັບ​ເລື່ອງ​ນີ້. ພຽງແຕ່ google.

Envoy ເປັນຕາຫນ່າງການບໍລິການບໍ?
- ບໍ່, Envoy ບໍ່ແມ່ນຕາໜ່າງບໍລິການ, ມັນເປັນເຊີບເວີພຣັອກຊີ. ມັນສາມາດຖືກນໍາໃຊ້ເພື່ອຈັດຕັ້ງຕາຫນ່າງການບໍລິການ (ແລະຫຼາຍ - ມັນເປັນຕົວແທນຈຸດປະສົງທົ່ວໄປ). ແຕ່ດ້ວຍຕົວມັນເອງ, ມັນບໍ່ແມ່ນຕາຫນ່າງການບໍລິການ.

- Network Service Mesh - ມັນເປັນຕາຫນ່າງບໍລິການບໍ?
- ບໍ່. ເຖິງວ່າຈະມີຊື່, ນີ້ບໍ່ແມ່ນຕາຫນ່າງການບໍລິການ (ເຈົ້າມັກຄວາມມະຫັດສະຈັນຂອງການຕະຫຼາດແນວໃດ?).

- ຕາໜ່າງບໍລິການຊ່ວຍກັບລະບົບບໍ່ຊິ້ງໂຄນທີ່ປະຕິກິລິຍາຂອງຂ້ອຍໂດຍອີງໃສ່ຄິວຂໍ້ຄວາມບໍ?
- ບໍ່, ຕາຫນ່າງການບໍລິການຈະບໍ່ຊ່ວຍທ່ານ.

- ຂ້ອຍຄວນໃຊ້ຕາໜ່າງບໍລິການໃດ?
- Linkerd, ບໍ່ມີ brainer.

- ບົດຄວາມດູດ! / ຜູ້ຂຽນ - ສຸດສະບູ!
— ກະ​ລຸ​ນາ​ແບ່ງ​ປັນ​ການ​ເຊື່ອມ​ຕໍ່​ມັນ​ກັບ​ຫມູ່​ເພື່ອນ​ຂອງ​ທ່ານ​ທັງ​ຫມົດ​ເພື່ອ​ໃຫ້​ເຂົາ​ເຈົ້າ​ສາ​ມາດ​ເຊື່ອ​ໃນ​ເລື່ອງ​ນີ້​!

ຂອບໃຈ

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

ໃນຂະນະທີ່ຂ້ອຍມັກເອີ້ນຕົວເອງວ່າ "ນັກພັດທະນາ Linkerd", ຄວາມຈິງແລ້ວແມ່ນວ່າຂ້ອຍເປັນຜູ້ຮັກສາໄຟລ໌ README.md ໃນໂຄງການ. ເຮັດວຽກກ່ຽວກັບ Linkerd ໃນມື້ນີ້ ຫຼາຍ, ຫຼາຍ, ຫຼາຍ много ປະຊາຊົນ, ແລະໂຄງການນີ້ຈະບໍ່ເປັນໄປໄດ້ໂດຍບໍ່ມີຊຸມຊົນທີ່ຫນ້າປະຫລາດໃຈຂອງຜູ້ປະກອບສ່ວນແລະຜູ້ໃຊ້.

ແລະສຸດທ້າຍ, ຂອບໃຈເປັນພິເສດຕໍ່ຜູ້ສ້າງ Linkerd, Oliver Gould (primus inter pares), ຜູ້ທີ່, ພ້ອມກັບຂ້າພະເຈົ້າຫຼາຍປີກ່ອນ, ໄດ້ dived headlong ເຂົ້າໄປໃນ fuss ທັງຫມົດນີ້ກັບຕາຫນ່າງການບໍລິການ.

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ຕາໜ່າງບໍລິການແມ່ນຫຍັງ ແລະເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງການມັນ [ສຳລັບແອັບພລິເຄຊັນຄລາວກັບບໍລິການຈຸລະພາກ]?"
• «Traefik 2.0: ການອັບເດດຕາໜ່າງການບໍລິການດ້ວຍການຮອງຮັບ TCP ແລະສ່ວນຕິດຕໍ່ເວັບໃໝ່"
• «Maesh - ຕາຫນ່າງການບໍລິການທີ່ງ່າຍດາຍໃຫມ່ສໍາລັບ Kubernetes ຈາກຜູ້ຂຽນຂອງ Traefik"
• «ກັບໄປຫາບໍລິການຈຸລະພາກກັບ Istio. ພາກທີ 1"
• «Conduit - ຕາຫນ່າງການບໍລິການທີ່ມີນ້ໍາຫນັກເບົາສໍາລັບ Kubernetes".

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