Skepping van sosiale netwerke

Wanneer sosiale netwerke op die basis van ons platform geskep word, word `n hele ″kombinasie″ van tegnologieë gebruik. Trouens, `n platform is `n raamwerk (`n stel sagteware-oplossings) + bedienerinfrastruktuur wat elke individuele projek bedien (instaanbedieners, CDN`e, groepbergingstelsels). As ons oor die sagteware-deel van die platform (oor die raamwerk) praat, kan ons sê dat dit 1) biblioteke en oplossings is op die gebied van hooggelaaide projekte; 2) biblioteke en oplossings op die gebied van KI; 3) sagteware-oplossings vir inligtingsekuriteit; 4) funksionele komponente van sosiale netwerke. In die stapel tegnologieë wat gebruik word, kan oplossings wat op Go, Phyton, JAVA, nodejs, php, Kotlin, Swift en ander tale gebaseer is, onderskei word. Ons beklemtoon dat ons platform `n hele stel (″stroper″) van oop oplossings is. Dit is belangrik om daarop te let dat in die veld van DBMS, beide SQL- en NoSQL-oplossings gebruik word (in kombinasie en afhangende van die take wat opgelos moet word), wat hoë spoed, betroubaarheid en skaalbaarheid van oplossings bied in toestande van verwerking van groot data-skikkings. Daarbenewens ontwikkel ons ons eie drywers vir die gebruikte stelsels en DBBS, wat ons in staat stel om `n aantal uitsonderings te hanteer en onder hoë vragte en betroubaarheidsvereistes te werk.

Vir sulke hoogs gelaaide projekte soos sosiale netwerke, organiseer ons `n hele netwerk van CDN en bergingsbedieners. Saam met vennote en kliënte stem ons saam oor die topologie van die projek, met inagneming van die eienskappe daarvan, sowel as `n stel vereistes - 1) op die gebied van betroubaarheid en veiligheid van die projek; 2) op die gebied van wetlike vereistes van die lande, waarvan die gebruikers toegang tot die projek moet hê. Die belangrikste is dat ons nie net die toepaslike infrastruktuur vir enige so projek kan skep nie, maar ook ons infrastruktuur kan verhuur. Besluite in die een of ander geval word geneem op grond van ekonomiese haalbaarheid en gemak van ondersteuning. Op die oomblik skep ons `n verspreide infrastruktuur, die platformbedieners is geleë in hoogs betroubare datasentrums in lande soos die VSA, Rusland, Singapoer, Duitsland, Nederland, Finland. Die infrastruktuur vir elke projek word op so `n manier toegewys dat hoë betroubaarheid en spoed van die projektoepassings verseker word in die toestande van gehoortoegang van regoor die wêreld.

Die belangrike ding om hier te onthou, is dat ons horisontaal-skaalbare projekte skep. Dit beteken onder meer dat dit nie nodig is om kapasiteit te reserveer vir `n gehoor wat nie oor 1-2 maande daar sal wees nie. Ons kan die infrastruktuur vinnig skaal in ooreenstemming met die dinamika van die projekte se groei. Met inagneming van die uitstekende optimalisering van die sagteware wat gebruik word en databergingsmetodes, benodig 1 projekkluster gemiddeld 3 bedieners. Jy benodig gemiddeld 2 + 1 groepe vir elke tien miljoen van die projekte se daaglikse gehoor (elke gebruiker genereer gemiddeld meer as 100 versoeke na die agterkant). Die koste om 1 groep te huur is ongeveer 1000 Amerikaanse dollars per maand. Boonop is daar die opsie om ons wolkinfrastruktuur te huur, wat dalk goedkoper kan wees as om jou eie klusters te gebruik, as gevolg van sinergie met ander projekte. Tegniese uitgawes word in elk geval meer as vergoed vir sulke projekte – beide deur advertensie-monetisering en deur die monetisering van interne dienste. Hoe groter die gehoor van die projek, hoe laer is die koste van die tegniese werking daarvan.

Fundamenteel en teoreties - ″JA″. Al ons oplossings is oopbron. Maar in die praktyk is dit nie altyd voordelig vir ons vennote nie, want hiervoor is dit nodig om hoogs gekwalifiseerde spesialiste te hê op die gebied van hoogs gelaaide projekte en die tegnologiestapel wat gebruik word. Daar is nietemin twee opsies vir samewerking - 1) ons lei en vorm `n aparte span om met die projek te werk; 2) ons gaan voort om die projek saam met jou te bedien en te ontwikkel (die laaste opsie is die winsgewendste vanuit die oogpunt van ″sinergie″, want ons oplossings ontwikkel en die koste van diens kan meer winsgewend wees as om `n aparte span te onderhou ).

Ons platform is toegerus met verskeie lae en meganismes van beskerming en sekuriteit, insluitend:

• Beskerming van persoonlike data:
  1) Persoonlike data word in geënkripteerde vorm gestoor;
  2) OWASP-standaarde word streng gevolg;
  3) Toegang tot toestelanalise + twee-faktor-verifikasie.
• Die interne bladsye van projekte binne die platform word beskerm teen outomatiese stelsels vir die ontleding, soek en kopiëring van inligting - probeer om `n data-ontleder te skryf, byvoorbeeld vanaf hierdie webwerf, en kyk self;
• Registrasie van bots in die stelsel is uitgesluit (kunsmatige intelligensie-tegnologieë word gebruik om gedragsaktiwiteit te ontleed);
• As kwaadwillige aktiwiteit bespeur word, genereer die stelsel outomaties ″misbruik-briewe″ en stuur dit na die datasentrums en internetverskaffers wat aan die aanval deelneem.

Dit is meer `n organisatoriese as `n tegniese kwessie. Wat die tegniese kant van die kwessie betref, is die toegang tot die DBBS streng afgebaken van die ontwikkelaars se toegang tot die programkode. Gewoonlik het ontwikkelaars binne ons platform nie toegang tot die nodusse van die databasisbestuurstelsel nie. Wat die organisatoriese en tegniese deel betref, word vir hierdie doeleindes ingenieurs wat gesertifiseer is op die gebied van inligtingsekuriteit gebruik. As `n reël is sulke mense die hoofingenieurs van die projek en is verantwoordelik vir die mees krities kwesbare deel. Toegang tot sulke dele van die projek word hoogs gereguleer en wetlik beskerm.

Kom ons gee n voorbeeld. Wanneer jy `n speletjie in `n programmeertaal skep, word die speletjie self `n objek van intellektuele eiendom, en nie die programmeertaal waarin dit geskryf is nie. In die lisensie-ooreenkoms vir die speletjie is dit egter nodig om die voorwerpe van intellektuele eiendom aan te dui wat gebruik is toe dit geskep is. Byvoorbeeld, visuele voorwerpe, programmeertale, biblioteke vrygestel onder die Apache-lisensie of die GPL. Ten spyte van die feit dat die platform self, op grond waarvan sosiale netwerke geskep word, aan ons behoort, is die uiteindelike objek van intellektuele eiendom die sosiale netwerk self, wat unieke eienskappe het. Hierdie intellektuele eiendom sal reeds aan jou behoort. Maar jou netwerklisensie-ooreenkoms moet die sagteware lys wat jy gebruik om dit te bou, insluitend ons platform. Ons sal jou help om `n lisensie-ooreenkoms korrek op te stel en jou intellektuele eiendomsvoorwerp te registreer.

In antwoord op die vorige vraag het ons aangedui dat ons jou sal help om `n produkbeskrywing (jou sosiale netwerk) korrek saam te stel, `n lisensie-ooreenkoms vir gebruikers op te stel en ook deur die prosedure te gaan om `n intellektuele eiendomsvoorwerp te registreer. In verskillende lande is verskillende departemente hiervoor verantwoordelik. Byvoorbeeld, in Rusland is Rospatent hiermee besig. In die VSA - die US Library of Congress. Dit maak nie saak waar jy jou intellektuele eiendom registreer nie. Die belangrikste ding is dat so `n registrasie wetlike beskerming in alle lande het.

Aan die einde van die ontwikkeling en by die lewering van die projek, dra ons die toegang tot die projekinfrastruktuur en die beskrywing vir die klante se spesialiste oor. Al ons oplossings is oopbron. Verder, as dit ekonomies voordelig vir die Partye is, kan ons saam met jou voortgaan met die instandhouding en ontwikkeling van jou projek. Daar is verskillende opsies vir jou keuse.

Die antwoord is eenvoudig:
1. QSNE is nie `n klaargemaakte sosiale netwerk nie, maar `n raamwerk wat gebruik word om hoëladingsprojekte te skep. `n Stel biblioteke, ″kubusse″ waaruit elke individuele sosiale netwerk gebou is;
2. Elke sosiale netwerk is uniek en het unieke eienskappe. Dit alles word aanvanklik ooreengekom en hang af van die paradigma en idee wat in die projek geplaas word. Daarbenewens het elke sosiale netwerk sy eie GUI, sy eie unieke styl - dit alles verg `n aansienlike hoeveelheid tyd om te ontwikkel;
3. `n Sosiale netwerk bestaan uit `n aantal komponente wat nie parallel ontwikkel word nie, maar streng opeenvolgend. Byvoorbeeld, webdeel, API en backend, toepassings.

Natuurlik nie. Die ontwikkeling van `n sosiale netwerk is `n multi-stap proses. Wanneer sulke hoëladingsprojekte ontwikkel word, word `n sekere stapel tegnologieë gebruik en `n hele ″kombinasie″ van oplossings word gebruik. Dit hang alles nie net af van die kompleksiteit van die projek nie, maar van die samestellende dele daarvan - byvoorbeeld, sommige projekte benodig videostrome, sommige nie, sommige projekte gebruik verskillende toepassings, en sommige herhaal die aanpasbare deel van die projek. Gemiddeld neem die ontwikkeling van `n sosiale netwerk van 3 (vir baie eenvoudige projekte) tot 18 maande.