Plattformen "1C: Enterprise" – vad finns under ytan?

Hej, Habr!
I den här artikeln börjar vi berätta om hur den är strukturerad inuti plattformen "1C:Enterprise 8" och vilka teknologier som används vid dess utveckling.

Varför anser vi att detta är intressant? För det första eftersom plattformen "1C:Enterprise 8" är en stor (mer än 10 miljoner kodrader) applikation skriven i C++ (klient, server osv.), JavaScript (webbklient), och, nyligen även Java. Stora projekt kan vara intressanta just på grund av sin omfattning, även om frågor som går obemärkt förbi i en liten kodbas blir framträdande i sådana projekt. För det andra är "1C:Enterprise" en reproducerbar, "boxad" produkt, och det finns inte många artiklar om sådana utvecklingar på Habré. Dessutom är det alltid intressant att veta hur det går till i andra team och företag.

Så, låt oss börja. I den här artikeln ger vi en översikt över vissa teknologier som används på plattformen, vi skisserar landskapet utan att gå djupt in i implementationen. Många mekanismer skulle kräva en detaljerad berättelse som skulle fylla en egen artikel, och för vissa – en hel bok!
För att börja måste vi klargöra grundläggande saker – vad är plattformen "1C:Enterprise" och av vilka komponenter består den? Svaret på denna fråga är inte så enkelt, eftersom termen "Plattform" (för kort kommer vi att kalla den så) omfattar både verktyget för att utveckla affärsapplikationer, runtime-miljön, och administrationsverktygen. Man kan grovt dela upp följande komponenter:

• kluster av servrar
• "tunn" klient som kan ansluta till servern via http och eget binärt protokoll
• klient för arbete i en tvåledsarkitektur med en databas, placerad på hårddisken eller i en nätverksmapp
• webbklient
• administrationsverktyg för applikationsservern
• utvecklingsmiljö (känd som Konfigurator)
• körmiljö för iOS, Android och Windows Phone (mobil plattform 1C)

Alla dessa delar, förutom webbklienten, är skrivna i C++. Dessutom finns det en nyligen tillkännagiven Konfigurator av nästa generation, skriven i Java.

Inbyggda applikationer

För utvecklingen av inhemska applikationer används C++03. På Windows används Microsoft Visual C++ 12 som kompilator (profil som är kompatibel med Windows XP), medan gcc 4.8 används för Linux och Android, och clang 5.0 används för iOS. Den standardbibliotek som används är gemensamt för alla OS och kompilatorer - STLPort. Detta beslut minskar sannolikheten för fel som är specifika för STL-implementeringen. För närvarande planerar vi att övergå till den STL-implementation som levereras med CLang, eftersom STLPort har upphört att utvecklas och är inkompatibel med det aktiverade C++11-stödet i gcc.
Serverns kodbas är gemensam till 99 %, medan klienten är gemensam till cirka 95 %. Dessutom använder även mobilplattformen samma C++-kod som ”den stora”, även om graden av enhetlighet är något lägre.
Precis som de flesta C++-användare gör vi inte anspråk på att använda 100 % av språkets och dess bibliotekens möjligheter. Vi använder till exempel praktiskt taget inte Boost, och av språkets möjligheter använder vi dynamisk typkonvertering. Samtidigt tillämpar vi aktivt:

• STL (i synnerhet strängar, behållare och algoritmer)
• flertärning, inklusive flertärning av implementeringar
• mallar
• hot swap av kod
• kloka pekare (egen implementation)

Genom att använda flertärning av gränssnitt (helt abstrakta klasser) blir det möjligt med en komponentmodell, som vi kommer att diskutera nedan.

Komponenter

För att säkerställa modularitet är all funktionalitet uppdelad i komponenter, som representerar dynamiska bibliotek (*.dll för Windows, *.so - för Linux). Det finns över ett och ett halvt hundra komponenter, och vi ger en beskrivning av några av dem:

backend
Innehåller plattformens metadata "motor".

accnt
Objekt som applikationsutvecklare använder för att bygga bokföring (kontoplaner och redovisningsregister)

bsl
Motor för exekvering av det inbyggda språket.

nuke
Egen implementation av minnesallokator.

dbeng8
Filbaserad databasmotor. En enkel filserverdatabas, baserad på ISAM, som också inkluderar en enkel SQL-processor.

wbase
Innehåller grundklasser och funktioner för att implementera användargränssnittet i Windows – fönsterklasser, åtkomst till GDI, osv.

Uppdelningen i flera komponenter är fördelaktig ur flera synvinklar:

• Uppdelningen främjar bättre design, särskilt bättre kodisolering.
• Från uppsättningen av komponenter kan man flexibelt sammanställa olika leveransalternativ:
  • Till exempel kommer installationen av en tunn klient att innehålla wbase, men inte backend.
  • Och på servern kommer wbase å sin sida inte att finnas.
  • Båda alternativen kommer självklart att innehålla nuke och bsl.

Alla komponenter som behövs för detta startalternativ laddas vid programstart. Detta är särskilt viktigt för registrering av SCOM-klasser, som vi kommer att diskutera nedan.

SCOM

För dekomponering på en lägre nivå används SCOM-systemet – liknande i ideologi med ATL-biblioteket. För dem som inte har arbetat med ATL, här är en kort sammanställning av de viktigaste möjligheterna och funktionerna.
För en särskilt utformad SCOM-klass:

• Ger fabriksmetoder som gör att man kan skapa en klass från en annan komponent, med endast namnet känt (utan avslöjande av implementationen).
• Ger infrastruktur för smarta pekare med referensräkning. Man behöver inte övervaka livslängden av SCOM-klassen manuellt.
• Möjliggör att samma objekt om det implementerar ett visst gränssnitt och automatiskt konverterar pekaren till objektet till en pekare på gränssnittet.
• Skapa ett tjänsteobjekt som alltid är tillgängligt via metoden get_service osv.

Till exempel kan man i komponenten json.dll beskriva en klass för att läsa JSON (t.ex. JSONStreamReader).
Klasser, instanser kan skapas från andra komponenter måste registreras i SCOM-maskinen:

SCOM_CLASS_ENTRY(JSONStreamReader)

Denna makro beskriver en särskild statisk klassregistrator vars konstruktör kommer att anropas vid inläsning av komponenten i minnet.
Efter det kan man skapa dess instans i en annan komponent:

IJSONStreamReaderPtr jsonReader = create_instance(SCOM_CLSIDOF(JSONStreamReader));

För att stödja tjänster erbjuder SCOM en ytterligare, ganska komplex infrastruktur. Centralt i den är begreppet SCOM-process, som fungerar som en behållare för aktiva tjänster (dvs. fungerar som en Service Locator) samt innehåller bindning till lokaliserade resurser. SCOM-processen binds till OS-tråden. Tack vare detta kan man så här få tjänster inuti applikationen:

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

Dessutom, genom att växla logiska (SCOM) processer kopplade till flödet kan man få nästan oberoende applikationer, sett ur informationsutrymmets perspektiv, som körs inom ett och samma flöde. Så här är vår tunna klient utformad, som arbetar med en filbas — inom en OS-process finns det två SCOM-processer, en kopplad till klienten och den andra till servern. Denna metod möjliggör en enhetlig kodning, som fungerar både på den lokala filbasen och i den "äkta" klient-server-versionen. Kostnaden för sådan enhetlighet är overhead, men praktiken visar att det är värt det.

Baserat på komponentmodellen för SCOM har både affärslogik och gränssnittets del av 1C: Företaget implementerats.

Användargränssnitt

Förresten, angående gränssnitt. Vi använder inte standardkontrollerna från Windows; våra kontroller är direkt implementerade via Windows API. För Linux-versionen används ett lager som fungerar genom biblioteket wxWidgets.
Biblioteket med kontroller är oberoende av andra delar av "1C: Företaget" och används också i flera andra interna verktyg.

Under åren har utseendet på kontrollerna i 1C: Företaget förändrats, men en signifikant förändring i principerna har inträffat endast en gång, år 2009, med lanseringen av version 8.2 och introduktionen av "styrda formulär". Förutom förändringen av utseendet har principen för formkomposition grundligt förändrats — man har övergivit pixelpositionering till förmån för flödeskomposition av elementen. Dessutom, i den nya modellen arbetar kontrollerna inte direkt med domänobjekten, utan med speciella DTO (Data Transfer Objects).
Dessa förändringar har gjort det möjligt att skapa webbklienten för "1C: Företaget", som återspeglar C++-logiken för kontroller i JavaScript. Vi försöker upprätthålla funktionell likvärdighet mellan den tunna och webbklienten. När detta inte är möjligt, till exempel på grund av begränsningar i det tillgängliga JavaScript API (till exempel är möjligheterna att arbeta med filer mycket begränsade), implementerar vi ofta den nödvändiga funktionaliteten genom webbläsartillägg skrivna i C++. För närvarande stödjer vi Internet Explorer och Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows och Linux) och Safari (MacOS).

Dessutom används teknologin för hanterade formulär för att skapa mobilapplikationsgränssnitt på 1C-plattformen. På mobila enheter renderas kontroller med hjälp av 'inhemska' teknologier för operativsystemet, men samma kod används för logiken för formulärlayout och gränssnittets reaktioner, som i den 'stora' plattformen '1C:Enterprise'.

1C-gränssnitt på Linux

1C-gränssnitt på en mobil enhet

1C-gränssnitt på andra plattformar
1C-gränssnitt på Windows

1C - webbklient

Öppen källkod

Även om vi inte använder standardbibliotek som är vanliga för C++-utvecklare på Windows (MFC, kontroller från WinAPI), skriver vi inte allt själva. Biblioteket som redan nämnts är wxWidgets, och vi använder också:

• cURL för att arbeta med HTTP och FTP.
• OpenSSL för att arbeta med kryptografi och upprätta TLS-anslutningar
• libxml2 och libxslt för att bearbeta XML
• libetpan för att arbeta med e-postprotokoll (POP3, SMTP, IMAP)
• mimetic för att bearbeta e-postmeddelanden
• sqllite för att lagra användarens aktivitetsloggar
• ICU för internationalisering

Listan skulle kunna fortsätta.
Dessutom använder vi en kraftigt modifierad version av Google Test och Google Mock när vi utvecklar enhetstester.
Biblioteken krävde anpassning för att vara kompatibla med SCOM-modellen för komponentorganisation.
Spridningen av 1C gör plattformen till ett utmärkt test för hållbarheten hos de bibliotek som används. Mångfalden av användare och scenarier avslöjar snabbt fel även i de mest sällan använda delarna av koden. Vi åtgärdar dem hos oss och försöker ge tillbaka till bibliotekens skapare. Erfarenheten av samarbetet varierar mycket.
Utvecklare cURL och libetpan snabbt svarar på pull-request, men patchen, till exempel, i OpenSSL kunde vi aldrig ge tillbaka.

Slutsats

I artikeln berörde vi några grundläggande aspekter av utvecklingen av plattformen ‘1C: Enterprise’. I artikelns begränsade omfattning har vi endast berört några intressanta aspekter, enligt vår mening.
En allmän beskrivning av olika mekanismer i plattformen kan ses ). Ett typiskt exempel på användning:.
Vilka ämnen skulle intressera dig i kommande artiklar?

Hur är den mobila plattformen för 1C implementerad?
Beskrivning av webbklientens interna struktur?
Eller kanske är du intresserad av processen för att välja funktioner för nya versioner, utveckling och testning?

Skriv i kommentarerna!

Källa: habr.com