Rumah  >  Soal Jawab  >  teks badan

java - 调用多个第三方接口哪一种方案更好?

目的

用户在下单的时候,会调用我们的后台服务器,我们的后台服务器又会根据不同渠道调用第三方下单接口,完成整个下单流程,但是第三方下单接口可能突然出问题或者不支持,所以目前我们每一种渠道都配置了好几种备用的下单接口,尽可能提高用户下单成功率。

问题

想选择一种更好的方案,来实现同样的效果。

方案

例如: 下单时type = 1 ,后台支持该类型的第三方下单接口有A,B,C。可能A,B,C会突然出问题,或者不支持,或者不稳定等问题。

  1. 每次下单轮询A,B,C 3个接口,直到成功为止,此时记录下失败的渠道 ,例如A,当A最近M分钟的失败次数大于N次,则下次下单的时候,只用轮询B,C接口。当最近X分钟内失败的渠道A又开始成功了并且成功次数大于X次,则下单的时候又可以轮询A,B,C,其中A,B,C轮询次数按照优先级排序。
    分析:每次都要轮询,但可以保证例如 X= 2 A失败了2次,此时我可以轮询到B去下单,而不会直接失败。

  2. 每次下单前直接确定一个接口A或者B或者C,根据优先级最高且最近M分钟内失败次数没有超过N次的。
    分析:如果N为10次,那么第11次的时候,才会选择一个合适的渠道,例如B。之所以是N次才剔除掉,是因为避免偶然失败情况。

  3. 有没更好的方式,解决多渠道(就类似上面可用的下单接口用A,B,C)下单的问题,尽可能提高下单的成功率,尽可能尝试更多的机会,尽可能让用户成功支付,尽可能预知第三方接口的问题(接口改变、服务器挂了、处理慢、业务类型不支持了等问题)

求大神分享经验。。。

========================================update 2016-7-7============================

  1. 需要同步返回给前端是否成功

  2. 第三方暂时没提供 比如某个业务类型不支持的错误码

其实大家的回答已经比较接近实际场景了~

感谢~

PHP中文网PHP中文网2712 hari yang lalu1256

membalas semua(7)saya akan balas

  • 怪我咯

    怪我咯2017-04-18 09:31:21

    Saya tidak begitu memahami perbezaan antara saluran A, B, C dan antara muka A, B, C yang anda nyatakan

    Masalah yang anda hadapi lebih hampir kepada masalah

    kemerosotan perkhidmatan yang sering dihadapi dalam perkhidmatan Internet semasa, iaitu: apabila perkhidmatan bergantung pada perkhidmatan lain yang tidak tersedia, logik alternatif sandaran dipanggil.

    Mod pemutus litar ini mungkin memenuhi keperluan anda:

    • Apabila perkhidmatan tidak tersedia (kadar ralat mencapai ambang tertentu), ia akan menurunkan taraf secara automatik kepada perkhidmatan alternatif

    • Selepas tetingkap masa tertentu, panggil semula perkhidmatan yang tidak tersedia sebelum ini Jika panggilan berterusan berjaya, ia akan dipulihkan jika panggilan gagal, perkhidmatan yang gagal tidak akan dipanggil lagi dalam tetingkap masa.

    Anda memerlukan komponen fius untuk melaksanakan penurunan taraf automatik dan fungsi pemulihan automatik:

    1. Tentukan strategi penurunan taraf, contohnya: mula menurunkan taraf apabila kadar ralat panggilan mencapai lebih daripada 50%

    2. Tentukan tempoh masa untuk pengumpulan kadar ralat Contohnya: setiap 1 minit, nilai semula kadar ralat permintaan.

    3. Tentukan tamat masa perkhidmatan untuk mengelakkan permintaan yang disekat daripada menduduki sumber rangkaian lebih lama.

    4. Tentukan penggunaan kumpulan benang untuk mengasingkan panggilan perkhidmatan untuk mengelakkan runtuhan perkhidmatan, apabila satu antara muka tidak tersedia dan semua sumber disekat olehnya, menyebabkan semua antara muka lain tidak tersedia

    5. Kumpulkan kadar kejayaan panggilan antara muka alternatif dan hantar permintaan berdasarkan kadar kejayaan semasa memanggil perkhidmatan.

    Anda boleh menggunakan Hystrix Netflix untuk mencapai ini. 1,2,3,4 di atas agak mudah.

    Point 5 perlu dilaksanakan sendiri.

    balas
    0
  • 阿神

    阿神2017-04-18 09:31:21

    Senario perniagaan poster memang tidak pernah ditemui dalam kerja harian, tetapi ia boleh dibandingkan dengan sistem perkhidmatan teragih.

    1. A,B,C boleh dibandingkan dengan tiga perkhidmatan pesanan Pelayan bahagian belakang akan memanggil perkhidmatan pesanan

    2. Mengikut kadar kegagalan pesanan bagi tiga antara muka, seperti A > B > C, permintaan boleh dihalakan ke perkhidmatan pesanan A terlebih dahulu Jika pesanan gagal, pesanan itu akan dicuba semula secara automatik N kali,< Jika masih gagal selepas 🎜> kali, turunkan taraf perkhidmatan N (perintah seterusnya akan dihalakan ke A dahulu), dan kemudian pindahkan permintaan ke B Strategi B ialah sama seperti BA

    3. memulakan urutan latar belakang untuk mengesan aktiviti dengan kerap Contohnya, jika anda mendapati bahawa

      telah diturunkan, anda boleh cuba menghubungi antara muka A untuk membuat pesanan dari semasa ke semasa (anda perlu. antara muka A untuk menyediakan antara muka Aktif yang berasingan), jika didapati A berjaya (ia juga boleh dinilai berdasarkan kadar kegagalan), maka A boleh dibawa dalam talian, maka permintaan seterusnya akan dihalakan ke pelayan A dahulu A

    4. Mungkin rancangan saya serupa dengan rancangan penulis 1 atau rancangan 2, tetapi rancangan poster 1 dan rancangan 2 kelihatan sangat kabur (tidak begitu jelas)

    5. Antara muka jenis ini disambungkan kepada antara muka pihak ketiga, dan antara muka tidak stabil Adalah disyorkan bahawa pengguna membuat pesanan dan memanggil pelayan terlebih dahulu boleh menyimpan beberapa parameter permintaan (. letakkannya dalam

      atau dalam pangkalan data), dan latar belakang boleh Memulakan urutan dan perlahan-lahan menolak pesanan ini melalui antara muka MQ, dan gesaan yang dikembalikan kepada pengguna boleh menunjukkan bahawa pesanan sedang dibuat digunakan di sini. Salah satu faedah utama ialah jika semua antara muka ditutup, kaedah segerak akan memberi pengguna perasaan yang lebih baik Iaitu, pesanan terus gagal, dan secara tidak segerak anda boleh mencuba lagi selepas tempoh masa pihak ketiga mempunyai masalah dengan antara muka pihak ketiga (perubahan antara muka, pelayan hang, pemprosesan perlahan, jenis perniagaan tidak disokong, dll.), kadar toleransi kesalahan lebih tinggi lagi TinggiA,B,C

    6. Terdapat perangkap dalam mekanisme cuba semula Pesanan mungkin berjaya dibuat, tetapi antara muka mengembalikan kegagalan, jadi anda mungkin perlu bergantung pada strategi penyahduplikasian pedagang pihak ketiga

      <🎜. >

      balas
      0
  • ringa_lee

    ringa_lee2017-04-18 09:31:21

    Laksatif.
    Jika anda memikirkan masalah ini dari sudut lain, ia sebenarnya tidak lebih daripada masalah 负载均衡 Perbezaannya ialah faktor di sini adalah secara rawak dan tidak mungkin untuk mendapatkan situasi beban secara intuitif , anda hanya boleh menetapkan sendiri mekanisme pangkat. Mekanisme
    adalah seperti berikut, dengan mengandaikan bahawa 100 kali terakhir 下单成功队列
    disimpan, di mana ketersediaan A ialah 53%, ketersediaan B ialah 30%, dan ketersediaan C ialah 17% . Kemudian undi mereka mengikut urutan dengan keutamaan A>B>C. Katakan A gagal kali ini dan B berjaya. Ketersediaan menjadi 52%, 31%, dan 17%.
    Sehingga ketersediaan B melebihi A, B akan diberi keutamaan Kaedah ini boleh melaksanakan mekanisme penarafan automatik dan mengimbangi penggunaan secara automatik untuk melaraskan strategi optimum.

    balas
    0
  • 高洛峰

    高洛峰2017-04-18 09:31:21

    Penyoal juga tahu bahawa tidak kira apa kaedah yang digunakan, tidak ada cara untuk mengelakkan masalah kegagalan panggilan Ia juga boleh dilihat dari kebanyakan jawapan yang jika panggilan itu berjaya dengan bilangan minimum panggilan, ia perlu berdasarkan keputusan panggilan sebelumnya Tetapkan keutamaan kepada A B C dan gunakan strategi semasa membuat panggilan. Terdapat banyak jawapan di atas. Izinkan saya memberi anda beberapa idea Penyoal boleh menganalisis secara buatan kegagalan panggilan antara muka Contohnya, untuk antara muka tertentu, adakah ia gagal sekali dan kemudiannya terus gagal adakah ia hanya Sekali-sekala, ia gagal secara bertitik, contohnya, ia mudah gagal apabila anda membuat panggilan tertentu terlalu kerap . Berdasarkan ini, anda boleh membuat strategi yang munasabah dan menganggarkan kesannya akan lebih dekat dengan apa yang anda mahukan.

    balas
    0
  • 迷茫

    迷茫2017-04-18 09:31:21

    Saya rasa menggunakan activemq sepatutnya memuaskan hati anda

    balas
    0
  • 迷茫

    迷茫2017-04-18 09:31:21

    Jika pelanggan mempunyai keperluan yang sangat tinggi untuk sambutan pesanan, anda boleh mengikut kaedah pertama, tetapi anda boleh membuat tiga pesanan pada masa yang sama Selagi satu berjaya, dua yang lain akan dibatalkan sewajarnya. Walau bagaimanapun, kaedah ini Terdapat keperluan untuk antara muka pihak ketiga dan pelbagai masalah dengan antara muka pihak ketiga boleh menjejaskan perkhidmatan perniagaan anda Contohnya, jika antara muka tidak bertindak balas, keupayaan pemprosesan perkhidmatan perniagaan anda akan berkurangan secara eksponen.
    Jika pelanggan tidak begitu sensitif dengan masa respons pesanan, anda boleh menggunakan MQ untuk melakukannya dan menyerahkan tugas pesanan kepada MQ pengguna boleh membuat pesanan dan memanggil semula hasilnya ke perkhidmatan perniagaan selepas berjaya.

    balas
    0
  • PHP中文网

    PHP中文网2017-04-18 09:31:21

    Original, kecuali pilihan kedua, akan ada masalah dengan pilihan lain Pengguna pasti akan ditolak berulang kali Contohnya, jika anda menghubungi saluran A, jika saluran A mempunyai masa tamat, tetapi keadaan ini Mungkin pengguna telah ditolak, biasanya dikenali sebagai drop order (kadangkala anda tidak boleh mendapatkan bayaran balik walaupun anda membuat pembetulan, dan anda hanya boleh memulakan permintaan pemulangan sahaja). pengguna berjaya membayar melalui pertanyaan pesanan penambahan Selepas kelewatan tertentu, jika anda mengedarkan pengguna ke saluran B pada masa ini, pengguna akan ditolak lagi Ini adalah masalah yang sering berlaku dalam pembayaran pihak ketiga buat perangkaan saluran hiliran dan utamakan saluran yang berkualiti Untuk pengedaran, mudah timbul masalah jika poster reka bentuk begini

    ps: Kebanyakan jawapan di atas tidak pernah melakukan pembayaran tiga pihak Tidak mustahil untuk mereka bentuk seperti poster pembayaran tiga pihak tidak boleh dilakukan dengan menghubungi antara muka seperti perkhidmatan yang diedarkan adalah sangat sensitif anda tidak berhati-hati, Akan ada pembayaran singkat dalam akaun syarikat dan anda akan kehilangan wang secara sia-sia

    balas
    0
  • Batalbalas