Pemikiran dan amalan pemisahan front-end dan back-end berdasarkan NodeJS (1) Full-stack development_node.js

Kata Pengantar

Untuk menyelesaikan pelbagai masalah yang disebabkan oleh model pembangunan web tradisional, kami telah melakukan banyak percubaan, tetapi disebabkan jurang fizikal antara bahagian hadapan dan belakang, penyelesaian yang dicuba semuanya serupa. Selepas belajar daripada pengalaman yang menyakitkan, hari ini kami memikirkan semula takrifan "front-end dan back-end", memperkenalkan NodeJS, yang biasa kepada pelajar front-end, dan cuba meneroka model pemisahan depan-end dan back-end yang baharu. .

Dengan peningkatan terminal yang berbeza (Pad/Mudah Alih/PC), keperluan untuk pembangun semakin tinggi dan lebih tinggi Responsif sisi penyemak imbas tulen tidak lagi dapat memenuhi keperluan pengalaman pengguna yang tinggi terminal. Untuk meningkatkan kecekapan pembangunan, keperluan untuk pemisahan bahagian hadapan dan bahagian belakang semakin mendapat perhatian Bahagian belakang bertanggungjawab untuk antara muka perniagaan/data, dan bahagian hadapan bertanggungjawab untuk paparan/. logik interaksi. Kami boleh menyesuaikan dan membangunkan berbilang versi antara muka data yang sama.

Topik ini telah banyak dibincangkan baru-baru ini, dan beberapa BU di Alibaba juga sedang membuat beberapa percubaan. Selepas perbincangan yang panjang, pasukan kami memutuskan untuk meneroka penyelesaian pemisahan bahagian depan dan belakang berdasarkan NodeJS Semasa proses itu, kami mempunyai beberapa pemahaman dan pemikiran yang berubah, yang direkodkan di sini akan mengambil bahagian dalam perbincangan dan membantu kami memperbaikinya.

1. Apakah pemisahan bahagian hadapan dan belakang?

Semasa perbincangan awal dalam kumpulan, saya mendapati bahawa setiap orang mempunyai pemahaman yang berbeza tentang pemisahan bahagian hadapan dan bahagian belakang Bagi memastikan perbincangan dapat dibincangkan dalam saluran yang sama, kita mesti mencapainya terlebih dahulu perjanjian tentang apa itu "pemisahan bahagian hadapan dan bahagian belakang".

Contoh pemisahan bahagian hadapan dan bahagian belakang yang semua orang bersetuju ialah SPA (Aplikasi halaman tunggal yang digunakan disediakan oleh bahagian belakang melalui antara muka tak segerak (AJAX/JSONP), dan bahagian hadapan hanya memaparkannya.
Dari satu segi, SPA memang mencapai pemisahan hujung depan dan belakang, tetapi terdapat dua masalah dengan pendekatan ini:

Antara perkhidmatan WEB, SPA menyumbang sebahagian kecil. Dalam banyak senario, terdapat mod campuran segerak/segerak dan tak segerak, dan SPA tidak boleh digunakan sebagai penyelesaian universal.
Dalam model pembangunan SPA semasa, antara muka biasanya disediakan berdasarkan logik pembentangan Kadang-kadang untuk meningkatkan kecekapan, bahagian belakang akan membantu kami mengendalikan beberapa logik pembentangan, yang bermaksud bahagian belakang masih terlibat dalam kerja lapisan Lihat, yang. adalah tidak nyata.
Pemisahan gaya SPA bahagian hadapan dan bahagian belakang adalah berdasarkan lapisan fizikal (dipercayai bahawa selagi ia adalah pelanggan, ia adalah bahagian hadapan, dan bahagian pelayan adalah bahagian belakang) . Bahagian ini tidak lagi dapat memenuhi keperluan kami untuk pemisahan bahagian hadapan dan bahagian belakang Kami percaya bahawa pembahagian tanggungjawab dapat dicapai Memenuhi senario penggunaan semasa kami:

Halaman hadapan: bertanggungjawab untuk lapisan Paparan dan Pengawal.
Bahagian belakang: hanya bertanggungjawab untuk lapisan Model, pemprosesan/data perniagaan, dsb.
Sebab pembahagian tanggungjawab ini akan dibincangkan kemudian.

2. Kenapa hujung depan dan belakang perlu dipisahkan?

Berkenaan isu ini, artikel Yu Bo The Evolution of Web R&D Model menerangkannya dengan sangat komprehensif Mari kita lihat dengan lebih dekat:

2.1 Senario terpakai bagi model pembangunan sedia ada

Beberapa model pembangunan yang disebut oleh Uncle Yu masing-masing mempunyai senario terpakai mereka sendiri, dan tiada siapa yang menggantikan yang lain sepenuhnya.

Sebagai contoh, MVC, yang memfokuskan pada bahagian belakang, sangat cekap dalam melakukan beberapa perniagaan paparan segerak Namun, apabila ia datang kepada halaman yang menggabungkan segerak dan tak segerak, ia akan menjadi lebih menyusahkan untuk berkomunikasi dengan pembangunan bahagian belakang.
Ajax ialah model pembangunan SPA utama, yang lebih sesuai untuk senario pembangunan APP, tetapi ia hanya sesuai untuk APP kerana isu seperti SEO sukar untuk diselesaikan Bagi banyak jenis sistem, kaedah pembangunan ini terlalu berat.
2.2 Tanggungjawab yang tidak jelas bagi bahagian hadapan dan belakang

Dalam sistem dengan logik perniagaan yang kompleks, kami paling takut untuk mengekalkan kod yang bercampur dengan bahagian hadapan dan bahagian belakang Kerana tiada kekangan, setiap lapisan M-V-C mungkin mempunyai kod dari lapisan lain. tiada kebolehselenggaraan sama sekali.
Walaupun pemisahan bahagian depan dan belakang tidak dapat menyelesaikan masalah ini sepenuhnya, ia boleh dikurangkan dengan banyak. Kerana ia dijamin secara fizikal bahawa anda tidak boleh melakukan ini.

2.3 Isu kecekapan pembangunan

Web Taobao pada asasnya berdasarkan rangka kerja MVC webx Seni bina menentukan bahawa bahagian hadapan hanya boleh bergantung pada bahagian belakang.
Oleh itu, model pembangunan kami masih menulis demo statik di bahagian hadapan dan menterjemahkannya ke dalam templat VM di bahagian belakang. Saya tidak akan membincangkan masalah model ini, yang telah dikritik sejak sekian lama.
Ia juga menyakitkan untuk membangunkan secara langsung berdasarkan persekitaran bahagian belakang, dan menyusahkan untuk mengkonfigurasi, memasang dan menggunakan. Untuk menyelesaikan masalah ini, kami mencipta pelbagai alat, seperti VMarket, tetapi bahagian hadapan masih perlu menulis VM dan bergantung pada data bahagian belakang, jadi kecekapan masih tidak tinggi.
Di samping itu, bahagian belakang tidak dapat menyingkirkan tumpuan kuatnya pada pembentangan dan menumpukan pada pembangunan lapisan logik perniagaan.

2.4 Had prestasi bahagian hadapan

Jika pengoptimuman prestasi dilakukan hanya pada bahagian hadapan, ruang adalah sangat terhad, jadi kami sering memerlukan kerjasama bahagian belakang untuk mencapai percikan api Namun, disebabkan oleh keterbatasan rangka kerja bahagian belakang, ia sukar bagi kami untuk menggunakan penyelesaian teknikal seperti Comet dan Bigpipe untuk mengoptimumkan prestasi.

Untuk menyelesaikan beberapa masalah yang dinyatakan di atas, kami telah membuat banyak percubaan dan membangunkan pelbagai alat, tetapi tidak pernah banyak peningkatan, terutamanya kerana kami hanya boleh menggunakan ruang kecil yang diperuntukkan kepada kami di bahagian belakang. Hanya dengan benar-benar memisahkan bahagian depan dan belakang kita boleh menyelesaikan masalah di atas sepenuhnya.

3. Bagaimana cara mengasingkan hujung depan dan belakang?

Bagaimana untuk memisahkan hujung depan dan belakang sebenarnya, jawapannya sudah ada di bahagian pertama:

Halaman hadapan: bertanggungjawab untuk lapisan Paparan dan Pengawal.
Bahagian belakang: bertanggungjawab untuk lapisan Model, pemprosesan/data perniagaan, dsb.

Bayangkan sahaja, jika bahagian hadapan menguasai Pengawal, kita boleh membuat reka bentuk url Kita boleh memutuskan untuk membuat secara serentak pada bahagian pelayan mengikut tempat kejadian, atau mengeluarkan data json berdasarkan data lapisan paparan , Komet, dsb. berdasarkan keperluan lapisan pembentangan dan sebagainya, ia sepenuhnya berdasarkan permintaan yang menentukan cara menggunakannya.

3.1 Pembangunan "Timbunan penuh" berdasarkan NodeJS

Jika kami ingin mencapai lapisan dalam gambar di atas, kami pasti memerlukan perkhidmatan web untuk membantu kami mencapai apa yang kami lakukan di bahagian depan dan belakang, jadi terdapat "pembangunan tindanan penuh berdasarkan NodeJS" yang disebutkan dalam tajuk

Gambar ini kelihatan ringkas dan mudah difahami, tetapi jika anda belum mencubanya, anda akan mempunyai banyak soalan.

Dalam mod SPA, bahagian belakang sudah menyediakan antara muka data yang diperlukan dan bahagian hadapan paparan sudah boleh dikawal Mengapa menambah lapisan tambahan NodeJS?
Bagaimanakah prestasi menambah satu lapisan lagi?
Dengan menambah satu lapisan lagi, adakah beban kerja bahagian hadapan akan meningkat?
Menambah lebih banyak lapisan bermakna lebih banyak risiko Bagaimana untuk memecahkannya?
NodeJS boleh melakukan segala-galanya, mengapa anda memerlukan JAVA?
Tidak mudah untuk menerangkan isu ini dengan jelas. Biar saya bercakap tentang proses pemahaman saya di bawah.

3.2 Mengapa menambah lapisan NodeJS?

Pada peringkat ini, kami terutamanya membangunkan model MVC bahagian belakang Model ini secara serius menghalang kecekapan pembangunan bahagian hadapan dan menghalang bahagian belakang daripada memfokuskan pada pembangunan perniagaan.
Penyelesaiannya adalah untuk membenarkan bahagian hadapan mengawal lapisan Pengawal, tetapi sukar untuk melakukannya di bawah sistem teknikal sedia ada, kerana adalah mustahil untuk semua bahagian hadapan untuk mempelajari Java, memasang persekitaran pembangunan bahagian belakang, dan tulis VM.
NodeJS dapat menyelesaikan masalah ini dengan baik.

3.3 Isu prestasi

Lapisan melibatkan komunikasi antara setiap lapisan, dan pasti akan ada kehilangan prestasi tertentu. Walau bagaimanapun, pelapisan yang munasabah boleh membuat tanggungjawab jelas dan memudahkan kerjasama, yang akan meningkatkan kecekapan pembangunan. Kerugian yang disebabkan oleh stratifikasi pasti akan ditebus oleh keuntungan di kawasan lain.
Di samping itu, sebaik sahaja kami memutuskan untuk membuat lapisan, kami boleh meminimumkan kerugian sebanyak mungkin dengan mengoptimumkan kaedah dan protokol komunikasi.

Contohnya:
Selepas halaman butiran Bayi Taobao dibuat statik, masih terdapat banyak maklumat yang perlu diperoleh dalam masa nyata, seperti logistik, promosi, dll. Oleh kerana maklumat ini berada dalam sistem perniagaan yang berbeza, bahagian hadapan perlu menghantar 5 atau 6 permintaan tak segerak untuk mengisi kandungan.
Dengan NodeJS, bahagian hadapan boleh memproksi lima permintaan tak segerak ini dalam NodeJS, dan boleh membuat Bigpipe dengan mudah ini boleh meningkatkan kecekapan pemaparan keseluruhan.
Mungkin anda fikir tidak mengapa untuk menghantar 5 atau 6 permintaan tak segerak pada PC, tetapi dari segi wayarles, sangat mahal untuk mewujudkan permintaan HTTP pada telefon mudah alih pelanggan Dengan pengoptimuman ini, prestasi boleh dipertingkatkan beberapa kali.

Butiran Taobao: Kami sedang dalam proses mengoptimumkan Taobao berdasarkan NodeJS. Saya akan berkongsi proses pengoptimuman selepas ia masuk dalam talian.

3.4 Adakah beban kerja bahagian hadapan meningkat?

Berbanding dengan hanya memotong halaman/melakukan demo, ia pasti menambah sedikit, tetapi di bawah model semasa, terdapat penyahpepijatan bersama dan pautan komunikasi Proses ini sangat memakan masa, terdedah kepada pepijat dan sukar untuk diselenggara.
Oleh itu, walaupun beban kerja akan meningkat sedikit, kecekapan pembangunan keseluruhan akan bertambah baik.

Selain itu, kos ujian boleh dijimatkan dengan banyak. Antara muka yang dibangunkan sebelum ini semuanya untuk lapisan pembentangan, menjadikannya sukar untuk menulis kes ujian. Jika bahagian hadapan dan bahagian belakang dipisahkan, walaupun ujian boleh dipisahkan, satu kumpulan orang akan menumpukan pada ujian antara muka dan kumpulan orang lain akan menumpukan pada menguji UI (bahagian kerja ini malah boleh digantikan. dengan alatan).

3.5 Bagaimana untuk mengawal risiko yang dibawa dengan menambahkan lapisan Node?

Dengan penggunaan Node secara besar-besaran, pelajar dari bahagian sistem/operasi dan penyelenggaraan/keselamatan pasti akan menyertai pembinaan infrastruktur Mereka akan membantu kami memperbaiki kemungkinan masalah dalam setiap pautan dan memastikan kestabilan sistem.

3.6 Node boleh melakukan segala-galanya, mengapa anda memerlukan JAVA?

Niat asal kami adalah untuk memisahkan bahagian depan dan belakang Jika kami mempertimbangkan isu ini, ia akan bertentangan dengan niat asal kami. Walaupun Node digunakan untuk menggantikan Java, tidak ada cara kami dapat menjamin bahawa pelbagai masalah yang dihadapi hari ini tidak akan berlaku, seperti tanggungjawab yang tidak jelas. Matlamat kami adalah untuk membangun secara berlapis, dengan orang profesional menumpukan pada melakukan perkara profesional. Infrastruktur berasaskan JAVA sudah sangat berkuasa dan stabil, dan lebih sesuai untuk melakukan seni bina semasa.

4 Pemisahan bahagian depan dan belakang Taobao berdasarkan Node

Gambar di atas ialah pemahaman saya tentang pemisahan dan lapisan bahagian hadapan dan belakang Taobao berdasarkan Node, serta skop tanggungjawab Node. Penerangan ringkas:

Hujung atas ialah pelayan, yang sering kita panggil hujung belakang. Bagi kami, bahagian belakang ialah koleksi antara muka, dan pelayan menyediakan pelbagai antara muka untuk kami gunakan. Kerana terdapat lapisan Node, tidak perlu mengehadkan bentuk perkhidmatannya. Untuk pembangunan bahagian belakang, mereka hanya menggunakan pelaksanaan antara muka yang mengambil berat tentang kod perniagaan.
Di bawah pelayan adalah aplikasi Node.
Terdapat lapisan Model Proxy dalam aplikasi Node untuk berkomunikasi dengan pelayan. Lapisan ini pada masa ini terutamanya untuk melicinkan cara kita memanggil antara muka yang berbeza dan merangkum beberapa Model yang diperlukan oleh lapisan paparan.
Lapisan Nod juga boleh dengan mudah merealisasikan vmcommon asal, tms (merujuk kepada sistem pengurusan kandungan Taobao) dan keperluan lain.
Terpulang kepada pembangun untuk menentukan rangka kerja yang hendak digunakan untuk lapisan Nod. Walau bagaimanapun, adalah disyorkan untuk menggunakan gabungan xTemplat ekspres xTemplat boleh dikongsi di antara hujung hadapan dan belakang.
Semua orang memutuskan cara menggunakan Node, tetapi perkara yang menarik ialah kita akhirnya boleh menggunakan Node untuk mencapai kaedah output yang kita inginkan dengan mudah: JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/synchronous, asynchronous, apa sahaja yang anda mahukan untuk melaraskannya bergantung sepenuhnya pada pemandangan anda.
Lapisan penyemak imbas tidak berubah dalam seni bina kami, dan kami tidak berharap pengenalan Node akan mengubah pemahaman anda sebelumnya tentang pembangunan dalam penyemak imbas.
Pengenalan Node hanya meletakkan kawalan bahagian hadapan ke atas bahagian yang sepatutnya dikawal oleh bahagian hadapan.
Kami sudah mempunyai dua projek dalam pembangunan dengan model ini Walaupun ia belum dilancarkan lagi, kami telah merasai faedah dari segi kecekapan pembangunan dan pengoptimuman prestasi.

5. Apa lagi yang perlu kita lakukan?

Sepadukan proses pembangunan Node ke dalam proses SCM sedia ada Taobao.
Pembinaan infrastruktur, seperti sesi, pembalak dan modul biasa lain.
Amalan Pembangunan Terbaik
Kisah kejayaan dalam talian
Pemahaman semua orang tentang konsep pemisahan bahagian hadapan dan belakang dalam Node
Selamat
Prestasi
…
Tidak banyak yang perlu diinovasikan dan dikaji secara teknikal, dan sudah ada banyak pengumpulan siap sedia. Sebenarnya, kuncinya adalah untuk membersihkan beberapa proses dan mengumpul penyelesaian biasa Saya percaya bahawa dengan lebih banyak amalan projek, ini secara beransur-ansur akan menjadi proses yang stabil.

6. "Pertengahan"

Walaupun model "pembangunan tindanan penuh berdasarkan NodeJS" sangat mengujakan, masih ada jalan yang panjang untuk mengubah pembangunan tindanan penuh berdasarkan Node menjadi sesuatu yang stabil dan boleh diterima oleh semua orang. Kami sedang mengusahakan The Projek "Midway" direka untuk menyelesaikan masalah ini. Walaupun kami baru bermula, kami semakin hampir dengan matlamat kami! !