Pada mulanya, kerana jumlah data tidak besar, prestasi sistem cukup baik, dan pelbagai pertanyaan senarai, pertanyaan laporan, fungsi eksport data Excel, dsb. semuanya digunakan dengan lancar. Walau bagaimanapun, apabila perniagaan syarikat berkembang dan volum pesanan terkumpul hari demi hari, dan permintaan untuk pertanyaan laporan dan eksport data daripada pelbagai jabatan perniagaan terus meningkat dalam tempoh kemudian, kami secara beransur-ansur merasakan bahawa sistem berjalan lebih perlahan dan lebih perlahan. Jadi penyelesaian pertama yang mungkin kita fikirkan ialah mengoptimumkan pangkalan data kesesakan sistem. Salah satu percubaan kami yang mungkin adalah untuk meletakkan pangkalan data secara berasingan pada pelayan untuk memisahkan pangkalan data dan aplikasi, atau untuk mewujudkan pelbagai indeks jadual pangkalan data, mengoptimumkan kod program, dsb. Selepas penyelidikan dan pengoptimuman sedemikian, prestasi beberapa fungsi sistem sememangnya mungkin bertambah baik, tetapi kami masih mendapati bahawa pertanyaan data dan eksport beberapa senarai fungsi masih sangat perlahan, atau apabila jumlah data terus terkumpul, fungsi eksport senarai yang pada asalnya lebih cepat mempunyai juga Ia semakin perlahan dan perlahan. Kami mencuba pelbagai kaedah, tetapi akhirnya kami tidak dapat mencapai kelajuan prestasi sistem yang ideal.
Untuk meningkatkan prestasi sistem, kami mungkin mengambil inisiatif untuk belajar daripada pengalaman teknikal beberapa syarikat Internet, seperti konkurensi tinggi, prestasi tinggi, data besar, pemisahan baca-tulis dan penyelesaian lain, tetapi mendapati kami tidak mempunyai cara untuk mula. Kami akan berfikir bahawa ciri perniagaan sistem adalah berbeza. Keselarasan sistem ERP tidak tinggi, terutamanya disebabkan oleh kerumitan perniagaan Tahap gandingan pelbagai perniagaan adalah lebih tinggi daripada aplikasi Internet, menjadikannya sukar untuk berpecah Logik pertanyaan data adalah lebih rumit daripada itu daripada sistem Internet Data yang ditanya dari halaman senarai selalunya memerlukan Hasilnya boleh diperolehi dengan mengaitkan 4 atau 5 jadual. Beberapa laporan mempunyai lebih banyak lagi. Ditambah dengan sifat urus niaga pelbagai operasi perniagaan dan keperluan ketekalan data yang tinggi, kami sering terperangkap dan tidak dapat mengoptimumkan lagi sistem.
Pada suatu masa dahulu, saya kecewa dengan satu sebab atau yang lain, memikirkan bahawa sistem ERP adalah sangat istimewa dan tidak boleh diubati, tetapi kemudiannya. . .
Saya tidak lagi fikir begitu, nampaknya ada penyelesaian baru O(∩_∩)O haha~
Sebelum menerangkan pelan khusus, izinkan saya berkongsi pendapat saya terlebih dahulu. Pertama sekali, saya fikir sebelum kita membina sistem ERP, kita mesti mempunyai pemikiran Internet hari ini. Kami tidak lagi mahu membina sistem bersatu. Kita perlu membahagikan sistem yang besar kepada sistem yang kecil. Sistem kecil ini kemudiannya dibenarkan untuk berkomunikasi antara satu sama lain melalui antara muka sistem. Ini membentuk sistem yang besar, khususnya pemikiran Internet "teredar" dan "berorientasikan perkhidmatan". Biarkan sistem menjadi sistem yang sememangnya menyokong kebolehskalaan yang tinggi dari segi reka bentuk seni bina.
Bagaimana cara melakukannya? Secara khusus, pengurusan pesanan, pengurusan komoditi, pengeluaran dan perolehan, pengurusan gudang, pengurusan logistik dan pengurusan kewangan perlu dibahagikan kepada subsistem. Subsistem ini boleh direka bentuk dan dibangunkan secara bebas, dan antara muka data yang diperlukan oleh pelbagai subsistem lain boleh didedahkan kepada dunia luar. Setiap subsistem mempunyai pangkalan data yang berasingan. Malah subsistem ini boleh dibangunkan dan diselenggara oleh pasukan yang berbeza, menggunakan sistem teknikal yang berbeza dan pangkalan data yang berbeza. Daripada menyepadukan mereka ke dalam sistem besar dan komprehensif yang sama, pangkalan data yang besar dan komprehensif, seperti sebelumnya.
Apakah kelebihan sistem seni bina baharu?
Perkara pertama dan paling penting ialah menyelesaikan masalah prestasi sistem. Pada masa lalu, terdapat hanya satu tika pangkalan data, dan adalah mustahil untuk berkembang kepada berbilang kejadian supaya pengimbangan beban boleh dicapai dengan menambahkan lebih banyak tika pangkalan data apabila prestasi adalah terhad. Sesetengah orang mungkin mengatakan bahawa penyelesaian pemisahan baca-tulis boleh digunakan, tetapi disebabkan oleh ciri-ciri sistem ERP, penyelesaian ini selalunya tidak realistik. Contohnya, semasa mengendalikan inventori, anda tidak boleh membaca inventori daripada perpustakaan bacaan dan kemudian menulis inventori dalam pustaka penulisan. Oleh kerana replikasi tuan-hamba adalah sensitif masa, inventori bertulis tidak boleh ditulis ke pangkalan data hamba dengan segera. Terdapat banyak senario sedemikian dalam ERP. Apatah lagi perpustakaan penulisan tidak boleh diperluaskan, hanya boleh ada. Penyelesaian reka bentuk baharu adalah untuk memisahkan perpustakaan penulisan, dan setiap subsistem mempunyai pangkalan data sendiri.
Kedua, ia sangat mudah untuk dikemas kini, dan setiap subsistem wujud sebagai perkhidmatan mikro latar belakang. Terdapat projek web yang berasingan di bahagian hadapan, dan projek web ini memanggil antara muka perkhidmatan subsistem ini di latar belakang. Dengan reka bentuk ini, apabila subsistem perniagaan tertentu perlu dikemas kini, ia boleh dikemas kini secara bebas. Tidak seperti seni bina satu proses sebelumnya, kemas kini kecil memerlukan keseluruhan sistem dimulakan semula, menyebabkan sesi pengguna hilang dan pengguna log masuk semula. Reka bentuk semasa tidak akan menghadapi masalah ini.
Pandangan penggunaan fizikal sistem
Memisahkan lapisan aplikasi ialah pelaksanaan konsep seni bina "perkhidmatan mikro". Pisahkan seni bina proses tunggal yang besar dan komprehensif yang asal kepada aplikasi yang boleh digunakan secara bebas mengikut modul perniagaan untuk mencapai kemas kini dan peningkatan sistem yang lancar serta memudahkan pengembangan beban. Secara khusus, secara teknikal anda boleh menggunakan antara muka gaya yang tenang, atau anda boleh menggunakan rangka kerja seperti Dubbo dalam Java untuk memudahkan kerumitan pembangunan. Pelanggan web ERP atau klien mudah alih lain juga merupakan aplikasi berasingan yang bertindak sebagai lapisan pembentangan. Ia sangat nipis. Ia hanya menerima parameter dan memanggil antara muka pelbagai program perkhidmatan mikro lain di latar belakang untuk mendapatkan data yang perlu dipaparkan. Perkhidmatan mikro bertindak sebagai lapisan logik perniagaan Setiap perkhidmatan mikro ialah program yang boleh digunakan secara bebas dan menyediakan antara muka akses data luaran.
Perkhidmatan mikro boleh menggunakan pelbagai rangka kerja RPC yang popular, seperti dubbo, yang boleh menyokong protokol panggilan berbilang Http, TCP, dll. Rangka kerja ini memudahkan pengekodan Rangka kerja merangkum butiran komunikasi data yang mendasari, membolehkan pelanggan melaksanakan kaedah jauh seolah-olah ia adalah kaedah tempatan sama mudahnya.
Seni bina perkhidmatan mikro Dubbo juga menyokong tadbir urus perkhidmatan, pengimbangan beban dan fungsi lain. Ini bukan sahaja boleh meningkatkan ketersediaan sistem, tetapi juga secara dinamik meningkatkan prestasi lapisan aplikasi sistem. Contohnya, dalam pengurusan gudang, perniagaan pergudangan sangat sibuk dan menggunakan banyak sumber CPU dan memori. Kami boleh menambah mesin lain dan menggunakan perkhidmatan pengurusan gudang yang berasingan. Ini membolehkan keseluruhan sistem mempunyai dua perkhidmatan pengurusan gudang yang berfungsi pada masa yang sama untuk mengimbangi beban. Dan semua ini dilakukan secara automatik di pusat pendaftaran perkhidmatan, seperti Zookeeper.
Struktur perkhidmatan mikro secara semula jadi menyokong kemas kini sistem dan operasi naik taraf. Sebagai contoh, jika modul kewangan mempunyai keperluan baharu dan perlu pergi ke dalam talian, kami hanya perlu menggantikan perkhidmatan modul kewangan dan memulakannya semula. Ini tidak akan memberi banyak kesan kepada pengguna yang telah log masuk ke sistem Mereka tidak perlu log masuk ke sistem semula, dan penggunaan perkhidmatan modul lain tidak akan terjejas.
Kesempitan pangkalan data adalah kecederaan kekal pada sistem ERP. Sebilangan besar logik sambungan jadual pertanyaan data kompleks membanjiri keseluruhan sistem. Kunci kejayaan pemisahan pangkalan data menegak ialah cara mereka bentuk semula gandingan bersama pelbagai modul dalam lapisan data sistem. Jika anda boleh menyelesaikan masalah ini, kerosakan kekal boleh diselesaikan.
Mari kita lihat dulu masalah gandingan modul lapisan data biasa. Keperluan adalah untuk memaparkan inventori bahan, senarai medan: nombor bahan, nama bahan, kategori, gudang, kuantiti
Senarai bahan:
Jadual inventori:
Kategori dan jadual gudang ditinggalkan. . .
Jelas sekali, dalam pangkalan data tradisional, kami hanya memerlukan operasi gabungan yang mudah untuk mengaitkan kedua-dua jadual ini, dan mengaitkan kategori dan jadual gudang untuk menanyakan data yang kami inginkan. Tetapi kini dalam seni bina kami, jadual bahan dan jadual produk tidak berada dalam contoh pangkalan data yang sama, dan kami tidak boleh menggunakan operasi gabungan Jadi bagaimana kami merealisasikan keperluan?
Seni bina baharu hanya membenarkan kami mendapatkan data melalui antara muka perkhidmatan pihak satu lagi, dan tidak boleh mengaitkan secara langsung dengan pangkalan data peribadi perkhidmatan pihak satu lagi. Sekurang-kurangnya dari perspektif seni bina, dari perspektif berorientasikan perkhidmatan, anda tidak boleh mengakses pangkalan data perkhidmatan pihak lain secara langsung. Dalam kes ini, dengan mengandaikan bahawa subsistem modul web memanggil subsistem gudang untuk mendapatkan data, kita perlu mencipta kaedah perkhidmatan dalam modul gudang untuk memasang data. Kemudian ia dikembalikan ke subsistem web. Seperti yang ditunjukkan dalam rajah di bawah, kaedah pengurusan gudang terlebih dahulu mendapatkan kod bahan jadual inventori tempatan dan maklumat medan nama gudang jadual gudang Selepas halaman, ia akhirnya bersedia untuk mengembalikan 20 keping data ke modul Web. ID bahan dalam 20 keping data ini adalah Sebagai parameter untuk meminta subsistem modul komoditi, subsistem komoditi mengembalikan maklumat komoditi yang berkaitan dengan 20 ID bahan ini kepada modul pengurusan gudang, dan kemudian modul pengurusan gudang memasang semula dua data medan. nama bahan dan kategori yang diperlukan dalam senarai atas untuk mencapai keperluan akhir Data dikembalikan ke subsistem web.
Mungkin anda akan mengatakan bahawa ini terlalu menyusahkan Prestasi kaedah ini pastinya tidak setinggi sambungan langsung, dan ia tidak dapat menyelesaikan masalah prestasi. Nampaknya begini keadaannya, tetapi jika anda memikirkannya dengan teliti, dalam persekitaran di mana keselarasan sistem adalah rendah, volum data adalah kecil, dan perniagaan tidak sibuk, prestasi sememangnya tidak sepantas gabungan tradisional kaedah dalam satu data. Tetapi mari kita fikirkan kemudian! Reka bentuk seni bina semasa kami adalah untuk memisahkan satu pangkalan data kepada berbilang pangkalan data, dan setiap pangkalan data boleh dijalankan pada pelayan yang berasingan, supaya tekanan pada pangkalan data boleh dimuatkan pada masa hadapan. Secara keseluruhannya, ini akan menghalang pangkalan data daripada menjadi hambatan prestasi apabila perniagaan sibuk pada masa hadapan. Ia menarik hanya memikirkannya, bukan?
Pada masa ini, sesetengah orang akan bertanya lagi, bagaimana jika jumlah data sistem dan perniagaan akan menjadi lebih besar pada masa hadapan, malah membahagikannya kepada beberapa pangkalan data tidak mencukupi? Kaedah saya adalah berdasarkan pangkalan data berpecah, dan setiap perpustakaan boleh memisahkan bacaan dan penulisan, menggunakan caching, dsb. Anda juga boleh terus membahagikan subsistem kepada berbilang subsistem sekali lagi. Ia bergantung kepada betapa sibuknya modul perniagaan.
Sesetengah orang mungkin bertanya lagi, sesetengah logik pertanyaan senarai adalah sangat kompleks dan melibatkan lebih daripada sepuluh jadual Jika data dipecah mengikut kaedah di atas, ia akan menjadi bencana! Ya, kamu betul. Dalam kes ini, rancangan saya adalah untuk menggunakan pertanyaan data peringkat laporan yang lebih kompleks ini untuk memaparkan keperluan dan saya boleh membina sistem laporan yang berasingan. Reka bentuk pangkalan data laporan menggunakan pendekatan gudang data. Untuk prestasi bacaan yang lebih tinggi, kami boleh mereka bentuk jadual pangkalan data ke dalam banyak medan berlebihan, yang merupakan reka bentuk anti-paradigma, dan mencipta banyak indeks gabungan.
Kunci kejayaan sistem ini ialah penyegerakan data dan perpustakaan perniagaan sistem ERP utama. Secara amnya, anda boleh menulis program penyegerakan berjadual untuk menjana secara langsung data akhir atau perantaraan yang diperlukan untuk paparan laporan melalui pemilihan, transformasi, dsb. data dalam sistem perniagaan utama ERP untuk memudahkan pertanyaan berkaitan. Sistem pelaporan juga boleh direka bentuk menggunakan seni bina perkhidmatan mikro. Seperti yang ditunjukkan dalam gambar di bawah:
Jika data yang diperlukan untuk laporan memerlukan masa nyata, kami boleh membenarkan sistem ERP untuk mencetuskan permintaan penyegerakan data semasa operasi perniagaan dan menyegerakkannya ke perpustakaan laporan dalam masa nyata.
Sesetengah orang mungkin bertanya lagi, banyak operasi dalam sistem ERP memerlukan transaksi. Bagaimanakah anda mencapai transaksi dan memastikan konsistensi data selepas memisahkan sistem?
Ini soalan yang bagus, dan ia juga soalan terakhir yang saya fikirkan sebelum saya memutuskan untuk menulis artikel ini. Dalam seni bina perkhidmatan mikro, bukan mudah untuk melaksanakan transaksi yang membanggakan perkhidmatan, sekurang-kurangnya tidak semudah aplikasi tempatan yang menggunakan transaksi pangkalan data tempatan, dengan prestasi yang cekap dan konsistensi data yang baik.
Mungkin anda pernah mendengar tentang konsep urus niaga teragih. Terdapat dua senario Satu menggunakan pelbagai pangkalan data dalam satu aplikasi Untuk memastikan konsistensi data, transaksi yang diedarkan perlu digunakan. Terdapat satu lagi situasi yang khusus untuk seni bina kami. Transaksi teragih dalam persekitaran perkhidmatan mikro, khususnya, menggunakan analogi. Operasi pembelian dan pergudangan direka dalam perkhidmatan pengurusan gudang. Selepas pergudangan, kuantiti pergudangan dalam pesanan belian dalam subsistem perolehan perlu dikemas kini. Proses ini memerlukan ketekalan data, iaitu kuantiti dalam jadual inventori ditulis ke dalam jadual inventori selepas pesanan pembelian berjaya dimasukkan ke dalam gudang, dan kuantiti dalam jadual pesanan pembelian perlu dikemas kini pada masa yang sama. Kami tidak boleh terus mengakses pangkalan data dalam perkhidmatan perolehan dalam perkhidmatan gudang Kami mesti menggunakan antara muka perkhidmatan yang disediakan oleh perkhidmatan perolehan. Jika ya, bagaimanakah kita boleh memastikan konsistensi data? Kerana kemungkinan besar jadual inventori ditulis dengan jayanya, tetapi panggilan ke perkhidmatan perolehan untuk menulis data pesanan pembelian gagal. Ia mungkin disebabkan oleh masalah rangkaian, jadi data tidak konsisten.
Dalam teknologi urus niaga yang diedarkan, terdapat pepatah untuk mencapai konsistensi akhirnya, yang bermaksud bahawa selagi saya dapat memastikan bahawa data di kedua-dua pihak akhirnya konsisten, ia adalah baik, dan transaksi tidak perlu digunakan. Jadi ada rancangan. Sebagai contoh, apabila subsistem gudang memproses pembelian dan pergudangan, ia perlu menambah data pesanan pergudangan dan mengemas kini data inventori dan jadual lain. Berbilang jadual ini semuanya berada dalam subsistem gudang, dan kami boleh menggunakan transaksi setempat untuk memastikan ketekalan data jadual dalam subsistem gudang. Kemudian hubungi subsistem perolehan untuk mengemas kini kuantiti pergudangan dalam pesanan pembelian. Untuk mengelakkan proses ini daripada terganggu secara tiba-tiba dan menyebabkan panggilan gagal, kami mempertimbangkan untuk menambah perisian tengah baris gilir mesej seperti ActiveMQ. Jika antara muka gagal dikembalikan, kami akan menulis permintaan pemprosesan kepada MQ Selepas subsistem perolehan kembali normal, MQ akan memberitahu subsistem perolehan untuk memproses operasi kemas kini. Memandangkan tiada lagi pemberitahuan selepas mesej digunakan, pengecualian berlaku semasa pemprosesan subsistem perolehan, menyebabkan kemas kini gagal. Masalah perlu ditulis ke perpustakaan log tempatan untuk memberitahu pentadbir untuk pampasan seterusnya pemprosesan. Dengan cara ini, pelbagai kaedah boleh digunakan untuk mencapai ketekalan akhir data. Walaupun kedengarannya agak mengelirukan, ini adalah penyelesaiannya. Tiada lagi yang lebih baik. Atau selepas kemas kini gagal, hubungi subsistem gudang sekali lagi untuk melancarkan semula resit gudang dan data inventori untuk mencapai konsistensi akhir! Seperti yang ditunjukkan dalam gambar:
Saya sangat berbesar hati dapat berkongsi ilmu dan pengalaman dengan semua orang Kerana perkongsian tanpa mementingkan diri semua orang yang kita boleh berkembang dan maju. Saya jarang berkongsi perkara dalam beberapa tahun kebelakangan ini, kadang-kadang kerana saya sangat sibuk di tempat kerja dan tidak masa untuk menulis apa-apa, kadang-kadang kerana saya malas atau tidak mempunyai perkara baru untuk dikongsi dengan semua orang. Akhir kata, saya harap semua pihak akan tegur dan perbetulkan kekurangan saya dalam perkongsian ini, agar kita sama-sama maju!
Atas ialah kandungan terperinci Bina sistem ERP pengedaran & perkhidmatan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
