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

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

ປະຫວັດຂອງ dotCloud

ຂ້ອຍໄດ້ຂຽນກ່ຽວກັບປະຫວັດຂອງ dotCloud ແລະທາງເລືອກສະຖາປັດຕະຍະກໍາສໍາລັບເວທີນີ້, ແຕ່ຂ້ອຍບໍ່ໄດ້ເວົ້າຫຼາຍກ່ຽວກັບຊັ້ນເຄືອຂ່າຍ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ບໍ່​ຕ້ອງ​ການ​ເຂົ້າ​ໄປ​ໃນ​ການ​ອ່ານ​ ບົດຄວາມສຸດທ້າຍ ກ່ຽວກັບ dotCloud, ນີ້ແມ່ນຂໍ້ສະຫຼຸບໂດຍຫຍໍ້: ມັນເປັນ PaaS platform-as-a-service ທີ່ອະນຸຍາດໃຫ້ລູກຄ້າສາມາດດໍາເນີນການຄໍາຮ້ອງສະຫມັກທີ່ຫລາກຫລາຍ (Java, PHP, Python ...), ສະຫນັບສະຫນູນສໍາລັບລະດັບຄວາມກ້ວາງຂອງຂໍ້ມູນ. ການບໍລິການ (MongoDB, MySQL, Redis ... ) ແລະຂັ້ນຕອນການເຮັດວຽກເຊັ່ນ Heroku: ທ່ານອັບໂຫລດລະຫັດຂອງທ່ານໃສ່ເວທີ, ມັນສ້າງຮູບພາບບັນຈຸແລະນໍາໃຊ້ພວກມັນ.

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

ເສັ້ນທາງການຈະລາຈອນສໍາລັບແອັບພລິເຄຊັນທີ່ເປັນເຈົ້າພາບ

ແອັບພລິເຄຊັນໃນ dotCloud ສາມາດເປີດເຜີຍຈຸດສິ້ນສຸດ HTTP ແລະ TCP.

ຈຸດສິ້ນສຸດ HTTP ເພີ່ມແບບໄດນາມິກໃສ່ການຕັ້ງຄ່າກຸ່ມ load balancer Hipache. ນີ້ແມ່ນຄ້າຍຄືກັນກັບສິ່ງທີ່ຊັບພະຍາກອນເຮັດໃນມື້ນີ້ Ingress ໃນ Kubernetes ແລະຕົວດຸ່ນດ່ຽງການໂຫຼດເຊັ່ນ Traefik.

ລູກຄ້າເຊື່ອມຕໍ່ກັບຈຸດສິ້ນສຸດ HTTP ຜ່ານໂດເມນທີ່ເຫມາະສົມ, ສະຫນອງໃຫ້ວ່າຊື່ໂດເມນຊີ້ໃຫ້ເຫັນ dotCloud load balancers. ບໍ່​ມີ​ຫຍັງ​ພິ​ເສດ.

TCP ຈຸດສິ້ນສຸດ ທີ່ກ່ຽວພັນກັບໝາຍເລກພອດ, ເຊິ່ງຖືກສົ່ງຜ່ານໄປຍັງຖັງບັນຈຸທັງໝົດໃນ stack ນັ້ນຜ່ານຕົວແປສະພາບແວດລ້ອມ.

ລູກຄ້າສາມາດເຊື່ອມຕໍ່ກັບຈຸດສິ້ນສຸດຂອງ TCP ໂດຍໃຊ້ຊື່ໂຮດທີ່ເຫມາະສົມ (ບາງສິ່ງບາງຢ່າງເຊັ່ນ: gateway-X.dotcloud.com) ແລະໝາຍເລກພອດ.

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

ຖ້າທ່ານຄຸ້ນເຄີຍກັບ Kubernetes, ນີ້ອາດຈະເຕືອນທ່ານກ່ຽວກັບການບໍລິການ NodePort.

ບໍ່ມີການບໍລິການທຽບເທົ່າຢູ່ໃນເວທີ dotCloud ClusterIP: ສໍາລັບຄວາມງ່າຍດາຍ, ການບໍລິການໄດ້ຖືກເຂົ້າເຖິງດ້ວຍວິທີດຽວກັນທັງຈາກພາຍໃນ ແລະພາຍນອກເວທີ.

ທຸກສິ່ງທຸກຢ່າງໄດ້ຖືກຈັດຕັ້ງຢ່າງງ່າຍດາຍ: ການປະຕິບັດເບື້ອງຕົ້ນຂອງ HTTP ແລະ TCP ເສັ້ນທາງເຄືອຂ່າຍອາດຈະເປັນພຽງແຕ່ສອງສາມຮ້ອຍສາຍຂອງ Python ແຕ່ລະຄົນ. ງ່າຍດາຍ (ຂ້າພະເຈົ້າຈະເວົ້າວ່າ naive) algorithms ທີ່ຖືກປັບປຸງໃຫມ່ຍ້ອນວ່າເວທີການຂະຫຍາຍຕົວແລະຄວາມຕ້ອງການເພີ່ມເຕີມປາກົດ.

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

ນີ້ແຕກຕ່າງຈາກຕາຫນ່າງບໍລິການທີ່ທັນສະໄຫມແນວໃດ?

ຈຳກັດ ການເບິ່ງເຫັນ. ພວກ​ເຮົາ​ບໍ່​ມີ​ການ​ວັດ​ແທກ​ໃດໆ​ສໍາ​ລັບ​ຕາ​ຫນ່າງ​ການ​ກໍາ​ນົດ​ເສັ້ນ TCP ເລີຍ. ເມື່ອເວົ້າເຖິງ HTTP routing, ຮຸ່ນຕໍ່ມາໄດ້ນໍາສະເຫນີລາຍລະອຽດ HTTP metrics ກັບລະຫັດຄວາມຜິດພາດແລະເວລາຕອບສະຫນອງ, ແຕ່ອຸປະກອນການບໍລິການທີ່ທັນສະໄຫມໄປຕື່ມອີກ, ສະຫນອງການປະສົມປະສານກັບລະບົບການລວບລວມ metrics ເຊັ່ນ Prometheus, ສໍາລັບຕົວຢ່າງ.

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

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

ຕາຫນ່າງການບໍລິການທີ່ທັນສະໄຫມແມ່ນດີກວ່າທີ່ຈະແກ້ໄຂບັນຫາດັ່ງກ່າວ. ກ່ອນອື່ນ ໝົດ, ພວກເຂົາກວດເບິ່ງວ່າການເຊື່ອມຕໍ່ຖືກສົ່ງຕໍ່ ໃນແຫຼ່ງ. ການໄຫຼຢ່າງມີເຫດຜົນແມ່ນຄືກັນ: клиент → меш → сервис, ແຕ່ໃນປັດຈຸບັນຕາຫນ່າງເຮັດວຽກຢູ່ໃນທ້ອງຖິ່ນແລະບໍ່ຢູ່ໃນ nodes ຫ່າງໄກສອກຫຼີກ, ດັ່ງນັ້ນການເຊື່ອມຕໍ່ клиент → меш ແມ່ນທ້ອງຖິ່ນແລະໄວຫຼາຍ (microseconds ແທນ milliseconds).

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

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

ເສັ້ນທາງການຈະລາຈອນສໍາລັບການບໍລິການເວທີ

ຕົກລົງ, ພວກເຮົາໄດ້ປຶກສາຫາລືກ່ຽວກັບການຈະລາຈອນລະຫວ່າງແອັບພລິເຄຊັນ, ແຕ່ສິ່ງທີ່ກ່ຽວກັບເວທີ dotCloud ຕົວມັນເອງ?

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

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

ການບໍລິການທີ່ສຳຄັນໃນລະດັບຕໍ່າເຫຼົ່ານີ້ໄດ້ຖືກນຳໄປໃຊ້ໂດຍການແລ່ນພາຊະນະບັນຈຸໂດຍກົງໃສ່ບາງຈຸດສຳຄັນ. ໃນກໍລະນີນີ້, ການບໍລິການເວທີມາດຕະຖານບໍ່ໄດ້ຖືກນໍາໃຊ້: linker, scheduler ແລະ runner. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຕ້ອງ​ການ​ທີ່​ຈະ​ປຽບ​ທຽບ​ກັບ​ເວ​ທີ​ການ​ບັນ​ຈຸ​ທີ່​ທັນ​ສະ​ໄຫມ​, ມັນ​ຄ້າຍ​ຄື​ການ​ແລ່ນ​ຍົນ​ຄວບ​ຄຸມ​ທີ່​ມີ​ docker run ໂດຍກົງໃນ nodes, ແທນທີ່ຈະມອບຫມາຍວຽກງານໃຫ້ Kubernetes. ມັນຂ້ອນຂ້າງຄ້າຍຄືກັນໃນແນວຄວາມຄິດ ໂມດູນຄົງທີ່ (ຝັກ), ທີ່ມັນໃຊ້ kubeadm ຫຼື bootkube ໃນເວລາ booting cluster standalone.

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

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

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

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

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

ຂ້າພະເຈົ້າສ່ວນບຸກຄົນພິຈາລະນາ SmartStack ເປັນຫນຶ່ງໃນຜູ້ສືບທອດຂອງລະບົບເຊັ່ນ Istio, Linkerd ແລະ Consul Connect ເພາະວ່າພວກເຂົາທັງຫມົດປະຕິບັດຕາມຮູບແບບດຽວກັນ:

• ດໍາເນີນການຕົວແທນໃນແຕ່ລະ node.
• ລູກຄ້າເຊື່ອມຕໍ່ກັບຕົວແທນ.
• ຍົນຄວບຄຸມຈະອັບເດດການຕັ້ງຄ່າພຣັອກຊີເມື່ອ backends ປ່ຽນແປງ.
• ...ກຳໄລ!

ການປະຕິບັດທີ່ທັນສະໄຫມຂອງຕາຫນ່າງການບໍລິການ

ຖ້າພວກເຮົາຕ້ອງການປະຕິບັດຕາຕະລາງທີ່ຄ້າຍຄືກັນໃນມື້ນີ້, ພວກເຮົາສາມາດໃຊ້ຫຼັກການທີ່ຄ້າຍຄືກັນ. ຕົວຢ່າງ, ຕັ້ງຄ່າເຂດ DNS ພາຍໃນໂດຍການສ້າງແຜນທີ່ຊື່ການບໍລິການໄປຫາທີ່ຢູ່ໃນຊ່ອງ 127.0.0.0/8. ຫຼັງຈາກນັ້ນ, ດໍາເນີນການ HAProxy ໃນແຕ່ລະ node ໃນ cluster, ຍອມຮັບການເຊື່ອມຕໍ່ໃນແຕ່ລະທີ່ຢູ່ບໍລິການ (ໃນເຄືອຂ່າຍຍ່ອຍນັ້ນ. 127.0.0.0/8) ແລະການປ່ຽນເສັ້ນທາງ / ການດຸ່ນດ່ຽງການໂຫຼດໄປຫາ backends ທີ່ເຫມາະສົມ. ການຕັ້ງຄ່າ HAProxy ສາມາດຄວບຄຸມໄດ້ confd, ຊ່ວຍໃຫ້ທ່ານສາມາດເກັບຂໍ້ມູນ backend ໃນ etcd ຫຼື Consul ແລະອັດຕະໂນມັດ push ການປັບປຸງການຕັ້ງຄ່າກັບ HAProxy ໃນເວລາທີ່ຈໍາເປັນ.

ນີ້ແມ່ນວິທີທີ່ Istio ເຮັດວຽກຫຼາຍ! ແຕ່ມີຄວາມແຕກຕ່າງບາງຢ່າງ:

• ການນໍາໃຊ້ ຕົວແທນທູດ ແທນ HAProxy.
• ເກັບຮັກສາການຕັ້ງຄ່າ backend ຜ່ານ Kubernetes API ແທນ etcd ຫຼື Consul.
• ການບໍລິການຖືກຈັດສັນຢູ່ໃນເຄືອຂ່າຍຍ່ອຍພາຍໃນ (ທີ່ຢູ່ Kubernetes ClusterIP) ແທນ 127.0.0.0/8.
• ມີອົງປະກອບເພີ່ມເຕີມ (Citadel) ເພື່ອເພີ່ມການກວດສອບ TLS ເຊິ່ງກັນແລະກັນລະຫວ່າງລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍ.
• ສະຫນັບສະຫນູນລັກສະນະໃຫມ່ເຊັ່ນ: ການທໍາລາຍວົງຈອນ, ການຕິດຕາມການແຈກຢາຍ, ການປະຕິບັດ canary, ແລະອື່ນໆ.

ລອງພິຈາລະນາເບິ່ງຄວາມແຕກຕ່າງບາງຢ່າງ.

ຕົວແທນທູດ

Envoy Proxy ໄດ້ຖືກຂຽນໂດຍ Lyft [ຄູ່ແຂ່ງຂອງ Uber ໃນຕະຫຼາດ taxi - ປະມານ. ເລນ]. ມັນຄ້າຍຄືກັນໃນຫຼາຍວິທີກັບຕົວແທນອື່ນໆ (ເຊັ່ນ: HAProxy, Nginx, Traefik ...), ແຕ່ Lyft ຂຽນຂອງເຂົາເຈົ້າເພາະວ່າພວກເຂົາຕ້ອງການຄຸນສົມບັດທີ່ຕົວແທນອື່ນໆຂາດ, ແລະເບິ່ງຄືວ່າສະຫລາດກວ່າທີ່ຈະສ້າງໃຫມ່ແທນທີ່ຈະຂະຫຍາຍອັນທີ່ມີຢູ່ແລ້ວ.

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

ແຕ່ Envoy ຍັງສາມາດເຮັດວຽກເປັນ ຍົນ​ຂໍ້​ມູນ (ຍົນຂໍ້ມູນ) ສໍາລັບຕາຫນ່າງການບໍລິການ. ນີ້ຫມາຍຄວາມວ່າ Envoy ໄດ້ຖືກຕັ້ງຄ່າໃນປັດຈຸບັນສໍາລັບຕາຫນ່າງການບໍລິການນີ້ ຍົນ​ຄວບ​ຄຸມ (ຍົນ​ຄວບ​ຄຸມ).

ຄວບຄຸມຍົນ

ສໍາລັບຍົນຄວບຄຸມ, Istio ອີງໃສ່ Kubernetes API. ນີ້ບໍ່ແມ່ນຄວາມແຕກຕ່າງຫຼາຍຈາກການໃຊ້ confd, ເຊິ່ງອີງໃສ່ etcd ຫຼື Consul ເພື່ອເບິ່ງຊຸດຂອງກະແຈໃນບ່ອນເກັບຂໍ້ມູນ. Istio ໃຊ້ Kubernetes API ເພື່ອເບິ່ງຊຸດຂອງຊັບພະຍາກອນ Kubernetes.

ລະຫວ່າງນີ້ແລະຈາກນັ້ນ: ຂ້າພະເຈົ້າສ່ວນບຸກຄົນພົບວ່າສິ່ງນີ້ເປັນປະໂຫຍດ ຄຳອະທິບາຍ API Kubernetesເຊິ່ງອ່ານວ່າ:

ເຊີບເວີ Kubernetes API ແມ່ນ “ເຊີບເວີທີ່ຂີ້ຄ້ານ” ທີ່ສະໜອງການເກັບຮັກສາ, ການສ້າງເວີຊັນ, ການກວດສອບຄວາມຖືກຕ້ອງ, ການອັບເດດ ແລະຄຳສັບສຳລັບຊັບພະຍາກອນ API.

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

ທີ່ຢູ່ບໍລິການ

Istio ອາໄສທີ່ຢູ່ ClusterIP ທີ່ Kubernetes ຈັດສັນ, ດັ່ງນັ້ນບໍລິການ Istio ໄດ້ຮັບທີ່ຢູ່ພາຍໃນ (ບໍ່ຢູ່ໃນຂອບເຂດ. 127.0.0.0/8).

ການຈາລະຈອນໄປຫາທີ່ຢູ່ ClusterIP ສໍາລັບການບໍລິການສະເພາະໃນກຸ່ມ Kubernetes ທີ່ບໍ່ມີ Istio ຖືກສະກັດໂດຍ kube-proxy ແລະຖືກສົ່ງໄປຫາ backend ຂອງ proxy ນັ້ນ. ຖ້າທ່ານສົນໃຈໃນລາຍລະອຽດດ້ານວິຊາການ, kube-proxy ຕັ້ງຄ່າກົດລະບຽບ iptables (ຫຼື IPVS load balancers, ຂຶ້ນກັບວິທີທີ່ມັນຖືກຕັ້ງຄ່າ) ເພື່ອຂຽນຄືນໃຫມ່ທີ່ຢູ່ IP ປາຍທາງຂອງການເຊື່ອມຕໍ່ໄປຫາທີ່ຢູ່ ClusterIP.

ເມື່ອ Istio ຖືກຕິດຕັ້ງຢູ່ໃນກຸ່ມ Kubernetes, ບໍ່ມີຫຍັງປ່ຽນແປງຈົນກ່ວາມັນຖືກເປີດໃຊ້ຢ່າງຈະແຈ້ງສໍາລັບຜູ້ບໍລິໂພກທີ່ລະບຸ, ຫຼືແມ້ກະທັ້ງ namespace ທັງຫມົດ, ໂດຍການແນະນໍາ container. sidecar ເຂົ້າໄປໃນຝັກທີ່ກໍາຫນົດເອງ. ຕູ້ຄອນເທນເນີນີ້ຈະ spin up an instance ຂອງ Envoy ແລະກໍານົດທີ່ກໍານົດໄວ້ຂອງກົດລະບຽບ iptables ເພື່ອສະກັດການຈະລາຈອນໄປຫາບໍລິການອື່ນໆແລະ redirect ການຈະລາຈອນນັ້ນກັບ Envoy.

ເມື່ອປະສົມປະສານກັບ Kubernetes DNS, ນີ້ຫມາຍຄວາມວ່າລະຫັດຂອງພວກເຮົາສາມາດເຊື່ອມຕໍ່ໂດຍຊື່ການບໍລິການແລະທຸກສິ່ງທຸກຢ່າງ "ພຽງແຕ່ເຮັດວຽກ." ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ລະຫັດຂອງພວກເຮົາມີບັນຫາຄໍາຖາມເຊັ່ນ http://api/v1/users/4242ແລ້ວ api ແກ້​ໄຂ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ 10.97.105.48, ກົດລະບຽບ iptables ຈະຂັດຂວາງການເຊື່ອມຕໍ່ຈາກ 10.97.105.48 ແລະສົ່ງຕໍ່ໄປຫາຕົວແທນ Envoy ທ້ອງຖິ່ນ, ແລະຕົວແທນທ້ອງຖິ່ນນັ້ນຈະສົ່ງຕໍ່ຄໍາຮ້ອງຂໍໄປຍັງ backend API ຕົວຈິງ. ຟີວ!

frills ເພີ່ມເຕີມ

Istio ຍັງສະຫນອງການເຂົ້າລະຫັດ end-to-end ແລະການກວດສອບຄວາມຖືກຕ້ອງຜ່ານ mTLS (TLS ເຊິ່ງກັນແລະກັນ). ອົງປະກອບທີ່ເອີ້ນວ່າ Citadel.

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

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

ພັດທະນາຫຼືຊື້

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

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

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

ຂ້ອຍຄວນເລືອກ Istio, Linkerd ຫຼື Consul Connect ບໍ?

ມາຮອດປະຈຸບັນພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບ Istio, ແຕ່ນີ້ບໍ່ແມ່ນຕາຫນ່າງການບໍລິການເທົ່ານັ້ນ. ທາງເລືອກທີ່ນິຍົມ - Linkerd, ແລະ​ມີ​ຫຼາຍ​ Consul Connect.

ສິ່ງທີ່ເລືອກ?

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

ຫນຶ່ງໃນວິທີການທີ່ດີແມ່ນການນໍາໃຊ້ເຄື່ອງມືເຊັ່ນ: SuperGloo. ມັນປະຕິບັດຊັ້ນ abstraction ເພື່ອເຮັດໃຫ້ງ່າຍແລະເປັນເອກະພາບ APIs ເປີດເຜີຍໂດຍຕາຫນ່າງການບໍລິການ. ແທນທີ່ຈະຮຽນຮູ້ສະເພາະ APIs (ແລະ, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ຂ້ອນຂ້າງສັບສົນ) ຂອງຕາຫນ່າງການບໍລິການທີ່ແຕກຕ່າງກັນ, ພວກເຮົາສາມາດນໍາໃຊ້ການກໍ່ສ້າງທີ່ງ່າຍດາຍຂອງ SuperGloo - ແລະປ່ຽນຈາກຫນຶ່ງໄປຫາອື່ນໄດ້ຢ່າງງ່າຍດາຍ, ຄືກັບວ່າພວກເຮົາມີຮູບແບບການຕັ້ງຄ່າລະດັບປານກາງທີ່ອະທິບາຍເຖິງການໂຕ້ຕອບ HTTP ແລະ backends ທີ່ມີຄວາມສາມາດ. ການສ້າງການຕັ້ງຄ່າຕົວຈິງສໍາລັບ Nginx, HAProxy, Traefik, Apache ...

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

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