ທາງເທີງ fakapov Cyan

ດີຕໍ່ທຸກຄົນ! 

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

Preamble

ດົນນານມາແລ້ວ, ເມື່ອ Cian ປະກອບດ້ວຍ monoliths, ແລະບໍ່ມີຄໍາແນະນໍາຂອງ microservices ເທື່ອ, ພວກເຮົາໄດ້ວັດແທກຄວາມພ້ອມຂອງຊັບພະຍາກອນໂດຍການກວດສອບ 3-5 ຫນ້າ. 

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

ຫນ້າຕົ້ນຕໍຂອງເວັບໄຊທ໌ຫຼືວິທີທີ່ພວກເຮົາເຂົ້າໃຈວ່າພວກເຮົາໄດ້ຕີດ້ານລຸ່ມ

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

ສົມມຸດວ່າພວກເຮົາໄດ້ພົບເຫັນວ່າມີຫຼາຍໆພາກສ່ວນທີ່ສໍາຄັນຂອງເວັບໄຊທ໌ທີ່ຮັບຜິດຊອບສໍາລັບການບໍລິການຕົ້ນຕໍ - ການຊອກຫາແລະການສົ່ງໂຄສະນາ. ຖ້າຈໍານວນຄໍາຮ້ອງຂໍທີ່ລົ້ມເຫລວເກີນ 1%, ນີ້ແມ່ນເຫດການສໍາຄັນ. ຖ້າພາຍໃນ 15 ນາທີໃນຊ່ວງເວລາສໍາຄັນອັດຕາຄວາມຜິດພາດເກີນ 0,1%, ນີ້ກໍ່ຖືວ່າເປັນເຫດການສໍາຄັນ. ເງື່ອນໄຂເຫຼົ່ານີ້ກວມເອົາສ່ວນໃຫຍ່ຂອງເຫດການ; ສ່ວນທີ່ເຫຼືອແມ່ນເກີນຂອບເຂດຂອງບົດຄວາມນີ້.

ເຫດການທີ່ດີທີ່ສຸດໃນ Cyan

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮຽນຮູ້ຢ່າງແນ່ນອນເພື່ອກໍານົດຄວາມຈິງທີ່ວ່າເຫດການເກີດຂຶ້ນ. 

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

ຖ້າທ່ານລວບລວມຄວາມລົ້ມເຫລວທັງຫມົດໃນໄລຍະສອງສາມປີຜ່ານມາ, ຜູ້ນໍາແມ່ນ: 

• mssql ເຫດການທີ່ກ່ຽວຂ້ອງ;
• ເຫດການທີ່ເກີດຈາກປັດໃຈພາຍນອກ;
• ຜິດພາດ admin.

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

ອັນດັບທີຫ້າ - "ການຈັດວາງສິ່ງທີ່ເປັນລະບຽບໃນ DNS"

ມັນເປັນພາຍຸໃນວັນອັງຄານ. ພວກເຮົາໄດ້ຕັດສິນໃຈຟື້ນຟູຄໍາສັ່ງໃນກຸ່ມ DNS. 

ຂ້ອຍຕ້ອງການໂອນເຄື່ອງແມ່ຂ່າຍ DNS ພາຍໃນຈາກຜູກກັບ powerdns, ຈັດສັນເຄື່ອງແມ່ຂ່າຍແຍກຕ່າງຫາກຢ່າງສົມບູນສໍາລັບການນີ້, ບ່ອນທີ່ບໍ່ມີຫຍັງຍົກເວັ້ນ DNS. 

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

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

ຂໍ້ສະຫຼຸບ:

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

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

ອັນດັບທີສີ່ - "ຈັດວາງສິ່ງຕ່າງໆໃຫ້ເປັນລະບຽບໃນ Nginx"

ມື້ຫນຶ່ງທີ່ດີ, ທີມງານຂອງພວກເຮົາໄດ້ຕັດສິນໃຈວ່າ "ພວກເຮົາມີພຽງພໍໃນເລື່ອງນີ້," ແລະຂະບວນການຂອງ refactoring configs nginx ໄດ້ເລີ່ມຕົ້ນ. ເປົ້າຫມາຍຕົ້ນຕໍແມ່ນເພື່ອນໍາເອົາ configs ໄປສູ່ໂຄງສ້າງ intuitive. ກ່ອນຫນ້ານີ້, ທຸກສິ່ງທຸກຢ່າງແມ່ນ "ສ້າງຕັ້ງຂຶ້ນໃນປະຫວັດສາດ" ແລະບໍ່ມີເຫດຜົນໃດໆ. ໃນປັດຈຸບັນແຕ່ລະ server_name ໄດ້ຖືກຍ້າຍໄປໄຟລ໌ທີ່ມີຊື່ດຽວກັນແລະ config ທັງຫມົດໄດ້ຖືກແຈກຢາຍເຂົ້າໄປໃນໂຟນເດີ. ໂດຍວິທີທາງການ, config ມີ 253949 ແຖວຫຼື 7836520 ຕົວອັກສອນແລະໃຊ້ເວລາເຖິງເກືອບ 7 megabytes. ໂຄງສ້າງລະດັບສູງສຸດ: 

ໂຄງສ້າງ Nginx

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

ມັນໄດ້ກາຍເປັນທີ່ດີກວ່າ, ແຕ່ໃນຂະບວນການປ່ຽນຊື່ແລະການແຈກຢາຍ configs, ບາງສ່ວນຂອງພວກມັນມີສ່ວນຂະຫຍາຍທີ່ບໍ່ຖືກຕ້ອງແລະບໍ່ໄດ້ລວມຢູ່ໃນຄໍາສັ່ງ *.conf. ດັ່ງນັ້ນ, ບາງເຈົ້າພາບກາຍເປັນບໍ່ສາມາດໃຊ້ໄດ້ແລະສົ່ງຄືນ 301 ໄປຫາຫນ້າຫລັກ. ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າລະຫັດຕອບສະຫນອງບໍ່ແມ່ນ 5xx/4xx, ນີ້ບໍ່ໄດ້ສັງເກດເຫັນທັນທີ, ແຕ່ວ່າພຽງແຕ່ໃນຕອນເຊົ້າ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາເລີ່ມຂຽນການທົດສອບເພື່ອກວດກາເບິ່ງອົງປະກອບໂຄງສ້າງພື້ນຖານ.

ຂໍ້ສະຫຼຸບ: 

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

ສະຖານທີ່ທີສາມ - "ທັນທີທັນໃດແລ່ນອອກຈາກພື້ນທີ່ໃນ Cassandra"

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

ມື້ໜຶ່ງທີ່ມີພາຍຸ, ກຸ່ມເກືອບກາຍເປັນຜັກ, ຄື:

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

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

ຂໍ້ສະຫຼຸບ:

• ໃນເຄື່ອງແມ່ຂ່າຍຂອງ cassandra ທັງຫມົດ, ບໍ່ເກີນ 60% ຂອງພື້ນທີ່ໃນແຕ່ລະພາທິຊັນຄວນຈະຖືກຄອບຄອງ. 
• ພວກເຂົາຄວນຈະຖືກໂຫລດຢູ່ທີ່ບໍ່ເກີນ 50% cpu.
• ທ່ານບໍ່ຄວນລືມກ່ຽວກັບການວາງແຜນຄວາມອາດສາມາດແລະຈໍາເປັນຕ້ອງຄິດມັນໂດຍຜ່ານແຕ່ລະອົງປະກອບ, ໂດຍອີງໃສ່ສະເພາະຂອງມັນ.
• ຫຼາຍ nodes ໃນ cluster, ທີ່ດີກວ່າ. ເຊີບເວີທີ່ບັນຈຸຂໍ້ມູນໜ້ອຍໜຶ່ງແມ່ນໂຫຼດເກີນໄວ, ແລະກຸ່ມດັ່ງກ່າວຈະຟື້ນຟູໄດ້ງ່າຍຂຶ້ນ. 

ອັນດັບທີສອງ - "ຂໍ້ມູນຫາຍໄປຈາກການເກັບຮັກສາກະແຈຂອງກົງສຸນ"

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

ຂໍ້ສະຫຼຸບ:

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

ສະຖານທີ່ທໍາອິດ - "Captain Unobvious" 

ໃນບາງຈຸດ, ພວກເຮົາສັງເກດເຫັນການແຈກຢາຍການໂຫຼດທີ່ບໍ່ສະເຫມີກັນໃນ nginx upstreams ໃນກໍລະນີທີ່ມີເຄື່ອງແມ່ຂ່າຍ 10+ ໃນ backend. ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າ round-robin ໄດ້ສົ່ງຄໍາຮ້ອງຂໍຈາກ 1st ໄປຫາ upstream ສຸດທ້າຍຕາມລໍາດັບ, ແລະແຕ່ລະ nginx reload ເລີ່ມຕົ້ນໃຫມ່, ການ upstreams ທໍາອິດສະເຫມີໄດ້ຮັບການຮ້ອງຂໍຫຼາຍກ່ວາສ່ວນທີ່ເຫຼືອ. ດັ່ງນັ້ນ, ພວກເຂົາເຈົ້າເຮັດວຽກຊ້າລົງແລະເວັບໄຊທ໌ທັງຫມົດໄດ້ຮັບຄວາມເສຍຫາຍ. ນີ້ໄດ້ກາຍເປັນທີ່ສັງເກດເຫັນເພີ່ມຂຶ້ນຍ້ອນວ່າຈໍານວນການຈະລາຈອນເພີ່ມຂຶ້ນ. ພຽງແຕ່ການອັບເດດ nginx ເພື່ອເປີດໃຊ້ແບບສຸ່ມບໍ່ໄດ້ຜົນ - ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດຄືນລະຫັດ lua ທີ່ບໍ່ໄດ້ອອກໃນຮຸ່ນ 1.15 (ໃນຂະນະນັ້ນ). ພວກເຮົາຕ້ອງແກ້ໄຂ nginx 1.14.2 ຂອງພວກເຮົາ, ແນະນໍາການສະຫນັບສະຫນູນແບບສຸ່ມເຂົ້າໄປໃນມັນ. ນີ້ໄດ້ແກ້ໄຂບັນຫາ. ແມງໄມ້ນີ້ຊະນະປະເພດ "Captain ບໍ່ຈະແຈ້ງ".

ຂໍ້ສະຫຼຸບ:

ມັນຫນ້າສົນໃຈແລະຕື່ນເຕັ້ນຫຼາຍທີ່ຈະຄົ້ນຫາແມງໄມ້ນີ້). 

• ຈັດຕັ້ງການຕິດຕາມຂອງທ່ານເພື່ອໃຫ້ມັນຊ່ວຍໃຫ້ທ່ານຊອກຫາການເຫນັງຕີງດັ່ງກ່າວຢ່າງໄວວາ. ຕົວຢ່າງ, ທ່ານສາມາດນໍາໃຊ້ ELK ເພື່ອຕິດຕາມ rps ໃນແຕ່ລະ backend ຂອງແຕ່ລະນ້ໍາ, ຕິດຕາມເວລາຕອບສະຫນອງຂອງພວກເຂົາຈາກຈຸດຂອງ nginx. ໃນກໍລະນີນີ້, ນີ້ຊ່ວຍໃຫ້ພວກເຮົາກໍານົດບັນຫາ. 

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

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