Mengapa Anda membutuhkan gateway?
Kami tahu bahwa kami ingin memasuki layanan itu sendiri, dan jelas bahwa kami tidak memiliki metode yang baik. Kami langsung memasukkan alamat IP + nomor port. Kami tahu bahwa pendekatan ini sangat buruk. Ada masalah besar dengan pendekatan ini. Pertama, itu memperlihatkan alamat IP mesin fisik kita. Ketika orang lain melihat alamat IP Anda, mereka tahu di mana layanan ini digunakan, memungkinkan orang lain untuk melakukan operasi serangan dengan sangat nyaman.
Kedua, kami memiliki begitu banyak layanan, apakah kami harus memanggil mereka satu per satu? Mari kita asumsikan bahwa kami telah melakukan otentikasi izin, dan masing -masing pelanggan kami mengakses program layanan pada berbagai JVM yang berjalan pada mesin yang berbeda. Setiap layanan kami membutuhkan otentikasi layanan. Apakah ini menjengkelkan? Jelas sangat menjengkelkan.
Kemudian kami menghadapi keduanya dan masalah umum mereka saat ini, dan kami membutuhkan cara untuk menyelesaikannya. Pertama-tama, mari kita lihat paparan alamat IP dan masalah titik tunggal yang disebabkan oleh penulisan alamat IP setelah kematian. Apakah saya juga perlu secara dinamis mempertahankan daftar layanan untuk layanan seperti itu sendiri? Saya perlu memanggil layanan ini sendiri, apakah saya juga memerlukan hal penyeimbang beban?
Ada juga hal -hal tentang paparan alamat IP. Apakah saya perlu menjadi proxy, seperti proxy terbalik Nginx, dan ada juga hal -hal yang menggunakan modul publik tentang hal ini, seperti verifikasi izin untuk semua portal. Jadi kita sekarang membutuhkan Gateway Zuul API. Ini memecahkan masalah di atas. Jika Anda ingin menghubungi layanan tertentu, itu akan memetakan Anda dan memetakan alamat IP layanan Anda
Jika Anda memasuki jalur, itu cocok dan itu akan mengakses layanan untuk Anda. Ini akan memiliki proses penerusan permintaan. Seperti Nginx, kekuatan spesifik dari instance mesin layanan, itu tidak akan secara langsung mengakses IP, itu akan pergi ke Pusat Registrasi Eureka untuk mendapatkan ID instance layanan, yaitu nama layanan. Saya menggunakan pita penyeimbang beban klien untuk mengakses salah satu instance layanan lagi.
Gateway API terutama digunakan untuk menyelesaikan masalah panggilan eksternal oleh layanan itu sendiri, dan untuk menyelesaikan masalah verifikasi izin. Anda dapat mengintegrasikan dan memanggil serangkaian filter di sini, seperti mengintegrasikan Shiro, Springsecurity, dan hal -hal lainnya.
Zuul dapat memuat mekanisme penyaringan dinamis untuk mencapai fungsi -fungsi berikut:
1. Verifikasi dan keamanan: Identifikasi persyaratan verifikasi untuk berbagai sumber daya dan tolak permintaan yang tidak sesuai dengan persyaratan.
2. Tinjau dan Pemantauan: Lacak data yang bermakna dan hasil statistik di lokasi tepi, sehingga membawa kita kesimpulan yang akurat tentang status produksi.
3. Routing Dinamis: Permintaan rute ke berbagai cluster backend secara dinamis sesuai kebutuhan.
4. Tes Stres: Secara bertahap meningkatkan aliran beban ke cluster untuk menghitung tingkat kinerja.
5. Alokasi Muat: Tetapkan kapasitas yang sesuai untuk setiap jenis beban dan mencabut permintaan yang melebihi nilai batas.
6. Pemrosesan Respons Statis: Buat respons parsial secara langsung di lokasi tepi untuk mencegahnya mengalir ke kluster internal.
7. Elastisitas Multi-Wilayah: Permintaan perutean di seluruh wilayah AWS dirancang untuk mencapai penggunaan ELB yang beragam dan memastikan bahwa lokasi tepi sedekat mungkin dengan pengguna.
Selanjutnya, buka demo kecil
Langkah pertama adalah membangun modul Zuul baru di bawah proyek asli dan memperkenalkan dependensi. Kodenya adalah sebagai berikut:
<dependency> <GroupId> org.springframework.cloud </groupid> <ArTifactId> Spring-cloud-starter-eureka </stifactid> <version> 1.3.5.release </version> </dependency> <RoupId> org.springframework.cloud </groupid> <ArtiFacD> <version> 1.3.5.release </version> </dependency>
Kemudian ketik anotasi @EnableZuulproxy pada kelas startup, dan kodenya adalah sebagai berikut:
Server: Port: 5000Spring: Aplikasi: Nama: API-GETEWAYZUUL: ROUTES: #Identifikasi nama layanan Anda, yang dapat didefinisikan sendiri di sini. Secara umum, kenyamanan dan spesifikasi sama dengan nama layanan Anda Hello-Service: #The Path of Service Mapping, melalui jalur ini, Anda dapat mengakses layanan Anda dari luar. Tujuannya adalah untuk menghindari mengekspos IP mesin Anda dan rute yang berorientasi layanan, dan memilih yang tersedia untuk Anda. # Berikut, Zuul secara otomatis tergantung pada hystrix dan pita, bukan untuk jalur yang berdiri sendiri: /hello-service /**# Ini pasti nama layanan di pusat pendaftaran Eureka Anda. Oleh karena itu, serviceID dikonfigurasi di sini karena dikombinasikan dengan Eureka. Jika Anda menggunakan Zuul saja, Anda harus menulis IP mesin Anda sendiri. #such as URL: http: // localhost: 8080/Ini tidak cukup baik untuk menulis IP mati. Jika IP ini gagal dan ini adalah ketersediaan tinggi, set pendaftaran layanan tidak akan digunakan. ServiceID: Hello-ServiceEureka: #Client: #Registrasi Alamat Pusat Layanan-URL: DefaultZone: http: // localhost: 8888/eureka/, http: // localhost: 8889/eureka/
Kemudian mulailah pusat registri dan dua penyedia layanan Hello-Service di artikel sebelumnya. Kemudian kami menjalankannya dan melihat fungsi penerusan permintaannya untuk melihat apakah itu jajak pendapat ke dalam dua layanan.
Masukkan LocalHost: 5000/Hello-Service/Hello, sebagai berikut:
Lalu menyegarkan lagi:
Anda dapat melihat bahwa Zuul telah membuat permintaan untuk mendistribusikannya. Ini dipetakan ke mesin tertentu berdasarkan nama layanan Anda Hello-Servie. Bukankah ini fungsi proxy terbalik?
Zuul juga dapat melakukan pemfilteran permintaan, jadi mari kita lakukan verifikasi token untuk menunjukkan. Pertama, kita perlu membuat kelas TokenFilter baru untuk mewarisi kelas Zuulfilter dan mengimplementasikan empat antarmuka. Kodenya adalah sebagai berikut:
Paket hjc.zuul; import com.netflix.zuul.zuulfilter; import com.netflix.zuul.context.requestcontext; import javax.servlet.http.httpservletrequest;/*** dibuat oleh CONG pada 2018/5/18. */TokenFilter kelas publik memperluas Zuulfilter {// Empat Jenis: Pra, Routing, Kesalahan, Posting // Pre: Ini terutama digunakan dalam tahap pemetaan perutean untuk menemukan tabel pemetaan routing // Routing: Filter penerusan routing spesifik ada di router perutean. Saat meneruskan permintaan spesifik, itu akan dipanggil // kesalahan: Setelah kesalahan filter sebelumnya terjadi, filter kesalahan akan dipanggil. // Posting: Filter ini tidak akan dipanggil setelah perutean dan kesalahan selesai. Ini adalah @Override public string filtertype () {return "pre"; } // Kustomisasi urutan eksekusi filter. Semakin besar nilainya, semakin banyak eksekusi. Semakin kecil nilainya, semakin banyak dieksekusi, semakin banyak dieksekusi terlebih dahulu. @Override public int filterorder () {return 0; } // Kontrol filter agar berlaku atau tidak. Anda dapat menulis serangkaian logika di dalamnya untuk mengontrol @override public boolean seharusnya filter () {return true; } // jalankan logika filter @Override public object run () {requestContext context = requestContext.getCurrentContext (); HttpservletRequest request = context.getRequest (); String token = request.getParameter ("token"); if (token == null) {context.setsendzuulResponse (false); Context.SetResponseStuScode (401); Context.SetResponseBody ("tidak ottalisasi"); kembali nol; } return null; }}FilterType: Mengembalikan string yang mewakili jenis filter. Empat jenis filter dengan siklus hidup yang berbeda didefinisikan dalam Zuul, sebagai berikut:
1. pre : Ini dapat dipanggil sebelum permintaan dialihkan. Ini digunakan untuk menemukan tabel pemetaan perutean selama tahap pemetaan perutean.
2.route : dipanggil selama permintaan perutean. Filter penerusan routing spesifik akan dipanggil saat merutekan penerusan permintaan spesifik router.
3. error : Dipanggil saat kesalahan terjadi saat memproses permintaan
4. post : Filter tidak akan dipanggil setelah perutean dan kesalahan selesai, yang ada pada tahap terakhir.
Di sini kami menyatakan pengecualian yang terjadi ketika filter Zuul menjalankan permintaan jaringan. Pengecualian yang ditangkap oleh TRY-Catch tidak dapat langsung dilemparkan ke halaman di filter. Pengecualian yang dilemparkan oleh aplikasi dapat dikembalikan ke halaman dengan menggunakan metode Context.set () dalam tangkapan. sebagai berikut:
coba {Business Logic ...} catch (Exception e) {RequestContext Context = RequestContext.GetCurrentContext (); context.set ("error.status_code", 401); context.set ("error.exception", e); context.set ("error.message", "sfdfsdf");}Selanjutnya, Anda perlu menambahkan filter ini ke Spring dan membiarkan Spring mengelolanya. Kodenya adalah sebagai berikut:
Paket hjc; impor hjc.zuul.tokenfilter; impor org.springframework.boot.springapplication; impor org.springframework.boot.autoconfigure.springbootApplication; impor org.springframework.cloud.netflix.zuulblex; org.springframework.context.annotation.bean;@springbootApplication@enablezuulproxypublic kelas ZuulApplication {public static void main (string [] args) {springapplication.run (zuulapplication.class, args); } // tinggalkan filter ke manajemen musim semi @Bean TokenFilter tokenFilter () {return new TokenFilter (); }}Selanjutnya, mari kita mulai kelas startup dan akses pertama tanpa token, sebagai berikut:
Anda dapat melihat bahwa pesan tanpa izin dikembalikan. Di sini saya ingin mengatakan bahwa token biasanya ditempatkan di header permintaan. Di sini kami tidak melakukan itu untuk tujuan demonstrasi.
Kemudian ambil token dan kunjungi, sebagai berikut:
Anda dapat melihat bahwa permintaan kami telah dikirim.
Di sini saya akan berbicara tentang apa rute default dan menghapus konfigurasi Zuul, sebagai berikut:
Server: Port: 5000Spring: Aplikasi: Nama: Api-Getewayeureka: #Client Client: #Register Center Alamat Layanan-URL: Defaultzone: http: // localhost: 8888/eureka/, http: // localhost: 8889/eureka/
Kemudian, restart dan lanjutkan akses, sebagai berikut:
,
Anda dapat melihat bahwa kami masih dapat terus mengakses. Kami tidak ada hubungannya, tetapi kami masih dapat mengaksesnya. Itu karena, secara default, Anda secara otomatis dinyatakan dengan nama layanan Anda Hello-Service.
Jadi, jika saya tidak ingin secara otomatis mendeklarasikannya untuk saya dan saya ingin mendefinisikannya sendiri, maka saya dapat menggunakan servis zuu.
Zuul: #Jika Layanan Diabaikan:* berarti semua rute default telah kedaluwarsa. Anda harus mencocokkannya satu per satu. Tidak ada yang akan kacau, kecuali Anda bertemu dengan bisnis aneh mengabaikan layanan:
Mari kita bicara tentang aturan pemetaan, misalnya
Zuul: Rute:#Identifikasi Nama Layanan Anda, Anda dapat mendefinisikannya sendiri di sini. Secara umum, kenyamanan dan spesifikasi sama dengan nama layanan Anda Hello-Service: #Service Mapped Path, melalui jalur ini, Anda dapat mengakses layanan Anda dari luar. Tujuannya adalah untuk menghindari mengekspos IP mesin Anda, dan rute berorientasi layanan adalah untuk Anda. #Herhere Zuul secara otomatis tergantung pada hystrix dan pita, bukan untuk jalur yang berdiri sendiri: /hello-service /**#Ini harus menjadi nama layanan pusat pendaftaran Eureka Anda, sehingga serviceId dikonfigurasi di sini karena dikombinasikan dengan eureka. Jika Anda menggunakan Zuul saja, Anda harus menulis IP mesin Anda, #such sebagai url: http: // localhost: 8080/Ini buruk, itu berarti menulis IP mati. Jika IP ini gagal dan ketersediaan tinggi, set pendaftaran layanan tidak akan digunakan serviceID: hello-servicezuul: rute: hello-service: path:/hello-service/ext/** serviceid: hello-service
Dua jalur pemetaan konfigurasi Zuul di sini memiliki /hello-service /. Anda dapat melihat itu/hello-service/** termasuk/hello-service/ext/**. Apakah ada konflik saat mencocokkan kedua jalur ini? Bagaimana cara menghadapinya? Siapa yang akan cocok terlebih dahulu?
Inilah urutan yang ditentukan dalam YML untuk dicocokkan. Jika ini adalah file konfigurasi dalam format application.properties, pesanan ini tidak dapat dijamin. File konfigurasi dalam format YML berurutan, yang dapat dijamin. Harap perhatikan ini di sini.
Bagaimana jika kita ingin mendefinisikan aturan yang cocok? Kemudian kita perlu mendefinisikan kacang di kelas startup, yang menentukan rute Anda, sebagai berikut:
Saya tidak akan menunjukkannya di sini. Saat Anda membutuhkannya, pergi dan cari informasi secara perlahan.
Ada juga pola abaikan: sebagai berikut:
Zuul: Rute:#Identifikasi Nama Layanan Anda, Anda dapat mendefinisikannya sendiri di sini. Secara umum, kenyamanan dan spesifikasi sama dengan nama layanan Anda Hello-Service: #Service Mapped Path, melalui jalur ini, Anda dapat mengakses layanan Anda dari luar. Tujuannya adalah untuk menghindari mengekspos IP mesin Anda, dan rute berorientasi layanan adalah untuk Anda. #Herhere Zuul secara otomatis tergantung pada hystrix dan pita, bukan untuk jalur yang berdiri sendiri: /hello-service /**#Ini harus menjadi nama layanan pusat pendaftaran Eureka Anda, sehingga serviceId dikonfigurasi di sini karena dikombinasikan dengan eureka. Jika Anda menggunakan Zuul saja, Anda harus menulis IP mesin Anda, #such sebagai url: http: // localhost: 8080/Ini buruk, itu berarti menulis IP mati. Jika IP ini gagal dan ketersediaan tinggi, set pendaftaran layanan tidak akan digunakan serviceID: Hello-Service diabaikan-pola: /halo /**
Abaikan-pola: Menunjukkan bahwa jalur /halo /** diblokir. Bahkan jika Anda/hello-service/hello/** tidak mungkin, Anda masih memblokirnya. Kami dapat lebih menyempurnakan konfigurasi ini. Misalnya, jika saya tidak ingin merutekan antarmuka /halo, maka kami dapat mengonfigurasinya seperti di atas
Bagaimana jika kita juga ingin mengonfigurasi awalan layanan? Kodenya adalah sebagai berikut:
Zuul: Rute:#Identifikasi Nama Layanan Anda, Anda dapat mendefinisikannya sendiri di sini. Secara umum, kenyamanan dan spesifikasi sama dengan nama layanan Anda Hello-Service: #Service Mapped Path, melalui jalur ini, Anda dapat mengakses layanan Anda dari luar. Tujuannya adalah untuk menghindari mengekspos IP mesin Anda, dan rute berorientasi layanan adalah untuk Anda. #Herhere Zuul secara otomatis tergantung pada hystrix dan pita, bukan untuk jalur yang berdiri sendiri: /hello-service /**#Ini harus menjadi nama layanan pusat pendaftaran Eureka Anda, sehingga serviceId dikonfigurasi di sini karena dikombinasikan dengan eureka. Jika Anda menggunakan Zuul saja, Anda harus menulis IP mesin Anda, #such sebagai url: http: // localhost: 8080/Ini tidak cukup baik untuk menulis IP mati. Jika IP ini gagal, ini sangat tersedia dan set pendaftaran layanan tidak akan digunakan serviceID: Hello-Service Prefix: /API /**
Anda dapat melihat bahwa layanan yang Anda kunjungi harus diawali dengan/API/, seperti/API/Hello-Service/**
Apa yang harus kita lakukan jika kita ingin melompat ke area lokal saya jika kami ingin melakukan akses jalur?
Saya berharap pengguna dapat secara otomatis melompat ke metode ini saat mengakses /lokal. Jadi saat ini, kita perlu menggunakan lompatan lokal Zuul, dan metode konfigurasi adalah sebagai berikut:
zuul: awalan:/API-pola diabaikan:/**/halo/** Rute: Lokal: Path:/Hello-Service/** URL: Maju:/Lokal
Beberapa yang umum digunakan, menghubungkan ke Springsecurity atau beberapa komponen pihak ketiga, akan mendapatkan beberapa informasi cookie Anda. Jadi Zuul Gateway telah membunuh semua informasi cookie Anda karena alasan keamanan, dan tidak ada cara untuk membuat cookie. Itu dibunuh secara default.
Di sini Zuul menyediakan Zuul. Header yang sensitif untuk membuat cookie dan header ini untuk Anda, dan jangan memfilter informasi ini. Kontrol informasi sensitif Anda.
Secara default, informasi header sensitif tidak dapat dilewati melalui gateway API. Kita dapat membuatnya lumayan melalui konfigurasi berikut:
Zuul: Rute: Hello-Service: Path: /Hello-Service /** ServiceID: Hello-Service Sensitive-Headers: Cookie, Header, dan hal-hal lainnya
Ini juga dapat digunakan dengan beberapa konfigurasi rinci Hystrix, seperti yang disebutkan sebelumnya. Saya tidak akan membicarakannya di sini
Di atas adalah semua konten artikel ini. Saya berharap ini akan membantu untuk pembelajaran semua orang dan saya harap semua orang akan lebih mendukung wulin.com.