ສະບາຍດີ! ຂ້ອຍຊື່ Vadim Madison, ຂ້ອຍເປັນຜູ້ນໍາພາການພັດທະນາຂອງ Avito System Platform. ມັນໄດ້ຖືກເວົ້າຫຼາຍກວ່າຫນຶ່ງຄັ້ງວ່າພວກເຮົາຢູ່ໃນບໍລິສັດກໍາລັງເຄື່ອນຍ້າຍຈາກສະຖາປັດຕະຍະກໍາ monolithic ໄປສູ່ microservices ແນວໃດ. ມັນເຖິງເວລາແລ້ວທີ່ຈະແບ່ງປັນວິທີທີ່ພວກເຮົາຫັນປ່ຽນໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາເພື່ອໃຫ້ໄດ້ປະໂຫຍດສູງສຸດຈາກການບໍລິການຈຸລະພາກ ແລະປ້ອງກັນຕົວເຮົາເອງຈາກການສູນເສຍພວກມັນ. PaaS ຊ່ວຍພວກເຮົາແນວໃດຢູ່ທີ່ນີ້, ວິທີທີ່ພວກເຮົາເຮັດໃຫ້ການໃຊ້ງານງ່າຍຂຶ້ນ ແລະຫຼຸດຜ່ອນການສ້າງ microservice ໃຫ້ຄລິກດຽວ - ອ່ານຕໍ່. ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງທີ່ຂ້າພະເຈົ້າຂຽນກ່ຽວກັບຂ້າງລຸ່ມນີ້ແມ່ນປະຕິບັດຢ່າງເຕັມສ່ວນໃນ Avito, ບາງສ່ວນຂອງມັນແມ່ນວິທີທີ່ພວກເຮົາພັດທະນາເວທີຂອງພວກເຮົາ.

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

ພວກເຮົາມາຮອດບໍລິການຈຸລະພາກແນວໃດ

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

ພວກເຮົາໄດ້ສ້າງສະຖາປັດຕະຍະກໍາ microservice ສໍາລັບຫຼາຍປີໃນປັດຈຸບັນ. ແນວໃດແທ້ - ເພື່ອນຮ່ວມງານຂອງພວກເຮົາໃນລາຍລະອຽດ ບອກ ຢູ່ພາກສ່ວນຂອງພວກເຮົາທີ່ RIT ++ 2017. ທີ່ CodeFest 2017 (ເບິ່ງ. видео), Sergey Orlov ແລະ Mikhail Prokopchuk ໄດ້ອະທິບາຍຢ່າງລະອຽດວ່າເປັນຫຍັງພວກເຮົາຕ້ອງການການຫັນປ່ຽນໄປສູ່ microservices ແລະບົດບາດຂອງ Kubernetes ຢູ່ທີ່ນີ້. ແລ້ວ, ຕອນນີ້ພວກເຮົາກໍາລັງເຮັດທຸກຢ່າງເພື່ອຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນຂະຫນາດທີ່ປະກົດຢູ່ໃນສະຖາປັດຕະຍະກໍາດັ່ງກ່າວ.

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

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

ວິທີການເອົາຊະນະຍຸກຂອງ "ການແຕກແຍກຈຸລະພາກ"

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

ນອກຈາກນັ້ນ, ເພື່ອໃຫ້ສະຖາປັດຕະຍະກໍາ microservice ມີປະສິດທິພາບ, ຂະບວນການຈໍານວນຫຼາຍຕ້ອງໄດ້ຮັບການສ້າງຕັ້ງຂຶ້ນ, ຄື:

• ການຕັດໄມ້;
•ຮ້ອງຂໍການຕິດຕາມ (Jaeger);
•ການລວບລວມຄວາມຜິດພາດ (Sentry);
• ສະຖານະ, ຂໍ້ຄວາມ, ເຫດການຈາກ Kubernetes (ການປະມວນຜົນກະແສເຫດການ);
•ຂອບເຂດຈໍາກັດເຊື້ອຊາດ / breaker ວົງຈອນ (ທ່ານສາມາດນໍາໃຊ້ Hystrix);
•ການຄວບຄຸມການເຊື່ອມຕໍ່ການບໍລິການ (ພວກເຮົາໃຊ້ Netramesh);
•ການຕິດຕາມ (Grafana);
• ການຊຸມນຸມ (TeamCity);
•ການສື່ສານແລະການແຈ້ງເຕືອນ (Slack, email);
• ການຕິດຕາມວຽກງານ; (ຈິຣາ)
• ການກະກຽມເອກະສານ.

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

ພວກເຮົາຈັດການການບໍລິການຈຸນລະພາກແນວໃດ

ການຊ່ວຍເຫຼືອຕໍ່ໄປນີ້ເພື່ອປະຕິບັດ "ນະໂຍບາຍຂອງພັກ" ທີ່ເປັນເອກະພາບໃນບັນດາການບໍລິການຈຸລະພາກ Avito ຫຼາຍ:

• ແບ່ງໂຄງສ້າງພື້ນຖານເປັນຊັ້ນໆ;
• ແນວຄວາມຄິດຂອງ Platform as a Service (PaaS);
• ຕິດຕາມກວດກາທຸກສິ່ງທຸກຢ່າງທີ່ເກີດຂຶ້ນກັບ microservices.

ຊັ້ນໂຄງສ້າງ abstraction ປະກອບມີສາມຊັ້ນ. ໃຫ້ໄປຈາກເທິງລົງລຸ່ມ.

A. ທາງເທີງ - service mesh . ທໍາອິດພວກເຮົາໄດ້ພະຍາຍາມ Istio, ແຕ່ມັນໄດ້ຫັນອອກວ່າມັນໃຊ້ຊັບພະຍາກອນຫຼາຍເກີນໄປ, ເຊິ່ງລາຄາແພງເກີນໄປສໍາລັບປະລິມານຂອງພວກເຮົາ. ດັ່ງນັ້ນ, ວິສະວະກອນອາວຸໂສໃນທີມສະຖາປັດຕະຍະກໍາ Alexander Lukyanchenko ພັດທະນາການແກ້ໄຂຂອງຕົນເອງ - Netramesh (ມີຢູ່ໃນ Open Source), ເຊິ່ງປະຈຸບັນພວກເຮົາໃຊ້ໃນການຜະລິດແລະທີ່ບໍລິໂພກຊັບພະຍາກອນຫນ້ອຍກວ່າ Istio ຫຼາຍຄັ້ງ (ແຕ່ບໍ່ໄດ້ເຮັດທຸກຢ່າງທີ່ Istio ສາມາດເວົ້າໂອ້ອວດໄດ້).
B. ຂະຫນາດກາງ - Kubernetes. ພວກເຮົານຳໃຊ້ ແລະປະຕິບັດການບໍລິການຈຸນລະພາກຢູ່ໃນມັນ.
C. ລຸ່ມ - ໂລຫະເປົ່າ. ພວກເຮົາບໍ່ໄດ້ໃຊ້ເມຄ ຫຼືສິ່ງຕ່າງໆເຊັ່ນ OpenStack, ແຕ່ອີງໃສ່ໂລຫະເປົ່າທັງໝົດ.

ຊັ້ນຂໍ້ມູນທັງໝົດຖືກລວມເຂົ້າກັນໂດຍ PaaS. ແລະເວທີນີ້, ໃນທາງກັບກັນ, ປະກອບດ້ວຍສາມສ່ວນ.

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

II. ຜູ້ເກັບລວມ ກັບການຄວບຄຸມຂອງເຄື່ອງມືທັງຫມົດໂດຍຜ່ານ dashboard ທົ່ວໄປ.

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

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

ທໍ່ພັດທະນາການບໍລິການຈຸລະພາກມາດຕະຖານເຮັດວຽກແນວໃດ?

ໂດຍທົ່ວໄປ, ລະບົບຕ່ອງໂສ້ການສ້າງ microservice ເບິ່ງຄືວ່ານີ້:

CLI-push → ການປະສົມປະສານຢ່າງຕໍ່ເນື່ອງ → Bake → Deploy → ການທົດສອບທຽມ → ການທົດສອບ Canary → Squeeze Test → Production → Maintenance.

ຂໍໃຫ້ຜ່ານມັນຢ່າງແທ້ຈິງໃນຄໍາສັ່ງນີ້.

CLI-push

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

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

— ສ້າງ​ການ​ບໍ​ລິ​ການ​ຕາມ​ແມ່​ແບບ — ບາດ​ກ້າວ​ໂດຍ​ຂັ້ນ​ຕອນ​, ໃນ​ຮູບ​ແບບ "ຂອງ​ຄວາມ​ຍາວ​ປາ​"​. ພວກເຮົາມີແມ່ແບບສໍາລັບພາສາການຂຽນໂປລແກລມຕົ້ນຕໍໃນ backend Avito: PHP, Golang ແລະ Python.

- ຫນຶ່ງຄໍາສັ່ງໃນແຕ່ລະຄັ້ງ deploys ສະພາບແວດລ້ອມສໍາລັບການພັດທະນາທ້ອງຖິ່ນໃນເຄື່ອງຈັກສະເພາະໃດຫນຶ່ງ - Minikube ໄດ້ຖືກເປີດຕົວ, Helm charts ແມ່ນອັດຕະໂນມັດສ້າງແລະເປີດຕົວໃນ kubernetes ທ້ອງຖິ່ນ.

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

— ມັນ​ປະ​ຕິ​ບັດ​ການ​ປະ​ກອບ​ສົດ​ຕົວ​ມັນ​ເອງ​. ສົມມຸດວ່ານັກພັດທະນາໄດ້ແກ້ໄຂບາງສິ່ງບາງຢ່າງໃນ microservice ຜ່ານ IDE ຂອງລາວ. ຜົນປະໂຫຍດເຫັນການປ່ຽນແປງໃນລະບົບໄຟລ໌ແລະ, ໂດຍອີງໃສ່ພວກມັນ, ກໍ່ສ້າງແອັບພລິເຄຊັນໃຫມ່ (ສໍາລັບ Golang) ແລະເລີ່ມຕົ້ນໃຫມ່. ສໍາລັບ PHP, ພວກເຮົາພຽງແຕ່ສົ່ງຕໍ່ໄດເລກະທໍລີພາຍໃນ cube ແລະການໂຫຼດສົດແມ່ນໄດ້ຮັບ "ອັດຕະໂນມັດ".

- ສ້າງ autotests. ໃນຮູບແບບຂອງຊ່ອງຫວ່າງ, ແຕ່ຂ້ອນຂ້າງເຫມາະສົມສໍາລັບການນໍາໃຊ້.

• ການນຳໃຊ້ Microservice.

ການນຳໃຊ້ບໍລິການຈຸນລະພາກທີ່ເຄີຍເປັນວຽກເລັກນ້ອຍສຳລັບພວກເຮົາ. ຕໍ່ໄປນີ້ແມ່ນຕ້ອງການ:

I. Dockerfile.

II. ກຳນົດຄ່າ.
III. ຕາຕະລາງ Helm, ເຊິ່ງຕົວມັນເອງແມ່ນສັບສົນແລະປະກອບມີ:

- ຕາຕະລາງດ້ວຍຕົນເອງ;
- ແມ່ແບບ;
— ຄຸນ​ຄ່າ​ສະ​ເພາະ​ຄໍາ​ນ​ຶງ​ເຖິງ​ສະ​ພາບ​ແວດ​ລ້ອມ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​.

ພວກ​ເຮົາ​ໄດ້​ເອົາ​ຄວາມ​ເຈັບ​ປວດ​ອອກ​ຈາກ​ການ reworking Kubernetes manifests ດັ່ງ​ນັ້ນ​ພວກ​ເຂົາ​ເຈົ້າ​ໃນ​ປັດ​ຈຸ​ບັນ​ໄດ້​ຖືກ​ສ້າງ​ຂຶ້ນ​ອັດ​ຕະ​ໂນ​ມັດ​. ແຕ່ສິ່ງທີ່ ສຳ ຄັນທີ່ສຸດ, ພວກເຂົາເຮັດໃຫ້ການ ນຳ ໃຊ້ງ່າຍຂື້ນໃນຂອບເຂດ ຈຳ ກັດ. ຈາກນີ້ໄປພວກເຮົາມີ Dockerfile, ແລະນັກພັດທະນາຂຽນ config ທັງຫມົດໃນໄຟລ໌ app.toml ສັ້ນດຽວ.

ແມ່ນແລ້ວ, ແລະໃນ app.toml ຕົວຂອງມັນເອງບໍ່ມີຫຍັງເຮັດສໍາລັບນາທີ. ພວກເຮົາລະບຸບ່ອນແລະຈໍານວນສໍາເນົາຂອງການບໍລິການທີ່ຈະຍົກຂຶ້ນມາ (ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງ dev, ໃນຂັ້ນຕອນ, ໃນການຜະລິດ), ແລະຊີ້ບອກເຖິງຄວາມຂຶ້ນກັບຂອງມັນ. ສັງເກດເຫັນຂະຫນາດເສັ້ນ = "ຂະຫນາດນ້ອຍ" ໃນຕັນ [ເຄື່ອງຈັກ]. ນີ້ແມ່ນຂອບເຂດຈໍາກັດທີ່ຈະຖືກຈັດສັນໃຫ້ກັບການບໍລິການຜ່ານ Kubernetes.

ຫຼັງຈາກນັ້ນ, ໂດຍອີງໃສ່ config, ຕາຕະລາງ Helm ທີ່ຈໍາເປັນທັງຫມົດແມ່ນຖືກສ້າງຂຶ້ນໂດຍອັດຕະໂນມັດແລະການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນແມ່ນຖືກສ້າງຂຶ້ນ.

• ການກວດສອບພື້ນຖານ. ການກວດສອບດັ່ງກ່າວຍັງອັດຕະໂນມັດ.
ຕ້ອງ​ການ​ຕິດ​ຕາມ​:
— ມີ Dockerfile;
— ມີ app.toml;
— ມີເອກະສານບໍ່?
— ແມ່ນ​ການ​ຂຶ້ນ​ຢູ່​ໃນ​ຄໍາ​ສັ່ງ​?
— ບໍ່​ວ່າ​ຈະ​ເປັນ​ການ​ກໍາ​ນົດ​ລະ​ບຽບ​ການ​ເຕືອນ​.
ເຖິງຈຸດສຸດທ້າຍ: ເຈົ້າຂອງບໍລິການເອງກໍານົດວ່າຕົວຊີ້ວັດຜະລິດຕະພັນໃດທີ່ຈະຕິດຕາມ.

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

I. ລາຍລະອຽດຫຍໍ້ຂອງການບໍລິການ. ຮູ້ຫນັງສືສອງສາມປະໂຫຍກກ່ຽວກັບສິ່ງທີ່ມັນເຮັດແລະເປັນຫຍັງມັນຈໍາເປັນຕ້ອງ.

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

III. ປື້ມບັນທຶກ. ຄູ່ມືສັ້ນໆກ່ຽວກັບການເລີ່ມຕົ້ນການບໍລິການແລະຄວາມຊັບຊ້ອນຂອງການຈັດການມັນ.

IV. FAQ, ບ່ອນທີ່ມັນຈະດີທີ່ຈະຄາດຄະເນບັນຫາທີ່ເພື່ອນຮ່ວມງານຂອງທ່ານອາດຈະພົບໃນເວລາທີ່ເຮັດວຽກກັບການບໍລິການ.

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

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

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

ສຸດທ້າຍ, ມັນເປັນການປະຕິບັດທີ່ດີທີ່ຈະທົບທວນເອກະສານ, ຄ້າຍຄືກັບການທົບທວນຄືນລະຫັດ.

ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ

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

ອົບ

ຂັ້ນຕອນຕໍ່ໄປແມ່ນການບໍລິການການຫຸ້ມຫໍ່ກ່ອນທີ່ຈະນໍາໃຊ້.

• ການກໍ່ສ້າງຄໍາຮ້ອງສະຫມັກ. ອີງຕາມການຄລາສສິກ - ໃນຮູບພາບ Docker.
• ການສ້າງຕາຕະລາງ Helm ສໍາລັບການບໍລິການຕົວມັນເອງແລະຊັບພະຍາກອນທີ່ກ່ຽວຂ້ອງ. ລວມທັງສໍາລັບຖານຂໍ້ມູນແລະ cache. ພວກມັນຖືກສ້າງຂື້ນໂດຍອັດຕະໂນມັດຕາມ config app.toml ທີ່ຖືກສ້າງຂຶ້ນໃນຂັ້ນຕອນ CLI-push.
• ການສ້າງປີ້ສໍາລັບຜູ້ເບິ່ງແຍງເພື່ອເປີດພອດ (ເມື່ອຕ້ອງການ).
• ແລ່ນການທົດສອບຫນ່ວຍງານແລະການຄິດໄລ່ການຄຸ້ມຄອງລະຫັດ. ຖ້າການຄຸ້ມຄອງລະຫັດແມ່ນຕໍ່າກວ່າເກນທີ່ລະບຸໄວ້, ສ່ວນຫຼາຍແລ້ວການບໍລິການຈະບໍ່ໄປຕື່ມອີກ - ເພື່ອປະຕິບັດ. ຖ້າມັນຢູ່ໃນຂອບເຂດທີ່ຍອມຮັບໄດ້, ການບໍລິການຈະຖືກມອບຫມາຍຄ່າສໍາປະສິດ "pessimizing": ຫຼັງຈາກນັ້ນ, ຖ້າບໍ່ມີການປັບປຸງຕົວຊີ້ວັດໃນໄລຍະເວລາ, ນັກພັດທະນາຈະໄດ້ຮັບການແຈ້ງເຕືອນວ່າບໍ່ມີຄວາມຄືບຫນ້າໃນການທົດສອບ (. ແລະບາງສິ່ງບາງຢ່າງທີ່ຕ້ອງເຮັດກ່ຽວກັບມັນ).
• ບັນຊີສໍາລັບຄວາມຈໍາແລະຂໍ້ຈໍາກັດ CPU. ພວກເຮົາສ່ວນໃຫຍ່ຂຽນ microservices ໃນ Golang ແລະດໍາເນີນການໃຫ້ເຂົາເຈົ້າໃນ Kubernetes. ເພາະສະນັ້ນ, ຄວາມອ່ອນໂຍນອັນ ໜຶ່ງ ທີ່ກ່ຽວຂ້ອງກັບຄວາມແປກປະຫຼາດຂອງພາສາ Golang: ໂດຍຄ່າເລີ່ມຕົ້ນ, ເມື່ອເລີ່ມຕົ້ນ, ທຸກແກນໃນເຄື່ອງແມ່ນໃຊ້, ຖ້າທ່ານບໍ່ໄດ້ຕັ້ງຕົວແປ GOMAXPROCS ຢ່າງຈະແຈ້ງ, ແລະເມື່ອການບໍລິການດັ່ງກ່າວຖືກເປີດຕົວໃນເຄື່ອງດຽວກັນ, ພວກມັນເລີ່ມຕົ້ນ. ​ເພື່ອ​ແຂ່ງ​ຂັນ​ດ້ານ​ຊັບ​ພະ​ຍາ​ກອນ, ແຊກ​ແຊງ​ເຂົ້າ​ກັນ. ເສັ້ນສະແດງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນວ່າເວລາປະຕິບັດການປ່ຽນແປງແນວໃດຖ້າທ່ານດໍາເນີນການຄໍາຮ້ອງສະຫມັກໂດຍບໍ່ມີການຂັດແຍ້ງແລະໃນການແຂ່ງຂັນສໍາລັບຮູບແບບຊັບພະຍາກອນ. (ແຫຼ່ງຂໍ້ມູນຂອງກາຟແມ່ນ ທີ່ນີ້).

ເວລາປະຕິບັດ, ຫນ້ອຍແມ່ນດີກວ່າ. ສູງສຸດ: 643ms, ຕໍາ່ສຸດທີ່: 42ms. ຮູບແມ່ນສາມາດຄລິກໄດ້.

ເວລາສໍາລັບການຜ່າຕັດ, ຫນ້ອຍແມ່ນດີກວ່າ. ສູງສຸດ: 14091 ns, ຕໍາ່ສຸດທີ່: 151 ns. ຮູບແມ່ນສາມາດຄລິກໄດ້.

ໃນຂັ້ນຕອນການກະກຽມການປະກອບ, ທ່ານສາມາດກໍານົດຕົວແປນີ້ຢ່າງຊັດເຈນຫຼືທ່ານສາມາດນໍາໃຊ້ຫ້ອງສະຫມຸດ automaxprocs ຈາກຜູ້ຊາຍຈາກ Uber.

ນຳໃຊ້

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

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

ການທົດສອບສັງເຄາະ

• ການທົດສອບຮອບປິດ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາໃຊ້ແຫຼ່ງເປີດ Hoverfly.io. ຫນ້າທໍາອິດ, ມັນບັນທຶກການໂຫຼດທີ່ແທ້ຈິງໃນການບໍລິການ, ຫຼັງຈາກນັ້ນ - ພຽງແຕ່ຢູ່ໃນ loop ປິດ - ມັນ emulates ມັນ.

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

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

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

b) ພວກເຮົາເບິ່ງການຕັດອອກຕາມ RPS.
ນີ້ພວກເຮົາເບິ່ງຄວາມແຕກຕ່າງລະຫວ່າງສະບັບປະຈຸບັນແລະສະບັບທີ່ຜ່ານມາແລະປະລິມານທັງຫມົດ. ຕົວຢ່າງ, ຖ້າການບໍລິການຜະລິດ 100 rps, ຫຼັງຈາກນັ້ນມັນຖືກຂຽນບໍ່ດີ, ຫຼືນີ້ແມ່ນສະເພາະຂອງມັນ, ແຕ່ໃນກໍລະນີໃດກໍ່ຕາມ, ນີ້ແມ່ນເຫດຜົນທີ່ຈະເບິ່ງການບໍລິການຢ່າງໃກ້ຊິດ.
ຖ້າຫາກວ່າ, ໃນທາງກົງກັນຂ້າມ, ມີ RPS ຫຼາຍເກີນໄປ, ບາງທີອາດມີບາງປະເພດຂອງຂໍ້ບົກພ່ອງແລະບາງຈຸດສິ້ນສຸດໄດ້ຢຸດເຊົາການດໍາເນີນການ payload, ແລະບາງອັນອື່ນຖືກກະຕຸ້ນຢ່າງງ່າຍດາຍ. return true;

ການທົດສອບ Canary

ຫຼັງຈາກທີ່ພວກເຮົາຜ່ານການທົດສອບສັງເຄາະ, ພວກເຮົາທົດສອບ microservice ໃນຈໍານວນຜູ້ໃຊ້ຈໍານວນຫນ້ອຍ. ພວກເຮົາເລີ່ມຕົ້ນຢ່າງລະມັດລະວັງ, ດ້ວຍສ່ວນແບ່ງນ້ອຍໆຂອງຜູ້ຊົມທີ່ມີຈຸດປະສົງຂອງການບໍລິການ - ຫນ້ອຍກວ່າ 0,1%. ໃນຂັ້ນຕອນນີ້, ມັນເປັນສິ່ງສໍາຄັນຫຼາຍທີ່ຕົວຊີ້ວັດດ້ານວິຊາການແລະຜະລິດຕະພັນທີ່ຖືກຕ້ອງຖືກລວມເຂົ້າໃນການຕິດຕາມເພື່ອໃຫ້ພວກເຂົາສະແດງບັນຫາໃນການບໍລິການໄວເທົ່າທີ່ຈະໄວໄດ້. ເວລາຂັ້ນຕ່ໍາສໍາລັບການທົດສອບ canary ແມ່ນ 5 ນາທີ, ຕົ້ນຕໍແມ່ນ 2 ຊົ່ວໂມງ. ສໍາລັບການບໍລິການທີ່ສັບສົນ, ພວກເຮົາກໍານົດເວລາດ້ວຍຕົນເອງ.
ໃຫ້ເຮົາວິເຄາະ:
— metrics ສະເພາະພາສາ, ໂດຍສະເພາະ, ພະນັກງານ php-fpm;
- ຄວາມ​ຜິດ​ພາດ​ໃນ Sentry​;
- ສະ​ຖາ​ນະ​ການ​ຕອບ​ສະ​ຫນອງ​;
— ທີ່​ໃຊ້​ເວ​ລາ​ຕອບ​ສະ​ຫນອງ​, ທີ່​ແນ່​ນອນ​ແລະ​ສະ​ເລ່ຍ​;
- latency;
— ຂໍ້​ຍົກ​ເວັ້ນ, ການ​ປຸງ​ແຕ່ງ​ແລະ​ການ​ບໍ່​ມີ​ການ​ຈັດ​ການ​;
- ຕົວ​ຊີ້​ວັດ​ຜະ​ລິດ​ຕະ​ພັນ​.

ການທົດສອບບີບ

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

ການຜະລິດ

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

ດັ່ງນັ້ນ, ເມື່ອການປັບຂະຫນາດພວກເຮົາວິເຄາະ:
- ຕົວ​ຊີ້​ວັດ CPU ແລະ RAM​,
- ຈໍາ​ນວນ​ຂອງ​ການ​ຮ້ອງ​ຂໍ​ໃນ​ແຖວ​,
- ເວ​ລາ​ຕອບ​ສະ​ຫນອງ​,
— ການ​ຄາດ​ຄະ​ເນ​ໂດຍ​ອີງ​ໃສ່​ຂໍ້​ມູນ​ປະ​ຫວັດ​ສາດ​ສະ​ສົມ​.

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

ບໍລິການ

ຫຼັງຈາກການບໍລິການຈຸນລະພາກຖືກປະຕິບັດແລ້ວ, ພວກເຮົາສາມາດຕິດພັນກັບມັນ.

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

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

ແຜງໜ້າປັດ

ໃນສັ້ນ, dashboard ແມ່ນແຜງຄວບຄຸມຂອງ PaaS ທັງຫມົດຂອງພວກເຮົາ.

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

ລວມ

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

ຂ້າພະເຈົ້າໄດ້ໃຫ້ບົດລາຍງານກ່ຽວກັບຫົວຂໍ້ນີ້ສໍາລັບ HighLoad++ 2018, ທ່ານສາມາດເບິ່ງມັນໄດ້ видео и ການນໍາສະເຫນີ.

ຕິດຕາມໂບນັດສໍາລັບຜູ້ທີ່ອ່ານຈົນຈົບ

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

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

ທ່ານສາມາດສະຫມັກຂໍເອົາການເຂົ້າຮ່ວມ ໃນຮູບແບບ google ນີ້. ຈາກທ່ານ - ຄໍາຕອບຂອງຄໍາຖາມວ່າເປັນຫຍັງທ່ານຈໍາເປັນຕ້ອງເຂົ້າຮ່ວມການຝຶກອົບຮົມແລະຂໍ້ມູນກ່ຽວກັບວິທີຕິດຕໍ່ທ່ານ. ຕອບເປັນພາສາອັງກິດ ເພາະຄຣິສຈະເລືອກຜູ້ທີ່ຈະເຂົ້າຝຶກອົບຮົມເອງ.
ພວກເຮົາຈະປະກາດຊື່ຂອງຜູ້ເຂົ້າຮ່ວມການຝຶກອົບຮົມໃນການປັບປຸງການຕອບນີ້ແລະໃນເຄືອຂ່າຍສັງຄົມ Avito ສໍາລັບນັກພັດທະນາ (AvitoTech ໃນ ເຟສບຸກ, Вконтакте, Twitter) ບໍ່ເກີນ 19 ກໍລະກົດ.

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