Платформа „1С: Предприятие“ — какво има под капака?

Здравей, Хабр!
В тази статия ще започнем разказа за това как е устроена вътрешността на платформата „1С:Предприятие 8“ и какви технологии се използват при разработката ѝ.

Защо смятаме, че това е интересно? Първо, защото платформата „1С:Предприятие 8“ е голямо (повече от 10 милиона реда код) приложение на C++ (клиент, сървър и т.н.), JavaScript (веб-клиент), и от скоро и Java. Големите проекти са интересни поне заради мащаба, тъй като въпросите, които не се забелязват в малките кодови бази, в тези проекти излизат на преден план. Второ, „1С:Предприятие“ е тиражируем, „коробъчен“ продукт, а статии за такива разработки на Хабра са съвсем малко. И винаги е интересно да научим как живеят в другите екипи и фирми.

Да започнем. В тази статия ще дадем преглед на някои технологии, които се прилагат в платформата, ще очертаем пейзажа, без дълбоко потапяне в реализацията. За много механизми подробният разказ би изисквал отделна статия, а за някои — цяла книга!
Първо е важно да се определи с базовите неща — какво е платформата „1С:Предприятие“ и от какви компоненти се състои. Отговорът на този въпрос не е толкова прост, тъй като под термина „Платформа“ (за краткост ще я наричаме така) се разбира и средство за разработка на бизнес приложения, и среда за изпълнение, и средства за администриране. Условно можем да откроим следните съставки:

• кластер от сървъри
• „тъмен“ клиент, способен да се свързва със сървъра по http и собствен бинарен протокол
• клиент за работа в двуслойна архитектура с база данни, разположена на твърд диск или мрежова папка
• веб-клиент
• средства за администриране на сървъра на приложенията
• среда за разработка (известна като Конфигуратор)
• среда за изпълнение за iOS, Android и Windows Phone (мобилна платформа 1С)

Всички тези части, с изключение на веб-клиента, са написани на C++. Освен това, наскоро бе анонсиран Конфигуратор от ново поколение, написан на Java.

Нативни приложения

За разработка на原生 приложения се използва C++03. Под 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 (в частност, стрингове, контейнери и алгоритми)
• множествено наследяване, включително множествено наследяване на реализации
• шаблони
• изключения
• умни указатели (собствена реализация)

Чрез използването на множествени наследявания на интерфейси (напълно абстрактни класове) става възможна компонентна модел, за който ще говорим по-долу.

FAudio

За осигуряване на модулност, целият функционал е разделен на компоненти, представляващи динамични библиотеки (*.dll за Windows, *.so — за Linux). Общият брой на компонентите е повече от хиляда и половина, представяме описания на някои от тях:

backend
Съдържа 'движка' на метаданните на платформата

accnt
Обекти, които приложните разработчици използват за изграждане на счетоводството (планове на сметки и регистри на счетоводството)

bsl
Движка за изпълнение на вградения език

nuke
Собствена реализация на алокатор на памет

dbeng8
Движка за файловата база. Проста файл-сървърна машина за бази данни, основана на ISAM, която включва и прост SQL-процесор

wbase
Съдържа основни класове и функции за реализиране на потребителски интерфейс на Windows — класове на прозорци, достъп до GDI и т.н.

Разделението на множество компоненти е полезно от няколко гледни точки:

• Разделянето спомага за по-добро проектиране, а именно — за по-добра изолация на кода
• От комплекта компоненти може гъвкаво да се създават различни опции за доставка:
  • Например, инсталацията на тънкия клиент ще съдържа wbase, но няма да включва backend.
  • а на сървъра wbase, обратно, няма да бъде.
  • и двата варианта, разбира се, ще съдържат nuke и bsl.

Всички необходими компоненти за този вариант на стартиране се зареждат при стартиране на програмата. В частност, това е необходимо за регистрацията на SCOM класовете, за които ще стане дума по-долу.

SCOM

За декомпозиция на по-ниско ниво се използва системата SCOM – подобна по идеология на библиотеката ATL. За тези, които не са работили с ATL, накратко ще изброя основните възможности и особености.
За специално оформен клас SCOM:

• Предоставя фабрични методи, позволяващи създаване на клас от друг компонент, познавайки само името му (без разкриване на реализацията).
• Предоставя инфраструктура за интелигентни указатели с броене на референции. За времето на живот на SCOM класа не е нужно да се следи ръчно.
• Позволява да се определи дали обектът реализира конкретен интерфейс и автоматично да се преобразува указателят на обекта в указател на интерфейса.
• Създайте обект-сервис, който винаги е достъпен чрез метода get_service и т.н.

Например, в компонента json.dll може да се опише клас за четене на JSON (например, JSONStreamReader).
Класове, екземпляри могат да се създават от други компоненти и трябва да бъдат регистрирани в SCOM машината:

SCOM_CLASS_ENTRY(JSONStreamReader)

Този макрос ще опише специален статичен клас-регистратор, чийто конструктор ще бъде извикан при зареждане на компонента в паметта.
След това може да създадете екземпляр в друга компонента:

IJSONStreamReaderPtr jsonReader = create_instance(SCOM_CLSIDOF(JSONStreamReader));

За поддръжка на сервисите SCOM предлага допълнителна, доста сложна инфраструктура. Централно в нея е понятието SCOM процес, който служи като контейнер за стартирани услуги (т.е. изпълнява роля на Service Locator) и съдържа връзка с локализираните ресурси. SCOM процесът е свързан с потока на ОС. Благодарение на това, вътре в приложението можете да получавате услугите по следния начин:

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

Освен това, като превключвате логическите (SCOM) процеси, свързани с потока, можете да получите практически независими приложения от гледна точка на информационното пространство, изпълняващи се в рамките на един поток. Така функционира нашият тънък клиент, работа с файловата база — в рамките на един процес на ОС се намират два SCOM процеса, един свързан с клиента, а вторият — със сървъра. Този подход позволява унификация на кода, който ще работи както на локалната файловата база, така и в „истинската“ клиент-сървър версия. Цената за тази хомогенност са разходите, но практиката показва, че си струват.

На базата на компонентната модел SCOM е реализирана и бизнес логиката, и интерфейсната част на 1С: Предприятие.

Потребителски интерфейс

Между другото, за интерфейсите. Ние не използваме стандартните контроли на Windows, нашите елементи за управление са реализирани директно на Windows API. За Linux версията е направен слой, работещ чрез библиотеката wxWidgets.
Библиотеката с елементи за управление не зависи от другите части на «1С:Предприятие» и ние я използваме още в няколко малки вътрешни утилити.

През годините на развитие 1С:Предприятие, видът на контролите се е променял, но сериозната промяна в принципите се е случила само веднъж, през 2009 година, с излизането на версия 8.2 и появата на «управляеми форми». Освен промяната на външния вид, принципът на компоновка на формата се е променил съществено — отказано е от позиционирането на елементите по пиксели в полза на flow компоновка на елементите. Освен това, в новия модел, елементите за управление работят не директно с домейнови обекти, а със специални DTO (Data Transfer Objects).
Тези промени позволиха създаването на уеб клиента на «1С:Предприятие», повтарящ C++ логиката на контролите на JavaScript. Ние се стараем да поддържаме функционалната еквивалентност между тънкия и уеб клиента. В случаите, когато това не е възможно, например, заради ограниченията на достъпните от JavaScript API (например, възможността за работа с файлове е много ограничена), често реализираме необходимата функционалност чрез разширения на браузерите, написани на C++. В момента поддържаме Internet Explorer и Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows и Linux) и Safari (MacOS).

Освен това, технологията на управляваните формуляри се използва за създаване на интерфейс на мобилни приложения на платформата 1С. На мобилните устройства, рисуването на контролите е реализирано с използване на „родни“ за операционната система технологии, но за логиката на компоновката на формата и реакцията на интерфейса се използва същият код, какъвто е и в „голямата“ платформа „1С:Предприятие“.

Интерфейсът на 1С под ОС Linux

Интерфейсът на 1С на мобилно устройство

Интерфейсът на 1С на други платформи
Интерфейсът на 1С под ОС Windows

Интерфейсът на 1С — уеб клиент

С отворен код

Въпреки че не използваме стандартните библиотеки за разработчици на C++ под Windows (MFC, контроли от WinAPI), ние не пишем всичките компоненти сами. Вече беше спомената библиотеката wxWidgets, а също така използваме:

• cURL за работа с HTTP и FTP.
• OpenSSL за работа с криптография и установяване на TLS съединения
• libxml2 и libxslt за парсинг на XML
• libetpan за работа с пощенски протоколи (POP3, SMTP, IMAP)
• mimetic за парсинг на имейл съобщения
• sqllite за съхранение на журнала на работата на потребителите
• ICU за интернационализация

Списъкът все още може да продължи.
Освен това, ние използваме силно модифицирани версии на Google Test и Google Mock при разработката на единични тестове.
Библиотеките изискваха адаптация за съвместимост с модела SCOM на организацията на компонентите.
Разпространеността на 1С прави платформата отличен тест за издръжливост на използваните в нея библиотеки. Разнообразието от потребители и сценарии бързо открива грешки дори в най-рядко използваните участъци от кода. Ние ги поправяме и се опитваме да ги върнем обратно на авторите на библиотеките. Опитът на взаимодействие се оказва много различен.
Разработчици cURL и libetpan бързо отговарят на pull-request, но пач, например, в OpenSSL нам така и не успяхме да върнем.

Заключение

В статията се докоснахме до няколко основни аспекта на разработката на платформата „1С: Предприятие“. В ограничен обем статията засегна само някои интересни, по наше мнение, аспекти.
Общото описание на различни механизми на платформата може да се види тук.
Какви теми биха ви били интересни в следващите статии?

Как е реализирана мобилната платформа 1С?
Описание на вътрешното устройство на уеб клиента?
Или, може би, ви интересува процесът на избор на функции за новите версии, разработка и тестване?

Пишете в коментарите!

Източник: habr.com