Apa itu arsitektur N-Tier?

Saya telah melihat beberapa posting pekerjaan pengembang baru-baru ini yang mencakup kalimat yang kurang lebih berbunyi seperti ini: "Harus memiliki pengalaman dengan arsitektur N-Tier", atau "Harus dapat mengembangkan aplikasi N-Tier".

Ini membuat saya bertanya, apa itu arsitektur N-Tier? Bagaimana seseorang mendapatkan pengalaman dengannya?

Wikipedia :

Dalam rekayasa perangkat lunak, arsitektur multi-tier (sering disebut sebagai arsitektur n-tier) adalah arsitektur client-server di mana, presentasi, pemrosesan aplikasi dan manajemen data adalah proses yang secara logis terpisah. Misalnya, aplikasi yang menggunakan middleware untuk melayani permintaan data antara pengguna dan database menggunakan arsitektur multi-tier. Penggunaan "arsitektur multi-tier" yang paling luas mengacu pada arsitektur tiga-tier.

Masih bisa diperdebatkan apa yang dianggap sebagai "tingkatan," tetapi menurut saya itu perlu setidaknya melewati batas proses. Atau yang disebut lapisan. Tapi, itu tidak perlu di mesin yang berbeda secara fisik. Meskipun saya tidak merekomendasikannya, Anda dapat meng - host tingkat logis dan basis data pada kotak yang sama.

Sunting : Salah satu implikasinya adalah bahwa tier presentasi dan tier logika (kadang-kadang disebut Business Logic Layer) perlu melintasi batas mesin "melintasi kabel" kadang-kadang melalui jaringan yang tidak dapat diandalkan, lambat, dan / atau tidak aman. Ini sangat berbeda dari aplikasi Desktop sederhana di mana data tinggal di mesin yang sama dengan file atau Aplikasi Web di mana Anda dapat menekan database secara langsung.

Untuk pemrograman n-tier, Anda perlu mengemas data dalam semacam bentuk yang dapat diangkut yang disebut "dataset" dan menerbangkannya melalui kabel. .NET's DataSet class atau protokol Layanan Web seperti SOAP adalah beberapa dari upaya tersebut untuk terbang objek melalui kabel.

Ini didasarkan pada bagaimana Anda memisahkan lapisan presentasi dari logika bisnis inti dan akses data ( Wikipedia )

• 3-tier berarti lapisan Presentasi + Lapisan komponen + Lapisan akses data.
• N-tier adalah ketika lapisan tambahan ditambahkan di luar ini, biasanya untuk modularitas tambahan, konfigurasi, atau interoperabilitas dengan sistem lain.

Ini adalah kata kunci yang merujuk pada hal-hal seperti arsitektur Web normal dengan misalnya, Javascript - ASP.Net - Middleware - Lapisan basis data. Setiap hal ini adalah "tingkat".

Aplikasi data N-tier adalah aplikasi data yang dipisahkan menjadi beberapa tingkatan. Juga disebut "aplikasi terdistribusi" dan "aplikasi multitier," aplikasi n-tier memisahkan pemrosesan menjadi tingkatan diskrit yang didistribusikan antara klien dan server. Ketika Anda mengembangkan aplikasi yang mengakses data, Anda harus memiliki pemisahan yang jelas antara berbagai tingkatan yang membentuk aplikasi.

Aplikasi n-tier tipikal mencakup tier presentasi, tier tengah, dan tier data. Cara termudah untuk memisahkan berbagai tingkatan dalam aplikasi n-tier adalah membuat proyek diskrit untuk setiap tingkatan yang ingin Anda sertakan dalam aplikasi Anda. Sebagai contoh, tier presentasi mungkin aplikasi Windows Forms, sedangkan logika akses data mungkin pustaka kelas yang terletak di tier tengah. Selain itu, lapisan presentasi mungkin berkomunikasi dengan logika akses data di tingkat tengah melalui layanan seperti layanan. Memisahkan komponen aplikasi ke dalam tingkatan yang terpisah meningkatkan kemampuan pemeliharaan dan skalabilitas aplikasi. Ini dilakukan dengan memungkinkan adopsi teknologi baru yang lebih mudah yang dapat diterapkan pada satu tingkat tanpa persyaratan untuk mendesain ulang seluruh solusi. Sebagai tambahan,

Diambil dari situs web Microsoft .

Jika saya mengerti pertanyaannya, maka bagi saya sepertinya si penanya benar-benar bertanya, "Oke, jadi 3-tier dipahami dengan baik, tetapi tampaknya ada campuran hype, kebingungan, dan ketidakpastian tentang apa yang 4-tier, atau untuk generalisasi, arsitektur N-tier artinya. Jadi ... apa definisi N-tier yang dipahami dan disepakati secara luas? "

Ini sebenarnya adalah pertanyaan yang cukup dalam, dan untuk menjelaskan mengapa, saya perlu sedikit lebih dalam. Tetap bersamaku.

Arsitektur 3-tier klasik: database, "logika bisnis" dan presentasi, adalah cara yang baik untuk memperjelas cara menghormati prinsip pemisahan masalah. Artinya, jika saya ingin mengubah bagaimana "bisnis" ingin melayani pelanggan, saya tidak harus melihat seluruh sistem untuk mencari tahu bagaimana melakukan ini, dan khususnya, keputusan masalah bisnis tidak boleh tersebar mau tak mau melalui kode.

Sekarang, model ini berfungsi dengan baik selama beberapa dekade, dan ini adalah model klasik 'client-server'. Maju cepat ke penawaran cloud, di mana browser web adalah antarmuka pengguna untuk set pengguna yang luas dan terdistribusi secara fisik, dan yang satu akhirnya harus menambahkan layanan distribusi konten, yang bukan bagian dari arsitektur 3-tier klasik (dan yang perlu dikelola sendiri).

Konsep ini menggeneralisasi ketika datang ke layanan, layanan mikro, bagaimana data dan komputasi didistribusikan dan sebagainya. Apakah sesuatu adalah 'tingkat' sebagian besar tergantung pada apakah atau tidak tingkat menyediakan antarmuka dan model penyebaran untuk layanan yang berada di belakang (atau di bawah) tingkat tersebut. Jadi jaringan distribusi konten akan menjadi tingkat, tetapi layanan otentikasi tidak akan.

Sekarang, buka dan baca deskripsi contoh arsitektur N-tier lainnya dengan mengingat konsep ini, dan Anda akan mulai memahami masalahnya. Perspektif lain termasuk pendekatan berbasis vendor (misalnya NGINX), penyeimbang muatan yang sadar konten, isolasi data dan layanan keamanan (misalnya IBM Datapower), yang semuanya mungkin atau mungkin tidak menambah nilai pada arsitektur tertentu, penyebaran, dan kasus penggunaan.

Ini pemahaman saya bahwa N-Tier memisahkan logika bisnis, akses klien dan data dari satu sama lain menggunakan mesin fisik yang terpisah. Teorinya adalah bahwa salah satunya dapat diperbarui secara terpisah dari yang lain.

Aplikasi data N-tier adalah aplikasi data yang dipisahkan menjadi beberapa tingkatan. Juga disebut "aplikasi terdistribusi" dan "aplikasi multitier," aplikasi n-tier memisahkan pemrosesan menjadi tingkatan diskrit yang didistribusikan antara klien dan server. Ketika Anda mengembangkan aplikasi yang mengakses data, Anda harus memiliki pemisahan yang jelas antara berbagai tingkatan yang membentuk aplikasi.

Dan seterusnya di http://msdn.microsoft.com/en-us/library/bb384398.aspx

Ketika membangun MCV biasa (arsitektur 3-tier), seseorang dapat memutuskan untuk mengimplementasikan MCV dengan antarmuka dek-ganda, sehingga seseorang dapat mengganti tier tertentu tanpa harus memodifikasi satu baris kode pun.

Kita sering melihat manfaatnya , misalnya dalam skenario di mana Anda ingin dapat menggunakan lebih dari satu basis data (dalam hal ini Anda memiliki antarmuka ganda antara kontrol dan lapisan data).

Ketika Anda meletakkannya di View-layer (presentasi), maka Anda dapat (tahan !!) mengganti antarmuka PENGGUNA dengan mesin lain, sehingga secara otomatis mengotomatiskan input NYATA (!!!) - dan dengan demikian Anda dapat menjalankan tes kegunaan yang membosankan ribuan kali tanpa pengguna harus mengetuk dan mengetuk kembali dan mengetuk ulang hal yang sama berulang kali.

Beberapa menggambarkan arsitektur 3-tier tersebut dengan 1 atau 2 antarmuka ganda sebagai arsitektur 4-tier atau 5-tier , secara implisit menyiratkan antarmuka ganda.

Kasus-kasus lain termasuk (tetapi tidak terbatas pada) fakta bahwa Anda - dalam kasus sistem database semi-atau-sepenuhnya direplikasi akan secara praktis dapat mempertimbangkan salah satu database sebagai "master", dan dengan demikian Anda akan memiliki tingkat terdiri dari master dan yang lain terdiri dari database slave.

Contoh ponsel

Oleh karena itu, multi-tier - atau N-tier - memang memiliki beberapa interpretasi, sedangkan saya pasti akan berpegang pada 3-tier + tingkat tambahan yang terdiri dari antarmuka-disk tipis yang terjepit di antaranya untuk memungkinkan tier-swap, dan dalam hal pengujian (terutama digunakan pada perangkat seluler), sekarang Anda dapat menjalankan tes pengguna pada perangkat lunak nyata, dengan mensimulasikan pengguna mengetuk dengan cara yang logika kontrol tidak dapat membedakan dari mengetuk pengguna nyata. Ini hampir penting dalam mensimulasikan tes pengguna nyata , di mana Anda dapat merekam semua input dari pengguna OTA, dan kemudian menggunakan kembali input yang sama ketika melakukan tes regresi.

Ketika kita berbicara tentang Tiers, kita biasanya berbicara tentang Proses Fisik (memiliki ruang memori yang berbeda).

Jadi, dalam kasus, Layers dari sebuah aplikasi dikerahkan dalam proses yang berbeda, proses yang berbeda tersebut akan menjadi tingkatan yang berbeda.

Misalnya, dalam aplikasi 3-tier, pembicaraan tier bisnis ke Mainframe (proses terpisah) dan pembicaraan ke Layanan Pelaporan (proses terpisah), maka aplikasi itu akan menjadi 5 tier.

Oleh karena itu, nama generiknya adalah n-tier.

dari https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier

Arsitektur N-tier membagi ban aplikasi menjadi ban logis dan tingkatan fisik terutama dan dibagi menjadi beberapa bagian.

Lapisan adalah cara untuk memisahkan tanggung jawab dan mengelola ketergantungan. Setiap lapisan memiliki tanggung jawab khusus. Lapisan yang lebih tinggi dapat menggunakan layanan di lapisan yang lebih rendah, tetapi tidak sebaliknya.

Tingkatan terpisah secara fisik, berjalan pada mesin yang terpisah. Tingkat dapat memanggil ke tingkat lain secara langsung, atau menggunakan pesan tidak sinkron (antrian pesan). Meskipun setiap layer mungkin di-host di tingkatnya sendiri, itu tidak diperlukan. Beberapa lapisan mungkin di-host di tingkat yang sama. Secara fisik memisahkan tingkatan meningkatkan skalabilitas dan ketahanan, tetapi juga menambahkan latensi dari komunikasi jaringan tambahan.

Aplikasi three-tier tradisional memiliki tier presentasi, tier tengah, dan tier basis data. Tingkat tengah adalah opsional. Aplikasi yang lebih kompleks dapat memiliki lebih dari tiga tingkatan. Diagram di atas menunjukkan aplikasi dengan dua tingkat menengah, merangkum area fungsionalitas yang berbeda.

Aplikasi N-tier dapat memiliki arsitektur lapisan tertutup atau arsitektur lapisan terbuka:

In a closed layer architecture, a layer can only call the next layer immediately down.
In an open layer architecture, a layer can call any of the layers below it.

Arsitektur layer tertutup membatasi ketergantungan antar layer. Namun, itu mungkin membuat lalu lintas jaringan yang tidak perlu, jika satu lapisan hanya meneruskan permintaan ke lapisan berikutnya.

Aplikasi N-tier adalah aplikasi yang memiliki lebih dari tiga komponen yang terlibat. Apa saja komponen itu?

• Cache
• Antrian pesan untuk perilaku asinkron
• Muat penyeimbang
• Cari server untuk mencari melalui sejumlah besar data
• Komponen yang terlibat dalam pemrosesan sejumlah besar data
• Komponen yang menjalankan teknologi heterogen yang dikenal sebagai layanan web, dll.

Semua aplikasi sosial seperti Instagram, Facebook, layanan industri skala besar seperti Uber, Airbnb, game multi-pemain besar online seperti Pokemon Go, aplikasi dengan fitur mewah adalah aplikasi n-tier.

Martin Fowler menunjukkan dengan jelas:

Layering adalah salah satu teknik paling umum yang digunakan perancang perangkat lunak untuk memecah sistem perangkat lunak yang rumit. Anda melihatnya di arsitektur mesin, di mana lapisan turun dari bahasa pemrograman dengan panggilan sistem operasi ke driver perangkat dan set instruksi CPU, dan ke gerbang logika di dalam chip. Jaringan memiliki FTP berlapis di atas TCP, yang di atas IP, yang di atas ethernet.

Ketika memikirkan suatu sistem dalam hal lapisan, Anda membayangkan subsistem utama dalam perangkat lunak yang diatur dalam beberapa bentuk lapisan kue, di mana setiap lapisan bersandar pada lapisan bawah. Dalam skema ini, lapisan yang lebih tinggi menggunakan berbagai layanan yang ditentukan oleh lapisan bawah, tetapi lapisan bawah tidak menyadari lapisan yang lebih tinggi. Selain itu, setiap lapisan biasanya menyembunyikan lapisan bawahnya dari lapisan di atas, jadi lapisan 4 menggunakan layanan lapisan 3, yang menggunakan layanan lapisan 2, tetapi lapisan 4 tidak mengetahui lapisan 2. (Tidak semua arsitektur pelapis opak seperti ini , tetapi sebagian besar — ​​atau lebih tepatnya sebagian besar sebagian besar buram.)

Memecah sistem menjadi beberapa lapisan memiliki sejumlah manfaat penting.

• Anda dapat memahami satu lapisan sebagai satu kesatuan yang koheren tanpa mengetahui banyak tentang lapisan lainnya. Anda dapat memahami cara membangun layanan FTP di atas TCP tanpa mengetahui detail cara kerja ethernet.

• Anda dapat mengganti lapisan dengan implementasi alternatif dari layanan dasar yang sama. Layanan FTP dapat berjalan tanpa perubahan ethernet, PPP, atau apa pun yang digunakan perusahaan kabel.

• Anda meminimalkan ketergantungan antar lapisan. Jika perusahaan kabel mengubah sistem transmisi fisiknya, asalkan mereka membuat IP berfungsi, kita tidak perlu mengubah layanan FTP kami.

• Lapisan membuat tempat yang baik untuk standardisasi. TCP dan IP adalah standar karena mereka menentukan bagaimana lapisan mereka harus beroperasi.

• Setelah Anda membangun sebuah lapisan, Anda dapat menggunakannya untuk banyak layanan tingkat yang lebih tinggi. Dengan demikian, TCP / IP digunakan oleh FTP, telnet, SSH, dan HTTP. Kalau tidak, semua protokol tingkat tinggi ini harus menulis protokol tingkat rendah mereka sendiri. Dari Perpustakaan Kyle Geoffrey Passarelli

Layering adalah teknik yang penting, tetapi ada kelemahannya.

• Lapisan merangkum beberapa, tetapi tidak semua, hal-hal baik. Akibatnya, Anda terkadang mendapatkan perubahan berjenjang. Contoh klasik dari ini dalam aplikasi perusahaan berlapis adalah menambahkan bidang yang perlu ditampilkan pada UI, harus ada dalam database, dan dengan demikian harus ditambahkan ke setiap lapisan di antaranya.

• Lapisan ekstra dapat merusak kinerja. Di setiap lapisan, hal-hal yang biasanya perlu diubah dari satu representasi ke yang lain. Namun, enkapsulasi fungsi yang mendasarinya sering memberi Anda keuntungan efisiensi yang lebih dari kompensasi. Lapisan yang mengontrol transaksi dapat dioptimalkan dan kemudian akan membuat semuanya lebih cepat. Tetapi bagian tersulit dari arsitektur berlapis adalah memutuskan lapisan mana yang harus dimiliki dan apa tanggung jawab setiap lapisan.