ສະຖານະການການນໍາໃຊ້ຕາຫນ່າງການບໍລິການ

ຫມາຍ​ເຫດ​. ແປ.: ຜູ້ຂຽນຂອງບົດຄວາມນີ້ (Luc Perkins) ເປັນຜູ້ສະຫນັບສະຫນູນຜູ້ພັດທະນາຢູ່ໃນອົງການ CNCF, ເຊິ່ງເປັນບ້ານຂອງບັນດາໂຄງການ Open Source ເຊັ່ນ Linkerd, SMI (Service Mesh Interface) ແລະ Kuma (ໂດຍວິທີທາງການ, ເຈົ້າຍັງສົງໄສວ່າເປັນຫຍັງ Istio ແມ່ນ? ບໍ່ຢູ່ໃນບັນຊີລາຍຊື່ນີ້? .). ອີກເທື່ອຫນຶ່ງຄວາມພະຍາຍາມເພື່ອເຮັດໃຫ້ຊຸມຊົນ DevOps ມີຄວາມເຂົ້າໃຈດີຂຶ້ນກ່ຽວກັບ hype ທີ່ມີທ່າອ່ຽງທີ່ເອີ້ນວ່າ "ຕາຫນ່າງການບໍລິການ", ລາວລາຍຊື່ 16 ຄວາມສາມາດລັກສະນະທີ່ວິທີແກ້ໄຂດັ່ງກ່າວສະຫນອງ.

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

* ຫມາຍ​ເຫດ​ transl.: ທີ່ນີ້ແລະຕໍ່ໄປໃນບົດຄວາມແນ່ນອນການແປພາສານີ້ ("ຕາຫນ່າງການບໍລິການ") ຈະຖືກໃຊ້ສໍາລັບຕາຫນ່າງການບໍລິການຄໍາສັບໃຫມ່.

ແຕ່ທໍາອິດຂ້ອຍຢາກອອກຄໍາເຫັນສອງສາມຢ່າງ:

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

ບັນຊີລາຍຊື່ສັ້ນ:

• ການຄົ້ນພົບການບໍລິການ;
• ການເຂົ້າລະຫັດ;
• ການກວດສອບແລະການອະນຸຍາດ;
• ການດຸ່ນດ່ຽງການໂຫຼດ;
• breaking ວົງຈອນ;
• autoscaling;
• ການນຳໃຊ້ canary;
• ການນຳໃຊ້ສີຟ້າ-ສີຂຽວ;
• ກວດສຸຂະພາບ;
• load shedding;
• ຈອນ;
• insulation;
• ການ​ຈໍາ​ກັດ​ອັດ​ຕາ​ການ​ຮ້ອງ​ຂໍ​, retry ແລະ​ຫມົດ​ເວ​ລາ​;
• telemetry;
• ການກວດສອບ;
• ການເບິ່ງເຫັນ.

1. ການຄົ້ນພົບການບໍລິການ

TL;DR: ເຊື່ອມຕໍ່ກັບການບໍລິການອື່ນໃນເຄືອຂ່າຍໂດຍໃຊ້ຊື່ງ່າຍໆ.

ການບໍລິການຄວນຈະສາມາດອັດຕະໂນມັດ "ຊອກຫາ" ເຊິ່ງກັນແລະກັນໂດຍໃຊ້ຊື່ທີ່ພຽງພໍ - ຕົວຢ່າງ, service.api.production, pets/staging ຫຼື cassandra. ສະພາບແວດລ້ອມຄລາວມີຄວາມຍືດຫຍຸ່ນ, ແລະຊື່ດຽວສາມາດເຊື່ອງຫຼາຍໆຕົວຢ່າງຂອງການບໍລິການ. ມັນເປັນທີ່ຊັດເຈນວ່າໃນສະຖານະການດັ່ງກ່າວມັນເປັນໄປບໍ່ໄດ້ທາງດ້ານຮ່າງກາຍທີ່ຈະ hardcode ທີ່ຢູ່ IP ທັງຫມົດ.

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

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

2. ການເຂົ້າລະຫັດ

TL;DR: ກໍາຈັດການຈາລະຈອນທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດລະຫວ່າງການບໍລິການ ແລະເຮັດໃຫ້ຂະບວນການນີ້ອັດຕະໂນມັດ ແລະສາມາດຂະຫຍາຍໄດ້.

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

ແນ່ນອນ, ສໍາລັບຕາຫນ່າງການບໍລິການ mTLS ທາງເລືອກ. ແຕ່ລະບໍລິການສາມາດເບິ່ງແຍງ TLS ຂອງຕົນເອງໄດ້, ແຕ່ນີ້ຫມາຍຄວາມວ່າເຈົ້າຈະຕ້ອງຊອກຫາວິທີສ້າງໃບຢັ້ງຢືນ, ແຈກຢາຍໃຫ້ເຂົາເຈົ້າໃນທົ່ວບໍລິການໂຮດ, ແລະລວມເອົາລະຫັດໃນແອັບພລິເຄຊັນທີ່ຈະໂຫລດໃບຢັ້ງຢືນເຫຼົ່ານີ້ຈາກໄຟລ໌. ແມ່ນແລ້ວ, ຢ່າລືມຕໍ່ອາຍຸໃບຢັ້ງຢືນເຫຼົ່ານີ້ໃນຊ່ວງເວລາປົກກະຕິ. ບໍລິການ Meshes ອັດຕະໂນມັດ mTLS ກັບລະບົບເຊັ່ນ SPIFFE, ເຊິ່ງ, ແລະເຮັດໃຫ້ການອັດຕະໂນມັດຂະບວນການອອກແລະ rotating ໃບຢັ້ງຢືນ.

3. ການຢັ້ງຢືນແລະການອະນຸຍາດ

TL;DR: ກໍານົດວ່າຜູ້ຮ້ອງຂໍແມ່ນໃຜແລະກໍານົດສິ່ງທີ່ພວກເຂົາໄດ້ຮັບອະນຸຍາດໃຫ້ເຮັດກ່ອນທີ່ຄໍາຮ້ອງຂໍມາຮອດການບໍລິການ.

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

1. ບໍລິການອື່ນໆ. ອັນນີ້ເອີ້ນວ່າ "ການຢືນຢັນ" ເພື່ອນ" ສໍາລັບຕົວຢ່າງ, ການບໍລິການ web ຕ້ອງການເຂົ້າເຖິງການບໍລິການ db. ຕາໜ່າງບໍລິການປົກກະຕິແລ້ວແກ້ໄຂບັນຫາດັ່ງກ່າວໂດຍໃຊ້ mTLS: ໃບຢັ້ງຢືນໃນກໍລະນີນີ້ເຮັດຫນ້າທີ່ເປັນຕົວລະບຸທີ່ຈໍາເປັນ.
2. ຜູ້ໃຊ້ມະນຸດບາງຄົນ. ອັນນີ້ເອີ້ນວ່າ "ການຢືນຢັນ" ການຮ້ອງຂໍ" ຕົວຢ່າງ, ຜູ້ໃຊ້ haxor69 ຕ້ອງການຊື້ໂຄມໄຟໃຫມ່. ຕາຫນ່າງການບໍລິການສະຫນອງກົນໄກຕ່າງໆ, e.g. JSON Web Token.

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

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

4. ການດຸ່ນດ່ຽງການໂຫຼດ

TL;DR: ແຈກຢາຍການໂຫຼດໃນທົ່ວການບໍລິການໂດຍອີງຕາມຮູບແບບສະເພາະ.

“ການບໍລິການ” ພາຍໃນພາກສ່ວນການບໍລິການມັກຈະປະກອບດ້ວຍຫຼາຍກໍລະນີ. ຕົວຢ່າງ, ມື້ນີ້ການບໍລິການ cache ປະກອບດ້ວຍ 5 ສະບັບ, ແລະໃນມື້ອື່ນ, ຈໍານວນຂອງພວກເຂົາອາດຈະເພີ່ມຂຶ້ນເປັນ 11. ຄໍາຮ້ອງຂໍທີ່ຖືກສົ່ງໄປຫາ cache, ຕ້ອງໄດ້ຮັບການແຈກຢາຍຕາມຈຸດປະສົງສະເພາະ. ຕົວຢ່າງ, ຫຼຸດຜ່ອນເວລາ latency ໜ້ອຍສຸດ ຫຼືເພີ່ມຄວາມເປັນໄປໄດ້ຂອງການເຂົ້າຫາຕົວຢ່າງທີ່ເຮັດວຽກ. ສູດການຄິດໄລ່ທີ່ຖືກນໍາໃຊ້ຫຼາຍທີ່ສຸດແມ່ນ Round-robin, ແຕ່ມີຫຼາຍຢ່າງອື່ນ - ຕົວຢ່າງ, ວິທີການນ້ໍາຫນັກ. (ນ້ຳໜັກ) ສອບຖາມ (ທ່ານສາມາດເລືອກເປົ້າຫມາຍທີ່ຕ້ອງການ), ວົງ (ແຫວນ) hashing (ໃຊ້ hashing ສອດຄ່ອງໃນທົ່ວ hosts upstream) ຫຼືວິທີການຮ້ອງຂໍຢ່າງຫນ້ອຍ (ຄວາມມັກແມ່ນໃຫ້ກັບ instance ທີ່ມີຄໍາຮ້ອງຂໍຫນ້ອຍທີ່ສຸດ).

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

5. ການທໍາລາຍວົງຈອນ

TL;DR: ຢຸດການຈະລາຈອນໄປຫາການບໍລິການທີ່ມີບັນຫາ ແລະຄວບຄຸມຄວາມເສຍຫາຍໃນສະຖານະການທີ່ຮ້າຍແຮງທີ່ສຸດ.

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

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

ທ່ານອາດຈະບໍ່ຕ້ອງການທີ່ຈະລ່ວງລະເມີດການທໍາລາຍວົງຈອນ, ແຕ່ມັນດີທີ່ຈະຮູ້ວ່າທ່ານມີແຜນການສໍາຮອງໃນກໍລະນີສຸກເສີນ.

6. Autoscaling

TL;DR: ເພີ່ມ ຫຼື ຫຼຸດ ຈ ໍ າ ນວນ ຂອງ ຕົວ ຢ່າງ ການ ບໍ ລິ ການ ຂຶ້ນ ກັບ ມາດ ຕະ ຖານ ທີ່ ກໍາ ນົດ ໄວ້.

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

ຕົວຢ່າງ, Kubernetes ຂະຫນາດບໍລິການໂດຍອີງໃສ່ CPU ແລະຄວາມຈໍາຂອງ pods (ເບິ່ງບົດລາຍງານຂອງພວກເຮົາ "ການປັບຂະໜາດອັດຕະໂນມັດ ແລະການຈັດການຊັບພະຍາກອນໃນ Kubernetes" - ປະ​ມານ​. ແປ.), ແຕ່ຖ້າທ່ານຕັດສິນໃຈຂະຫນາດໂດຍອີງໃສ່ metric ອື່ນໆ (ໃນກໍລະນີຂອງພວກເຮົາ, ການຈະລາຈອນທີ່ກ່ຽວຂ້ອງກັບ), ທ່ານຈະຕ້ອງມີ metric ພິເສດ. ການຄຸ້ມຄອງ ແບບນີ້ ສະແດງໃຫ້ເຫັນວິທີການເຮັດສິ່ງນີ້ກັບ ທູດພິເສດ, ອິຊິໂອ и Prometheus, ແຕ່ຂະບວນການຕົວມັນເອງແມ່ນຂ້ອນຂ້າງສັບສົນ. ພວກເຮົາຕ້ອງການຕາຫນ່າງການບໍລິການເຮັດໃຫ້ງ່າຍດາຍນີ້ໂດຍການອະນຸຍາດໃຫ້ພວກເຮົາພຽງແຕ່ກໍານົດເງື່ອນໄຂເຊັ່ນ: "ເພີ່ມຈໍານວນຂອງຕົວຢ່າງການບໍລິການ. auth, ຖ້າຈໍານວນຄໍາຮ້ອງຂໍທີ່ຍັງຄ້າງຢູ່ເກີນຂອບເຂດພາຍໃນຫນຶ່ງນາທີ."

7. ການນຳໃຊ້ Canary

TL;DR: ທົດສອບຄຸນສົມບັດໃໝ່ ຫຼືເວີຊັນບໍລິການໃນກຸ່ມຜູ້ໃຊ້ຍ່ອຍ.

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

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

8. ການນຳໃຊ້ສີຟ້າ-ສີຂຽວ

TL;DR: ເປີດຕົວຄຸນສົມບັດໃຫມ່ທີ່ເຢັນ, ແຕ່ກຽມພ້ອມທີ່ຈະເອົາທຸກສິ່ງທຸກຢ່າງກັບຄືນ.

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

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

ຫມາຍ​ເຫດ​. ແປ.: ທ່ານ​ສາ​ມາດ​ອ່ານ​ເພີ່ມ​ເຕີມ​ກ່ຽວ​ກັບ​ຍຸດ​ທະ​ສາດ​ການ​ນໍາ​ໃຊ້​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ໃນ Kubernetes (ລວມ​ທັງ canary ທີ່​ກ່າວ​ມາ​, ສີ​ຟ້າ / ສີ​ຂຽວ​ແລະ​ອື່ນໆ​) ໃນ ບົດຂຽນນີ້.

9. ກວດສຸຂະພາບ

TL;DR: ຕິດຕາມເບິ່ງວ່າບໍລິການໃດໃຊ້ໄດ້ ແລະຕອບສະໜອງຕໍ່ສິ່ງທີ່ບໍ່ມີປະໂຫຍດອີກຕໍ່ໄປ.

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

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

10. Load shedding

TL;DR: ປ່ຽນເສັ້ນທາງການຈາລະຈອນໃນການຕອບໂຕ້ຕໍ່ການເພີ່ມຂື້ນຊົ່ວຄາວໃນການນໍາໃຊ້.

ຖ້າຫາກວ່າການບໍລິການສະເພາະໃດຫນຶ່ງແມ່ນ overloaded ກັບການຈະລາຈອນ, ທ່ານສາມາດ redirect ບາງສ່ວນຂອງການຈະລາຈອນນີ້ຊົ່ວຄາວກັບສະຖານທີ່ອື່ນ (ນັ້ນແມ່ນ, "dump", "ໂອນ" (ຫຼົ່ນລົງ) ລາວຢູ່ທີ່ນັ້ນ). ສໍາລັບຕົວຢ່າງ, ການບໍລິການສໍາຮອງຂໍ້ມູນຫຼືສູນຂໍ້ມູນ, ຫຼືຖາວອນ Pulsar ຫົວຂໍ້. ດັ່ງນັ້ນ, ການບໍລິການຈະສືບຕໍ່ດໍາເນີນການບາງຄໍາຮ້ອງຂໍແທນທີ່ຈະ crashing ແລະຢຸດການປຸງແຕ່ງທຸກສິ່ງທຸກຢ່າງທັງຫມົດ. Load shedding ແມ່ນດີກວ່າທີ່ຈະທໍາລາຍວົງຈອນ, ແຕ່ມັນບໍ່ໄດ້ຖືກແນະນໍາໃຫ້ໃຊ້ໃນທາງຜິດ. ມັນຊ່ວຍປ້ອງກັນຄວາມລົ້ມເຫຼວຂອງ cascading ທີ່ເຮັດໃຫ້ການບໍລິການ downstream crash.

11. ການສັນຈອນຂະໜານ/ການສະທ້ອນ

TL;DR: ສົ່ງຄໍາຮ້ອງຂໍຫນຶ່ງໄປຫາຫຼາຍບ່ອນໃນເວລາດຽວກັນ.

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

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

12. insulation

TL;DR: ແຍກຕາໜ່າງການບໍລິການຂອງທ່ານເຂົ້າໄປໃນເຄືອຂ່າຍຂະໜາດນ້ອຍ.

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

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

13. ຮ້ອງຂໍການຈໍາກັດອັດຕາ, retry ແລະ timeouts

TL;DR: ທ່ານບໍ່ຈໍາເປັນຕ້ອງລວມເອົາວຽກງານການຄຸ້ມຄອງຄໍາຮ້ອງຂໍ nitty-gritty ໃນ codebase ຂອງທ່ານ.

ສິ່ງທັງຫມົດເຫຼົ່ານີ້ສາມາດຖືກພິຈາລະນາກໍລະນີການນໍາໃຊ້ແຍກຕ່າງຫາກ, ແຕ່ຂ້ອຍໄດ້ຕັດສິນໃຈສົມທົບພວກມັນເນື່ອງຈາກລັກສະນະທົ່ວໄປຫນຶ່ງ: ເຂົາເຈົ້າປະຕິບັດຫນ້າວຽກການຄຸ້ມຄອງວົງຈອນການຮ້ອງຂໍໂດຍປົກກະຕິຈັດການໂດຍຫ້ອງສະຫມຸດຄໍາຮ້ອງສະຫມັກ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ກໍາ​ລັງ​ພັດ​ທະ​ນາ​ເວັບ​ໄຊ​ຕ​໌ server ໃນ Ruby on Rails (ບໍ່​ໄດ້​ປະ​ສົມ​ປະ​ສານ​ກັບ​ຕາ​ຫນ່າງ​ການ​ບໍ​ລິ​ການ​) ທີ່​ເຮັດ​ໃຫ້​ການ​ຮ້ອງ​ຂໍ​ໃຫ້​ບໍ​ລິ​ການ backend ຜ່ານ ກ. ພ. ພ, ຄໍາຮ້ອງສະຫມັກຈະຕ້ອງຕັດສິນໃຈວ່າຈະເຮັດແນວໃດຖ້າການຮ້ອງຂໍ N ລົ້ມເຫລວ. ທ່ານຍັງຈະຕ້ອງຊອກຫາຈໍານວນການຈະລາຈອນທີ່ບໍລິການເຫຼົ່ານີ້ຈະສາມາດປຸງແຕ່ງແລະ hardcode ຕົວກໍານົດການເຫຼົ່ານີ້ໂດຍໃຊ້ຫ້ອງສະຫມຸດພິເສດ. ນອກຈາກນັ້ນ, ຄໍາຮ້ອງສະຫມັກຈະຕ້ອງຕັດສິນໃຈໃນເວລາທີ່ມັນເຖິງເວລາທີ່ຈະປະຖິ້ມແລະປ່ອຍໃຫ້ຄໍາຮ້ອງຂໍ fizzle ອອກ (ອີງຕາມການຫມົດເວລາ). ແລະເພື່ອປ່ຽນຕົວກໍານົດການຂ້າງເທິງນີ້, ເຄື່ອງແມ່ຂ່າຍເວັບຈະຕ້ອງຖືກຢຸດ, ຕັ້ງຄ່າໃຫມ່ແລະເລີ່ມຕົ້ນອີກເທື່ອຫນຶ່ງ.

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

14. Telemetry

TL;DR: ເກັບກໍາຂໍ້ມູນທີ່ຈໍາເປັນທັງຫມົດ (ແລະບໍ່ຂ້ອນຂ້າງ) ຈາກການບໍລິການ.

Telemetry ແມ່ນຄໍາສັບທົ່ວໄປທີ່ປະກອບມີ metrics, ຕິດຕາມການແຈກຢາຍ, ແລະບັນທຶກ. ຕາໜ່າງການບໍລິການສະເໜີໃຫ້ກົນໄກການເກັບກຳ ແລະປະມວນຜົນຂໍ້ມູນທັງສາມປະເພດ. ນີ້ແມ່ນບ່ອນທີ່ສິ່ງທີ່ເຮັດໃຫ້ມົວເລັກນ້ອຍເພາະວ່າຈໍານວນທາງເລືອກທີ່ເປັນໄປໄດ້ມີຂະຫນາດໃຫຍ່ເກີນໄປ. ເພື່ອເກັບກໍາຂໍ້ວັດແທກມີ Prometheus ແລະເຄື່ອງມືອື່ນໆທີ່ສາມາດຖືກນໍາໃຊ້ເພື່ອເກັບກໍາໄມ້ທ່ອນ ຄ່ອງແຄ້ວ, Loki, Vector ແລະອື່ນໆ. (ຕົວຢ່າງ ClickHouse ກັບຂອງພວກເຮົາ ເຮືອນໄມ້ທ່ອນ ສໍາລັບ K8s - ປະມານ. ແປ.), ສໍາລັບການຕິດຕາມແຈກຢາຍມີ Jaeger ແລະອື່ນໆ. ແຕ່ລະຕາຫນ່າງການບໍລິການອາດຈະສະຫນັບສະຫນູນບາງເຄື່ອງມືແລະບໍ່ແມ່ນເຄື່ອງອື່ນໆ. ມັນຈະເປັນຫນ້າສົນໃຈທີ່ຈະເບິ່ງວ່າໂຄງການສາມາດເຮັດໄດ້ ເປີດ Telemetry ສະຫນອງບາງ convergence.

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

• tail logs ຈາກການບໍລິການສະເພາະໃດຫນຶ່ງໃນ CLI;
• ຕິດຕາມປະລິມານການຮ້ອງຂໍຈາກ dashboard ຕາຫນ່າງການບໍລິການ;
• ເກັບກໍາການຕິດຕາມທີ່ແຈກຢາຍແລະສົ່ງຕໍ່ພວກເຂົາໄປສູ່ລະບົບເຊັ່ນ Jaeger.

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

15. ການກວດສອບ

TL;DR: ຜູ້​ທີ່​ລືມ​ບົດ​ຮຽນ​ປະ​ຫວັດ​ສາດ​ຈະ​ຖືກ​ພິ​ຈາ​ລະ​ນາ​ຄືນ​ໃໝ່.

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

ມັນເປັນທີ່ຊັດເຈນວ່າການກວດສອບແມ່ນກ່ຽວຂ້ອງຢ່າງໃກ້ຊິດກັບ telemetry. ຄວາມແຕກຕ່າງແມ່ນວ່າ telemetry ປົກກະຕິແລ້ວແມ່ນກ່ຽວຂ້ອງກັບສິ່ງຕ່າງໆເຊັ່ນການຜະລິດແລະຄວາມສົມບູນທາງດ້ານເຕັກນິກ, ໃນຂະນະທີ່ການກວດສອບສາມາດກ່ຽວຂ້ອງກັບກົດຫມາຍແລະບັນຫາອື່ນໆທີ່ເກີນຂອບເຂດດ້ານວິຊາການຢ່າງເຂັ້ມງວດ (ຕົວຢ່າງ, ການປະຕິບັດຕາມ GDPR - ກົດລະບຽບທົ່ວໄປຂອງ EU ກ່ຽວກັບການປົກປ້ອງຂໍ້ມູນ).

16. ເບິ່ງຕົວຢ່າງ

TL;DR: React.js ທີ່ມີຊີວິດຊີວາດົນນານ - ແຫຼ່ງອິນເຕີເຟດທີ່ແປກປະຫຼາດທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້.

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

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

ບໍ່ໄດ້ລວມຢູ່ໃນບັນຊີລາຍຊື່

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

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

ສະຫລຸບ

ນັ້ນຄືທັງໝົດໃນຕອນນີ້! ອີກເທື່ອ ໜຶ່ງ, ບັນຊີລາຍຊື່ນີ້ແມ່ນບໍ່ຖືກຕ້ອງຫຼາຍແລະສ່ວນຫຼາຍອາດຈະບໍ່ຄົບຖ້ວນ. ຖ້າ​ຫາກ​ທ່ານ​ຄິດ​ວ່າ​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ພາດ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ຜິດ​ພາດ​, ກະ​ລຸ​ນາ​ຕິດ​ຕໍ່​ຫາ​ຂ້າ​ພະ​ເຈົ້າ​ໃນ Twitter (@lucckerkins). ກະ​ລຸ​ນາ​ເຄົາ​ລົບ​ກົດ​ລະ​ບຽບ​ຂອງ​ຄວາມ​ຖືກ​ຕ້ອງ​.

PS ຈາກນັກແປ

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

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

• «Service Mesh: ສິ່ງທີ່ນັກວິສະວະກອນຊອບແວທຸກຄົນຕ້ອງຮູ້ກ່ຽວກັບເຕັກໂນໂລຢີທີ່ຮ້ອນທີ່ສຸດ"
• «ຕາໜ່າງບໍລິການແມ່ນຫຍັງ ແລະເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງການມັນ [ສຳລັບແອັບພລິເຄຊັນຄລາວກັບບໍລິການຈຸລະພາກ]?"
• «ກັບໄປຫາບໍລິການຈຸລະພາກກັບ Istio. ພາກທີ 1".

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