Secara singkat tentang jenis arsitektur perangkat lunak, dan mana yang kami pilih untuk penyedia IaaS

Ada banyak jenis arsitektur perangkat lunak dengan pro dan kontra mereka. Selanjutnya, kita akan berbicara tentang fitur-fitur yang paling populer di antara mereka dan berbicara tentang transisi kita ke layanan-layanan mikro.


/ libreshot / PD

Jenis Arsitektur Perangkat Lunak

Arsitektur berlapis

Ini adalah salah satu arsitektur yang paling umum. Atas dasar itu, banyak kerangka kerja besar dibangun - Java EE, Drupal, Express. Mungkin contoh paling terkenal dari arsitektur ini adalah model jaringan OSI .

Sistem ini dibagi menjadi beberapa level, yang masing-masing berinteraksi dengan hanya dua yang bertetangga. Oleh karena itu, permintaan ke database, yang biasanya terletak di bagian paling akhir dari rantai interaksi, melewati secara berurutan melalui setiap "lapisan".

Arsitektur tidak menyiratkan jumlah level wajib - mungkin ada tiga, empat, lima atau lebih. Paling sering, sistem tiga-tier digunakan: dengan tingkat presentasi (klien), tingkat logika, dan tingkat data.


Banyak buku dan artikel telah ditulis tentang arsitektur bertingkat. Dan ada perbedaan pendapat tentang kelebihan dan kekurangannya.

Pro:

Setiap tingkat arsitektur ini melakukan serangkaian fungsi yang sangat terbatas (yang tidak diulang dari lapisan ke lapisan) dan tidak tahu bagaimana tingkat lainnya diatur. Oleh karena itu, "isi" level dapat diubah tanpa risiko konflik global antar lapisan.

Secara umum, aplikasi bertingkat begitu luas sehingga generator template khusus dibuat untuk pengembangannya. Misalnya, LASG untuk Visual Studio menawarkan beberapa metode pembuatan kode yang mengotomatiskan tugas-tugas rutin dan membantu membangun tingkatan aplikasi.

Kekurangan:

Dalam pemrograman, ada pepatah yang mengatakan bahwa masalah apa pun dapat diselesaikan dengan menambahkan tingkat abstraksi lain. Namun, pendekatan ini pada akhirnya dapat menyebabkan organisasi yang buruk dari kode dan membingungkan pengembang.

Masalah lain muncul dari ini - kecepatan rendah. Banyak informasi mulai berlalu sia-sia dari lapisan ke lapisan, tanpa menggunakan logika bisnis. Masalah ini kadang - kadang disebut anti-pola sinkhole, pola desain ketika jumlah operasi yang tidak berguna mulai menang atas yang berguna.

Menemukan bug pada sistem multi-tier juga bisa sulit . Sebelum memasukkan basis data, informasi melewati semua tingkatan (karena basis data adalah komponen terakhir). Jika karena alasan tertentu informasi ini rusak (atau hilang di sepanjang jalan), maka untuk menemukan kesalahan, Anda harus menganalisis setiap level secara terpisah.

Cocok:

• Untuk membuat aplikasi baru yang perlu digunakan dengan cepat. Ini adalah semacam "template tujuan umum."
  
  

  Ketika kami mulai bekerja pada sistem internal penyedia infrastruktur virtual kami di 1cloud , kami menggunakan jenis arsitektur khusus ini. Pada awalnya, kami tidak memiliki tugas untuk menciptakan layanan IaaS yang mampu memproses lalu lintas puluhan atau ratusan ribu pengguna. Kami memutuskan untuk segera meluncurkan produk di pasar dan mulai mengembangkan basis pelanggan, dan menyelesaikan masalah penskalaan saat tersedia (dan sekarang kami mentransfer semua sistem ke arsitektur layanan mikro, yang akan dibahas nanti).

  
  Di antara para pengembang ada pendapat bahwa tidak perlu sejak hari-hari pertama proyek untuk mempersiapkannya untuk muatan kolosal (tulis perangkat lunak bukti masa depan). Persyaratan aktual untuk aplikasi atau layanan mungkin berbeda dari harapan, dan tujuan bisnis dapat berubah . Oleh karena itu, kode yang ditulis dengan memperhatikan risiko masa depan yang jauh menjadi hutang teknis.
• Menurut O'Reilly, arsitektur berlapis adalah pilihan alami untuk banyak aplikasi perusahaan. Karena perusahaan (terutama yang besar) sering berbagi kompetensi: ada tim yang bertanggung jawab untuk front-end, ada orang yang bertanggung jawab untuk back-end, dan sebagainya. Ini menyiratkan pembagian alami aplikasi ke tingkat: beberapa pengembang bekerja pada klien, yang lain pada logika.
  
  Hubungan serupa antara struktur organisasi dan pendekatan pengembangan aplikasi juga ditentukan oleh hukum Conway , yang dirumuskan kembali pada tahun 1967. Bunyinya: "Ketika mengembangkan suatu sistem, organisasi dipaksa untuk mematuhi skema yang mengulangi struktur komunikasi dalam perusahaan."

Arsitektur Berorientasi Kejadian

Dalam hal ini, pengembang menentukan perilaku (reaksi) untuk program ketika terjadi peristiwa. Suatu peristiwa dalam sistem dianggap sebagai perubahan yang signifikan di negaranya.

Anda dapat menggambar analogi dengan membeli mobil di kabin. Ketika sebuah mobil menemukan pemilik baru, kondisinya berubah dari "dijual" menjadi "dijual". Acara ini meluncurkan proses persiapan pra-penjualan - pemasangan peralatan tambahan, memeriksa kondisi teknis, mencuci, dll.

Sistem yang digerakkan oleh peristiwa biasanya mengandung dua komponen: sumber acara (agen) dan konsumennya (tenggelam). Biasanya ada dua jenis acara juga: acara awal dan acara yang ditanggapi konsumen.

Contoh implementasi arsitektur seperti itu adalah perpustakaan Java Swing. Jika kelas membutuhkan peringatan tentang suatu peristiwa, pengembang mengimplementasikan apa yang disebut pendengar - ActionListener (dia "menangkap" peristiwa terkait), dan menambahkannya ke objek yang dapat dihasilkan oleh peristiwa ini.

Kode implementasi berikut untuk mekanisme ini disediakan di Wiki:

public class FooPanel extends JPanel implements ActionListener { public FooPanel() { super(); JButton btn = new JButton("Click Me!"); btn.addActionListener(this); this.add(btn); } @Override public void actionPerformed(ActionEvent ae) { System.out.println("Button has been clicked!"); } } 

Keuntungan arsitektur:

Karena aplikasi terdiri dari sejumlah besar modul asinkron (yang tidak memiliki informasi tentang implementasi satu sama lain), mereka mudah untuk diukur. Sistem seperti itu dirakit sebagai konstruktor - Anda tidak perlu mendaftarkan dependensi, cukup terapkan modul baru. Selain itu, model asinkron memungkinkan kinerja aplikasi yang tinggi.

Kekurangan:

Sifat asinkron dari aplikasi semacam itu mempersulit proses debug. Satu peristiwa dapat memicu beberapa rantai tindakan sekaligus. Jika ada banyak rantai seperti itu, maka bisa sulit untuk memahami apa yang sebenarnya menyebabkan kegagalan. Untuk mengatasi masalah, kita harus mengatasi kondisi sulit untuk penanganan kesalahan. Dari sini masalah dengan mengikuti logging - log sulit untuk struktur.

Cocok untuk:

• Pembuatan sistem asinkron. Ini jelas karena arsitektur itu sendiri terdiri dari sejumlah besar modul asinkron.
• Dapat digunakan untuk membuat UI. Halaman web bertindak sebagai wadah di mana masing-masing komponennya diisolasi dan merespons tindakan pengguna tertentu.
• Untuk mengatur pengiriman pesan antara berbagai sistem informasi.

Arsitektur mikrokernel

Jenis arsitektur ini terdiri dari dua komponen: inti dari sistem dan plugin. Plugin bertanggung jawab atas logika bisnis, dan kernel mengelola pemuatan dan pembongkarannya.


Sebagai contoh arsitektur microkernel, buku O'Reilly menyediakan Eclipse IDE. Ini adalah editor sederhana yang membuka file, memungkinkan mereka untuk diedit dan menjalankan proses latar belakang. Tetapi dengan penambahan plugin (misalnya, Java compiler), fungsinya meluas.

Arsitektur microkernel pada suatu waktu menggunakan sistem operasi Symbian untuk perangkat seluler (pengembangan dihentikan pada 2012). Dalam microkernel-nya adalah penjadwal tugas, sistem dan driver manajemen memori, dan sistem file serta komponen yang bertanggung jawab untuk komunikasi telepon bertindak sebagai plug-in.

Keuntungan arsitektur:

Mudah untuk mem-port aplikasi dari satu lingkungan ke lingkungan yang lain, karena hanya microkernel yang perlu dimodifikasi. Pemisahan kebijakan tingkat tinggi dan mekanisme tingkat rendah menyederhanakan dukungan sistem dan memastikan ekstensibilitasnya.

Kekurangan:

Kinerja aplikasi berkurang jika Anda memasukkan terlalu banyak modul. Namun, dapat menjadi masalah untuk menemukan keseimbangan antara jumlah plugin dan jumlah tugas mikronukleus (biasanya hanya berisi kode yang sering digunakan).

Juga sulit untuk menentukan terlebih dahulu (sebelum pengembangan aplikasi) tingkat optimal fragmentasi kode mikronukleus. Dan mengubah pendekatan nanti hampir mustahil.

Baik untuk:

• Buat aplikasi yang dapat dikembangkan yang digunakan oleh banyak orang. Sebagai contoh, iPhone OS memiliki akar "microkernel" - pengembangnya mengambil inspirasi dari Mach (ini adalah salah satu contoh pertama dari microkernel).
• Pembuatan aplikasi dengan pemisahan yang jelas dari metode dasar dan aturan tingkat tinggi.
• Pengembangan sistem dengan seperangkat aturan yang berubah secara dinamis yang harus sering diperbarui.

Layanan microser

Mirip dengan arsitektur yang digerakkan oleh peristiwa dan mikrokernel. Tetapi mereka digunakan ketika tugas aplikasi individual dapat dengan mudah dibagi menjadi fungsi-fungsi kecil - layanan independen . Layanan ini dapat ditulis dalam berbagai bahasa pemrograman karena mereka berkomunikasi satu sama lain menggunakan REST API (misalnya, menggunakan JSON atau Hemat ).

Dalam proporsi apa kode dibagi, pengembang memutuskan, tetapi Sam Newman, penulis buku " Membuat Layanan Mikro, " merekomendasikan agar Anda mengalokasikan sebanyak mungkin baris kode ke layanan mikro karena tim dapat mereproduksi dalam dua minggu. Menurutnya, ini akan memungkinkan untuk menghindari "kembung" berlebihan dari arsitektur.

Paling sering, layanan mikro diluncurkan dalam wadah yang disebut. Wadah-wadah ini dapat diakses melalui jaringan ke layanan dan aplikasi microser lainnya, dan sistem orkestrasi mengelola semuanya: contohnya termasuk Kubernetes, Docker Swarm, dll.

Keuntungan:

Arsitektur microservice menyederhanakan penskalaan aplikasi. Untuk mengimplementasikan fitur baru, cukup tulis layanan baru. Jika fungsi tidak lagi diperlukan, layanan microsoft dapat dinonaktifkan. Setiap layanan mikro adalah proyek terpisah, oleh karena itu mudah untuk mendistribusikan pekerjaan mereka di antara tim pengembangan.

Baca lebih lanjut tentang mekanisme penskalaan sistem layanan mikro dalam buku oleh Martin L. Abbott, The Art of Skalability.

Kekurangan:

Sulit untuk mencari kesalahan. Tidak seperti sistem monolitik (ketika semua fungsi berada di kernel yang sama), mungkin sulit untuk menentukan mengapa permintaan "jatuh". Untuk perincian, Anda harus masuk ke log dari proses "bersalah" (jika ada beberapa, masalahnya diperburuk).

Ini menciptakan overhead tambahan untuk pengiriman pesan antar layanan microser. Menurut perkiraan kami, pertumbuhan biaya jaringan dapat mencapai 25%.

Kelemahan lain adalah perlunya bertahan dengan konsep konsistensi akhirnya ( koherensi dalam jangka panjang ). Layanan Microsoft memiliki gudang data mereka sendiri, yang diakses oleh layanan Microsoft lainnya. Informasi tentang perubahan pada data ini tidak didistribusikan secara instan melalui sistem. Oleh karena itu, situasi muncul ketika beberapa layanan mikro (meskipun untuk periode waktu yang sangat singkat) memiliki data yang sudah usang.

Tempat menggunakan:

• Dalam proyek besar dengan beban tinggi. Misalnya, layanan microser digunakan oleh platform streaming. Sistem pengiriman konten dan layanan dukungan lainnya dapat diskalakan secara independen satu sama lain, beradaptasi untuk memuat perubahan.
• Dalam sistem yang menggunakan sumber daya "campuran". Jika salah satu bagian dari aplikasi membutuhkan lebih banyak waktu prosesor, dan yang kedua - memori, maka masuk akal untuk membaginya menjadi layanan microser. Kemudian mereka dapat di-host di mesin yang berbeda - dengan CPU yang kuat atau sejumlah besar memori, masing-masing.
• Ketika keamanan dibutuhkan . Karena layanan mikro diisolasi dan berkomunikasi dengan API, dapat dijamin bahwa hanya informasi yang diperlukan layanan tertentu yang ditransmisikan. Ini penting ketika bekerja dengan kata sandi atau data kartu pembayaran.

Mengapa kita beralih ke layanan microser di 1cloud

Seperti yang telah kami katakan, dasar layanan yang kami sediakan ( cloud pribadi , server virtual , penyimpanan cloud objek , dll.) Didasarkan pada arsitektur multi-level. Dia menunjukkan dirinya di sisi yang baik, tetapi sekarang kemampuannya untuk skala mulai habis.

Kami menjadi semakin banyak mitra yang memberikan solusi berdasarkan platform waralaba kami. Ada situs dan layanan jarak jauh yang sulit dikelola dari satu titik (khususnya, peralatan kami terletak di beberapa pusat data di Rusia, Kazakhstan, dan Belarus ).

Untuk mempermudah skala fungsi yang ada dan memperkenalkan fitur baru, kami mentransfer seluruh infrastruktur kami ke layanan microsoft di 1cloud .



Kami ingin memisahkan mereka menjadi modul-modul terpisah dan alih-alih satu basis data yang kompleks mendapatkan N yang sederhana. Dengan demikian, dalam arsitektur baru, setiap fitur akan memiliki basis data terpisah. Ini jauh lebih nyaman dan efisien dalam dukungan dan pengembangan.

Kami akan dapat membagi pekerjaan pada layanan antara beberapa pengembang (sorot spesialisasi di perusahaan) dan skala efektif secara horizontal - bila perlu, kami hanya menghubungkan layanan microser baru.

Pelanggan kami juga akan menerima sejumlah keuntungan. Karena layanan Microsoft tidak terhubung satu sama lain, maka ketika layanan tertentu gagal, hanya saja layanan itu tidak tersedia, semua yang lain akan terus berfungsi secara normal. Selain itu, bahkan jika penurunan global dalam layanan kami terjadi, panel kontrol akan terus bekerja.

Pelanggan dari Kazakhstan dan Belarus (dan negara-negara lain tempat kami akan membuka kantor perwakilan) akan melihat peningkatan signifikan dalam kecepatan dan responsif antarmuka, karena panel kontrol akan berlokasi secara lokal.

Apa yang sudah dilakukan

Sejauh ini kami hanya menerapkan pilot pertama: "Layanan Pemantauan". Layanan yang tersisa akan ditransfer ke trek baru pada akhir 2018 - awal 2019.

Pada saat yang sama, arsitektur baru meletakkan dasar teknologi untuk tahap selanjutnya - migrasi ke wadah. Sekarang kita menggunakan infrastruktur Windows, dan untuk beralih ke wadah, kita perlu menulis ulang semua kode yang terakumulasi ke .NetCore dan mentransfernya ke Linux.

Kami berencana untuk memulai transisi baru pada awal 2019 dan menyelesaikannya pada akhir tahun depan.

Apa lagi yang kami tulis di Blog 1cloud:

• 1cloud Cloud Architecture Evolution: Tantangan Modulasi
• Bagaimana IaaS membantu franchisee 1C: pengalaman 1cloud
• Mengapa pemantauan perlu dilakukan?