Mengapa Alibaba tidak menggunakan ZooKeeper untuk penemuan perkhidmatan?

Berdiri di persimpangan masa depan, sering menarik untuk melihat kembali jalan sejarah yang hilang, kerana kita secara tidak sengaja akan mempunyai pemikiran gila, seperti apa yang akan berlaku jika sesuatu berlaku lebih awal, tetapi perkara lain telah tidak berlaku? Sama seperti apa yang akan berlaku jika Archduke Ferdinand dan isterinya, pewaris takhta Empayar Austro-Hungary, tidak ditembak mati oleh Princip pemuda Serbia yang bersemangat, dan apa yang akan berlaku jika Qiu Laodao tidak melaluinya Kampung Niujia?

Pada penghujung tahun 2007, Taobao memulakan projek pembinaan semula dalaman yang dipanggil "Batu Berwarna-warni Projek ini kemudiannya menjadi perkhidmatan Taobao, penyelidikan sendiri untuk pengedaran, dan melangkah keluar dari Internet". sistem, dan pusat pendaftaran perkhidmatan Taobao ConfigServer dilahirkan pada tahun yang sama.

Sekitar tahun 2008, Yahoo, bekas gergasi Internet, mula mengumumkan secara beransur-ansur produk penyelarasan yang diedarkan oleh data besar ZooKeeper secara terbuka Produk ini merujuk kepada kertas kerja yang diterbitkan oleh Google di Chubby dan Paxos.

Pada November 2010, ZooKeeper telah membangunkan daripada sub-projek Apache Hadoop kepada projek peringkat tertinggi Apache, secara rasmi mengumumkan bahawa ZooKeeper telah menjadi produk gred industri, matang dan stabil.

Pada tahun 2011, Alibaba sumber terbuka Dubbo Untuk menjadikannya sumber terbuka yang lebih baik, adalah perlu untuk memisahkan hubungan dengan sistem dalaman Alibaba menyokong ZooKeeper sumber terbuka kemudiannya, di China, dengan yang sukar kerja pemain industri, penyelesaian perkhidmatan biasa Dubbo + ZooKeeper telah menjadikan ZooKeeper terkenal sebagai pusat pendaftaran.

Double 11 pada 2015, hampir 8 tahun telah berlalu sejak perkhidmatan ConfigServer dilancarkan "skala perkhidmatan" dalaman Alibaba melebihi beberapa juta, serta promosi strategi teknologi pemulihan bencana IDC "beribu batu jauhnya", dsb. , yang bersama-sama mendorong Alibaba untuk membuka dalaman Laluan naik taraf seni bina daripada ConfigServer 2.0 kepada ConfigServer 3.0 dijelaskan.

Masa semakin menuju ke tahun 2018. Berdiri di persimpangan 10 tahun, berapa ramai yang sanggup memperlahankan sedikit dan melihat dengan lebih dekat bidang penemuan perkhidmatan apabila mengejar konsep teknologi baharu yang sentiasa berubah? memikirkan atau memikirkannya? Soalan:

Penemuan perkhidmatan, adakah ZooKeeper benar-benar pilihan terbaik?

Mengimbas kembali sejarah, kami juga kadang-kadang mempunyai mitos Dalam konteks penemuan perkhidmatan, apakah yang akan berlaku jika ZooKeeper dilahirkan lebih awal daripada pusat pendaftaran HSF ConfigServer kami?

Adakah kita akan mengambil lencongan menggunakan ZooKeeper dahulu dan kemudian secara panik mengubah dan menampal ZooKeeper untuk menyesuaikan diri dengan senario dan keperluan berorientasikan perkhidmatan Alibaba?

Namun, berdiri di atas bahu hari ini dan pendahulu kami, kami tidak pernah menyedari setegas yang kami lakukan hari ini bahawa Dalam bidang penemuan perkhidmatan, ZooKeeper bukanlah pilihan terbaik, seperti yang pernah kami lakukan bersama kami semua tahun ini Fellow Eureka dan artikel ini Eureka! Mengapa Anda Tidak Harus Menggunakan ZooKeeper untuk Penemuan Perkhidmatan dengan tegas menerangkan mengapa anda tidak boleh menggunakan ZooKeeper untuk penemuan perkhidmatan!

Saya tidak bersendirian dalam laluan saya.

Analisis Keperluan Pusat Pendaftaran dan Pertimbangan Reka Bentuk Utama

Seterusnya, mari kita kembali kepada analisis permintaan untuk penemuan perkhidmatan, digabungkan dengan amalan Alibaba dalam senario utama, menganalisisnya satu demi satu dan membincangkan mengapa ZooKeeper bukan pusat Pendaftaran yang paling sesuai penyelesaian.

Adakah pusat pendaftaran adalah sistem CP atau AP?

Saya percaya bahawa pembaca sudah biasa dengan teori CAP dan BASE, dan ia telah menjadi salah satu prinsip utama yang membimbing pembinaan sistem teragih dan aplikasi Internet, saya tidak akan menghuraikannya mengenai teori mereka di sini. Kami akan terus Memasukkan analisis ketekalan data dan keperluan ketersediaan pusat pendaftaran:

• Analisis keperluan ketekalan data

Fungsi paling penting pusat pendaftaran boleh dianggap sebagai fungsi Pertanyaan Si = F(service-name)，以 service-name 为查询参数，service-name 对应的服务的可用的 endpoints (ip:port) Senarai ialah nilai pulangan

Nota: Perkhidmatan akan disingkatkan sebagai svc dalam teks berikut.

Pertama, mari kita lihat kesan ketidakkonsistenan pada data utama endpoints (ip:port), iaitu akibat tidak memenuhi C dalam CAP:

Seperti yang ditunjukkan dalam rajah di atas, jika svcB menggunakan 10 nod copy/ Replica), jika untuk nama perkhidmatan yang sama svcB, dua pertanyaan bagi dua nod pemanggil svcA mengembalikan data yang tidak konsisten, contohnya: S1 = { ip1,ip2,ip3...,ip9 }, S2 = { ip2 , ip3,....ip10}, Jadi apakah kesan ketidakkonsistenan ini?

Saya percaya anda pasti perasan bahawa trafik setiap nod svcB akan menjadi sedikit tidak seimbang.

Berbanding dengan 8 nod {ip2...ip9} yang lain, trafik permintaan ip1 dan ip10 adalah sedikit lebih kecil, tetapi jelas bahawa dalam sistem yang diedarkan, walaupun untuk perkhidmatan yang digunakan rakan ke rakan, kerana masa ketibaan permintaan, status perkakasan, penjadualan sistem pengendalian, GC mesin maya, dsb., pada bila-bila masa, status nod yang digunakan rakan sebaya ini tidak boleh konsisten sepenuhnya, dan dalam kes trafik yang tidak konsisten, selagi memandangkan pusat pendaftaran berada dalam masa yang dijanjikan oleh SLA (contohnya, 1s (dalam) data menumpu kepada keadaan yang konsisten (iaitu, memenuhi ketekalan akhirnya), lalu lintas akan cenderung untuk konsisten dalam erti kata statistik, jadi pusat pendaftaran direka bentuk dengan model yang akhirnya konsisten, yang boleh diterima sepenuhnya dalam amalan pengeluaran. . CAP tidak berpuas hati dengan pengaruh.

Pertimbangkan struktur penggunaan 5-nod pemulihan bencana tiga bilik komputer ZooKeeper (iaitu struktur 2-2-1), seperti yang ditunjukkan di bawah:
• Apabila partition rangkaian berlaku dalam bilik komputer 3, iaitu komputer bilik 3 berada dalam Rangkaian telah menjadi pulau terpencil Kami tahu bahawa walaupun perkhidmatan ZooKeeper keseluruhan tersedia, nod ZK5 tidak boleh ditulis kerana Ketua tidak dapat dihubungi.

Dalam erti kata lain, pada masa ini, perkhidmatan aplikasi svcB di bilik komputer 3 tidak boleh digunakan baru, dimulakan semula, dikembangkan atau dikurangkan, tetapi dari perspektif panggilan rangkaian dan perkhidmatan, walaupun svcA di bilik komputer 3 tidak boleh memanggil bilik komputer 1 dan svcB di bilik komputer 2, tetapi rangkaian dengan svcB di bilik komputer 3 jelas OK Mengapa tidak saya hubungi perkhidmatan bilik komputer ini?

Sekarang kerana pusat pendaftaran itu sendiri telah melepaskan ketersediaan untuk memastikan konsistensi data (C) di bawah otak berpecah (P), perkhidmatan di bilik komputer yang sama tidak boleh dipanggil. Boleh dikatakan dalam praktiknya, pusat pendaftaran tidak boleh memusnahkan ketersambungan antara perkhidmatan atas apa-apa sebab sendiri Ini adalah undang-undang besi yang harus dipatuhi oleh reka bentuk pusat pendaftaran! Kami akan terus membincangkan pemulihan bencana pelanggan pusat pendaftaran nanti.

Pada masa yang sama, mari kita pertimbangkan ketidakkonsistenan data dalam kes ini Jika bilik komputer 1, 2, dan 3 semuanya menjadi pulau terpencil, maka jika svcA di setiap bilik komputer hanya mendapat senarai IP svcB di bilik komputer ini, ia. akan juga Iaitu, data senarai IP svcB di setiap bilik komputer adalah tidak konsisten. Apakah kesannya?

Sebenarnya ia tidak memberi impak yang besar, tetapi dalam kes ini, semuanya menjadi panggilan dari bilik komputer yang sama Apabila kami merancang pusat pendaftaran, kadang-kadang kami menggunakan data di pusat pendaftaran untuk tidak konsisten untuk membantu aplikasi secara proaktif Mencapai panggilan dalam bilik komputer yang sama, dengan itu mengoptimumkan kesan pautan panggilan perkhidmatan RT!

Melalui penjelasan kami di atas, kami dapat melihat bahawa dalam pertukaran CAP, ketersediaan pusat pendaftaran adalah lebih bernilai daripada ketekalan data yang kukuh, jadi reka bentuk keseluruhan harus lebih berat sebelah kepada AP dan bukannya CP ketidakkonsistenan berada dalam julat yang boleh diterima, manakala P Dropping A sepenuhnya melanggar prinsip bahawa pusat pendaftaran tidak boleh memusnahkan ketersambungan perkhidmatan itu sendiri atas sebarang sebabnya sendiri.

Skala perkhidmatan, kapasiti, ketersambungan perkhidmatan

Apakah skala "perkhidmatan mikro" syarikat anda? Beratus-ratus perkhidmatan mikro? Digunakan beratus-ratus nod? Bagaimana dengan 3 tahun kemudian? Internet ialah tempat di mana keajaiban berlaku Mungkin "perkhidmatan" anda menjadi nama rumah dalam sekelip mata, trafik anda berganda, dan skala anda berganda!

Apabila skala perkhidmatan pusat data melebihi bilangan tertentu (skala perkhidmatan = F{bilangan pub perkhidmatan, bilangan perkhidmatan subs}), ZooKeeper sebagai pusat pendaftaran akan segera terharu seperti keldai dalam gambar di bawah

Sebenarnya, apabila ZooKeeper digunakan di tempat yang betul, iaitu, dalam senario penyelarasan teragih berbutir kasar dan senario penyelarasan, tps dan bilangan sambungan yang disokong oleh ZooKeeper adalah mencukupi, kerana senario ini tidak mempunyai permintaan yang kuat terhadap Kebolehskalaan dan kapasiti ZooKeeper.

Tetapi dalam senario penemuan perkhidmatan dan pemantauan kesihatan, apabila skala perkhidmatan meningkat, sama ada permintaan tulis yang disebabkan oleh pendaftaran perkhidmatan apabila aplikasi kerap dikeluarkan, atau tulis permintaan yang disebabkan oleh status kesihatan perkhidmatan tahap milisaat, atau Jika semua mesin atau bekas di seluruh pusat data mempunyai sambungan yang panjang ke pusat pendaftaran, ZooKeeper tidak lama lagi akan dapat mengatasi tekanan sambungan yang dibawa olehnya, namun ZooKeeper tidak boleh berskala dan tidak dapat menyelesaikan masalah kebolehskalaan mendatar dengan menambahkan nod.

Jika anda ingin menyelesaikan masalah pertumbuhan skala perkhidmatan berdasarkan ZooKeeper, kaedah praktikal yang boleh dipertimbangkan ialah mencari cara untuk menyelesaikan perniagaan, membahagikan domain perniagaan secara menegak dan membahagikannya kepada beberapa pusat pendaftaran ZooKeeper, tetapi sebagai universal Adakah benar-benar boleh untuk kumpulan organisasi platform perkhidmatan membahagikan dan mengurus perniagaan mengikut baton teknikal kerana keupayaan perkhidmatan yang tidak mencukupi?

Dan ini melanggar fakta bahawa pusat pendaftaran itu sendiri (kapasiti tidak mencukupi) memusnahkan ketersambungan perkhidmatan Untuk memberikan contoh mudah, 1 perniagaan carian, 1 perniagaan peta, 1 perniagaan hiburan besar, dan 1 perniagaan permainan , Sekiranya perkhidmatan antara. mereka saling eksklusif? Mungkin hari ini ya, tetapi bagaimana dengan esok, bagaimana dengan satu tahun dari sekarang, bagaimana dengan sepuluh tahun dari sekarang? Siapa tahu pada masa hadapan, beberapa domain perniagaan akan dibuka untuk mencipta inovasi perniagaan yang pelik? Sebagai perkhidmatan asas, pusat pendaftaran tidak boleh meramalkan masa depan dan pastinya tidak boleh menghalang permintaan perkhidmatan perniagaan untuk sambungan yang wujud pada masa hadapan.

Adakah pusat pendaftaran memerlukan storan dan log transaksi yang berterusan?

Perlu atau tidak.

Kami tahu bahawa protokol ZAB ZooKeeper akan terus menulis log transaksi pada setiap nod ZooKeeper untuk setiap permintaan tulis, dan pada masa yang sama, ia akan sentiasa mencerminkan (Snapshot) data memori ke cakera untuk memastikan ketekalan dan ketahanan data. Ini adalah ciri yang sangat baik, serta pemulihan data selepas ranap sistem Walau bagaimanapun, kita perlu bertanya, dalam senario penemuan perkhidmatan, adakah data teras - senarai alamat masa nyata perkhidmatan sihat benar-benar memerlukan kegigihan data? ?

Untuk data ini, jawapannya adalah tidak.

Seperti yang ditunjukkan dalam rajah di atas, jika svcB telah melalui perkhidmatan pendaftaran (ip1), pengembangan kepada 2 nod (ip1, ip2), dan pengecutan akibat downtime (ip1 downtime), proses ini telah berlaku 3 kali Tulis operasi untuk ZooKeeper.

Walau bagaimanapun, selepas analisis yang teliti, sebenarnya adalah tidak penting untuk terus merekodkan proses perubahan ini melalui log transaksi, kerana dalam penemuan perkhidmatan, pemula panggilan perkhidmatan lebih mengambil berat tentang senarai alamat masa nyata dan status kesihatan masa nyata perkhidmatan yang ingin dihubungi , setiap kali panggilan dimulakan, ia tidak mengambil berat tentang senarai alamat perkhidmatan sejarah dan status kesihatan masa lalu perkhidmatan yang akan dipanggil.

Tetapi kenapa perlu kerana pusat pendaftaran yang tersedia untuk pengeluaran, sebagai tambahan kepada senarai alamat masa nyata dan status kesihatan masa nyata perkhidmatan, juga akan menyimpan beberapa maklumat metadata perkhidmatan, seperti versi perkhidmatan , pengumpulan, maklumat Meta seperti pusat data di mana ia terletak, berat, maklumat dasar pengesahan, label perkhidmatan, dsb. Data ini perlu disimpan secara berterusan, dan pusat pendaftaran harus menyediakan keupayaan untuk mendapatkan semula maklumat meta ini.

Service Health Check

Apabila menggunakan ZooKeeper sebagai pusat pendaftaran perkhidmatan, pengesanan kesihatan perkhidmatan sering menggunakan mekanisme Track aktif Sesi ZooKeeper dan mekanisme yang digabungkan dengan ZNode Ephemeral Secara mudah, pemantauan kesihatan perkhidmatan terikat kepada ZooKeeper . Pemantauan kesihatan sesi, atau mengikat kepada pengesanan aktiviti pautan panjang TCP.

Ini juga boleh menyebabkan masalah maut dalam banyak kes Apabila pengesanan aktiviti pautan panjang TCP antara ZK dan mesin pembekal perkhidmatan adalah normal, adakah perkhidmatan itu sihat? Jawapannya sudah tentu tidak! Pusat pendaftaran harus menyediakan penyelesaian pemantauan kesihatan yang lebih kaya, dan logik sama ada perkhidmatan itu sihat atau tidak harus terbuka kepada penyedia perkhidmatan untuk menentukannya, dan bukannya menjadikannya ujian aktiviti TCP satu saiz untuk semua!

Salah satu prinsip reka bentuk asas pengesanan kesihatan adalah memberi maklum balas tentang status kesihatan sebenar perkhidmatan itu sendiri sejujur ​​mungkin, jika tidak, keputusan penentuan status kesihatan yang tidak dipercayai oleh pemanggil perkhidmatan adalah lebih teruk daripada tiada pengesanan kesihatan.

Pertimbangan pemulihan bencana untuk pusat pendaftaran

Seperti yang dinyatakan sebelum ini, Secara praktiknya, pusat pendaftaran tidak boleh memusnahkan ketersambungan antara perkhidmatan atas sebarang sebab sendiri, jadi dari segi ketersediaan, ia adalah masalah yang penting pendaftaran Pusat (Pendaftaran) itu sendiri tidak berfungsi sama sekali. Patutkah pautan svcA memanggil svcB terjejas?

Ya, ia tidak sepatutnya terjejas.

Pautan panggilan perkhidmatan (aliran tindak balas permintaan) harus bergantung pada pusat pendaftaran Ia hanya perlu bergantung pada pusat pendaftaran apabila perlu untuk pelepasan perkhidmatan, mesin dalam talian dan luar talian, pengembangan dan pengecutan perkhidmatan, dsb.

Ini memerlukan pusat pendaftaran untuk mereka bentuk pelanggan yang disediakannya dengan teliti Pelanggan harus mempunyai cara pemulihan bencana apabila perkhidmatan pusat pendaftaran tidak tersedia sepenuhnya. Contohnya, mereka bentuk mekanisme data cache pelanggan (kami memanggilnya snapshot pelanggan) adalah OK satu cara yang berkesan. Selain itu, mekanisme pemeriksaan kesihatan pusat pendaftaran hendaklah direka bentuk dengan teliti agar situasi seperti pengosongan tidak berlaku dalam situasi ini.

Klien asli ZooKeeper tidak mempunyai keupayaan ini, jadi apabila menggunakan ZooKeeper untuk melaksanakan pusat pendaftaran, kita mesti bertanya kepada diri sendiri, jika semua nod ZooKeeper terbunuh, adakah semua pautan panggilan perkhidmatan dalam pengeluaran anda tidak akan terjejas? Dan latihan kegagalan harus dilakukan secara berkala pada perkara ini.

Adakah anda mempunyai pakar ZooKeeper untuk dipercayai?

ZooKeeper nampaknya merupakan produk yang sangat mudah, tetapi tidak semestinya untuk menggunakannya secara besar-besaran dan menggunakannya dengan baik dalam pengeluaran. Jika anda memutuskan untuk memperkenalkan ZooKeeper dalam pengeluaran, lebih baik anda bersedia untuk mendapatkan bantuan daripada pakar teknikal ZooKeeper pada bila-bila masa Manifestasi paling tipikal adalah dalam dua aspek:

• Mesin keadaan pelanggan/Sesi yang sukar dikuasai.

Klien asli ZooKeeper pastinya tidak mudah digunakan, tetapi sebenarnya ia tidak begitu mudah untuk memahami sepenuhnya protokol interaksi antara pelanggan ZooKeeper dan Pelayan memahami sepenuhnya dan menguasai mesin ZooKeeper Client/Session (gambar di bawah) tidak semudah dan jelas:

Tetapi penyelesaian penemuan perkhidmatan berdasarkan ZooKeeper bergantung pada pengurusan sambungan/Sesi yang lama, ZNode Ephemeral, Event&Notification, dan mekanisme ping yang disediakan oleh ZooKeeper Oleh itu, untuk menggunakan ZooKeeper dengan baik untuk penemuan perkhidmatan, anda mesti memahami mekanisme teras dan prinsip ZooKeeper Ini kadang-kadang membuat anda mudah marah ? Dan jika anda memahami semua ini dan tidak masuk ke dalam sebarang perangkap, tahniah, anda telah menjadi pakar teknikal ZooKeeper.

• Unbearable Exception Handling

Apabila kami menyambungkan ZooKeeper ke aplikasi dalaman Alibaba, terdapat WIKI yang dipanggil "Apa yang Anda Mesti Tahu Mengenai Integrasi Aplikasi ZooKeeper", yang membincangkan pengendalian pengecualian seperti berikut:

Jika anda mahu memilih apa pembangun aplikasi perlu tahu dengan jelas apabila menggunakan ZooKeeper? Jadi berdasarkan pengalaman sokongan kami sebelum ini, ia mestilah pengendalian pengecualian.

Apabila segala-galanya (hos, cakera, rangkaian, dll.) bernasib baik berfungsi dengan baik, aplikasi dan ZooKeeper juga mungkin berjalan dengan baik, tetapi malangnya, kita akan menghadapi pelbagai kejutan sepanjang hari, Dan ini mengikut Undang-undang Murphy, perkara buruk yang tidak dijangka sentiasa berlaku apabila anda paling bimbang tentang mereka.

Jadi pastikan anda memahami dengan teliti pengecualian dan ralat yang mungkin berlaku dalam ZooKeeper dalam sesetengah senario, pastikan anda memahami pengecualian dan ralat ini dengan betul, dan ketahui cara aplikasi anda mengendalikan situasi ini dengan betul.

• ConnectionLossException dan acara Terputus

Ringkasnya, ini adalah pengecualian yang boleh dipulihkan dalam Sesi ZooKeeper yang sama (Boleh Dipulihkan), tetapi pembangun aplikasi perlu bertanggungjawab memulihkan aplikasi kepada keadaan yang betul.

Terdapat banyak sebab untuk pengecualian ini, seperti gangguan rangkaian antara mesin aplikasi dan nod ZooKeeper, masa henti nod ZooKeeper, masa GC Penuh sebelah pelayan terlalu lama, atau proses permohonan anda digantung dan proses permohonan Masa GC Penuh terlalu lama Pemulihan boleh dilakukan kemudian.

Untuk memahami pengecualian ini, anda perlu memahami masalah biasa dalam aplikasi yang diedarkan, seperti yang ditunjukkan di bawah:

Dalam permintaan pelanggan dan tindak balas pelayan biasa, apabila sambungan panjang antara mereka terganggu, Apabila pelanggan merasakan peristiwa kilat ini , ia akan berada dalam situasi yang memalukan, iaitu, ia tidak dapat menentukan keadaan permintaan yang berdekatan apabila peristiwa itu berlaku Adakah pelayan menerima permintaan ini? Adakah ia telah diproses? Kerana ini tidak dapat ditentukan, apabila klien menyambung semula ke pelayan, terdapat tanda tanya sama ada permintaan itu perlu dicuba semula (Cuba Semula).

Jadi apabila mengendalikan acara putus sambungan, pembangun aplikasi mesti tahu apakah permintaan berhampiran gangguan (ini selalunya sukar untuk dinilai), sama ada permintaan itu idempoten, dan untuk permintaan perniagaan dalam pemprosesan perkhidmatan bahagian pelayan Semantik "proses sekali sahaja", "proses paling banyak sekali" dan "proses sekurang-kurangnya sekali" harus dipilih dan dijangka.

Sebagai contoh, jika aplikasi menerima ConnectionLossException dan permintaan sebelumnya ialah operasi Cipta, maka jika aplikasi menangkap pengecualian ini, logik pemulihan yang mungkin untuk aplikasi adalah untuk menentukan sama ada nod yang dicipta oleh permintaan sebelumnya sudah wujud Jangan cipta jika ia wujud, jika tidak, ciptalah ia.

Untuk contoh lain, jika aplikasi menggunakan Watch untuk memantau peristiwa penciptaan nod yang tidak wujud, maka semasa ConnectionLossException, adalah mungkin untuk menghadapi situasi semasa tempoh gangguan ini, proses klien lain mungkin telah dibuat nod telah dipadamkan, jadi untuk aplikasi semasa, acara penciptaan nod kebimbangan terlepas Apakah kesan kehilangan ini pada aplikasi? Adakah ia boleh diterima atau tidak boleh diterima? Pembangun aplikasi perlu menilai dan memprosesnya mengikut semantik perniagaan.

• SessionExpiredException dan acara SessionExpired

Tamat masa sesi ialah pengecualian yang tidak boleh dipulihkan Ini bermakna apabila aplikasi menangkap pengecualian ini, aplikasi tidak boleh memulihkan keadaan aplikasi dalam Sesi yang sama dan mesti mewujudkan semula Sesi yang baharu. nod sementara yang dikaitkan dengan Sesi lama mungkin juga telah tamat tempoh, dan kunci yang dimilikinya mungkin telah tamat tempoh. ...

Dalam proses cuba menggunakan ZooKeeper untuk penemuan perkhidmatan mereka sendiri, rakan-rakan Alibaba pernah merumuskan perkongsian pengalaman di forum teknologi intranet kami

pada artikel tersebut dengan tepat menyebut:

. ia hanya akan muncul apabila terdapat masalah rangkaian atau senario yang tidak normal, dan ia mungkin tidak terdedah untuk masa yang lama...

Ke kiri, ke kanan

Bukankah Alibaba percuma sepenuhnya? Tidak juga.

Semua orang yang biasa dengan sistem teknikal Alibaba tahu bahawa Alibaba sebenarnya mengekalkan kluster ZooKeeper terbesar di China, dengan skala keseluruhan hampir seribu nod perkhidmatan ZooKeeper.

Pada masa yang sama, Alibaba middleware juga mengekalkan cawangan kod ZooKeeper, TaoKeeper, yang berorientasikan pengeluaran berskala besar, sangat tersedia, dan lebih mudah untuk dipantau dan dikendalikan berdasarkan amalan kami menggunakan ZooKeeper dalam pelbagai perniagaan talian dan pengeluaran dalam tempoh 10 tahun yang lalu, , jika anda menggunakan frasa untuk menilai ZooKeeper, maka kami fikir ZooKeeper sepatutnya menjadi "Raja Penyelarasan untuk Data Besar"!

Ia memainkan peranan yang tidak boleh ditukar ganti dalam senario seperti kunci teragih berbutir kasar, pemilihan induk teragih, pensuisan ketersediaan tinggi siap sedia aktif, dll. yang tidak memerlukan sokongan TPS yang tinggi, dan keperluan ini sering tertumpu pada data besar , tugas luar talian, dsb. Dalam bidang perniagaan, kerana medan data besar, adalah penting untuk membahagikan set data, dan kebanyakan masa, set data ini diproses secara selari oleh tugas dan berbilang proses/benang sentiasa menjadi beberapa titik di mana tugas dan proses ini perlu diselaraskan Pada masa ini, ZooKeeper A tempat untuk memainkan peranan yang besar.

Walau bagaimanapun, dalam pautan urus niaga senario urus niaga, terdapat kekurangan semula jadi dalam akses data perniagaan utama, penemuan perkhidmatan berskala besar, pemantauan kesihatan berskala besar, dsb. Kita harus mencuba yang terbaik untuk mengelak daripada memperkenalkan ZooKeeper dalam senario ini. Dalam pengeluaran Alibaba Dalam amalan, aplikasi mesti menjalankan penilaian ketat terhadap senario, kapasiti dan keperluan SLA apabila memohon untuk menggunakan ZooKeeper.

Jadi, anda boleh menggunakan ZooKeeper, tetapi pergi ke kiri untuk data besar, kanan untuk transaksi, kiri untuk penyelarasan teragih dan kanan untuk penemuan perkhidmatan. Penutup 10 tahun dalam amalan, kami akan meringkaskan pengalaman dan pelajaran kami dalam reka bentuk dan penggunaan pusat penemuan dan pendaftaran perkhidmatan Kami berharap dapat memberi inspirasi dan membantu industri tentang cara menggunakan ZooKeeper dengan lebih baik dan cara mereka bentuk pusat pendaftaran perkhidmatan mereka sendiri dengan lebih baik.

Akhir sekali, semua jalan menghala ke Rom, dan saya amat berharap pusat pendaftaran anda akan dilahirkan terus di Rom.

Atas ialah kandungan terperinci Mengapa Alibaba tidak menggunakan ZooKeeper untuk penemuan perkhidmatan?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!