Pengenalan

Saya sentiasa percaya bahawa PHP kini telah berkembang ke dalam bidang kejuruteraan. Pada masa lalu, pembangun PHP menganggap kelajuan sebagai keindahan, dan kelajuan dan skala sentiasa bercanggah. Projek PHP hari ini, terutamanya projek yang lebih besar, telah berkembang secara beransur-ansur ke tahap yang memerlukan kedua-dua kejuruteraan dan skala. Kejuruteraan kod bermakna berkembang menjadi seni bina yang semakin kompleks. Untuk seni bina yang kompleks, perkhidmatan mikro selalunya merupakan pilihan yang baik.

Saya memerlukan soalan ini dalam projek baru-baru ini. Saya perlu membangunkan perkhidmatan peta Perkhidmatan ini sudah tentu bukan dalam bentuk perpustakaan kelas yang mudah, tetapi mempunyai pangkalan data sendiri dan antara muka perkhidmatannya sendiri. Dalam kes ini, pilihan terbaik ialah penservitan. Sudah tentu, terdapat banyak cara untuk melakukan perkhidmatan, seperti Thrift, HTTP, dll. Tetapi saya menilai persekitaran jabatan semasa PHP adalah bahasa arus perdana, dan kemajuan projek saya juga agak ketat Pada pandangan saya, Thrift, HTTP dan kaedah lain semuanya menggunakan protokol rangkaian untuk mencapai penyahgandingan perkhidmatan penyelesaian. Saya fikir pendekatan ini tidak perlu apabila projek itu tidak jelas dalam keadaan kritikal. Kelemahan menggunakan penservitian protokol rangkaian ialah ia memperkenalkan kerumitan yang ketara. Kerumitan ini selalunya bermakna pelaburan dalam tenaga kerja, sumber material dan masa. Jadi saya berharap dapat menyediakan "perpustakaan kelas perkhidmatan" dalam bahasa PHP untuk pembangunan.

Apa yang saya fikirkan ialah Komposer PHP.

Pengubahsuaian Komposer

Mencipta pustaka perkhidmatan

Pertama, saya perlu menukar "perpustakaan perkhidmatan" saya daripada aplikasi Saya (bernama xxx/main1) adalah bebas Untuk kebebasan ini, saya tidak memilih untuk mencipta direktori dalam aplikasi (malah, saya terfikir untuk membuat direktori seperti Perkhidmatan). Namun, jika kod tersebut digandingkan dengan program perniagaan, saya merasakan kerana kemalasan manusia, sukar untuk mengawal diri dari awal hingga akhir dan berkeras untuk tidak menggunakan pelbagai fungsi mudah dalam aplikasi. Jadi pilihan saya adalah untuk mencipta projek baharu dalam repositori Git dan namakannya xxx/mapService.

composer.json

Kini terdapat dua projek Git (xxx/main1 dan xxx/mapService saya menambah pernyataan berikut pada fail composer.json dalam main1:

Composer.json dalam mapService adalah seperti berikut:

Konfigurasi ini memberitahu projek main1 bahawa alamat Git mapService perlu digunakan versi.

Sudah tentu anda perlu memberi perhatian kepada perkara berikut:

• dev-master bermaksud menggunakan secara langsung cabang induk mapService. Jika mapService mempunyai teg lain, anda boleh menggunakan maklumat teg di sini
• repositori ialah alamat projek
• Perkhidmatan yang saya ada di sini diletakkan pada GitLab yang dibina oleh syarikat kami
• Ruang nama folder src di bawah mapService ialah xxxx\xxxx\MapService\ dan menyokong PSR-4
• mapService menggunakan illuminate/database

Akhir sekali gunakan kemas kini komposer - vvv boleh memuat turun mapService yang kami perlukan dan letakkan dalam direktori vendor.

Kemas kini dan pengubahsuaian

Editor kami kini berada dalam projek utama1 Jika kami telah mengedit dan mengubah suai projek mapService, dan ingin menggabungkannya ke dalam cabang induk mapService , masukkan terus direktori vender/xxx/mapService dan lakukan operasi yang sepadan dengan Git. Ini membenarkan pengubahsuaian kod langsung.

Konfigurasi bebas

Gabungan struktur ini hanyalah langkah pertama dalam perarakan panjang. Apa yang lebih penting kemudian ialah apabila menulis perkhidmatan ini, saya perlu sentiasa ingat untuk tidak menggunakan segala-galanya dalam main1, untuk mengekalkan kebebasan mapService (kemerdekaan adalah salah satu syarat yang diperlukan untuk penservitan). Sebagai contoh, masalah pertama yang saya hadapi ialah fail konfigurasi perlu bebas.

Kaedah pelaksanaan saya ialah untuk mencipta kelas Config secara langsung dalam mapService, dan konfigurasi ditulis terus dalam kelas ini.

Saya sentiasa merasakan bahawa pelaksanaan fail konfigurasi ini agak mengecewakan, kerana dengan cara ini, fail konfigurasi ini memasuki perpustakaan Git. Tetapi saya benar-benar tidak dapat memikirkan penyelesaian yang lebih baik. Terdapat cara dalam Laravel untuk mencipta Config dalam folder konfigurasi Laravel dengan melaksanakan ServiceProvider, tetapi kaedah ini hanya digunakan untuk Laravel. Tiada kesejagatan. Sebaliknya, saya fikir pangkalan data yang digunakan oleh perkhidmatan itu sendiri adalah sebahagian daripada perkhidmatan itu, dan ia nampaknya tidak ada kena mengena dengan meletakkannya dalam perpustakaan Git perkhidmatan.

Struktur direktori

Struktur direktori adalah seperti di atas

• Configs menyediakan fail konfigurasi
• Kontrak menyediakan protokol antara muka
• Pengecualian memberikan pengecualian
• Sokongan menyediakan kaedah pihak ketiga atau perpustakaan kelas
• Model menyediakan interaksi dengan pangkalan data
• Pelaksanaan Node.php Antara muka khusus

Perkara yang paling penting tentang perkhidmatan ialah protokol antara muka. Jadi buat folder Kontrak dan antara muka perkhidmatan yang disediakan.

Pengendalian pengecualian antara muka harus cuba menggunakan pengecualian dan bukannya kod ralat untuk interaksi. Dan pengecualian ini harus disesuaikan sebanyak mungkin. Dengan cara ini, terdapat kemungkinan pemprosesan bersatu di peringkat atas.

Berfikir

Saya meletakkan model seni bina ini sebagai model berorientasikan perkhidmatan pada tahap kod PHP. Senario yang boleh digunakan hendaklah:

• Penservitian yang dirancang kemudiannya
• Senario di mana kedua-dua tenaga manusia dan pemikiran pada peringkat awal berharap dapat mengekalkan pembangunan pesat

dan Git Perbezaan antara SubTree dan SubModule

Malah, ketiga-tiga kaedah ini semuanya menggunakan satu projek sebagai perpustakaan kelas untuk projek lain. SubTree dan SubModule ialah penyelesaian Git. Komposer ialah penyelesaian untuk bahasa PHP Selain fungsi menambah projek ke projek lain, ia juga menyediakan penyelesaian seperti menambah versi dan penyelesaian pergantungan. Jika projek anda dalam PHP, maka menggunakan Composer sudah pasti merupakan pilihan yang lebih baik.

Servis protokol kemudiannya

Jika mapService saya mahu menjadi perkhidmatan protokol kemudian, maka projek mapService boleh dipermudahkan menjadi SDK Untuk logik perniagaan lapisan atas. Hanya gunakan kemas kini komposer untuk mengemas kini.

Pendaftaran dan penemuan perkhidmatan

Apa yang dipanggil "perpustakaan perkhidmatan" yang saya panggil di sini tidak menyelesaikan masalah pendaftaran perkhidmatan Saya tidak tahu berapa banyak projek menggunakan perkhidmatan saya. Ini mungkin memerlukan kerja proses tambahan.