มิคาอิล ซาโลซิน (ต่อไปนี้ – MS): - สวัสดีทุกคน! ฉันชื่อไมเคิล. ฉันทำงานเป็นนักพัฒนาแบ็กเอนด์ที่ซอฟต์แวร์ MC2 และฉันจะพูดถึงการใช้ Go ในแบ็กเอนด์ของแอปพลิเคชันมือถือ Look+
มีใครที่นี่ชอบฮ็อกกี้บ้างไหม?
แอปพลิเคชันนี้เหมาะสำหรับคุณ ใช้สำหรับ Android และ iOS และใช้ในการรับชมการถ่ายทอดสดการแข่งขันกีฬาต่างๆ ทางออนไลน์และบันทึกไว้ แอปพลิเคชั่นนี้ยังมีสถิติต่าง ๆ การส่งข้อความ ตารางการประชุม ทัวร์นาเมนต์ และข้อมูลอื่น ๆ ที่เป็นประโยชน์สำหรับแฟน ๆ
นอกจากนี้ในแอปพลิเคชันยังมีช่วงเวลาวิดีโอเช่น คุณสามารถรับชมช่วงเวลาที่สำคัญที่สุดของการแข่งขัน (ประตู, การต่อสู้, การยิงจุดโทษ ฯลฯ ) หากคุณไม่ต้องการรับชมการออกอากาศทั้งหมด ก็สามารถรับชมได้เฉพาะรายการที่น่าสนใจที่สุดเท่านั้น
คุณใช้อะไรในการพัฒนา?
ส่วนหลักเขียนด้วยภาษา Go API ที่ไคลเอนต์มือถือสื่อสารด้วยเขียนในภาษา Go บริการสำหรับส่งการแจ้งเตือนแบบพุชไปยังโทรศัพท์มือถือก็เขียนด้วยภาษา Go เรายังต้องเขียน ORM ของเราเองด้วย ซึ่งเราอาจพูดถึงสักวันหนึ่ง บริการเล็กๆ น้อยๆ บางอย่างเขียนขึ้นใน Go: การปรับขนาดและการโหลดภาพสำหรับบรรณาธิการ...
เราใช้ PostgreSQL เป็นฐานข้อมูล อินเทอร์เฟซตัวแก้ไขเขียนด้วย Ruby on Rails โดยใช้ ActiveAdmin gem การนำเข้าสถิติจากผู้ให้บริการสถิติจะเขียนด้วยภาษา Ruby เช่นกัน
สำหรับการทดสอบ API ระบบ เราใช้ Python unittest Memcached ใช้เพื่อควบคุมการเรียกชำระเงิน API, “Chef” ใช้เพื่อควบคุมการกำหนดค่า, Zabbix ใช้เพื่อรวบรวมและตรวจสอบสถิติระบบภายใน Graylog2 ใช้สำหรับการรวบรวมบันทึก Slate เป็นเอกสาร API สำหรับไคลเอนต์
การเลือกโปรโตคอล
ปัญหาแรกที่เราพบ: เราจำเป็นต้องเลือกโปรโตคอลสำหรับการโต้ตอบระหว่างแบ็กเอนด์และไคลเอนต์มือถือ โดยพิจารณาจากประเด็นต่อไปนี้...
- ข้อกำหนดที่สำคัญที่สุด: ข้อมูลของลูกค้าจะต้องได้รับการอัปเดตแบบเรียลไทม์ นั่นคือทุกคนที่รับชมการออกอากาศควรได้รับการอัปเดตเกือบจะในทันที
- เพื่อให้สิ่งต่าง ๆ ง่ายขึ้น เราถือว่าข้อมูลที่ซิงโครไนซ์กับไคลเอนต์จะไม่ถูกลบ แต่ถูกซ่อนไว้โดยใช้แฟล็กพิเศษ
- คำขอที่หายากทุกประเภท (เช่น สถิติ องค์ประกอบของทีม สถิติของทีม) จะได้รับจากคำขอ GET ทั่วไป
- นอกจากนี้ระบบยังต้องรองรับผู้ใช้ 100 คนในเวลาเดียวกันได้อย่างง่ายดาย
ด้วยเหตุนี้ เราจึงมีตัวเลือกโปรโตคอลสองตัวเลือก:
- เว็บซ็อกเก็ต แต่เราไม่ต้องการช่องทางจากไคลเอนต์ไปยังเซิร์ฟเวอร์ เราจำเป็นต้องส่งการอัปเดตจากเซิร์ฟเวอร์ไปยังไคลเอนต์เท่านั้น ดังนั้น websocket จึงเป็นตัวเลือกที่ซ้ำซ้อน
- เหตุการณ์ที่เซิร์ฟเวอร์ส่ง (SSE) เกิดขึ้นพอดี! มันค่อนข้างเรียบง่ายและตอบสนองทุกสิ่งที่เราต้องการโดยพื้นฐานแล้ว
เหตุการณ์ที่เซิร์ฟเวอร์ส่ง
คำไม่กี่คำเกี่ยวกับวิธีการทำงานของสิ่งนี้...
มันทำงานบนการเชื่อมต่อ http ไคลเอนต์ส่งคำขอ เซิร์ฟเวอร์ตอบสนองด้วย Content-Type: text/event-stream และไม่ปิดการเชื่อมต่อกับไคลเอนต์ แต่ยังคงเขียนข้อมูลไปยังการเชื่อมต่อ:
สามารถส่งข้อมูลในรูปแบบที่ตกลงกับลูกค้าได้ ในกรณีของเรา เราได้ส่งไปในรูปแบบนี้: ชื่อของโครงสร้างที่เปลี่ยนแปลง (บุคคล ผู้เล่น) ถูกส่งไปยังฟิลด์เหตุการณ์ และ JSON พร้อมฟิลด์ใหม่ที่เปลี่ยนแปลงสำหรับผู้เล่นจะถูกส่งไปยังฟิลด์ข้อมูล
ตอนนี้เรามาพูดถึงวิธีการโต้ตอบกัน
- สิ่งแรกที่ไคลเอนต์ทำคือกำหนดครั้งสุดท้ายที่ดำเนินการซิงโครไนซ์กับบริการ: จะดูที่ฐานข้อมูลท้องถิ่นและกำหนดวันที่ของการเปลี่ยนแปลงล่าสุดที่บันทึกไว้
- มันส่งคำขอพร้อมวันที่นี้
- เพื่อเป็นการตอบสนอง เราได้ส่งการอัปเดตทั้งหมดที่เกิดขึ้นตั้งแต่วันนั้นไปให้เขา
- หลังจากนั้นจะทำการเชื่อมต่อกับช่องถ่ายทอดสดและจะไม่ปิดจนกว่าจะต้องการการอัปเดตเหล่านี้:
เราส่งรายการการเปลี่ยนแปลงให้เขา: หากมีคนทำประตู เราจะเปลี่ยนคะแนนของการแข่งขัน หากเขาได้รับบาดเจ็บ ก็จะถูกส่งแบบเรียลไทม์เช่นกัน ดังนั้นลูกค้าจะได้รับข้อมูลล่าสุดในฟีดเหตุการณ์การแข่งขันทันที เป็นระยะๆ เพื่อให้ลูกค้าเข้าใจว่าเซิร์ฟเวอร์ยังไม่ตาย และไม่มีอะไรเกิดขึ้น เราจะส่งการประทับเวลาทุกๆ 15 วินาที เพื่อให้ลูกค้าทราบว่าทุกอย่างเป็นไปตามปกติและไม่จำเป็นต้องเชื่อมต่อใหม่
การเชื่อมต่อสดให้บริการอย่างไร?
- ก่อนอื่น เราสร้างช่องทางที่จะรับการอัปเดตที่บัฟเฟอร์ไว้
- หลังจากนั้นเราติดตามช่องนี้เพื่อรับข้อมูลอัปเดต
- เราตั้งค่าส่วนหัวที่ถูกต้องเพื่อให้ลูกค้ารู้ว่าทุกอย่างเรียบร้อยดี
- ส่งปิงครั้งแรก เราเพียงแค่บันทึกการประทับเวลาการเชื่อมต่อปัจจุบัน
- หลังจากนั้นเราก็อ่านจากช่องวนไปจนช่องอัพเดตปิด ช่องจะได้รับการประทับเวลาปัจจุบันหรือการเปลี่ยนแปลงที่เราเขียนไว้เพื่อเปิดการเชื่อมต่อเป็นระยะๆ
ปัญหาแรกที่เราพบคือ: สำหรับแต่ละการเชื่อมต่อที่เปิดกับไคลเอนต์ เราสร้างตัวจับเวลาที่ทำเครื่องหมายทุกๆ 15 วินาที - ปรากฎว่าถ้าเรามีการเชื่อมต่อ 6 รายการที่เปิดด้วยเครื่องหนึ่งเครื่อง (พร้อมเซิร์ฟเวอร์ API หนึ่งเครื่อง) 6 มีการสร้างตัวจับเวลานับพันตัว ส่งผลให้เครื่องไม่รองรับน้ำหนักที่ต้องการ ปัญหาไม่ได้ชัดเจนสำหรับเรามากนัก แต่เราได้รับความช่วยเหลือเล็กน้อยและแก้ไขได้
เป็นผลให้ตอนนี้ ping ของเรามาจากช่องทางเดียวกับที่มีการอัปเดตมา
ดังนั้นจึงมีตัวจับเวลาเพียงตัวเดียวที่ติ๊กทุกๆ 15 วินาที
มีฟังก์ชันเสริมหลายอย่างที่นี่ - การส่งส่วนหัว, ping และโครงสร้างเอง นั่นคือชื่อของตาราง (บุคคล, การแข่งขัน, ฤดูกาล) และข้อมูลเกี่ยวกับรายการนี้จะถูกส่งมาที่นี่:
กลไกในการส่งอัพเดต
มาดูกันว่าการเปลี่ยนแปลงมาจากไหน เรามีบรรณาธิการหลายคนที่ดูการออกอากาศแบบเรียลไทม์ พวกเขาสร้างเหตุการณ์ทั้งหมด มีคนถูกส่งออกไป มีคนได้รับบาดเจ็บ มีบางอย่างมาทดแทน...
เมื่อใช้ CMS ข้อมูลจะเข้าสู่ฐานข้อมูล หลังจากนี้ ฐานข้อมูลจะแจ้งเซิร์ฟเวอร์ API เกี่ยวกับเรื่องนี้โดยใช้กลไก Listen/Notify เซิร์ฟเวอร์ API ส่งข้อมูลนี้ไปยังไคลเอนต์แล้ว ดังนั้นเราจึงมีเซิร์ฟเวอร์เพียงไม่กี่เครื่องที่เชื่อมต่อกับฐานข้อมูล และไม่มีภาระพิเศษบนฐานข้อมูล เนื่องจากไคลเอนต์ไม่ได้โต้ตอบโดยตรงกับฐานข้อมูลในทางใดทางหนึ่ง:
PostgreSQL: ฟัง/แจ้งเตือน
กลไก Listen/Notify ใน Postgres ช่วยให้คุณสามารถแจ้งเตือนสมาชิกกิจกรรมว่าบางกิจกรรมมีการเปลี่ยนแปลง - มีการสร้างบันทึกบางส่วนในฐานข้อมูล เพื่อทำเช่นนี้ เราได้เขียนทริกเกอร์และฟังก์ชันง่ายๆ:
เมื่อแทรกหรือเปลี่ยนแปลงบันทึก เราจะเรียกใช้ฟังก์ชันแจ้งเตือนในช่อง data_updates โดยส่งชื่อของตารางและตัวระบุของบันทึกที่มีการเปลี่ยนแปลงหรือแทรกไปที่นั่น
สำหรับตารางทั้งหมดที่ต้องซิงโครไนซ์กับไคลเอนต์ เราจะกำหนดทริกเกอร์ ซึ่งหลังจากเปลี่ยน / อัปเดตบันทึกแล้ว จะเรียกใช้ฟังก์ชันที่ระบุในสไลด์ด้านล่าง
API สมัครรับการเปลี่ยนแปลงเหล่านี้อย่างไร
มีการสร้างกลไก Fanout - ส่งข้อความไปยังไคลเอนต์ รวบรวมช่องทางลูกค้าทั้งหมดและส่งการอัปเดตที่ได้รับผ่านช่องทางเหล่านี้:
ที่นี่ไลบรารี pq มาตรฐานซึ่งเชื่อมต่อกับฐานข้อมูลและบอกว่าต้องการฟังช่องสัญญาณ (data_updates) จะตรวจสอบว่าการเชื่อมต่อเปิดอยู่และทุกอย่างเรียบร้อยดี ฉันกำลังละเว้นการตรวจสอบข้อผิดพลาดเพื่อประหยัดพื้นที่ (การไม่ตรวจสอบเป็นอันตราย)
ต่อไป เราตั้งค่า Ticker แบบอะซิงโครนัส ซึ่งจะส่ง Ping ทุกๆ 15 วินาที และเริ่มฟังช่องที่เราสมัครรับข้อมูล หากเราได้รับ Ping เราจะเผยแพร่ Ping นี้ หากเราได้รับรายการใดประเภทหนึ่ง เราจะเผยแพร่รายการนี้ให้กับสมาชิกทั้งหมดของ Fanout นี้
Fan-out ทำงานอย่างไร
ในภาษารัสเซียแปลว่า "ตัวแยก" เรามีวัตถุหนึ่งที่ลงทะเบียนสมาชิกที่ต้องการรับข้อมูลอัปเดต และทันทีที่การอัปเดตมาถึงออบเจ็กต์นี้จะเผยแพร่การอัปเดตนี้ให้กับสมาชิกทั้งหมด ง่ายพอ:
มีการใช้งานอย่างไรใน Go:
มีโครงสร้างที่ซิงโครไนซ์โดยใช้ Mutexes มีช่องสำหรับบันทึกสถานะการเชื่อมต่อของ Fanout กับฐานข้อมูล เช่น กำลังฟังอยู่และจะได้รับการอัปเดต รวมถึงรายการช่องสัญญาณที่มีอยู่ทั้งหมด - แผนที่ ซึ่งกุญแจสำคัญคือช่องสัญญาณและโครงสร้างในรูปแบบของ ค่านิยม (โดยพื้นฐานแล้วไม่ได้ใช้ในทางใดทางหนึ่ง)
สองวิธี - เชื่อมต่อและตัดการเชื่อมต่อ - ช่วยให้เราสามารถบอก Fanout ว่าเรามีการเชื่อมต่อกับฐาน มันปรากฏขึ้น และการเชื่อมต่อกับฐานขาด ในกรณีที่สอง คุณต้องยกเลิกการเชื่อมต่อไคลเอนต์ทั้งหมด และแจ้งพวกเขาว่าพวกเขาไม่สามารถฟังสิ่งใด ๆ ได้อีกต่อไป และให้เชื่อมต่อใหม่อีกครั้งเนื่องจากการเชื่อมต่อกับพวกเขาปิดลง
นอกจากนี้ยังมีวิธีการสมัครสมาชิกที่เพิ่มช่องให้กับ “ผู้ฟัง”:
มีวิธียกเลิกการสมัครซึ่งจะลบช่องออกจากผู้ฟังหากไคลเอ็นต์ยกเลิกการเชื่อมต่อ เช่นเดียวกับวิธีเผยแพร่ซึ่งช่วยให้คุณสามารถส่งข้อความไปยังสมาชิกทั้งหมดได้
คำถาม: – มีอะไรถ่ายทอดผ่านช่องทางนี้?
นางสาว: – แบบจำลองที่มีการเปลี่ยนแปลงหรือส่ง Ping (โดยพื้นฐานแล้วเป็นเพียงตัวเลขหรือจำนวนเต็ม)
นางสาว: – คุณสามารถส่งอะไรก็ได้ ส่งโครงสร้างใดก็ได้ เผยแพร่มัน แค่เปลี่ยนเป็น JSON เท่านั้นเอง
นางสาว: – เราได้รับการแจ้งเตือนจาก Postgres – ประกอบด้วยชื่อตารางและตัวระบุ ตามชื่อตารางและตัวระบุ เราได้รับบันทึกที่เราต้องการ จากนั้นเราจะส่งโครงสร้างนี้เพื่อเผยแพร่
โครงสร้างพื้นฐาน
สิ่งนี้มีลักษณะอย่างไรจากมุมมองของโครงสร้างพื้นฐาน? เรามีเซิร์ฟเวอร์ฮาร์ดแวร์ 7 เครื่อง หนึ่งในนั้นทุ่มเทให้กับฐานข้อมูลโดยเฉพาะ ส่วนอีก 6 เครื่องที่ทำงานเสมือน API มี XNUMX ชุด: เครื่องเสมือนแต่ละเครื่องที่มี API ทำงานบนเซิร์ฟเวอร์ฮาร์ดแวร์ที่แยกจากกัน - เพื่อความน่าเชื่อถือ
เรามีส่วนหน้าสองรายการที่ติดตั้ง Keepalived เพื่อปรับปรุงการเข้าถึง ดังนั้นหากมีสิ่งใดเกิดขึ้น ส่วนหน้าหนึ่งจะสามารถแทนที่อีกส่วนหน้าหนึ่งได้ นอกจากนี้ – CMS สองชุด
นอกจากนี้ยังมีผู้นำเข้าสถิติ มี DB Slave ซึ่งทำการสำรองข้อมูลเป็นระยะ มี Pigeon Pusher แอปพลิเคชันที่ส่งการแจ้งเตือนแบบพุชไปยังไคลเอนต์ รวมถึงสิ่งโครงสร้างพื้นฐาน: Zabbix, Graylog2 และ Chef
ในความเป็นจริง โครงสร้างพื้นฐานนี้ซ้ำซ้อน เนื่องจากสามารถให้บริการได้ 100 รายการโดยใช้เซิร์ฟเวอร์น้อยกว่า แต่มีเหล็ก - เราใช้มัน (เราบอกว่ามันเป็นไปได้ - ทำไมจะไม่ได้)
ข้อดีของไป
หลังจากที่เราพัฒนาแอปพลิเคชันนี้แล้ว ข้อได้เปรียบที่ชัดเจนของ Go ก็ปรากฏให้เห็น
- ห้องสมุด http ที่ยอดเยี่ยม ด้วยมันคุณสามารถสร้างได้ค่อนข้างมากนอกกรอบ
- นอกจากนี้ ช่องทางยังช่วยให้เราใช้กลไกในการส่งการแจ้งเตือนไปยังลูกค้าได้อย่างง่ายดาย
- สิ่งมหัศจรรย์ Race detector ช่วยให้เราสามารถกำจัดจุดบกพร่องร้ายแรงหลายประการได้ (โครงสร้างพื้นฐานชั่วคราว) ทุกสิ่งที่ทำงานบนการแสดงละครจะถูกเปิดตัว คอมไพล์ด้วยคีย์ Race; และด้วยเหตุนี้ เราจึงสามารถดูโครงสร้างพื้นฐานชั่วคราวเพื่อดูว่าเรามีปัญหาอะไรได้บ้าง
- ความเรียบง่ายและความเรียบง่ายของภาษา
เรากำลังมองหานักพัฒนา! หากใครต้องการกรุณา
คำถาม
คำถามจากผู้ชม (ต่อไปนี้ - B): – สำหรับฉันดูเหมือนว่าคุณจะพลาดประเด็นสำคัญอย่างหนึ่งเกี่ยวกับ Fan-out ฉันเข้าใจถูกต้องหรือไม่ว่าเมื่อคุณส่งคำตอบให้กับลูกค้า คุณจะบล็อกหากลูกค้าไม่ต้องการอ่าน
นางสาว: - ไม่ เราไม่ได้ปิดกั้น ประการแรก เรามีทั้งหมดนี้อยู่เบื้องหลัง nginx นั่นคือไม่มีปัญหากับไคลเอนต์ที่ช้า ประการที่สอง ไคลเอนต์มีช่องที่มีบัฟเฟอร์ - อันที่จริงเราสามารถอัปเดตได้มากถึงร้อยรายการ... หากเราไม่สามารถเขียนถึงช่องได้ มันก็จะลบมันทิ้ง หากเราเห็นว่าช่องถูกบล็อก เราก็จะปิดช่องเพียงเท่านี้ ลูกค้าจะเชื่อมต่อใหม่หากเกิดปัญหาใดๆ ดังนั้นโดยหลักการแล้วที่นี่ไม่มีการปิดกั้น
ที่: – เป็นไปได้ไหมที่จะส่งบันทึกไปยัง Listen/Notify โดยทันที และไม่ใช่ตารางตัวระบุ
นางสาว: – Listen/Notify มีขีดจำกัดที่ 8 ไบต์สำหรับการโหลดล่วงหน้าที่ส่ง โดยหลักการแล้ว อาจเป็นไปได้ที่จะส่งข้อมูลหากเราจัดการกับข้อมูลจำนวนเล็กน้อย แต่สำหรับฉันแล้วดูเหมือนว่าวิธีนี้ [วิธีที่เราทำ] มีความน่าเชื่อถือมากกว่า ข้อจำกัดอยู่ใน Postgres เอง
ที่: – ลูกค้าจะได้รับการอัปเดตเกี่ยวกับการแข่งขันที่พวกเขาไม่สนใจหรือไม่?
นางสาว: - โดยทั่วไปแล้วใช่ ตามกฎแล้วมีการแข่งขัน 2-3 นัดที่เกิดขึ้นแบบคู่ขนานและถึงแม้จะน้อยมากก็ตาม หากลูกค้ากำลังดูบางสิ่งบางอย่าง ก็มักจะดูการแข่งขันที่กำลังดำเนินอยู่ จากนั้น ลูกค้าจะมีฐานข้อมูลท้องถิ่นซึ่งมีการเพิ่มการอัปเดตเหล่านี้ทั้งหมด และแม้จะไม่มีการเชื่อมต่ออินเทอร์เน็ต ลูกค้าก็สามารถดูการแข่งขันที่ผ่านมาทั้งหมดที่เขาอัปเดตได้ โดยพื้นฐานแล้ว เราซิงโครไนซ์ฐานข้อมูลของเราบนเซิร์ฟเวอร์กับฐานข้อมูลในเครื่องของลูกค้า เพื่อให้เขาสามารถทำงานแบบออฟไลน์ได้
ที่: – ทำไมคุณถึงสร้าง ORM ของคุณเอง?
Alexey (หนึ่งในผู้พัฒนา Look+): – ตอนนั้น (ปีที่แล้ว) มี ORM น้อยกว่าตอนนี้ ซึ่งก็มีค่อนข้างมาก สิ่งที่ฉันชอบเกี่ยวกับ ORM ส่วนใหญ่ก็คือส่วนใหญ่ทำงานบนอินเทอร์เฟซที่ว่างเปล่า นั่นคือวิธีการใน ORM เหล่านี้พร้อมที่จะดำเนินการกับทุกสิ่ง: โครงสร้าง ตัวชี้โครงสร้าง ตัวเลข บางอย่างที่ไม่เกี่ยวข้องโดยสิ้นเชิง...
ORM ของเราสร้างโครงสร้างตามแบบจำลองข้อมูล ตัวฉันเอง. ดังนั้นวิธีการทั้งหมดจึงเป็นรูปธรรม ไม่ใช้การสะท้อน ฯลฯ พวกเขายอมรับโครงสร้างและคาดหวังที่จะใช้โครงสร้างเหล่านั้นที่มา
ที่: – มีผู้เข้าร่วมกี่คน?
นางสาว: – ในระยะเริ่มแรก มีคนสองคนเข้าร่วม เราเริ่มต้นที่ไหนสักแห่งในเดือนมิถุนายน และในเดือนสิงหาคม ส่วนหลักก็พร้อมแล้ว (เวอร์ชันแรก) มีการเปิดตัวในเดือนกันยายน
ที่: – เมื่อคุณอธิบาย SSE คุณไม่ได้ใช้การหมดเวลา ทำไมเป็นเช่นนั้น?
นางสาว: – พูดตามตรง SSE ยังคงเป็นโปรโตคอล html5: มาตรฐาน SSE ได้รับการออกแบบมาเพื่อสื่อสารกับเบราว์เซอร์เท่าที่ฉันเข้าใจ มันมีคุณสมบัติเพิ่มเติมเพื่อให้เบราว์เซอร์สามารถเชื่อมต่อใหม่ได้ (และอื่นๆ) แต่เราไม่ต้องการมัน เนื่องจากเรามีไคลเอนต์ที่สามารถใช้ตรรกะใดๆ ในการเชื่อมต่อและรับข้อมูลได้ เราไม่ได้สร้าง SSE แต่เป็นอะไรที่คล้ายกับ SSE นี่ไม่ใช่โปรโตคอลเอง
ไม่จำเป็นเลย เท่าที่ฉันเข้าใจ ลูกค้าใช้กลไกการเชื่อมต่อเกือบตั้งแต่เริ่มต้น พวกเขาไม่สนใจจริงๆ
ที่: – คุณใช้ยูทิลิตี้อะไรเพิ่มเติมบ้าง?
นางสาว: – เราใช้ govet และ golint มากที่สุดเพื่อทำให้สไตล์เป็นหนึ่งเดียว เช่นเดียวกับ gofmt ไม่มีการใช้สิ่งอื่นใด
ที่: – คุณใช้อะไรในการดีบัก?
นางสาว: – การดีบักส่วนใหญ่ดำเนินการโดยใช้การทดสอบ เราไม่ได้ใช้ดีบักเกอร์หรือ GOP ใด ๆ
ที่: – คุณสามารถคืนสไลด์ที่ใช้ฟังก์ชัน Publish ได้หรือไม่ ชื่อตัวแปรตัวอักษรตัวเดียวทำให้คุณสับสนหรือไม่?
นางสาว: - เลขที่. พวกเขามีขอบเขตการมองเห็นที่ค่อนข้าง "แคบ" ไม่ได้ใช้ที่อื่นยกเว้นที่นี่ (ยกเว้นภายในของคลาสนี้) และมีขนาดเล็กมาก - ใช้เวลาเพียง 7 บรรทัดเท่านั้น
ที่: – ถึงกระนั้นก็ยังไม่เข้าใจสัญชาตญาณ…
นางสาว: - ไม่ ไม่ นี่คือโค้ดจริง! มันไม่เกี่ยวกับสไตล์ มันเป็นเพียงชั้นเรียนที่มีประโยชน์และมีขนาดเล็กมาก - มีเพียง 3 ช่องในชั้นเรียนเท่านั้น...
นางสาว: – โดยทั่วไปแล้ว ข้อมูลทั้งหมดที่ซิงโครไนซ์กับไคลเอนต์ (การแข่งขันฤดูกาล ผู้เล่น) จะไม่เปลี่ยนแปลง พูดโดยคร่าวๆ ถ้าเราสร้างกีฬาอื่นที่เราต้องเปลี่ยนการแข่งขัน เราก็จะคำนึงถึงทุกอย่างในไคลเอนต์เวอร์ชันใหม่ และไคลเอนต์เวอร์ชันเก่าจะถูกแบน
ที่: – มีแพ็คเกจการจัดการการพึ่งพาของบุคคลที่สามหรือไม่?
นางสาว: – เราใช้ go dep
ที่: – มีบางอย่างเกี่ยวกับวิดีโอในหัวข้อของรายงาน แต่ไม่มีสิ่งใดในรายงานเกี่ยวกับวิดีโอ
นางสาว: – ไม่ ฉันไม่มีอะไรในหัวข้อเกี่ยวกับวิดีโอนี้ เรียกว่า "Look+" ซึ่งเป็นชื่อของแอปพลิเคชัน
ที่: – คุณบอกว่ามันสตรีมให้กับลูกค้าเหรอ?..
นางสาว: – เราไม่ได้เกี่ยวข้องกับการสตรีมวิดีโอ สิ่งนี้ทำโดย Megafon ทั้งหมด ใช่ ฉันไม่ได้บอกว่าแอปพลิเคชันนี้เป็น MegaFon
นางสาว: – ไป – สำหรับการส่งข้อมูลทั้งหมด – คะแนน, เหตุการณ์การแข่งขัน, สถิติ... Go คือแบ็กเอนด์ทั้งหมดสำหรับแอปพลิเคชัน ลูกค้าจะต้องทราบจากลิงก์ใดที่จะใช้สำหรับผู้เล่นเพื่อให้ผู้ใช้สามารถดูการแข่งขันได้ เรามีลิงก์ไปยังวิดีโอและสตรีมที่เตรียมไว้
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com