Kata pengantar
Sekarang semakin banyak perusahaan yang merangkul Spring Cloud. Spring Boot adalah generasi berikutnya dari kerangka kerja web dan Spring Cloud adalah pemimpin dalam layanan mikro terbaru dan paling populer. Alasan apa yang harus Anda tolak? Banyak siswa di Java juga mulai secara aktif belajar Spring Cloud. Bahkan, ada masalah lain di sini: Meskipun semua orang telah belajar Eureka, Ribbon, Hystrix, Zuul, Retign, dll., Masih sulit untuk menerapkannya pada proyek yang sebenarnya.
Kesulitan layanan mikro terletak pada pemisahan layanan. Kerangka kerja hanyalah sebuah alat, dan banyak orang akan menggunakannya. Pemisahan layanan dan hubungan antara layanan adalah hal -hal yang perlu dipertimbangkan selama pemisahan.
Hari ini seorang teman sekelas mengirimi saya email untuk bertanya kepada saya tentang dua pertanyaan berikut:
Berikut adalah beberapa jawaban berdasarkan pengalaman saya sendiri, hanya untuk referensi:
Mengenai API dalam pertanyaan pertama adalah pengontrol di bawah setiap layanan mikro?
Apa yang kami sebut API sebenarnya adalah antarmuka, dan kebanyakan dari mereka dikembangkan menggunakan Spring MVC, yang merupakan metode beranotasi dalam pengontrol. Anotasi adalah yang sering kita gunakan:
Mengenai pertanyaan pertama, apakah memerlukan proyek terpadu untuk merangkum pengontrol layanan mikro lainnya?
Sebenarnya tidak ada pola yang tetap. Sebagian besar dari ini langsung diteruskan ke layanan bisnis Anda melalui API Gateway
Ambil kategori bisnis situs web blog seperti Yuantiandi sebagai contoh:
Ada fungsi bisnis. Ketika saya melihat posting blog tertentu, informasi yang perlu saya kembalikan adalah sebagai berikut:
Pada saat ini, antarmuka kami untuk melihat artikel sebenarnya melibatkan tiga bagian data, informasi artikel itu sendiri, informasi komentar, dan informasi penulis.
Ada 3 layanan, layanan pengguna, layanan blog, dan layanan komentar
Jadi pertanyaannya adalah, itu melibatkan interaksi antara beberapa layanan sebelumnya. Faktanya, pertanyaan yang sama dengan teman sekelas di atas bertanya kepada saya. Apakah saya perlu memiliki proyek terpadu dan mengumpulkan layanan lain? Bisakah mereka saling menelepon?
Saya merekomendasikan dua cara untuk mengimplementasikan ini:
1. Gerbang API ke depan langsung ke Layanan Blog
API kami adalah antarmuka untuk mendapatkan informasi posting blog. Badan utama harus menjadi layanan blog. Ada antarmuka untuk informasi posting blog di layanan blog. Di antarmuka, kami menghubungi antarmuka informasi pengguna yang disediakan oleh Layanan Pengguna, dan kami juga memanggil informasi komentar posting blog di layanan komentar. Mari kita lihat kode pseudo:
@GetMapping ("/blog/detail/{id}") Bloginfo publik blogInfo (@pathvariable ("id") Long ID) {// Dapatkan informasi blog blog blog = blogService.getById (id); // Dapatkan informasi pengguna userInfo userInfo = userfeignclient.getUserInfo (blog.getUserId ()); // Dapatkan informasi komentar komentarinfo komentarinfo = komentarfeignclient.getcommentInfo (id); Kembalikan kumpulkan semua informasi dan kembalikan. }2. Tambahkan lapisan layanan agregasi
Lapisan layanan pengumpulan adalah teman sekelas di atas, apakah perlu memiliki proyek terpadu untuk melakukan layanan perakitan? Ini berarti bahwa layanan blog kami masih memberikan informasi blog dasar, dan layanan agregasi bisnis yang terpisah ditambahkan untuk mengumpulkan informasi ini dan mengembalikannya ke penelepon secara seragam. Kode pseudo adalah sebagai berikut:
@GetMapping ("/blog/detail/{id}") Bloginfo publik blogInfo (@pathvariable ("id") Long ID) {// Dapatkan informasi blog blog blog = blogfeignclient.getById (id); // Dapatkan informasi pengguna userInfo userInfo = userfeignclient.getUserInfo (blog.getUserId ()); // Dapatkan informasi komentar komentarinfo komentarinfo = komentarfeignclient.getcommentInfo (id); Kembalikan kumpulkan semua informasi dan kembalikan. }Data disebut dari jarak jauh, tentu saja Anda bisa menyebutnya secara paralel di sini. Cara lain adalah melakukan operasi agregasi di Gateway API. Solusi ini juga layak. Saya sarankan untuk tidak melakukannya di gateway. Gateway API sesederhana mungkin dan hanya maju. Menambahkan lapisan layanan agregasi adalah pilihan yang baik.
Jika tata kelola layanan Anda dibangun dengan Dubbo, lapisan layanan agregasi juga merupakan metode yang lebih baik. Agregasi Layanan Dubbo menyediakan antarmuka HTTP ke panggilan eksternal.
3. Penelepon memperoleh berbagai data sendiri
Cara lain adalah dengan memanggil antarmuka blog, antarmuka komentar, dan antarmuka pengguna sendiri. Dengan cara ini, antarmuka hanya perlu memperhatikan data sendiri dan menyerahkan masalah perakitan kepada pengguna. Ini umumnya lebih sedikit digunakan. Yang terbaik adalah mengembalikan data ke penelepon pada satu waktu, dan menyebutnya berulang kali, terutama di terminal seluler, yang membutuhkan terlalu banyak permintaan dan membuang -buang lalu lintas.
Meringkaskan
Adapun cara merakit data, Anda harus memutuskannya sendiri. Anda dapat menempatkan perakitan di layanan bisnis yang sesuai, atau menambahkan layanan agregasi untuk mengumpulkannya secara terpisah, atau membiarkan klien mengumpulkannya dengan sendirinya.
Layanan pasti bisa dipanggil satu sama lain. Jika mereka tidak dapat dipanggil satu sama lain, lalu apa gunanya memecah mereka? Gunakan peti untuk menghubungi antarmuka layanan, dan Anda hanya memperlakukannya sebagai panggilan antar layanan.
Oke, di atas adalah seluruh konten artikel ini. Saya berharap konten artikel ini memiliki nilai referensi tertentu untuk studi atau pekerjaan semua orang. Jika Anda memiliki pertanyaan, Anda dapat meninggalkan pesan untuk berkomunikasi. Terima kasih atas dukungan Anda ke wulin.com.