ฉันเดาว่าคุณหมายถึง นี้ การตั้งค่า DNS ของ Shopify

ชี้ ก บันทึกไปยังที่อยู่ IP ของ Shopify 23.227.38.65. ชี้ CNAME บันทึกด้วยชื่อ www ถึง ร้านค้า.myshopify.com

โดเมนราก (@)

อย่างที่คุณทราบ คุณไม่สามารถมี CNAME บนรูท (@) โดเมน ดังนั้นโดเมนรูทจำเป็นต้องจัดการด้วย a ก และ AAAA บันทึกที่ชี้ไปที่ที่อยู่ IP คงที่

วิธีที่บริษัทขนาดใหญ่ปรับขนาดนี้ทั่วโลกคือการใช้ "anycast" ซึ่งมีการประกาศที่อยู่ IP เดียวกันผ่าน BGP จากศูนย์ข้อมูลหลายแห่ง

คุณสามารถคิดว่า Anycast เป็นโหลดบาลานซ์ที่จัดการโดยเราเตอร์ โดยที่เซิร์ฟเวอร์หลายเครื่องในศูนย์ข้อมูลเดียวกันหรือต่างกันสามารถรับและจัดการทราฟฟิกสำหรับที่อยู่ IP เดียวได้

หากคุณยังไม่ได้เป็น AS ที่มีพื้นที่ IP ของคุณเอง การออกอากาศใดๆ ก็ไม่อยู่ในขอบเขตสำหรับคุณอย่างแน่นอน

วิธีง่ายๆ ในการเริ่มที่นี่คือไม่เรียกใช้โฮสติ้งใดๆ บนโดเมนรูท แต่เพียงแค่เปลี่ยนเส้นทางไปที่ www. จากนั้นกล่องตัวเปลี่ยนเส้นทาง nginx กล่องเดียว (หรือหลายกล่องที่อยู่หลังตัวโหลดบาลานเซอร์ level4/tcp) สามารถรองรับการเปลี่ยนเส้นทางโดเมนจำนวนมาก

หากคุณต้องการกล่องจำนวนมากเนื่องจากมีคำขอจำนวนมาก ให้ใช้โหลดบาลานซ์ tcp/layer4 กับเซิร์ฟเวอร์ตัวเปลี่ยนเส้นทางของคุณ เพื่อให้คุณสามารถทำแอปพลิเคชัน (http) และการยกเลิก ssl บนกล่องที่อยู่ด้านหลังตัวโหลดบาลานเซอร์เพื่อความสามารถในการปรับขนาดที่มากขึ้น (ตัวโหลดบาลานซ์ตัวเดียวสามารถ รองรับการจราจรได้มากขึ้น)

ใช้การเปลี่ยนเส้นทางถาวร (301) ซึ่ง แคชอย่างไม่มีกำหนด ลดทราฟฟิกที่เกิดซ้ำจากลูกค้ารายเดิม

แนวทางปฏิบัติที่ดีที่สุดที่นี่ ใช้ letsencrypt/certbot เพื่อสร้างอัตโนมัติ/ต่ออายุโดเมนตัวเปลี่ยนเส้นทางเมื่อตั้งค่า DNS แล้ว เปลี่ยนเส้นทางไปที่ https ในโดเมนเดียวกันเสมอ (เช่น. http://example.com --> https://example.com) ก่อนเปลี่ยนเส้นทางไปยังโดเมนอื่น (https://www.example.com).

www

กำลังดูของ shopify ร้านค้า.myshopify.com (ที่ไหน www CNAME ควรชี้) จะเห็นว่ามีอันเดียว ก บันทึกที่เป็นอยู่ในปัจจุบัน 23.227.38.74.

ใช้ก เครื่องมือ ping ทั่วโลก คุณจะเห็นว่า IP นี้มีเวลาแฝงไม่กี่มิลลิวินาทีจากหลายแห่งทั่วโลก ซึ่งหมายความว่าไม่ใช่เซิร์ฟเวอร์เดียวในตำแหน่งเดียว (เวลาแฝงข้ามมหาสมุทรแอตแลนติกมักจะทำงาน 60ms ในกรณีที่ดีที่สุด...ดังนั้นเมื่อคุณเห็น ping 4ms จากสหรัฐอเมริกาและสหภาพยุโรปสำหรับ IP เดียวกัน...คุณจะรู้ว่า ping เหล่านั้นไม่ใช่' ไปที่เซิร์ฟเวอร์เดียวกัน) คุณยังสามารถตรวจสอบได้โดยเรียกใช้เส้นทางการติดตามไปยัง IP เดียวกันจากเซิร์ฟเวอร์ต่างๆ ในภูมิศาสตร์ที่แตกต่างกัน

ที่ปลายทางแต่ละแห่งที่ตอบสนองต่อ IP นั้น พวกเขาอาจมีตัวจัดสรรภาระงานที่กำหนดเส้นทางคำขอไปยังฮาร์ดแวร์ต่างๆ

ดังนั้นเบื้องหลัง Shopify CNAME จึงเป็น single-IP anycast ข้อดีของการให้ CNAME แก่ลูกค้าของคุณคือคุณมีอิสระในการเปลี่ยน IP ที่อยู่เบื้องหลังชื่อนั้น โดยที่ลูกค้าของคุณไม่จำเป็นต้องอัปเดต DNS ในตอนท้าย โปรดทราบว่า... เมื่อคุณให้ลูกค้าของคุณ ก บันทึกสำหรับรากของพวกเขา (@) ตัวเปลี่ยนเส้นทางโดเมน... คุณต้องแน่ใจว่านี่คือที่อยู่ IP ที่คุณสามารถควบคุมและกำหนดใหม่ให้กับฮาร์ดแวร์อื่นได้ หากคุณมีปัญหากับเซิร์ฟเวอร์/ตัวโหลดบาลานซ์ (เช่น สิ่งที่เป็นประเภท IP ยืดหยุ่นของ AWS หรือพื้นที่ IP ของคุณเอง ถ้าคุณเป็น AS)

เท่าที่ฉันทราบ ไม่มี "คำใบ้" ใดๆ ที่ระบุในคำขอ DNS (และส่วนหนึ่งของการแคชตัวแก้ไข DNS) เมื่อคอมพิวเตอร์ของคุณติดตามเชน CNAME เมื่อแก้ไขชื่อเพื่อบอกเซิร์ฟเวอร์ DNS สุดท้ายว่าโดเมนดั้งเดิมคืออะไร ที่คุณร้องขอ หากมี คุณอาจจินตนาการว่าเซิร์ฟเวอร์ DNS มีกฎเงื่อนไขเพื่อส่งคืนที่อยู่ IP ที่แตกต่างกันสำหรับชื่อเดียวกัน โดยขึ้นอยู่กับชื่อที่อยู่ด้านหลัง

ดังนั้นหากคุณไม่ต้องการใช้วิธี Shopify (bgp/anycast) สิ่งที่ตรงไปตรงมาที่สุดคือการให้ลูกค้าของคุณ CNAME ที่ไม่ซ้ำกัน. ด้วยวิธีนี้ คุณสามารถทำโหลดบาลานซ์ในระดับ DNS (ส่งคืน IP ที่แตกต่างกันสำหรับ CNAME ของลูกค้าแต่ละรายที่ไม่ซ้ำกัน)

คุณสามารถปฏิบัติตามแบบแผนบางอย่างเช่น customerdomain.tld.example.com และจัดเตรียม DNS โดยอัตโนมัติตามฐานข้อมูลทรัพย์สินของลูกค้า

และสำหรับโดเมนรูท (@) คุณยังสามารถใช้ IP ตัวเปลี่ยนเส้นทางเดียว (อย่างน้อยหนึ่งกล่องหลัง IP/load-balancer เดียว) จัดการการเปลี่ยนเส้นทางสำหรับโดเมนทั้งหมดเพื่อ www.customerdomain.tld CNAME ใด customerdomain.tld.example.com.

อัปเดต... ฉันอาจพลาดประเด็นของคำถามของคุณ

สิ่งนี้จะช่วยได้มากเมื่อฉันต้องการย้ายเว็บไซต์จำนวนมากไปยังโครงสร้างพื้นฐานใหม่

ดังที่ฉันได้กล่าวไว้ข้างต้น อย่างน้อยก็สำหรับ root/@ ในกรณีนี้ คุณต้องควบคุม IP นั้นและสามารถกำหนดให้กับโครงสร้างพื้นฐานอื่นได้...ไม่เช่นนั้น ลูกค้าทั้งหมดของคุณจะต้องอัปเดต DNS เมื่อ IP นั้นเปลี่ยนแปลงเนื่องจากการย้ายข้อมูล

สำหรับ www/CNAME กรณีนี้ไม่ใช่ปัญหาเพราะคุณสามารถอัปเดต IP ที่อยู่เบื้องหลัง CNAME บน DNS ของคุณเองได้

ดังนั้นฉันจะเน้นที่ตัวเลือกสำหรับโดเมนรูทเท่านั้น (@) เนื่องจากเป็นปัญหามากที่สุด (ลูกค้าต้องดำเนินการเพื่ออัปเดต DNS เมื่อที่อยู่ IP ของบริการเปลี่ยนแปลง) ตัวเลือก...

ตัวเลือก 0 - ไม่รองรับรูท/@ โดเมนสำหรับลูกค้า

ไม่ว่าคุณจะโฮสต์อะไรก็ตาม ให้โฮสต์บนโดเมนย่อย (www หรืออื่น ๆ). หากลูกค้าต้องการเปลี่ยนเส้นทาง ก็สามารถจัดการได้เมื่อสิ้นสุดการทำงานกับเจ้าหน้าที่ไอที

สิ่งนี้จะลบ DNS ของลูกค้าที่ชี้ไปที่ปัญหาที่อยู่ IP ที่แก้ไขออกอย่างสมบูรณ์ คุณสามารถอัปเดตที่อยู่ IP ของ CNAME ทางฝั่งของคุณ และการย้ายโครงสร้างพื้นฐานหรือการเปลี่ยนแปลง IP จะกลายเป็นเรื่องง่ายๆ

ตัวเลือก 1 - ที่อยู่ IP ที่กำหนดได้

คุณสามารถใช้สิ่งต่างๆ เช่น ที่อยู่ IP ที่กำหนดได้ (สิ่งที่เป็นประเภท IP แบบยืดหยุ่นของ AWS ผู้ให้บริการ VPS ที่จริงจังส่วนใหญ่เสนอสิ่งที่คล้ายกัน)

สิ่งนี้ทำให้คุณสามารถปรับใช้เซิร์ฟเวอร์ใหม่ (ที่ผู้ให้บริการรายนั้น) จากนั้นเปลี่ยน IP ไปยังเซิร์ฟเวอร์ใหม่

ปัญหาคือคุณล็อคอินผู้ขาย/ผู้ให้บริการ เนื่องจากที่อยู่ IP เป็นของผู้ขาย ดังนั้น หากคุณต้องการย้ายจาก AWS ไปยัง Google-Cloud หรือฮาร์ดแวร์ของคุณเอง คุณจะไม่สามารถนำ IP เหล่านั้นติดตัวไปด้วยได้....การอัปเดต DNS สำหรับลูกค้าของคุณ นอกจากนี้ IPs อาจถูกล็อคภูมิภาค ดังนั้นคุณจึงไม่สามารถกำหนด IP ให้กับเซิร์ฟเวอร์อื่นที่ผู้ให้บริการในศูนย์ข้อมูลอื่นได้อย่างง่ายดาย

ตัวเลือก 2 - กลายเป็น AS และรับพื้นที่ IP ของคุณเอง

หากคุณกำลังดำเนินการโฮสติ้งอย่างจริงจัง เป็นเพียงเรื่องของเวลาก่อนที่คุณจะต้องเป็น AS (ระบบอัตโนมัติ) ทาง อริน หรือ สุก หรือองค์กรอื่น หากบริษัทของคุณอยู่นอกอเมริกาเหนือและยุโรป

จากนั้นคุณจะต้องได้รับ (หรือเช่า) บล็อกที่อยู่ IP ของคุณเอง คุณสามารถรับ ipv6 ฟรีได้ตามปกติ ipv4 หมดแล้ว แต่อย่างน้อย RIPE ก็ช่วยให้คุณอยู่ในรายการรอสำหรับ a /24 (ที่อยู่ 256 แห่ง) เมื่อพวกเขากู้คืนเมื่อเวลาผ่านไป มิฉะนั้น คุณจะต้องซื้อพื้นที่ที่อยู่จากผู้อื่น (มีตลาดที่คุณสามารถเข้าร่วมได้)

และแน่นอนว่าคุณต้องทำงานร่วมกับผู้ให้บริการที่อนุญาตให้คุณนำที่อยู่ IP ของคุณเอง

ต่อไปนี้คือลิงค์ที่ใช้งานได้จริงสองสามลิงค์ที่อธิบายถึงการตั้งค่า anycast แต่สำหรับผู้เริ่มต้น ให้ละเว้นบิตของ anycast และมุ่งเน้นไปที่การตั้งค่าการรับเป็น AS รับพื้นที่ IP และค้นหาพันธมิตรอินฟาเรดที่เหมาะสม (เนื่องจากการเรียกใช้ BGP/anycast ไม่ใช่เรื่องเล็กน้อย)

• https://labs.ripe.net/author/samir_jafferali/build-your-own-anycast-network-in-nine-steps/
• https://ripe69.ripe.net/wp-content/uploads/presentations/36-Anycast-on-a-shoe-string-RIPE69.pdf

ข้อเสีย:

• ลงทุนเวลาเพื่อตั้งค่าและเรียนรู้ (เช่น BGP หากผู้ให้บริการอัพสตรีมของคุณไม่จัดการให้คุณ)
• การลงทุนทางการเงิน (ค่าสมาชิก/ค่า IP สำหรับ RIPE/ARIN และค่าใช้จ่ายสูงที่อาจเกิดขึ้นในการรับ/เช่าบล็อค IPv4)
• จำกัดการทำงานกับผู้ให้บริการ VPS ที่อนุญาตให้คุณนำ IP ของคุณเอง
  • หรือคุณต้องเช่าพื้นที่ชั้นวางและจัดการกับการเพียร์/การกำหนดเส้นทาง/การสลับ/BGP/อื่นๆ ความล้มเหลวของฮาร์ดแวร์ การตรวจสอบฮาร์ดแวร์ SNMP เป็นต้น
• สิ่งรบกวนใหม่ๆ เช่น การออกตั๋วและการร้องเรียนการละเมิดที่เกี่ยวข้องกับพื้นที่ IP ของคุณ

สมเหตุสมผลอย่างแน่นอนในระดับหนึ่งหรือหากคุณมีทักษะและเครื่องมือในการจัดการอยู่แล้ว

ตัวเลือก 3 - DNS ที่ไม่เป็นมาตรฐาน

เพิ่มผู้ให้บริการ DNS ที่มีการจัดการบางรายแล้ว CNAMEการสนับสนุนเหมือนสำหรับโดเมนเปล่า / รูท

หากคุณใช้หนึ่งในผู้ให้บริการเหล่านี้หรือติดตั้งเองหากคุณใช้ DNS ของคุณเอง... นั่นจะสามารถแก้ไขปัญหาได้

ดูคำตอบนี้

หากคุณพึ่งพาสิ่งนี้ แสดงว่าคุณถูกผู้ขายล็อคไว้กับผู้ให้บริการ DNS ที่รองรับคุณสมบัติที่ไม่ได้มาตรฐานนี้ หรือคุณต้องเรียกใช้ DNS ของคุณเองและดำเนินการด้วยตนเอง

ตัวเลือก 4 - CDN

คุณสามารถวางบริการอื่นไว้ข้างหน้า ทั้งนี้ขึ้นอยู่กับแอปของคุณ เช่น บริการแบบ CDN (stackpath, cloudflare, aws-cloudfront เป็นต้น) คนเหล่านี้จะจัดการกับ DNS/Anycast และหัวข้อที่เกี่ยวข้อง และคุณสามารถให้ลูกค้าของคุณชี้ไปที่บริการ CDN และเรียกใช้บริการของคุณที่อยู่เบื้องหลัง CDN

การเปลี่ยนบริการแบ็คเอนด์กลายเป็นการเปลี่ยนแปลงการกำหนดค่าที่ CDN (หรือคล้ายกัน) เพื่อบอก CDN ถึงชื่อ/ips ของเอ็นด์พอยต์ของคุณที่ควรขอเนื้อหา

ข้อเสีย:

• ค่าใช้จ่ายเพิ่มเติมหากคุณไม่ต้องการ
• จำเป็นต้องตรวจสอบให้แน่ใจว่าปลายทางแบบแคชและไม่ได้แคช (เช่น แอป) ได้รับการกำหนดค่าบน CDN เพื่อให้ตรงกับวิธีการทำงานของแอปพลิเคชันของคุณ
• เลเยอร์เพิ่มเติมที่ต้องแก้ไขข้อบกพร่องหากแอปของคุณใช้งานไม่ได้ (CDN ทำลายคำขอหรือแอปของคุณทำงานหรือไม่)
• โดยปกติหมายความว่าระเบียน CNAME ของลูกค้าของคุณจะชี้ไปที่โดเมนของ CDN...ไม่ใช่ของคุณ โดเมนของคุณอยู่ในการกำหนดค่าของแอป CDN เป็นเซิร์ฟเวอร์อัปสตรีม คุณจึงมีระบบล็อคอินของผู้ขาย...หากคุณต้องการเปลี่ยน CDN ลูกค้าทั้งหมดของคุณจะต้องอัปเดต DNS CNAME เพื่อให้ชี้ไปที่อันใหม่ คุณสามารถลดสิ่งนี้ได้โดยใส่ CNAME 2 ชั้น (ลูกค้า -> คุณ -> CDN) แต่นั่นก็ไม่ดีนักจาก มุมมองประสิทธิภาพ.

สิ่งที่ฉันจะทำ

ไม่มีรายละเอียดเพิ่มเติมเกี่ยวกับขนาดฐานลูกค้า ทักษะ (เช่น BGP) ไม่ว่าคุณจะใช้ฮาร์ดแวร์ของตัวเองหรือเช่า VPS ราคาถูก...

ฉันชอบความเรียบง่าย คุณทำให้มันซับซ้อนขึ้นได้ในภายหลัง อะไรคือสิ่งที่ง่ายที่สุดที่ช่วยให้ต้นทุนของฉันลดลง ไม่ใช้เวลามาก สร้างประสบการณ์การใช้งานที่ดีให้กับลูกค้าของฉัน และท้ายที่สุดช่วยให้ฉันกลับไปทำกิจกรรมที่สร้างรายได้ (แทนที่จะใช้เวลากับแบ็กเอนด์ทางเทคนิคนั้น มีเวลา/ต้นทุนทางการเงินโดยหวังว่าจะลดต้นทุนโดยรวมตามขนาด) ฉันไม่ใช่ google ดังนั้นฉันจึงควรเพิ่มบรรทัดบนสุดของฉันมากกว่าการเพิ่มประสิทธิภาพทีละน้อยโดยเฉพาะอย่างยิ่งหากยังไม่มีความจำเป็นทางเทคนิค (ยัง)

ฉันจะทำสิ่งต่อไปนี้...

• ไม่รองรับโดเมนเปล่า/รูทของลูกค้า ลูกค้าที่ต้องการเปลี่ยนเส้นทางสามารถให้เจ้าหน้าที่ไอทีตั้งค่าได้ในตอนท้าย อาการปวดหัวที่สำคัญน้อยกว่าหนึ่งครั้ง
  • หรือถ้าคุณต้องการสนับสนุนสิ่งนี้ ให้คุณตั้งค่า IP ตัวเปลี่ยนเส้นทางเดียวที่คุณรู้ว่าคุณจะไม่สูญเสีย (เช่น AWS elastic IP) และให้ลูกค้าตั้งค่า ก และ AAAA บันทึก บริการที่เหลือของคุณไม่จำเป็นต้องโฮสต์ในที่เดียวกัน (เช่น ตัวเปลี่ยนเส้นทางสามารถเป็น AWS กับ ELB ได้ หากคุณต้องการปรับขนาดการเปลี่ยนเส้นทาง และกล่องของลูกค้าสามารถใช้ VPS ราคาถูกได้)
• ลูกค้าแต่ละรายจะได้รับ CNAME ที่คาดเดาได้ (เฉพาะสำหรับพวกเขา) ตามโดเมนที่โฮสต์หรือ ID ลูกค้า (CUS1234.example.com เหมาะสมกว่าถ้าคุณให้ลูกค้าสามารถเปลี่ยนโดเมนที่พวกเขาโฮสต์ได้อย่างง่ายดาย)
• DNS ของฉันอัปเดตอัตโนมัติตามฐานข้อมูลลูกค้าของฉัน (โดเมนลูกค้า -> CNAME เฉพาะลูกค้า -> ที่อยู่ IP ที่โฮสต์แอปของลูกค้า)
• ฉันสามารถตรวจสอบ DNS ของลูกค้าได้อย่างง่ายดาย และ DNS ของฉันก็ชี้ไปยังตำแหน่งที่ถูกต้องทั้งหมด
• ฉันสามารถตรวจสอบการรับส่งข้อมูล/การละเมิด DNS ตามลูกค้าแต่ละรายแยกกัน (เนื่องจากพวกเขามีชื่อเฉพาะ) จากตำแหน่งข้อมูลของลูกค้า

ลูกค้าตั้งค่า DNS เพียงครั้งเดียวและไม่ต้องเปลี่ยน เว้นแต่ต้องการเปลี่ยนโดเมนที่โฮสต์

การย้ายข้อมูลผ่านอินฟาเรดนั้นค่อนข้างง่ายหากคุณมีกลไกการสำรอง/กู้คืน/จำลองแบบที่ดีซึ่งทำงานควบคู่กับการค้นหาบริการบางรูปแบบบนเลเยอร์การจัดเตรียมเซิร์ฟเวอร์/vps/แอพของคุณ

• ตั้งค่า DNS TTL ต่ำในระเบียน DNS ของคุณ (เช่น ชื่อที่ CNAME ของลูกค้าชี้ไป CUST1234.example.com 10.0.0.1) ก่อนการย้ายข้อมูล
• หมุนอินฟราใหม่รวมถึงการจำลองข้อมูลจากอินฟราเก่า (ฐานข้อมูล เนื้อหาที่ผู้ใช้อัปโหลด ฯลฯ)
• เปลี่ยนระเบียน DNS ของลูกค้าของคุณ (ก, AAAA) เพื่อชี้ไปที่ IP ใหม่
• ถอดอินฟาเรดเก่าออกหลังจากระยะขอบ DNS TTL + ผ่านไป

หากแบ็กเอนด์ข้อมูลของคุณไม่สามารถจัดการการเขียนจาก 2 จุดปลายทางของลูกค้าที่ใช้งานจริงได้ในเวลาเดียวกัน คุณอาจต้องมีการหยุดทำงานสำหรับการย้ายข้อมูล...เนื่องจากจะมีการทับซ้อนกันเมื่อแคช DNS เก่าหมดอายุ

ข้อดีของการตั้งค่าประเภทนี้คือฉันสามารถเรียกใช้กับผู้ให้บริการ VPS ที่มีชื่อเสียงเกือบทุกรายที่ฉันต้องการ (การจัดเตรียมอัตโนมัติของฉันไม่จู้จี้จุกจิก) ฉันไม่จำเป็นต้องลงทุนเพื่อเป็น AS และจัดการกับค่าใช้จ่ายเพิ่มเติมในการจัดการพื้นที่ IP ของฉันเอง (มันสมเหตุสมผลแล้วที่จะทำเช่นนี้ในระดับหนึ่ง...แต่ฉันไม่รู้สถานการณ์ของบริษัทของคุณ) .

ฉันสามารถทำสิ่งต่าง ๆ เช่น การจัดสรรภาระงานทางภูมิศาสตร์ตาม DNS (ส่งคืน IP ที่แตกต่างกันสำหรับชื่อเดียวกันโดยขึ้นอยู่กับภูมิภาคของเซิร์ฟเวอร์ที่ร้องขอ) สิ่งนี้ทำให้คุณสามารถจัดหาเซิร์ฟเวอร์หลายเครื่องภายใต้ชื่อเดียวกันให้กับลูกค้าในภูมิภาคต่างๆ (ดังนั้นพวกเขาจึงไม่ต้องจัดการกับเวลาแฝงข้ามสหรัฐอเมริกาหรือข้ามมหาสมุทรแอตแลนติกเมื่อโหลดแอป) คุณสามารถเสนอสิ่งนี้ตามลูกค้าแต่ละรายเป็นมูลค่าเพิ่ม/ขายต่อยอดได้

หมายเหตุเกี่ยวกับการโหลดบาลานซ์...

ฉันพูดถึงการโหลดบาลานซ์ tcp/layer4 หลายครั้งโดยไม่ได้อธิบายเพิ่มเติม โดยทั่วไปแล้วคุณจะมีโหลดบาลานซ์ทั่วไปสองประเภท layer4/transport/tcp และ layer7/application/http(s)

ตัวจัดสรรภาระงาน layer7/application/http "พูด" http และยุติการเชื่อมต่อ ssl ก่อนพร็อกซีคำขอ (โดยปกติจะเป็น http ที่ไม่ได้เข้ารหัส) ไปยังหนึ่งในเซิร์ฟเวอร์หลายตัวที่อยู่หลังบาลานเซอร์/พร็อกซี การดำเนินการนี้เป็นเรื่องง่ายแต่อาจนำไปสู่ปัญหาที่เซิร์ฟเวอร์ที่อยู่เบื้องหลังโหลดบาลานเซอร์ไม่รู้ว่าควรจะแสร้งทำเป็นว่ากำลังพูด https เมื่อเขียนส่วนหัว คุกกี้ที่ปลอดภัย การเปลี่ยนเส้นทาง ฯลฯ นอกจากนี้ยังหมายความว่าโหลดบาลานเซอร์ของคุณต้องทำงานมากขึ้น ตามคำขอ (แยกวิเคราะห์ http และจัดการกับโอเวอร์เฮด SSL) งานพิเศษนี้จำกัดความสามารถในการปรับขนาดของโหลดบาลานเซอร์ ซึ่งโดยปกติจะเป็นโหนด/เครื่อง/vps เดียว

ตัวจัดสรรภาระงาน layer4/tcp ไม่จำเป็นต้องแยกวิเคราะห์คำขอ http หรือมีค่าใช้จ่ายการยกเลิก SSL มันไม่รู้อะไรเลยเกี่ยวกับ http คำขอถูกส่งไปยังหนึ่งในหลาย ๆ เซิร์ฟเวอร์ที่จัดการการยกเลิก ssl และจัดการคำขอ http

หากคุณกังวลเกี่ยวกับการใช้เซสชัน TLS ซ้ำ (หรือขาด) ส่งผลต่อประสิทธิภาพ เป็นเรื่องปกติที่จะใช้ redis หรือ memcached เป็นแคชเซสชัน TLS ที่ใช้ร่วมกันระหว่างเว็บเซิร์ฟเวอร์หลายแห่ง คุณจึงไม่ต้องกังวลเกี่ยวกับโหลดบาลานซ์ที่ทำให้ผู้ใช้ "เหนียว" กล่องเฉพาะด้านหลังโหลดบาลานเซอร์ จิงซ์ ไม่ปรากฏว่ารองรับแคชเซสชัน TLS แบบปิดกล่อง (แคชแชร์เฉพาะระหว่างผู้ปฏิบัติงาน nginx ในกล่องเดียวกัน) แฮพร็อกซี่ ดูเหมือนจะมีบางอย่าง แต่ฉันยังไม่ได้ลองและไม่รู้ว่ามันจะทำงานอย่างไรใน haproxy/level4 หน้ากลุ่ม nginx ที่การสิ้นสุดของ ssl เกิดขึ้น

คุณสามารถใช้ nginx หรือ haproxy เป็น load balancer ของเลเยอร์ 4/tcp ได้ ทั้งคู่ค่อนข้างตรงไปตรงมาในการตั้งค่า สำหรับกรณีการใช้งานขั้นสูง (และประสิทธิภาพอาจดีกว่า) คุณสามารถดูที่ Linux Virtual Server (LVS)

อีกวิธีหนึ่งในการกระจายโหลดคือการส่งคืนระเบียน A หรือ AAAA หลายรายการสำหรับชื่อเดียว ตามหลักการแล้ว ไคลเอ็นต์ DNS จะเลือกแบบสุ่มจากที่อยู่ที่ส่งกลับ ดังนั้นคุณจึงได้รับการแจกจ่ายโหลดผ่านที่อยู่ IP หลายแห่ง หากคุณเริ่มพบปัญหาการปรับขนาดด้วยระดับโหลดบาลานเซอร์ของคุณ นี่เป็นวิธีที่ใช้เทคโนโลยีต่ำในการเพิ่มสเกลให้มากขึ้น (เพียงเพิ่มโหลดบาลานเซอร์อีกตัวเทียบกับกลุ่มแอปพลิเคชันเซิร์ฟเวอร์เดียวกันหรือต่างกัน) อย่างไรก็ตาม ไม่มีอะไรบังคับให้ไคลเอนต์ปัดเศษที่อยู่ IP ของคุณ...ดังนั้นสิ่งนี้จึงไม่ได้ทำให้คุณควบคุมได้มากนักว่า IP ใดที่จะโหลดได้...แต่ก็ยังดีกว่าไม่ทำอะไรเลย