Evolusi seni bina dan penerokaan reka bentuk Ele.me

Pengenalan

Model industri dan cepat menghasilkannya. "Cepat" adalah keutamaan pertama, dan tidak perlu menghabiskan terlalu banyak tenaga untuk reka bentuk seni bina. Hanya apabila tapak web memasuki tempoh pengembangan, ia perlu melabur lebih banyak tenaga dalam seni bina untuk membawa trafik tapak web apabila ia meletup. Ele.me telah ditubuhkan selama 8 tahun, dan kini jumlah pesanan harian telah melebihi 9 juta Kami juga mempunyai struktur laman web yang agak lengkap.

1. Infrastruktur laman web

Pada masa awal, kami menggunakan rangka kerja yang memudahkan untuk mengembangkan SOA. Kami menggunakan rangka kerja SOA untuk menyelesaikan dua perkara:

1. Pembahagian kerja dan kerjasama

Pada masa awal laman web, mungkin hanya ada 1 hingga 5 pengaturcara Pada masa itu, semua orang boleh sibuk dengan perkara yang sama. Mereka semua memahami kerja masing-masing dan sering menyelesaikan masalah dengan "menjerit".

Tetapi apabila bilangan orang bertambah, kaedah ini jelas tidak boleh dilaksanakan. Adalah mustahil untuk seseorang mengemas kini kod dan kemudian meletakkan semua kod orang lain dalam talian semula, bukan? Oleh itu, kita mesti mempertimbangkan isu pembahagian kerja dan kerjasama.

2. Pengembangan pesat

Pada masa lalu, jumlah pesanan mungkin berkisar antara 1k hingga 10,000 Walaupun telah meningkat sebanyak 10 kali ganda, jumlah keseluruhannya tidak terlalu tinggi, dan tekanan pada laman web tidak begitu hebat. Apabila jumlah pesanan benar-benar berubah dari 100,000 hingga 1,000,000, dan dari 1,000,000 hingga 2,000,000, bilangan itu mungkin hanya berkembang 10 kali ganda, tetapi ia merupakan satu cabaran besar kepada seni bina keseluruhan tapak web.

Latar belakang kami ialah kami telah berkembang daripada 1 juta pada tahun 2014 kepada 9 juta sekarang Pasukan teknikal telah berkembang daripada lebih daripada 30 orang pada mulanya kepada satu pasukan lebih daripada 900 orang sekarang. Pada masa ini, pembahagian kerja dan kerjasama adalah satu cabaran yang besar. Pembahagian dan penyepaduan perkhidmatan dan pembahagian dan penyepaduan pasukan memerlukan sistem rangka kerja untuk menyokong mereka. Ini juga merupakan peranan rangka kerja SOA.

Lihat situasi semasa kami Bahagian tengah adalah keseluruhan sistem seni bina kami, dan bahagian kanan adalah beberapa asas yang berkaitan dengan penservitan, termasuk komponen atau perkhidmatan asas.

Mari kita bercakap tentang bahasa terlebih dahulu.

Pengasasnya adalah semua pelajar kolej memulakan perniagaan mereka sendiri, jadi sudah tentu Python adalah pilihan pertama yang baik. Setakat ini, Python juga merupakan pilihan yang baik, tetapi mengapa kita perlu mengembangkan ke Java dan Go?

Ramai orang boleh menulis Python, tetapi tidak ramai orang boleh melakukannya dengan baik. Apabila perniagaan berkembang, lebih ramai pembangun diperlukan. Dengan mengambil kira persekitaran ekologi Jawa yang matang dan ekosistem Go yang baru muncul, kami akhirnya memilih ekosistem di mana Python, Java dan Go wujud bersama dalam pelbagai bahasa.

WebAPI terutamanya melaksanakan beberapa operasi biasa yang tidak berkaitan dengan logik perniagaan seperti pemunggahan HTTPS, pengehadan semasa dan pengesahan keselamatan.

Service Orchestrator ialah lapisan orkestrasi perkhidmatan yang merealisasikan penukaran protokol rangkaian dalaman dan luaran serta pengagregatan dan penyesuaian perkhidmatan melalui konfigurasi.

Di sebelah kanan gambar rajah seni bina terdapat beberapa sistem tambahan yang mengelilingi rangka kerja berorientasikan perkhidmatan ini, seperti sistem Kerja untuk melaksanakan tugas secara kerap. Kami mempunyai hampir 1,000 perkhidmatan Bagaimana kami memantau sistem ini? Jadi mesti ada sistem pemantauan. Apabila terdapat hanya lebih daripada 30 orang pada mulanya, kami lebih baik berlari ke mesin untuk mencari log Tetapi apabila terdapat lebih daripada 900 orang, anda tidak boleh pergi ke mesin untuk mencari log yang kami perlukan sistem pembalakan berpusat. Sistem lain tidak akan diterangkan satu persatu di sini.

Rom tidak dibina dalam sehari, infrastruktur adalah proses evolusi. Tenaga kita terhad, jadi apa yang perlu kita lakukan dahulu?

2. Servis berpecah

Apabila laman web menjadi lebih besar, struktur asal tidak dapat bersaing dengan rentak pembangunan. Perkara pertama yang perlu kita lakukan ialah:

Pisah Repo besar kepada Repo kecil, bahagikan perkhidmatan besar kepada perkhidmatan kecil dan bahagikan perkhidmatan asas terpusat kami kepada mesin fizikal yang berbeza.

Perpecahan perkhidmatan sahaja mengambil masa lebih setahun untuk disiapkan iaitu proses yang agak panjang.

Dalam proses ini, kita mesti mempunyai definisi API yang baik. Kerana apabila API anda berada dalam talian, kos untuk membuat beberapa pengubahsuaian adalah agak tinggi. Akan ada ramai orang yang bergantung pada API anda, dan banyak kali anda tidak tahu siapa yang bergantung pada API anda Ini adalah masalah besar.

Kemudian abstrak beberapa perkhidmatan asas. Banyak perkhidmatan asal sebenarnya digabungkan dalam kod perniagaan asal. Sebagai contoh, ambil perniagaan pembayaran Apabila perniagaan itu sangat mudah, kod berganding rapat tidak penting Tetapi apabila semakin banyak perniagaan yang berkembang memerlukan perkhidmatan pembayaran, adakah anda perlu melakukan satu untuk setiap perniagaan (contohnya, fungsi pembayaran)? ? Oleh itu, kita perlu mengekstrak perkhidmatan asas ini, seperti perkhidmatan pembayaran, perkhidmatan SMS, perkhidmatan tolak, dll.

Perkhidmatan pembongkaran nampaknya sangat mudah dan tidak bernilai, tetapi inilah yang perlu kita lakukan dari awal. Malah, dalam tempoh ini, semua seni bina sebelumnya boleh ditangguhkan, kerana jika anda tidak membuat pelarasan seni bina, orang tidak akan mati, tetapi jika anda tidak membongkar perkhidmatan, orang akan benar-benar mati.

Pemecahan perkhidmatan mestilah proses yang panjang, tetapi ia sebenarnya adalah proses yang sangat menyakitkan dan memerlukan banyak kejuruteraan sistem sistem sokongan.

3. Sistem pelepasan

Pelepasan adalah faktor ketidakstabilan terbesar. Banyak syarikat mempunyai had yang ketat pada tetingkap masa keluaran, contohnya:

• Hanya dua hari seminggu untuk mengepos;
• Sama sekali tidak dipos pada hujung minggu;
• Pengeposan sama sekali tidak dibenarkan semasa tempoh perniagaan puncak;
• Tunggu...

Kami mendapati bahawa masalah terbesar dengan penerbitan ialah tiada operasi rollback boleh laku yang mudah selepas penerbitan. Siapa yang akan melaksanakan operasi rollback? Bolehkah penerbit melaksanakannya, atau adakah ia memerlukan orang yang berdedikasi untuk melaksanakannya? Jika ia adalah penerbit, penerbit tidak bekerja dalam talian 24 jam sehari Apakah yang perlu saya lakukan jika ada masalah dan saya tidak dapat mencari seseorang? Jika terdapat orang yang berdedikasi untuk melakukan pemulangan semula, dan tiada operasi pemulangan semula yang mudah dan bersatu, maka orang ini perlu biasa dengan kod penerbit, yang pada dasarnya tidak boleh dilaksanakan.

Jadi kami memerlukan sistem penerbitan Sistem penerbitan mentakrifkan operasi rollback bersatu Semua perkhidmatan mesti mengikut operasi rollback yang ditakrifkan oleh sistem penerbitan.

Adalah keperluan wajib bagi semua orang untuk menyambung ke sistem penerbitan dalam Ele.me Semua sistem mesti disambungkan ke sistem penerbitan. Rangka kerja sistem penerbitan adalah sangat penting. Perkara ini sebenarnya sangat penting kepada syarikat dan perlu dipertimbangkan dalam barisan keutamaan pertama.

4. Rangka Kerja Perkhidmatan

Langkah seterusnya ialah rangka kerja perkhidmatan Ele.me, yang membahagikan Repo besar kepada Repo kecil dan perkhidmatan besar kepada perkhidmatan kecil untuk menjadikan perkhidmatan kami sebebas mungkin Ini memerlukan satu set rangka kerja Perkhidmatan yang diedarkan untuk menyokong.

Rangka kerja perkhidmatan yang diedarkan termasuk pendaftaran perkhidmatan, penemuan, pengimbangan beban, penghalaan, kawalan aliran, pemutus litar, degradasi dan fungsi lain, yang tidak akan dibincangkan satu persatu di sini. Seperti yang dinyatakan sebelum ini, Ele.me ialah ekosistem berbilang bahasa, termasuk Python dan Java rangka kerja berorientasikan perkhidmatan kami juga berbilang bahasa. Ini akan memberi kesan pada pemilihan perisian tengah kami yang seterusnya, seperti lapisan DAL.

5. Lapisan akses data DAL

Apabila volum perniagaan menjadi lebih besar dan lebih besar, pangkalan data akan menjadi halangan.

Pada peringkat awal, prestasi pangkalan data boleh dipertingkatkan dengan menaik taraf perkakasan. Contohnya:

• Naik taraf kepada mesin dengan lebih banyak CPU;
• Tukar cakera keras kepada SSD atau sesuatu yang lebih maju.

Tetapi peningkatan perkakasan akhirnya mempunyai had kapasiti. Lebih-lebih lagi, ramai rakan kongsi perniagaan mengendalikan pangkalan data secara langsung semasa menulis kod Terdapat banyak kes di mana pangkalan data itu diletupkan sebaik sahaja perkhidmatan itu masuk dalam talian. Selepas pangkalan data dimusnahkan, tidak ada peluang lain untuk memulihkan perniagaan melainkan pangkalan data dipulihkan.

Jika data dalam pangkalan data adalah normal, perniagaan sebenarnya boleh diberi pampasan. Jadi apabila kita membina lapisan perkhidmatan DAL, perkara pertama yang perlu dilakukan ialah mengehadkan arus, dan perkara lain boleh diketepikan. Kemudian untuk penggunaan semula sambungan, rangka kerja Python kami menggunakan model berbilang proses, benang tunggal dan coroutine.

Malah, pelbagai proses tidak boleh berkongsi sambungan. Contohnya: 10 proses Python digunakan pada mesin, dan setiap proses mempunyai 10 sambungan pangkalan data. Berkembang kepada 10 mesin, terdapat 1,000 sambungan pangkalan data. Untuk pangkalan data, sambungan adalah perkara yang sangat mahal, dan lapisan DAL kami perlu menggunakan semula sambungan.

Penggunaan semula sambungan ini bukan mengenai penggunaan semula sambungan perkhidmatan itu sendiri, tetapi penggunaan semula sambungan pada lapisan DAL Iaitu, perkhidmatan mempunyai 1000 sambungan ke lapisan DAL Selepas penggunaan semula sambungan, pangkalan data hanya boleh mengekalkan sedozen sambungan. Sebaik sahaja didapati bahawa permintaan pangkalan data adalah transaksi, DAL akan membantu anda mengekalkan hubungan yang sepadan dengan sambungan ini. Apabila transaksi tamat, sambungan pangkalan data dimasukkan semula ke dalam kumpulan kongsi untuk digunakan oleh orang lain.

Kemudian lakukan asap dan fius. Pangkalan data juga boleh digabungkan. Apabila pangkalan data berasap, kami akan mematikan beberapa permintaan pangkalan data untuk memastikan pangkalan data tidak ranap.

6. Tadbir Urus Perkhidmatan

Selepas kerangka perkhidmatan, ia melibatkan isu tadbir urus perkhidmatan. Tadbir urus perkhidmatan sebenarnya adalah satu konsep yang besar. Yang pertama adalah untuk mengebumikan mata Anda perlu mengebumikan banyak mata pemantauan.

Sebagai contoh, jika terdapat permintaan, sama ada permintaan itu berjaya atau gagal, dan berapa masa tindak balas permintaan itu, letakkan semua penunjuk pemantauan pada sistem pemantauan. Kami mempunyai skrin pemantauan yang besar dengan banyak penunjuk pemantauan. Terdapat pasukan khusus menonton skrin ini 72 jam sehari Jika terdapat sebarang turun naik dalam keluk, seseorang akan ditemui untuk menyelesaikannya. Yang lain ialah sistem penggera Perkara yang dipaparkan pada skrin pemantauan sentiasa terhad dan hanya boleh memaparkan penunjuk utama yang sangat penting itu. Pada masa ini, sistem penggera diperlukan.

Rom tidak dibina dalam sehari, dan infrastruktur ialah proses evolusi. Sumber dan masa kita sentiasa terhad Sebagai seorang arkitek dan CTO, bagaimana kita boleh menghasilkan perkara yang lebih penting dengan sumber yang terhad?

Kami telah membina banyak sistem dan merasakan bahawa kami telah melakukan kerja yang baik, tetapi sebenarnya, kami tidak merasakan bahawa kami telah kembali ke Zaman Batu, kerana semakin banyak masalah dan semakin banyak permintaan saya merasakan bahawa masih terdapat kekurangan dalam sistem anda Terdapat banyak fungsi yang saya ingin lakukan dengan sesuatu.

Sebagai contoh, untuk sistem kawalan aliran, kami masih memerlukan pengguna untuk mengkonfigurasi nombor serentak, jadi adakah nombor serentak ini tidak memerlukan pengguna untuk mengkonfigurasinya sama sekali? Adakah mungkin untuk mengawal bilangan konkurensi secara automatik berdasarkan keadaan perkhidmatan kami sendiri?

Kemudian terdapat kaedah naik taraf SDK adalah perkara yang sangat menyakitkan. Sebagai contoh, rangka kerja perkhidmatan kami 2.0 telah dikeluarkan pada Disember tahun lepas, dan sesetengah orang masih menggunakan 1.0. Adakah mungkin untuk mencapai peningkatan SDK tanpa kerugian Kita boleh mengawal masa dan rentak peningkatan itu sendiri.

Selain itu, pemantauan semasa kami hanya menyokong pengagregatan pada perkhidmatan yang sama dan tidak dibahagikan kepada kluster atau mesin Jadi, bolehkah penunjuk masa hadapan dibahagikan kepada kluster dan mesin? Untuk memberikan contoh paling mudah, jika terdapat 10 mesin pada perkhidmatan, mungkin terdapat masalah pada satu mesin sahaja, tetapi semua penunjuknya akan diagihkan sama rata kepada 9 mesin yang lain. Anda hanya melihat peningkatan dalam kependaman perkhidmatan keseluruhan, tetapi mungkin hanya satu mesin memperlahankan keseluruhan kluster perkhidmatan. Tetapi kami belum dapat memantau dalam lebih banyak dimensi.

Terdapat juga penggera pintar ini mesti pantas, lengkap dan tepat. Kita boleh melakukannya dengan lebih cepat dan lebih menyeluruh. Pada waktu puncak setiap hari, lebih daripada 1,000 penggera dihantar keluar setiap minit. Adakah semua seribu penggera berguna? Selepas menghubungi polis terlalu banyak kali, ia sama dengan tidak menghubungi polis langsung. Semua orang keletihan dan berhenti menonton. Bagaimanakah saya boleh membezakan penggera ini dengan lebih tepat? Adakah terdapat analisis pautan yang lebih bijak? Pada masa hadapan, patutkah kita tidak meletakkan penunjuk pemantauan dalam pemantauan kita, tetapi analisis pautan, supaya kita dapat mengetahui dengan jelas nod mana yang sepadan dengan masalah tersebut.

Soalan-soalan ini melibatkan prinsip kerja kita: selagi perkara itu mencukupi, kita mesti boleh membuat persediaan untuk hari hujan dan membuat perancangan awal tertentu.

Atas ialah kandungan terperinci Evolusi seni bina dan penerokaan reka bentuk Ele.me. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!