Tatlong antas na arkitektura

Panimula sa three-tier architecture

Ang tatlong-tier na arkitektura ay ang pinakakaraniwang arkitektura ng pakikipag-ugnayan sa Internet. Ito ay lumitaw nang ang dalawang-tier na bahagi ng server ay nahahati sa dalawang bahagi: isang logic layer at isang data layer .

Ito ay mukhang ganito:

Ang layer ng kliyente ay ang bahagi ng "ibinahagi na application" na responsable para sa pakikipag-ugnayan ng user. Ang layer na ito ay hindi dapat maglaman ng lohika ng negosyo at hindi dapat mag-imbak ng kritikal na data. Gayundin, hindi ito dapat direktang makipag-ugnayan sa layer ng database, ngunit sa pamamagitan lamang ng layer ng lohika ng negosyo.

Gayunpaman, mayroon pa ring ilang lohika dito. Una, ito ay pakikipag-ugnayan sa gumagamit sa pamamagitan ng interface, pagpapatunay ng data na ipinasok niya, gumagana sa mga lokal na file. Kasama rin dito ang lahat ng nauugnay sa awtorisasyon ng user at pag-encrypt ng data kapag nagtatrabaho sa server.

Pangalawa, ito ay isang simpleng lohika ng negosyo. Halimbawa, kung nagpadala ang isang online na tindahan ng listahan ng mga produkto, maaari naming ayusin at i-filter ang mga ito sa panig ng kliyente. At narito rin ang primitive na pag-iimbak ng data: pag-cache, naka-log-in na cookies ng user, at iba pa.

Ang business logic layer ay matatagpuan sa pangalawang antas, karamihan sa business logic ay nakatutok dito. Sa labas nito, ang mga fragment lamang na na-export sa kliyente, pati na rin ang mga elemento ng lohika na nakalubog sa database (mga naka-imbak na pamamaraan at pag-trigger) ay nananatili.

Ang isang napaka-bahagi ng server ng lohika ng negosyo ay naglalaman ng hindi lamang kaparehong lohika, ngunit malulutas din ang mga problema sa pag-scale: ang code ay nahahati sa mga bahagi at ipinamahagi sa iba't ibang mga server. Ang ilang lubos na hinihiling na mga serbisyo ay maaaring tumakbo sa dose-dosenang mga server. Ang load sa pagitan ng mga ito ay pinamamahalaan ng load balancer.

Karaniwang idinisenyo ang mga application ng server sa paraang madaling mailunsad ang isa pang kopya ng server at makapagsimulang magtrabaho sa pakikipagtulungan sa iba pang mga kopya nito. Iyon ay, kahit na sa proseso ng pagsulat ng server code, hindi ka magkakaroon ng mga garantiya na ang iyong static na klase ay inilunsad sa isang pagkakataon.

Ang layer ng data ay nagbibigay ng imbakan ng data at inilalagay sa isang hiwalay na antas, na ipinatupad, bilang panuntunan, sa pamamagitan ng mga sistema ng pamamahala ng database (DBMS), ang koneksyon sa bahaging ito ay ibinibigay lamang mula sa antas ng server ng application.

Mga dahilan para sa paghihiwalay ng layer ng data

Ang paghihiwalay ng layer ng data sa isang ganap na ikatlong layer ay naganap sa maraming dahilan, ngunit ang pangunahing isa ay ang tumaas na pagkarga sa server.

Una, nagsimulang mangailangan ang mga database ng maraming memorya at oras ng processor para sa pagproseso ng data. Samakatuwid, nagsimula silang mailagay sa lahat ng dako sa magkahiwalay na mga server.

Sa pagtaas ng load, ang backend ay madaling madoble at sampung kopya ng isang server ay maaaring itaas, ngunit ito ay imposible na duplicate ang database - ang database ay nanatiling isang solong at hindi mahahati na bahagi ng system.

Pangalawa, ang mga database ay naging matalino - mayroon silang sariling lohika sa negosyo. Sinimulan nilang suportahan ang mga nakaimbak na pamamaraan, mga pag-trigger, ang kanilang sariling mga wika tulad ng PLSQL. At kahit na ang mga programmer ay lumitaw na nagsimulang magsulat ng code na tumatakbo sa loob ng DBMS.

Ang lahat ng lohika na hindi nakatali sa data ay dinala sa backend at inilunsad nang magkatulad sa dose-dosenang mga server. Ang lahat ng kritikal na nakatali sa data ay nanatili sa loob ng DBMS, at doon na ang mga problema ng tumaas na pagkarga ay kailangang lutasin gamit ang sarili nating mga pamamaraan:

• Ang database cluster ay isang pangkat ng mga database server na nag-iimbak ng parehong data at nagsi-synchronize nito gamit ang isang partikular na protocol.
• Sharding - ang data ay nahahati sa mga lohikal na bloke at ipinamahagi sa iba't ibang mga server ng database. Napakahirap na mapanatili ang mga pagbabago sa database gamit ang diskarteng ito.
• Ang diskarte ng NoSQL ay upang mag-imbak ng data sa mga database na binuo upang mag-imbak ng malaking halaga ng data. Ang mga ito ay madalas na hindi kahit na mga database, ngunit tiyak na mga imbakan ng file. Napakahina ng pag-andar kumpara sa mga relational database.
• Pag-cache ng data. Sa halip na isang simpleng cache sa antas ng database, lumitaw ang buong caching DBMS, na nag-imbak ng resulta lamang sa memorya.

Malinaw na kailangan ang hiwalay na tao at/o buong team para pamahalaan ang zoo na ito ng mga teknolohiya ng server, na humantong sa pag-alis ng layer ng data sa isang hiwalay na layer.

Mahalaga! Ang lahat ng mga advanced na teknolohiya ay isinilang sa kailaliman ng malalaking IT corporations, kapag ang mga lumang diskarte ay hindi na nakayanan ang mga bagong hamon. Ang paggawa ng mga database sa isang hiwalay na layer ay hindi naimbento ng sinumang programmer, ngunit ng isang grupo ng mga inhinyero sa isang lugar sa kaibuturan ng Oracle o IBM.

Interesting! Noong nagsimulang magsulat si Zuckerberg sa Facebook, nagtrabaho lang siya sa PHP + MySQL. Noong may milyun-milyong user, sumulat sila ng isang espesyal na tagasalin na nagsalin ng lahat ng PHP code sa C ++ at pinagsama-sama ito sa native machine code.

Gayundin, ang MySQL ay hindi kayang mag-imbak ng data ng bilyun-bilyong user, kaya binuo ng Facebook ang konsepto ng mga database ng NoSQL at nagsulat ng isang malakas na server-side na NoSQL DBMS - Cassandra. Sa pamamagitan ng paraan, ito ay ganap na nakasulat sa Java.

Labo ng lokasyon ng logic ng application

At kahit na ang isang three-tier na arkitektura ay halos hindi malabo na namamahagi ng mga tungkulin sa pagitan ng mga bahagi nito, hindi laging posible na tumpak na matukoy kung saan sa system ang isang bagong bahagi ng lohika ng negosyo (bagong code) ay kailangang idagdag.

Ang isang halimbawa ng naturang kalabuan ay ipinapakita sa larawan sa ibaba:

Ang bahagi ng server ay puno ng kulay abong background, ang bahagi ng kliyente ay puno ng puti. Ang isang magandang halimbawa ng huling diskarte (dulong kanan) ay ang mga modernong mobile app. Ang client side (sa telepono) ay naglalaman ng view (display), logic, at data. At kung minsan lamang ang data na ito ay naka-synchronize sa server.

Ang isang halimbawa ng pinakakaliwang opsyon ay isang tipikal na PHP server, na mayroong lahat ng logic sa server, at binibigyan nito ang kliyente ng static na HTML. Sa isang lugar sa pagitan ng dalawang sukdulang ito, makikita ang iyong proyekto.

Sa simula ng trabaho, pagkatapos mong makilala ang proyekto, kakailanganin mong kumunsulta sa mga programmer na nagtatrabaho dito, tungkol sa mga lugar kung saan mas mahusay para sa iyo na ipatupad ang lohika ng susunod na gawain.

Huwag mag-atubiling gawin ito. Una, hindi sila umakyat sa monasteryo ng ibang tao gamit ang kanilang charter. Pangalawa, magiging mas madali para sa lahat (at ikaw din) na mahanap ang code na kailangan mo sa lugar kung saan mo inaasahan na mahanap ito.