แพลตฟอร์ม "1C: Enterprise" - มีอะไรอยู่ภายใต้ประทุน?

เฮ้ ฮับ!
ในบทความนี้เราจะเริ่มเรื่องราวเกี่ยวกับวิธีการทำงานภายใน แพลตฟอร์ม "1C: องค์กร 8" และเทคโนโลยีใดบ้างที่ใช้ในการพัฒนา

ทำไมเราถึงคิดว่ามันน่าสนใจ? ประการแรก เนื่องจากแพลตฟอร์ม 1C:Enterprise 8 เป็นแอปพลิเคชันขนาดใหญ่ (มากกว่า 10 ล้านบรรทัด) ใน C++ (ไคลเอนต์ เซิร์ฟเวอร์ ฯลฯ) JavaScript (เว็บไคลเอ็นต์) และล่าสุด และ ชวา. โปรเจ็กต์ขนาดใหญ่สามารถน่าสนใจได้อย่างน้อยก็เพราะขนาดของโปรเจ็กต์ เนื่องจากปัญหาที่มองไม่เห็นในโค้ดเบสขนาดเล็กจะเกิดขึ้นอย่างเต็มกำลังในโครงการดังกล่าว ประการที่สอง “1C:Enterprise” เป็นผลิตภัณฑ์ “บรรจุกล่อง” ที่ทำซ้ำได้ และมีบทความน้อยมากเกี่ยวกับการพัฒนาดังกล่าวในHabré การได้รู้ว่าชีวิตในทีมและบริษัทอื่นๆ เป็นอย่างไรเป็นเรื่องที่น่าสนใจเสมอ

มาเริ่มกันเลย ในบทความนี้ เราจะให้ภาพรวมของเทคโนโลยีบางอย่างที่ใช้ในแพลตฟอร์มและสรุปภาพรวม โดยไม่ต้องเจาะลึกถึงการใช้งาน อันที่จริง สำหรับกลไกหลายอย่าง เรื่องราวที่มีรายละเอียดจะต้องมีบทความแยกต่างหาก และสำหรับบางเล่ม ก็ต้องอ่านทั้งเล่ม!
ขั้นแรกควรตัดสินใจเลือกสิ่งพื้นฐาน - แพลตฟอร์ม 1C:Enterprise คืออะไรและประกอบด้วยส่วนประกอบใดบ้าง คำตอบสำหรับคำถามนี้ไม่ใช่เรื่องง่าย เพราะคำว่า “แพลตฟอร์ม” (สำหรับความกะทัดรัด เราจะเรียกมันเช่นนั้น) หมายถึงวิธีในการพัฒนาแอปพลิเคชันทางธุรกิจ สภาพแวดล้อมรันไทม์ และเครื่องมือการดูแลระบบ ส่วนประกอบต่อไปนี้สามารถแยกแยะได้คร่าวๆ:

• คลัสเตอร์เซิร์ฟเวอร์
• ไคลเอนต์ "thin" ที่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ผ่าน http และโปรโตคอลไบนารีของตัวเอง
• ไคลเอนต์สำหรับการทำงานในสถาปัตยกรรมสองชั้นพร้อมฐานข้อมูลที่อยู่ในฮาร์ดไดรฟ์หรือโฟลเดอร์เครือข่าย
• เว็บไคลเอ็นต์
• เครื่องมือการดูแลระบบแอปพลิเคชันเซิร์ฟเวอร์
• สภาพแวดล้อมการพัฒนา (เรียกว่า Configurator)
• สภาพแวดล้อมรันไทม์สำหรับ iOS, Android และ Windows Phone (แพลตฟอร์มมือถือ 1C)

ทุกส่วนเหล่านี้เขียนด้วยภาษา C++ ยกเว้นเว็บไคลเอ็นต์ นอกจากนี้ยังมีการประกาศเมื่อเร็ว ๆ นี้ ตัวกำหนดค่ารุ่นใหม่เขียนด้วยภาษาจาวา

แอพเนทีฟ

C++03 ใช้เพื่อพัฒนา Native Application สำหรับ Windows นั้นจะใช้ Microsoft Visual C++ 12 (โปรไฟล์ที่เข้ากันได้กับ Windows XP) เป็นคอมไพเลอร์และสำหรับ Linux และ Android - gcc 4.8 สำหรับ iOS - clang 5.0 ไลบรารีมาตรฐานที่ใช้จะเหมือนกันสำหรับระบบปฏิบัติการและคอมไพเลอร์ทั้งหมด - STLPort โซลูชันนี้ช่วยลดโอกาสที่จะเกิดข้อผิดพลาดเฉพาะการใช้งาน STL ขณะนี้เรากำลังวางแผนที่จะโยกย้ายไปยังการใช้งาน STL ที่มาพร้อมกับ CLang เนื่องจาก STLPort ถูกยกเลิกแล้วและเข้ากันไม่ได้กับโหมดที่เปิดใช้งาน C++11 ของ gcc
ฐานรหัสของเซิร์ฟเวอร์เป็นแบบทั่วไป 99% ส่วนลูกค้า - 95% ยิ่งไปกว่านั้น แม้แต่แพลตฟอร์มมือถือก็ใช้รหัส C++ เดียวกันกับรหัส "ใหญ่" แม้ว่าเปอร์เซ็นต์การรวมจะค่อนข้างต่ำกว่าก็ตาม
เช่นเดียวกับผู้ใช้ C++ ส่วนใหญ่ เราไม่ได้อ้างว่าใช้ความสามารถของภาษาและไลบรารีได้ 100% ดังนั้นเราจึงไม่ใช้ Boost และหนึ่งในคุณสมบัติภาษาคือการหล่อประเภทไดนามิก ในขณะเดียวกัน เราก็ใช้งาน:

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

ด้วยการใช้การสืบทอดอินเทอร์เฟซหลายรายการ (คลาสนามธรรมโดยสมบูรณ์) โมเดลส่วนประกอบจึงเป็นไปได้ ซึ่งจะกล่าวถึงด้านล่าง

ส่วนประกอบ

เพื่อให้มั่นใจถึงความเป็นโมดูล ฟังก์ชันการทำงานทั้งหมดจะแบ่งออกเป็นส่วนประกอบต่างๆ ซึ่งเป็นไลบรารีแบบไดนามิก (*.dll สำหรับ Windows, *.so สำหรับ Linux) มีส่วนประกอบทั้งหมดมากกว่าหนึ่งร้อยห้าสิบส่วน นี่คือคำอธิบายบางส่วน:

แบ็กเอนด์
ประกอบด้วยกลไกข้อมูลเมตาของแพลตฟอร์ม

บัญชี
ออบเจ็กต์ที่นักพัฒนาแอปพลิเคชันใช้เพื่อสร้างบันทึกทางบัญชี (ผังบัญชีและทะเบียนการบัญชี)

BSL
เอ็นจิ้นการดำเนินการภาษาแบบฝัง

เรือใต้น้ำปรมาณู
การใช้งานตัวจัดสรรหน่วยความจำแบบกำหนดเอง

ดีเบง8
เอ็นจิ้นฐานข้อมูลไฟล์ กลไกฐานข้อมูลเซิร์ฟเวอร์ไฟล์อย่างง่ายที่ใช้ ISAM ซึ่งรวมถึงตัวประมวลผล SQL แบบธรรมดาด้วย

wbase
ประกอบด้วยคลาสพื้นฐานและฟังก์ชันสำหรับการนำส่วนต่อประสานผู้ใช้ Windows ไปใช้ - คลาสหน้าต่าง, การเข้าถึง GDI ฯลฯ

การแบ่งองค์ประกอบออกเป็นหลายส่วนมีประโยชน์จากหลายมุมมอง:

• การแยกส่งเสริมการออกแบบที่ดีขึ้น โดยเฉพาะอย่างยิ่งการแยกโค้ดที่ดีขึ้น
• จากชุดส่วนประกอบ คุณสามารถประกอบตัวเลือกการจัดส่งต่างๆ ได้อย่างยืดหยุ่น:
  • ตัวอย่างเช่น การติดตั้งไคลเอ็นต์แบบธินจะมี wbase แต่จะไม่มีแบ็กเอนด์
  • แต่บนเซิร์ฟเวอร์ wbase ตรงกันข้ามจะไม่เป็นเช่นนั้น
  • แน่นอนว่าทั้งสองตัวเลือกจะมีอาวุธนิวเคลียร์และ bsl

ส่วนประกอบทั้งหมดที่จำเป็นสำหรับตัวเลือกการเปิดใช้นี้จะถูกโหลดเมื่อโปรแกรมเริ่มทำงาน โดยเฉพาะอย่างยิ่งสิ่งนี้จำเป็นสำหรับการลงทะเบียนคลาส SCOM ซึ่งจะกล่าวถึงด้านล่าง

SCOM

สำหรับการสลายตัวในระดับที่ต่ำกว่านั้น จะใช้ระบบ SCOM ซึ่งเป็นห้องสมุดที่มีอุดมการณ์คล้ายกับ ATL สำหรับผู้ที่ไม่ได้ทำงานกับ ATL เราจะแสดงรายการความสามารถและคุณสมบัติหลักโดยย่อ
สำหรับคลาส SCOM ที่ออกแบบมาเป็นพิเศษ:

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

ตัวอย่างเช่น คุณสามารถอธิบายคลาสสำหรับการอ่าน JSON (เช่น JSONStreamReader) ในคอมโพเนนต์ json.dll
สามารถสร้างคลาสและอินสแตนซ์ได้จากส่วนประกอบอื่นๆ โดยจำเป็นต้องลงทะเบียนในเครื่อง SCOM:

SCOM_CLASS_ENTRY(JSONStreamReader)

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

IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));

เพื่อรองรับบริการ SCOM เสนอโครงสร้างพื้นฐานเพิ่มเติมที่ค่อนข้างซับซ้อน ศูนย์กลางอยู่ที่แนวคิดของกระบวนการ SCOM ซึ่งทำหน้าที่เป็นคอนเทนเนอร์สำหรับการเรียกใช้บริการ (เช่น มีบทบาทเป็น Service Locator) และยังมีการเชื่อมโยงกับทรัพยากรที่แปลเป็นภาษาท้องถิ่นอีกด้วย กระบวนการ SCOM เชื่อมโยงกับเธรด OS ด้วยเหตุนี้ คุณสามารถรับบริการต่างๆ ภายในแอปพลิเคชันได้ดังนี้:

SCOM_Process* process = core::current_process();
if (process)
         return get_service<IMyService>(process);

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

ตามโมเดลส่วนประกอบ SCOM มีการใช้ทั้งตรรกะทางธุรกิจและส่วนอินเทอร์เฟซของ 1C: Enterprise

หน้าจอผู้ใช้

โดยวิธีการเกี่ยวกับอินเทอร์เฟซ เราไม่ได้ใช้การควบคุม Windows มาตรฐาน การควบคุมของเราถูกนำไปใช้โดยตรงบน Windows API สำหรับเวอร์ชัน Linux มีการสร้างเลเยอร์ที่ทำงานผ่านไลบรารี wxWidgets
ไลบรารีการควบคุมไม่ได้ขึ้นอยู่กับส่วนอื่นๆ ของ 1C:Enterprise และเราใช้ในยูทิลิตี้ภายในขนาดเล็กอื่นๆ อีกหลายรายการ

ในช่วงหลายปีที่ผ่านมาของการพัฒนา 1C:Enterprise รูปลักษณ์ของการควบคุมเปลี่ยนไป แต่การเปลี่ยนแปลงหลักการที่ร้ายแรงเกิดขึ้นเพียงครั้งเดียวในปี 2009 ด้วยการเปิดตัวเวอร์ชัน 8.2 และการถือกำเนิดของ "แบบฟอร์มที่ได้รับการจัดการ" นอกเหนือจากการเปลี่ยนรูปลักษณ์แล้ว หลักการของเค้าโครงแบบฟอร์มยังเปลี่ยนไปโดยพื้นฐาน - มีการปฏิเสธการวางตำแหน่งองค์ประกอบแบบพิกเซลต่อพิกเซลเพื่อสนับสนุนการจัดวางองค์ประกอบแบบโฟลว์ นอกจากนี้ ในรูปแบบใหม่ การควบคุมไม่ทำงานโดยตรงกับออบเจ็กต์โดเมน แต่ทำงานด้วย DTO พิเศษ (ออบเจ็กต์การถ่ายโอนข้อมูล).
การเปลี่ยนแปลงเหล่านี้ทำให้สามารถสร้างเว็บไคลเอ็นต์ 1C:Enterprise ที่จำลองตรรกะ C++ ของตัวควบคุม JavaScript ได้ เราพยายามรักษาความเท่าเทียมกันในการทำงานระหว่างไคลเอ็นต์แบบบางและแบบเว็บ ในกรณีที่ไม่สามารถทำได้ เช่น เนื่องจากข้อจำกัดของ JavaScript API ที่มีอยู่ (เช่น ความสามารถในการทำงานกับไฟล์มีจำกัดมาก) เรามักจะใช้ฟังก์ชันการทำงานที่จำเป็นโดยใช้ส่วนขยายของเบราว์เซอร์ที่เขียนด้วยภาษา C++ ขณะนี้เรารองรับ Internet Explorer และ Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows และ Linux) และ Safari (MacOS)

นอกจากนี้ เทคโนโลยีแบบฟอร์มที่ได้รับการจัดการยังใช้เพื่อสร้างอินเทอร์เฟซสำหรับแอปพลิเคชันมือถือบนแพลตฟอร์ม 1C บนอุปกรณ์เคลื่อนที่ การเรนเดอร์การควบคุมจะดำเนินการโดยใช้เทคโนโลยีดั้งเดิมของระบบปฏิบัติการ แต่สำหรับลอจิกโครงร่างแบบฟอร์มและการตอบสนองของอินเทอร์เฟซ รหัสเดียวกันนี้จะถูกใช้ในแพลตฟอร์ม 1C:Enterprise "ขนาดใหญ่"

อินเทอร์เฟซ 1C บนระบบปฏิบัติการ Linux

อินเทอร์เฟซ 1C บนอุปกรณ์มือถือ

อินเทอร์เฟซ 1C บนแพลตฟอร์มอื่น
อินเทอร์เฟซ 1C บนระบบปฏิบัติการ Windows

อินเทอร์เฟซ 1C - เว็บไคลเอ็นต์

โอเพ่นซอร์ส

แม้ว่าเราจะไม่ได้ใช้ไลบรารีมาตรฐานสำหรับนักพัฒนา C++ ภายใต้ Windows (MFC, การควบคุมจาก WinAPI) แต่เราไม่ได้เขียนส่วนประกอบทั้งหมดด้วยตนเอง ห้องสมุดได้ถูกกล่าวถึงแล้ว wxวิดเจ็ตและเรายังใช้:

• ม้วน สำหรับการทำงานกับ HTTP และ FTP
• OpenSSL สำหรับการทำงานกับการเข้ารหัสและสร้างการเชื่อมต่อ TLS
• libxml2 และ libxslt สำหรับการแยกวิเคราะห์ XML
• ลิเบตปัน สำหรับการทำงานกับโปรโตคอลเมล (POP3, SMTP, IMAP)
• เลียนแบบ เพื่อแยกวิเคราะห์ข้อความอีเมล
• sqllite สำหรับจัดเก็บบันทึกผู้ใช้
• ไอซียู เพื่อความเป็นสากล

รายการดำเนินต่อไป
นอกจากนี้ เรายังใช้เวอร์ชันที่ได้รับการปรับเปลี่ยนอย่างมาก การทดสอบของ Google и Google จำลอง เมื่อพัฒนาการทดสอบหน่วย
ไลบรารีจำเป็นต้องมีการปรับเปลี่ยนเพื่อให้เข้ากันได้กับโมเดลการจัดองค์ประกอบ SCOM
ความแพร่หลายของ 1C ทำให้แพลตฟอร์มนี้เป็นการทดสอบความแข็งแกร่งที่ยอดเยี่ยมสำหรับไลบรารีที่ใช้ในนั้น ผู้ใช้และสถานการณ์ที่หลากหลายเปิดเผยข้อผิดพลาดอย่างรวดเร็วแม้ในส่วนโค้ดที่ไม่ค่อยได้ใช้มากที่สุด เราแก้ไขด้วยตนเองและพยายามส่งคืนให้กับผู้เขียนห้องสมุด ประสบการณ์การมีปฏิสัมพันธ์จะแตกต่างกันมาก
นักพัฒนา ม้วน и ลิเบตปัน ตอบสนองต่อคำขอดึงอย่างรวดเร็ว แต่แพตช์เช่นใน OpenSSL เราไม่เคยสามารถคืนมันได้

ข้อสรุป

ในบทความเราได้กล่าวถึงประเด็นหลักหลายประการของการพัฒนาแพลตฟอร์ม 1C: Enterprise ในขอบเขตที่จำกัดของบทความ เราได้กล่าวถึงแง่มุมที่น่าสนใจในความเห็นของเราเท่านั้น
สามารถดูคำอธิบายทั่วไปของกลไกแพลตฟอร์มต่างๆ ได้ ที่นี่.
หัวข้อใดที่คุณสนใจในบทความต่อๆ ไป

แพลตฟอร์มมือถือ 1C มีการใช้งานอย่างไร
คำอธิบายโครงสร้างภายในของเว็บไคลเอ็นต์?
หรือบางทีคุณอาจสนใจกระบวนการเลือกฟีเจอร์สำหรับการเปิดตัวใหม่ การพัฒนา และการทดสอบ

เขียนในความคิดเห็น!

ที่มา: will.com