Platformo "1C: Enterprise" - kio estas sub la kapuĉo?

Hej Habr!
En ĉi tiu artikolo ni komencos la rakonton pri kiel ĝi funkcias interne platformo "1C:Enterprise 8" kaj kiaj teknologioj estas uzataj en ĝia evoluo.

Platformo "1C: Enterprise" - kio estas sub la kapuĉo?

Kial ni opinias, ke ĉi tio estas interesa? Unue, ĉar la platformo 1C:Enterprise 8 estas granda (pli ol 10 milionoj da linioj de kodo) aplikaĵo en C++ (kliento, servilo, ktp.), JavaScript (retkliento), kaj, pli lastatempe, Kaj java. Grandaj projektoj povas esti interesaj almenaŭ pro sia skalo, ĉar aferoj, kiuj estas nevideblaj en malgranda kodbazo, ekestas plenforte en tiaj projektoj. Due, "1C:Enterprise" estas reproduktebla, "boksita" produkto, kaj estas tre malmultaj artikoloj pri tiaj evoluoj pri Habré. Ankaŭ ĉiam estas interese scii kiel estas la vivo en aliaj teamoj kaj kompanioj.

Do ni komencu. En ĉi tiu artikolo ni donos superrigardon de kelkaj el la teknologioj kiuj estas uzataj en la platformo kaj skizos la pejzaĝon, sen plonĝi profunde en la efektivigon. Ja por multaj mekanismoj, detala rakonto postulus apartan artikolon, kaj por iuj, tutan libron!
Komence, indas decidi pri la bazaj aferoj - kio estas la platformo 1C:Enterprise kaj el kiuj komponantoj ĝi konsistas. La respondo al ĉi tiu demando ne estas tiel simpla, ĉar la termino "Platformo" (por koncizeco, ni nomos ĝin tiel) rilatas al rimedo por disvolvi komercajn aplikaĵojn, rultempan medion kaj administrajn ilojn. La sekvaj komponantoj povas esti proksimume distingitaj:

  • servilo areto
  • "maldika" kliento kapabla konekti al la servilo per http kaj sia propra binara protokolo
  • kliento por labori en dunivela arkitekturo kun datumbazo situanta sur malmola disko aŭ reto-dosierujo
  • TTT-kliento
  • iloj pri administrado de aplikaĵserviloj
  • evolumedio (konata kiel Configurator)
  • rultempa medio por iOS, Android kaj Windows Phone (poŝtelefona platformo 1C)

Ĉiuj ĉi tiuj partoj, escepte de la retkliento, estas skribitaj en C++. Aldone, estas la lastatempe anoncita Nova generacio agordilo, skribita en Java.

Denaskaj programoj

C++03 estas uzata por evoluigi indiĝenajn aplikojn. Por Vindozo, Microsoft Visual C++ 12 (profilo kongrua kun Windows XP) estas uzata kiel kompililo, kaj por Linukso kaj Android - gcc 4.8, por iOS - clang 5.0. La norma biblioteko uzata estas la sama por ĉiuj operaciumoj kaj kompililoj - STLPort. Ĉi tiu solvo reduktas la verŝajnecon de STL-efektiv-specifaj eraroj. Nuntempe ni planas migri al la STL-efektivigo, kiu sendas kun CLang, ĉar STLPort estis ĉesigita kaj estas nekongrua kun la ebligita reĝimo C++11 de gcc.
La kodbazo de la servilo estas 99% ofta, la kliento - 95%. Krome, eĉ la movebla platformo uzas la saman C++-kodon kiel la "granda", kvankam la procento de unuiĝo tie estas iom pli malalta.
Kiel plej multaj uzantoj de C++, ni ne pretendas uzi 100% de la kapabloj de la lingvo kaj ĝiaj bibliotekoj. Do, ni praktike ne uzas Boost, kaj unu el la lingvotrajtoj estas dinamika tipa casting. Samtempe ni aktive uzas:

  • STL (specife ŝnuroj, ujoj kaj algoritmoj)
  • multobla heredo, inkl. multobla efektiviga heredo
  • padronoj
  • esceptoj
  • inteligentaj montriloj (persona efektivigo)

Uzante multoblan heredon de interfacoj (tute abstraktaj klasoj), komponentmodelo iĝas ebla, kiu estos diskutita malsupre.

Komponantoj

Por certigi modularecon, ĉiuj funkcioj estas dividitaj en komponantojn, kiuj estas dinamikaj bibliotekoj (*.dll por Vindozo, *.so por Linukso). Estas pli ol cent kvindek komponantoj entute; jen priskriboj de kelkaj el ili:

backend
Enhavas la platforman metadatuman motoron

akcento
Objektoj, kiujn aplikaĵprogramistoj uzas por konstrui kontadajn registrojn (konttabloj kaj kontadaj registroj)

BSL
Enigita lingva ekzekutmotoro

nuke
Propra efektivigo de memor-asignilo

dbeng8
Dosiera datumbaza motoro. Simpla dosierservila datumbaza motoro bazita sur ISAM, kiu ankaŭ inkluzivas simplan SQL-procesoron

wbazo
Enhavas la bazajn klasojn kaj funkciojn por efektivigi la Vindozan uzantinterfacon - fenestroklasoj, GDI-aliro, ktp.

Dividi en plurajn komponentojn estas utila de pluraj vidpunktoj:

  • Apartigo antaŭenigas pli bonan dezajnon, precipe pli bonan kodan izolitecon
  • El aro da komponantoj vi povas flekseble kunmeti malsamajn liverajn opciojn:
    • Ekzemple, instalaĵo de maldika kliento enhavos wbase, sed ne havos backend
    • sed ĉe la wbase-servilo, male, ĝi ne estos
    • ambaŭ opcioj kompreneble enhavos nuke kaj bsl

Ĉiuj komponantoj necesaj por ĉi tiu lanĉa opcio estas ŝarĝitaj kiam la programo komenciĝas. Ĉi tio, precipe, estas necesa por registri SCOM-klasojn, kiuj estos diskutitaj sube.

SCOM

Por putriĝo sur pli malalta nivelo, la SCOM-sistemo estas uzita, biblioteko simila en ideologio al ATL. Por tiuj, kiuj ne laboris kun ATL, ni mallonge listigas la ĉefajn kapablojn kaj funkciojn.
Por speciale dizajnita SCOM-klaso:

  • Provizas fabrikajn metodojn, kiuj ebligas al vi krei klason de alia komponanto sciante nur ĝian nomon (sen malkaŝi la efektivigon)
  • Disponigas referenc-nombran inteligentan montrilinfrastrukturon. SCOM-klasa vivdaŭro ne bezonas esti monitorita permane
  • Permesas al vi ekscii ĉu objekto efektivigas specifan interfacon kaj aŭtomate konverti montrilon al la objekto al montrilo al la interfaco.
  • Kreu servobjekton, kiu ĉiam estas alirebla per la metodo get_service ktp.

Ekzemple, vi povas priskribi klason por legi JSON (ekzemple, JSONStreamReader) en la komponanto json.dll.
Klasoj kaj kazoj povas esti kreitaj de aliaj komponentoj; ili devas esti registritaj en la SCOM-maŝino:

SCOM_CLASS_ENTRY(JSONStreamReader)

Ĉi tiu makroo priskribos specialan statikan registrilon klason, kies konstruktilo estos vokita kiam la komponanto estas ŝarĝita en memoron.
Post ĉi tio, vi povas krei ekzemplon de ĝi en alia ero:

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

Por subteni servojn, SCOM ofertas plian, sufiĉe kompleksan infrastrukturon. Centra al ĝi estas la koncepto de SCOM-procezo, kiu funkcias kiel ujo por prizorgi servojn (t.e., ludas la rolon de Service Locator), kaj ankaŭ enhavas ligon al lokalizitaj resursoj. La SCOM-procezo estas ligita al la OS-fadeno. Danke al ĉi tio, ene de la aplikaĵo vi povas ricevi servojn kiel ĉi:

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

Krome, ŝanĝante logikaj (SCOM) procezoj ligitaj al fadeno, vi povas akiri aplikojn kiuj estas praktike sendependaj de la vidpunkto de la informspaco, funkciante ene de la sama fadeno. Jen kiel nia maldika kliento funkcias kun dosiera datumbazo - ene de unu OS-procezo estas du SCOM-procezoj, unu asociita kun la kliento, kaj la dua kun la servilo. Ĉi tiu aliro permesas al ni unuigi la skribadon de kodo, kiu funkcios kaj sur la loka dosierdatumbazo kaj en la "reala" kliento-servila versio. La prezo por tia unuformeco estas supera, sed praktiko montras, ke ĝi valoras ĝin.

Surbaze de la SCOM-komponentmodelo, kaj la komerca logiko kaj la interfacparto de 1C: Enterprise estas efektivigitaj.

Uzantinterfaco

Cetere, pri interfacoj. Ni ne uzas normajn Vindozajn kontrolojn; niaj kontroloj estas efektivigitaj rekte sur la Vindoza API. Por la Linukso-versio, tavolo estis farita, kiu funkcias per la biblioteko wxWidgets.
La biblioteko de kontroloj ne dependas de aliaj partoj de 1C:Enterprise kaj estas uzata de ni en pluraj aliaj malgrandaj internaj utilecoj.

Dum la jaroj de disvolviĝo de 1C:Enterprise, la aspekto de kontroloj ŝanĝiĝis, sed grava ŝanĝo en principoj okazis nur unufoje, en 2009, kun la ĵeto de versio 8.2 kaj la apero de "administritaj formoj". Krom ŝanĝi la aspekton, la principo de formo-aranĝo esence ŝanĝiĝis - estis malakcepto de pikselo-post-piksela poziciigado de elementoj favore al fluo-aranĝo de elementoj. Krome, en la nova modelo, kontroloj ne funkcias rekte kun domajnaj objektoj, sed kun specialaj DTOoj (Objektoj de Transdono de Datumoj).
Ĉi tiuj ŝanĝoj ebligis krei retklienton 1C:Enterprise, kiu reproduktas la C++-logikon de JavaScript-kontroloj. Ni provas konservi funkcian ekvivalenton inter maldikaj kaj retaj klientoj. En kazoj, kie tio ne eblas, ekzemple pro limigoj de la disponebla JavaScript API (ekzemple, la kapablo labori kun dosieroj estas tre limigita), ni ofte efektivigas la necesajn funkciojn per retumiloj skribitaj en C++. Nuntempe ni subtenas Internet Explorer kaj Microsoft Edge (Vindozo), Google Chrome (Vindozo), Fajrovulpo (Vindozo kaj Linukso) kaj Safaro (MacOS).

Krome, administritaj formoj teknologio estas uzata por krei interfacon por moveblaj aplikoj sur la 1C platformo. Sur porteblaj aparatoj, la bildigo de kontroloj estas efektivigita uzante teknologiojn indiĝenajn al la operaciumo, sed por la form-aranĝa logiko kaj interfacrespondo, la sama kodo estas uzata kiel en la "granda" platformo 1C:Enterprise.

Platformo "1C: Enterprise" - kio estas sub la kapuĉo?
1C interfaco sur Linukso OS

Platformo "1C: Enterprise" - kio estas sub la kapuĉo?
1C interfaco sur poŝtelefono

1C interfaco sur aliaj platformoj Platformo "1C: Enterprise" - kio estas sub la kapuĉo?
1C interfaco sur Vindoza OS

Platformo "1C: Enterprise" - kio estas sub la kapuĉo?
Interfaco 1C - TTT-kliento

Apertfonta

Kvankam ni ne uzas normajn bibliotekojn por C++-programistoj sub Vindozo (MFC, kontroloj de WinAPI), ni ne skribas ĉiujn komponantojn mem. La biblioteko jam estis menciita wxWidgets, kaj ni ankaŭ uzas:

  • kirlo por labori kun HTTP kaj FTP.
  • OpenSSL por labori kun kriptografio kaj establi TLS-ligojn
  • libxml2 kaj libxslt por XML-analizo
  • libetpan por labori kun poŝtaj protokoloj (POP3, SMTP, IMAP)
  • mimeta por analizi retpoŝtajn mesaĝojn
  • sqllite por konservi uzantajn protokolojn
  • ICU por internaciigo

La listo daŭras.
Aldone, ni uzas tre modifitan version Google Testo и Google Mock dum disvolvado de unutestoj.
La bibliotekoj postulis adaptadon esti kongruaj kun la SCOM-komponenta organizmodelo.
La tropezo de 1C faras la platformon bonega provo de forto por la bibliotekoj uzataj en ĝi. Vario de uzantoj kaj scenaroj rapide malkaŝas erarojn en eĉ la plej malofte uzataj kodaj areoj. Ni mem korektas ilin kaj provas redoni ilin al la bibliotekaŭtoroj. La sperto de interago montriĝas tre malsama.
Programistoj kirlo и libetpan respondi rapide al tirpetoj, sed la flikaĵo, ekzemple, en OpenSSL Ni neniam sukcesis redoni ĝin.

konkludo

En la artikolo ni tuŝis plurajn ĉefajn aspektojn de la disvolviĝo de la platformo 1C: Enterprise. En la limigita amplekso de la artikolo, ni tuŝis nur kelkajn interesajn, laŭ nia opinio, aspektojn.
Ĝenerala priskribo de la diversaj platformmekanismoj troveblas tie.
Kiuj temoj interesus vin en estontaj artikoloj?

Kiel estas efektivigita la movebla platformo 1C?
Priskribo de la interna strukturo de la TTT-kliento?
Aŭ eble vi interesiĝas pri la procezo elekti funkciojn por novaj eldonoj, evoluado kaj testado?

Skribu en la komentoj!

fonto: www.habr.com

Aldoni komenton