Dalam peranan saya sebagai seorang Arkitek Solusi, saya telah bekerja dengan pelanggan dan SI merentangi Asia Tenggara dan India.  Mereka ini menghasilkan aplikasi era baru berlandaskan web.  Aplikasi-aplikasi ini termasuk platform jual-beli stok, gerbang bayaran, solusi perbankan mudah alih, solusi VAS telekomunikasi, sistem menjejak kesihatan/aktiviti masa nyata, platform e-perniagaan etc.  Selepas beberapa tugas, saya sedar terdapat satu pola.  Bukan sahaja sistem ini mementingkan misi atau perniagaan, ia turut berkongsi beberapa sifat yang sama.   Keperluan dan rekabentuk aplikasi-aplikasi ini ada banyak persamaan dan keserupaan.  Di bawah ini adalah beberapa persamaan ciri-ciri yang terdapat pada mana-mana aplikasi perniagaan di era kini tanpa mengira bidang dan tujuannya:-

• Semuanya akan dihadapkan kepada umum dan boleh digunakan melalui beberapa titik sentuhan kepada pengguna.  g. aplikasi mudah alih, web etc
• Semuanya akan bermula dengan trafik yang rendah/kenaan/permintaan pengguna dan akhirnya akan berkembang menjadi sistem yang sibuk dalam satu perniagaan
• Sistem-sistem ini akan saling berinteraksi merentasi aplikasi sedia ada dan/atau dengan beberapa sistem lain yang dirancang untuk dibangunkan dalam tempoh satu tahun akan datang
• Sistem-sistem ini perlu menjadi modular supaya sesetengah fungsinya dapat diganti tanpa memberi impak kepada yang lain

Semasa perbinncangan dengan pasukan aplikasi dan infrastruktur, kami merumuskan beberapa fakta umum yang boleh digunapakai dalam kebanyakan situasi semasa membangunkan sistem berlandaskan web yang menghadap pengguna.   Saya akan nyatakan beberapa ilmu yang saya pelajari dan beberapa cadangan yang kami rumuskan semasa pelbagai tugasan:-

• Adalah terbaik untuk meneruskan rekabentuk yang modular dengan ruang hubung kait dan kontrak antara modul yang berbeza. Ruang hubung kait dan kontrak ini akan membantu anda meminimakan perubahan dan impak perubahan yang dibuat pada satu modul.  Sebagai contoh, jika anda sering menggabungkan semua interaksi pangkalan data anda sebagai API capaian data, ia akan membantu anda menghindarkan impak perubahan pangkalan data.  API capaian data boleh direkabentuk untuk menghantar data ke aplikasi sebagai JSON  atau XML.  Ini akan memisahkan sepenuhnya aplikasi daripada perubahan pada rekabentuk pangkalan data, pemulihan dan malah platform pangkalan data.  Lagipun, semua titik sentuhan pangkalan data anda berada pada satu tempat di mana mudah untuk membuat pemfaktoran semula kod semasa perubahan rekabentuk pangkalan data.  Pemisahan yang sama boleh dilakukan pada setiap lapisan capaian data, aplikasi, web dan interaksi pengguna.

• Sementara menerima permintaan pengguna adalah lebih baik untuk membariskan permintaan menggunakan cara barisan mesej daripada membiarkan pengguna menunggu semasa pelayan memproses permintaan. Sama untuk permintaan DB, sebalik membenarkan aplikasi untuk membuat hubungan, adalah lebih baik untuk membenarkannya membariskan permintaan.  Ini juga membolehkan penggunaan sumber yang lebih baik dan mengurangkan pertukaran konteks.  Dengan pangkalan data PostgreSQL, anda mempunyai pilihan alatan seperti pgpool dan pgBouncer untuk memudahkan barisan penyambungan.

• Selalunya adalah lebih baik untuk membahagikan aplikasi kepada beberapa bahagian yang dipanggil modul (sub-aplikasi kecil) atau servis mikro yang boleh berfungsi dengan servis mikro/modul yang lain e.g. anda boleh mengganti dan mengubah modul pendaftaran pelanggan anda tanpa memberi impak kepada modul lain yang bergantung pada pendaftaran pelanggan untuk mengambil maklumat pelanggan atau mendaftar pelanggan baru. Interaksi antara modul-modul ini boleh dilakukan melalui Web Service yang memudahkan antara muka dan kontrak antara sub-aplikasi/servis mikro ini.

• Apabila jumlah transaksi meningkat, secara praktikalnya adalah mustahil untuk menambah dengan satu disk atau satu pelayan. Anda patut merancang untuk melancarkan senibina aplikasi anda dengan cara entiti yang mempunyai transaksi tulis yang tinggi, boleh terbahagi apabila perlu. Postres Plus Advance Server EnterpriseDB memudahkan Hash Partitioning yang boleh membantu anda mencapai pembahagian traksaksi tulis merentangi disk-disk berbeza.  Pilihan lain ialah anda boleh menggunakan pangkalan data noSQL seperti MongoDB untuk berkongsi entiti dengan operasi tulis yang besar merentasi beberapa pelayan.  Lagipun, senibina aplikasi hibrid kini bukanlah jarang, di mana beberapa entiti diagihkan ke dalam simpanan noSQL dan sebahagian disimpan dalam pangkalan data relasional.

• Banyak keperluan yang rumit atau keperluan yang tidak jelas perlukan rekabentuk skema yang normal. Ini membenarkan adaptasi yang mudah untuk mengubah hierarki hubungan atau untuk memperkenalkan konsep baru nanti.  Contoh tipikal bagi ini ialah peraturan aplikasi.  Anda mungkin akhirnya menyimpan peraturan maklumat metadata merentangi 3-4 “tables” dan menghubungkannya pada masa nyata, boleh mengakibatkan masalah besar, walaupun pada skala kecil.  Pendekatan yang lebih baik ialah menggunakan enjin peraturan yang berlandaskan aplikasi di mana peraturan boleh dispesifikasikan dalam dokumen XML atau JSON dan disimpan sementara dalam pelayan aplikasi.  Sama juga dengan hubungan terperinci dalam entiti lain yang telah banyak berubah sejak beberapa tahun kebelakangan ini dan pasti akan terus berubah.  Adalah lebih baik untuk menyimpan maklumat sebegini di dalam pangkalan data noSQL atau jenis data rata e.g. JSON atau Array.  PostgreSQL menawarkan banyak jenis data yang berlainan, penyambungan dan indek untuk membolehkan anda menyimpan data anda dengan cara yang terbaik.

• Simpan sementara data anda dalam pelayan aplikasi. Tiada apa yang baru mengenai “caching”, anda mungkin telah menyimpan sementara data statik.  Tetapi masih terdapat banyak data yang anda tidak simpan sementara.  Sebenarnya anda boleh menyimpan sementara data operasi yang dikemaskini dalam masa nyata.  Dalam keadaan nahas, data ini boleh dibina semula daripada transaksi atau log aktiviti.  Saya akan jelaskan lebih lanjut mengenai ini dalam salah satu blog saya nanti.

• Di sebalik menggunakan cara tradisional iaitu “SELECT FOR UPDATE”, capai keselarian tinggi dengan kunci optimistic.

• Pada hari ini, dalam kebanyakan aplikasi, data pada mulanya dibaca kemudian dikemaskini. Jadi sementara terdapat beban membaca kerana pertanyaan dan pencarian, semua operasi tulis juga menjana permintaan baca pada pangkalan data.  g. sebelum mendaftar pengguna baru, anda akan menyemak jika pengguna itu telah wujud.  Dengan membuat replika baca dan menyeimbangkan beban, permintaan bacaan merentangi beberapa replika boleh menjadi agak berguna.  PostgreSQL menyediakan replikasi “steaming” sebagai cara mudah untuk membuat replika bacaan.  Menggunakan ciri yang sama, anda juga boleh membina cluster berskala dan keberadaan tinggi dengan PostgreSQL.  Ciri-ciri replikasi yang sama turut ada  dalam MongoDB, ia fleksibel untuk menspesifikasikan pilihan baca dari mana untuk mendapatkan data.

• Kerap semasa merekabentuk sistem yang melibatkan transaksi kewangan atau pengurusan inventori e.g. laman perniagaan, perbankan mudah alih, pembayaran bil mudah alih atau aplikasi dompet mudah alih yang ringkas, anda akan menghadapi masalah besar pada liability atau pengurusan inventori. Tipikalnya terdapat satu butiran pada satu baris atau satu baris untuk akaun dalaman.  Ini sering menjadi pusat pertelagahan dan pencerutan.  Lihat jika ini boleh dihindarkan dengan beberapa proksi atau entity palsu.  Saya akan terangkan lebih lanjut mengenai ini dalam salah satu blog saya nanti.

Anda boleh menulis kepada kami di success@ashnik.com jika anda mencari perunding dan cadangan pembangunan dalam membangun dan melancarkan sebuah sistem dengan keperluan pemprosesan yang tinggi.  Sementara itu jangan ke mana-mana, saya akan kembali pada tahun 2016 dengan blog yang lebih terperinci mengenai cadangan-cadangan di atas.