8 kesalahan pengkomputeran yang diedarkan untuk pemaju PHP-tutorial php-php.cn

The 8 Fallacies of Distributed Computing for PHP Developers

lapan salah faham yang pemaju PHP perlu berhati -hati dalam bangunan yang diedarkan aplikasi Kesalahpahaman ini penting bagi pemaju PHP kerana kami membina aplikasi yang diedarkan setiap hari: mashup, aplikasi yang berinteraksi dengan perkhidmatan sabun dan rehat, pengesahan pengguna melalui Facebook, Google atau Twitter API, mengambil maklumat dari pangkalan data jauh dan perkhidmatan cache, dan banyak lagi. Apa yang kita bina adalah aplikasi pengkomputeran yang diedarkan. Oleh itu, adalah penting untuk memahami lapan kesalahpahaman ini dan implikasinya.

Walaupun penambahbaikan yang ketara dalam kebolehpercayaan rangkaian dan jalur lebar, faktor -faktor ini tidak sempurna. Pemaju mesti meramalkan kegagalan yang berpotensi dan menggabungkan strategi pemprosesan yang sepadan dalam reka bentuk dan penggunaan aplikasi.

Cybersecurity sentiasa menjadi isu penting, dan pemaju mesti mengutamakan amalan keselamatan yang baik dan menilai langkah -langkah keselamatan rakan kongsi mereka. Pemaju harus bersedia untuk menangani perubahan topologi, kemungkinan menukar pembekal, dan kos yang berkaitan dengan penghantaran data. Mereka juga harus mengambil pendekatan yang fleksibel yang dapat mengendalikan pelbagai pangkalan data dan sumber data tanpa mengandaikan bahawa rangkaian adalah isomorfik.

Rangkaian boleh dipercayai

ini jelas tidak betul. Walaupun latency rangkaian telah menurun dan jalur lebar telah meningkat dengan ketara sejak tahun 1995, adalah salah untuk mengatakan bahawa rangkaian itu boleh dipercayai. Katakan kami membina aplikasi mudah yang tidak menggunakan terlalu banyak perkhidmatan - aplikasi PHP yang menggunakan MySQL sebagai backend. Nampaknya tidak ada masalah. Walau bagaimanapun, katakan kami kemudian memutuskan untuk menggunakan penyedia hosting MySQL seperti Xeround untuk memenuhi keperluan pangkalan data kami. Walaupun dengan skalabiliti yang baik dan ketersediaan yang tinggi, bagaimana jika ada masalah dengan sistem mereka? Bagaimana jika infrastruktur mereka dilanda serangan DDOS atau mempunyai downtime kerana isu dalaman? Kami sering mendengar kira -kira 99.999% uptime, tetapi itu masih belum 100%. Dengan lonjakan perkhidmatan dan jalur lebar yang biasanya sangat tersedia hari ini, mudah dilupakan bahawa tiada apa yang sempurna. Bagaimana anda mempertimbangkan kegagalan perkhidmatan dalam permohonan anda?

kelewatan adalah sifar

Walaupun kelewatan mungkin sangat rendah, ia memang jauh lebih rendah daripada beberapa tahun yang lalu, ia tidak akan menjadi sifar. Mengutip Arnon Rotem-Gal-Oz dalam artikelnya "Penjelasan terperinci tentang salah faham pengiraan yang diedarkan": Pada kelajuan kira-kira 300,000 km/s (3.6 * 10E12 Teraangstrom/dua minggu), walaupun pemprosesan dilakukan dalam masa nyata, ping dari Eropah ke Amerika Syarikat dan kemudian mengembalikan akan mengambil sekurang-kurangnya 30 milisekonds.

Adakah ini perkara yang buruk? Bercampur. Bergantung kepada struktur aplikasi kami dan sumber yang ada, kami dapat mengurangkan masalah latensi. Kami boleh menjadi tuan rumah aplikasi kami menggunakan perkhidmatan seperti Amazon Web Services dan memanfaatkan S3 supaya data kami terletak di beberapa wilayah di seluruh dunia, membawa lebih dekat kepada pengguna akhir kami dan mengurangkan latensi untuk aplikasi di web. Tetapi walaupun kita dapat mengurangkan latensi, kita tidak dapat menghapuskannya. Kita boleh mengambil pelbagai kaedah dan seni bina untuk mengurangkan kesannya kepada kita, tetapi tidak kira apa yang kita lakukan, ia akan sentiasa berada di sana. Adakah anda menganggap ini semasa merancang permohonan anda?

jalur lebar tanpa had

Adakah jalur lebar itu benar -benar tidak terhad? Jika ya, apakah harga Infinite? Apabila kita menganggap bahawa rangkaian semakin bergerak ke arah mudah alih, semua yang lama dilahirkan semula. Saya tidak mengatakan bahawa kami bermula dengan kelajuan akses dial-up, rangkaian 4G yang dikemas kini jauh lebih cepat daripada rangkaian 2G dan 3G sebelumnya. Walau bagaimanapun, walaupun kadar data puncak mereka kini lebih rendah daripada sambungan jalur lebar standard. Selain itu, dengan populariti jalur lebar mudah alih, bilangan pengguna berpotensi yang ingin menggunakan perkhidmatan kami (kami semua mahu menjadi popular, sekurang -kurangnya beberapa kejayaan Facebook) berkembang pada kadar yang membimbangkan. Pertimbangkan statistik ini dari mobithinking:

Terdapat 5.9 bilion pengguna mudah alih.
1.2 bilion pengguna rangkaian mudah alih dengan liputan 3G.
Peranti mudah alih menyumbang 8.49% klik global.

Memandangkan ini, adalah adil untuk mengatakan bahawa walaupun kadar jalur lebar dan penembusan mereka di seluruh dunia semakin meningkat, kadar pertumbuhan pengguna mengimbangi ini. Selanjutnya, dengan fleksibiliti besar yang disediakan oleh jalur lebar mudah alih, penggunaan perkhidmatan sementara yang jelas secara semulajadi muncul. Adakah anda bersedia untuk beban yang berpotensi besar dalam perkhidmatan ini? Bolehkah anda mengendalikan puncak yang disebabkan oleh ketersediaan ini?

Cybersecurity

Saya fikir ia adil untuk mengatakan bahawa ia adalah, dan akan sentiasa salah, tanpa terlalu terperinci. Jika anda mempunyai sebarang soalan, mungkin anda harus bercakap dengan ahli LinkedIn atau Eharmony. Apabila kami merancang dan menggunakan aplikasi kami, berapa banyak usaha yang kami masukkan ke dalam lokasi yang dihoskan aplikasi (seperti Rackspace, Pagodabox, atau CloudControl) dan dalam reka bentuk aplikasi itu sendiri? Menurut SecurityAffairs, Laporan Prolexic:

lalu lintas paket yang mensasarkan industri perkhidmatan kewangan meningkat sebanyak 3,000% bulan ke bulan.
Jumlah data trafik yang berniat jahat untuk industri perkhidmatan kewangan pada suku keempat tahun 2011 adalah 19.1TB dan 14 bilion paket, peningkatan pada tahun 2012.
Pada tahun 2012, jumlah data yang dikenal pasti dan dikurangkan adalah 65TB, dan paket data adalah 1.1 trilion, 80 kali pada tahun 2011.

Memandangkan rangkaian tidak selamat, kita perlu memastikan kita menggunakan amalan keselamatan yang baik sebagai satu perkara yang sudah tentu. Memandangkan banyak nasihat yang baik dari blog Chris Shiflett, Keselamatan PHP Essential, PHP Security Alliance, dan banyak lagi, sukar untuk tidak tahu bagaimana untuk memasukkan keselamatan ke dalam teras aplikasi kami dan mengapa. Apakah amalan keselamatan anda? Adakah anda telah menilai vendor yang anda gunakan?

kekal tidak berubah

tidak? Betul? Ia tidak akan berubah, atau adakah kita tidak tahu? Apabila kita menjadi tuan rumah aplikasinya kepada orang lain, kita tidak tahu. Jika penyedia menyusun semula pusat data mereka, menaik tarafnya, tweak, topologi berubah untuk apa jua sebab. Memandangkan kenaikan penggunaan telefon pintar yang disebutkan di atas, topologi sering berubah. Dari perspektif pengguna dan penyedia, topologi berubah hampir setiap hari! Sekiranya topologi berubah dan perkhidmatan luaran yang bergantung kepada tidak lagi boleh diakses, mengakibatkan, sebagai contoh, ketidakupayaan untuk mengakses pangkalan data, maka ini pasti masalah. Walau bagaimanapun, jika terdapat perubahan dalam pembekal kami dan aplikasi terus dijalankan, maka itu mungkin tidak menjadi masalah. Sudah tentu, mudah untuk menulis aplikasi kecil dan dihoskan dalam konfigurasi mudah. Tetapi aplikasi akan berubah, terutama yang semakin popular. Adakah anda menganggap perubahan topologi dalam reka bentuk anda? Bagaimana anda menerangkan atau menangani kegagalan dalam reka bentuk aplikasi dan reka bentuk penggunaan?

Hanya satu pentadbir

"tetapi aplikasi saya dihoskan oleh penyedia perkhidmatan tunggal. Mereka menyediakan sistem operasi, pangkalan data dan sokongan pelayan web," kata anda. Ok, dengan anggapan itu permohonan anda, adakah ia hanya satu pentadbir? Sekiranya ada hanya satu pentadbir, adakah anda benar -benar percaya bahawa pembekal akan mengendalikan permohonan anda? Jika mereka sakit atau bercuti, saya tidak suka memikirkan apa yang akan berlaku. Sering kali, terdapat sekurang -kurangnya beberapa pentadbir, walaupun setiap ketajaman teknikal dan lebih luas pentadbir mungkin berbeza -beza. Strategi, seperti pengesanan pencerobohan rangkaian dan dasar keselamatan lain, perlu dibangunkan, tetapi tidak ada jaminan bahawa mereka semua akan mematuhi ketelitian yang sama dan ketekunan wajar. Memandangkan banyak penyedia hosting yang tersedia hari ini dan sedikit masa yang diperlukan untuk mengemas kini rekod DNS, kami mempunyai banyak pilihan dan fleksibiliti, jika satu penyedia tidak memenuhi keperluan dan harapan kami, kami boleh beralih kepada yang lain. Pernahkah anda mempertimbangkan bagaimana ini akan mempengaruhi anda? Bagaimana jika anda tidak dapat menukar pembekal dengan mudah? Bagaimana jika anda mempunyai sebilangan besar penguncian vendor, atau kos mudah alih yang tinggi? Bagaimana jika seni bina aplikasi anda tidak cukup fleksibel? Apakah langkah -langkah yang boleh anda lakukan untuk mengurangkan risiko seperti ini?

Kos penghantaran adalah sifar

Seperti semua kenyataan setakat ini, kesahihan ini tidak mungkin. Jika pelayan yang menyokong aplikasi kami terletak di rak yang sama di pusat data yang sama, kos pemindahan boleh dikurangkan, tetapi dari segi kos masa. Bagaimana dengan kos wang? Ya, kita boleh menaikkan dan turun tak terhingga seperti yang diperlukan, dan kita dapat menyimpan data aplikasi kami di antara pusat data geo yang disebarkan supaya ia hampir dengan pengguna akhir kita yang mungkin, tetapi pada harga apa? Apakah komposisi seni bina permohonan atau perkhidmatan anda? Adakah hampir sifar dari segi kos atau masa? Sekiranya anda dapat mengurangkannya, adakah ia akan menambah yang lain?

isomorphism rangkaian

Tidak seperti salah faham lain, saya fikir sebagai pemaju PHP, kita dilahirkan untuk memahami ini. Kami menganjurkan aplikasi kami di pelayan Windows, Linux, Solaris, BSD dan Mac OS X. Kami menggunakan MySQL, SQLServer, SQLite, PostgreSQL, MongoDB, Hadoop, dan Oracle untuk menyimpan data. Kami menggunakan perkhidmatan luaran melalui XML atau JSON yang memerlukan antara muka yang berbeza. Sebagai sistem multi-operasi dan komuniti pelbagai perkhidmatan, kita boleh mengatakan bahawa sejak hari-hari awal, kita tidak pernah menjangkakan rangkaian isomorfik. Tetapi soalan masih perlu ditanya, adakah kaedah anda fleksibel? Bolehkah anda mengendalikan pelbagai pangkalan data dan sumber data? Adakah anda menggunakan corak reka bentuk yang relevan, seperti kilang abstrak, untuk mengambil data dari pelbagai sumber dan jenis menggunakan antara muka kod telus? Atau jika anda perlu melakukan sesuatu semudah beralih dari XML ke JSON, adakah kod anda akan pecah?

Kesimpulan

Saya fikir sebagai pemaju PHP, lapan salah faham pengkomputeran yang diedarkan adalah sama pentingnya seperti dahulu. Memandangkan banyak maklumat dan sumber yang tersedia, kami berada dalam kedudukan yang sangat berfaedah untuk memahami mereka dan mengurangkan risiko yang timbul. Apa pendapat anda? Adakah anda menganggapnya semasa membangunkan aplikasi dan perkhidmatan? Bagaimanakah anda berfikir bahawa lapan salah faham ini mempengaruhi permohonan anda?

(gambar tetap tidak berubah)

Atas ialah kandungan terperinci 8 kesalahan pengkomputeran yang diedarkan untuk pemaju PHP. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!