Cara Mengatur Arsitektur Layanan Mikro di Ruby: Panduan Langkah demi Langkah

Apa Itu Layanan Mikro?

Layanan mikro adalah salah satu tren terbaru dalam desain perangkat lunak di mana beberapa layanan independen berkomunikasi di antara mereka sendiri dan memiliki proses dan sumber daya mereka sendiri. Pendekatan ini berbeda dari desain aplikasi client-server yang khas. Aplikasi client-server biasa terdiri dari satu atau lebih klien, back-end monolitik yang mencakup semua data domain dan logika, dan API yang memungkinkan klien untuk mengakses back-end dan fungsinya.

Dalam arsitektur layanan mikro, backend monolitik yang dijelaskan malah digantikan oleh serangkaian layanan terdistribusi. Desain ini memungkinkan pemisahan tanggung jawab yang lebih baik, perawatan yang lebih mudah, fleksibilitas yang lebih besar dalam pilihan teknologi untuk setiap layanan, dan skalabilitas serta toleransi kesalahan yang lebih mudah. Pada saat yang sama, sistem terdistribusi yang kompleks memiliki tantangan tersendiri. Mereka memiliki peluang lebih besar untuk berurusan dengan kondisi balapan, dan lebih sulit untuk di-debug karena masalah tidak mudah diarahkan ke satu layanan tunggal, tetapi didistribusikan melalui banyak layanan. Jika upaya tidak dilakukan untuk mengikuti praktik terbaik saat membangun sistem seperti itu, Anda mungkin menemukan diri Anda dikelilingi oleh api yang Anda tidak tahu cara memadamkannya. Perhatian khusus harus diberikan dengan kontrak muatan layanan, karena perubahan dalam satu layanan dapat memengaruhi semua kliennya, dan akibatnya semua rangkaian layanan back-end.

Semua pertimbangan ini penting, tetapi mari kita asumsikan Anda sudah memikirkannya. Sekarang yang Anda inginkan adalah menemukan cara untuk membangun back-end layanan mikro sendiri. Jadi mari kita selami itu.

Cara Mengatur Arsitektur Layanan Mikro

Saat ini ada banyak cara Anda dapat mengatur layanan mikro Anda, dan dalam panduan ini kami akan fokus pada arsitektur broker.

Arsitektur Pialang

Arsitektur broker adalah salah satu cara agar layanan Anda dapat berkomunikasi di antara mereka sendiri. Di dalamnya, semua layanan mengelilingi server perpesanan, broker, dan semua terhubung dengannya. Layanan mengirim pesan ke broker, yang kemudian mengetahui layanan atau layanan lain mana yang dia butuhkan untuk meneruskan pesan ini. Dengan cara ini, layanan tidak perlu menyimpan informasi tentang layanan lain. Sebaliknya, mereka mengandalkan broker untuk mengurus semua pesan, dan memungkinkan mereka untuk diisolasi dan fokus hanya pada domain khusus mereka. Pialang juga dapat menyimpan pesan ketika penerima mereka sedang down, memungkinkan pengirim dan penerima untuk tidak dipaksa untuk naik secara bersamaan, sehingga memungkinkan untuk isolasi yang lebih besar. Tentu saja, ada kekurangan dari solusi ini karena broker dapat dengan cepat menjadi hambatan karena semua komunikasi harus melalui mereka, dan itu juga bisa menjadi satu titik kegagalan untuk backend Anda. Namun, ada beberapa cara untuk mengurangi masalah ini. Salah satu caranya adalah dengan menjalankan beberapa contoh broker secara paralel, yang akan memungkinkan toleransi kesalahan sistem yang lebih baik. Cara lain akan menggunakan arsitektur lain. Arsitektur alternatif berbeda dari arsitektur yang akan kami terapkan dalam panduan ini dengan tidak menggunakan broker, atau dengan menggunakan arsitektur broker yang berbeda, atau dengan menggunakan protokol pengiriman pesan yang berbeda seperti HTTP.

Komunikasi Antar Layanan

Dalam panduan ini, kami akan menggunakan ZeroMQ untuk menangani komunikasi antara layanan dan broker.

ZeroMQ menyediakan lapisan abstraksi protokol yang menangani pesan asinkron multi-bagian melalui transportasi acak. Keuntungan menggunakan ZeroMQ untuk pengiriman pesan antara layanan dan broker berada di luar cakupan panduan ini, jadi kami tidak akan membahasnya di sini, tetapi jika Anda ingin tahu lebih banyak tentangnya, lihat artikel Quora berikut. Jika Anda tertarik untuk mencari cara lain agar layanan Anda saling berkomunikasi, saya sarankan Anda melihat artikel Broker vs. Brokerless untuk melihat apa lagi yang bisa dicapai.

Membangun Suite Layanan Mikro

Artikel ini akan memandu Anda melalui semua langkah yang diperlukan untuk membuat suite layanan mikro Anda. Sistem kami akan terdiri dari broker dan layanan. Kami juga akan menggunakan skrip klien kecil untuk menguji panggilan ke rangkaian layanan, tetapi perlu diingat bahwa kode klien dapat dengan mudah digunakan di mana saja.

Jadi, mari kita mulai membangun.

Mulai

Pertama, pastikan Anda memiliki semua yang Anda butuhkan untuk menjalankan broker dan layanannya. Pertama, mulailah dengan mengunduh dan menginstal Node.js, ZeroMQ, dan Git di komputer Anda. Jika Anda menggunakan OSX, ada paket homebrew untuk masing-masingnya, dan sebagian besar distribusi Linux juga memiliki paket untuk masing-masingnya, jadi Anda seharusnya tidak memiliki masalah dengan ini. Pengguna Windows cukup menggunakan tautan unduhan yang disediakan di atas.

Menjalankan Pialang

Setelah menginstal semua dependensi yang diperlukan, mari jalankan broker kita. Dalam panduan ini, kami menggunakan implementasi Node.js dari broker yang merupakan bagian dari ZMQ Service Oriented Suite. Anda dapat menemukan kode dan dokumentasinya di GitHub. Untuk menjalankan broker, pertama-tama klon bootstrap Broker ke mesin Anda. Repositori ini adalah bootstrap untuk menggunakan library broker di atas. Catatan, langkah ini tidak diperlukan karena pustaka asli itu sendiri dapat dijalankan, tetapi perbedaan antara keduanya adalah bahwa dalam repositori bootstrap Anda dapat mengubah konfigurasi default.

Jadi, pertama, gunakan perintah Git berikut untuk mengunduh proyek ke mesin Anda:

 $ git clone [email protected]:dadah/zmq-broker-bootstrap.git

Setelah Anda selesai melakukannya, pindah ke direktori yang dibuat:

 $ cd zmq-broker-bootstrap

Sekarang instal dependensi paket:

 $ npm install

Broker sekarang sudah siap. Untuk menjalankan broker Anda, jalankan perintah berikut:

 $ bin/zss-broker run

Anda dapat menemukan file konfigurasi untuk setiap lingkungan di direktori config/ . Ini adalah konfigurasi pengembangan default:

 { "broker": { "backend": "tcp://127.0.0.1:7776", "frontend": "tcp://127.0.0.1:7777" }, "log": { "consolePlugin": { "level": "debug" } } }

Parameter backend menentukan alamat ip:port dari back-end dan front-end broker. Alamat back-end adalah tempat broker menerima permintaan dari dan membalas layanan, dan alamat front-end adalah tempat ia menerima dan mengirim ke klien layanan. Anda juga dapat mengatur level logging dengan mengubah log.consolePlugin.level . Nilai yang mungkin adalah trace , debug , info , warn dan error , dan nilai tersebut menentukan jumlah informasi logging yang akan dihasilkan oleh proses broker.

Menjalankan Layanan

Setelah broker Anda aktif, sekarang saatnya untuk mengembangkan layanan mikro Ruby pertama Anda. Mulailah dengan membuka jendela konsol baru. Kemudian, buat direktori tempat layanan Anda akan disimpan dan kemudian pergi ke direktori itu. Dalam panduan ini, kami menggunakan klien Ruby dan layanan ZMQ SOA Suite. Ada layanan bootstrap "Hello world" yang tersedia, jadi mari kita gunakan untuk menjalankan layanan mikro pertama kita.

Buka direktori layanan Anda dan klon repositori bootstrap:

 $ git clone [email protected]:dadah/zmq-service-suite-ruby-bootstrap.git

Buka direktori yang baru dibuat:

 $ cd zmq-service-suite-ruby-bootstrap

Sekarang instal semua dependensi:

 $ bundle install

Untuk memulai layanan, jalankan perintah berikut:

 $ bin/zss-service run

Besar. Anda memiliki dan menjalankan layanan pertama Anda.

Jika Anda pergi ke jendela konsol tempat Anda membiarkan broker Anda berjalan, Anda dapat melihat output berikut:

 2015-12-15 16:45:05 | INFO | BROKER - Async Broker is waiting for messages... 2015-12-15 16:45:14 | DEBUG | BACKEND - received from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 76f50741-913a-43b9-94b0-36d8f7bd75b1 2015-12-15 16:45:14 | DEBUG | BACKEND - routing from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 76f50741-913a-43b9-94b0-36d8f7bd75b1 to SMI.UP request... 2015-12-15 16:45:14 | INFO | SMI - SMI register for sid: HELLO-WORD instance: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b! 2015-12-15 16:45:14 | DEBUG | BACKEND - reply to: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 76f50741-913a-43b9-94b0-36d8f7bd75b1 with status: 200 2015-12-15 16:45:15 | DEBUG | BACKEND - received from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 3b3a0416-73fa-4fd2-9306-dad18bc0502a 2015-12-15 16:45:15 | DEBUG | BACKEND - routing from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 3b3a0416-73fa-4fd2-9306-dad18bc0502a to SMI.HEARTBEAT request... 2015-12-15 16:45:15 | DEBUG | BACKEND - reply to: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 3b3a0416-73fa-4fd2-9306-dad18bc0502a with status: 200 2015-12-15 16:45:16 | DEBUG | BACKEND - received from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: b3044c24-c823-4394-8204-1e872f30e909 2015-12-15 16:45:16 | DEBUG | BACKEND - routing from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: b3044c24-c823-4394-8204-1e872f30e909 to SMI.HEARTBEAT request... 2015-12-15 16:45:16 | DEBUG | BACKEND - reply to: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: b3044c24-c823-4394-8204-1e872f30e909 with status: 200

Log ini berarti broker telah mengakui keberadaan layanan baru dan menerima pesan detak jantung darinya. Setiap detik, layanan mengirimkan pesan detak jantung ke broker, sehingga tahu bahwa instance layanan sudah habis.

Mengkonsumsi dari Layanan

Jadi sekarang kami memiliki layanan yang berjalan, bagaimana kami menggunakannya?

Di repositori bootstrap, ada klien dummy yang dapat Anda gunakan untuk menguji layanan "Hello World" Anda. Cukup buka jendela atau tab konsol baru, dan buka direktori layanan Anda. Setelah Anda berada di sana, jalankan perintah berikut:

 $ bin/zss-client

Anda akan melihat sesuatu seperti ini:

 15-49-15 16:49:54 | INFO | ZSS::CLIENT - Request 90a88081-3485-45b6-91b3-b0609d64592a sent to HELLO-WORD:*#HELLO/WORLD with 1.0s timeout 15-49-15 16:49:54 | INFO | ZSS::CLIENT - Received response to 90a88081-3485-45b6-91b3-b0609d64592a with status 200 "Hello World"

Jika Anda pergi ke jendela konsol tempat layanan Anda berjalan, Anda akan melihat ini:

 Started hello-word daemon... 15-45-15 16:45:14 | INFO | ZSS::SERVICE - Starting SID: 'HELLO-WORD' ID: 'hello-word#aaa65374-8585-410a-a41d-c8a5b024553b' Env: 'development' Broker: 'tcp://127.0.0.1:7776' 15-49-15 16:49:54 | INFO | ZSS::SERVICE - Handle request for HELLO-WORD:*#HELLO/WORLD 15-49-15 16:49:54 | INFO | ZSS::SERVICE - Reply with status: 200

Bagus. Anda baru saja meluncurkan dan menggunakan layanan mikro "Hello World" Anda. Ini bukan, bagaimanapun, apa yang kami mulai lakukan. Kami ingin membangun layanan kami. Mari kita ke sana, kalau begitu.

Membangun Layanan Anda

Pertama, mari hentikan layanan “Hello World” kami. Buka jendela konsol layanan dan tekan Ctrl+C untuk menghentikan layanan. Selanjutnya kita perlu mengubah layanan "Hello World" menjadi layanan "Orang".

Struktur Kode

Mari kita mulai dengan melihat pohon kode proyek. Ini terlihat seperti ini:

• Direktori bin adalah tempat Anda menyimpan skrip yang meluncurkan layanan Anda.
• Direktori config menyimpan semua file konfigurasi.
  • File boot.rb adalah tempat Anda dapat menambahkan semua dependensi layanan Anda. Jika Anda membukanya, Anda dapat melihat ada banyak dependensi yang sudah terdaftar di sana. Jika Anda perlu menambahkan lagi, di sinilah Anda harus melakukannya.
  • File application.yml menyimpan semua pengaturan aplikasi Anda. Kami akan melihat file ini nanti.
  • Di direktori config/initializers Anda dapat menambahkan skrip penginisialisasi Anda. Anda dapat, misalnya, menambahkan pengaturan untuk koneksi ActiveRecord atau Redis di sini. Skrip yang Anda tambahkan ke direktori ini akan berjalan pada startup layanan.
• Di direktori db/migrate Anda dapat menyimpan migrasi ActiveRecord atau Sekuel Anda jika ada. Jika tidak, Anda dapat menghapus direktori ini sama sekali.
• Direktori lib adalah tempat kode aplikasi utama Anda berada.
  • File settings.rb hanya memuat file application.yml dan membuatnya tersedia di seluruh cakupan layanan, sehingga Anda dapat mengakses konfigurasi Anda di mana saja. Misalnya, Settings.broker.backend mengembalikan alamat backend broker yang Anda tentukan dalam file YML di atas.
  • File service_register.rb adalah tempat Anda mendaftarkan layanan dan rute layanan Anda. Kami akan menjelaskannya nanti.
  • File hello_world_service.rb mendefinisikan titik akhir layanan "Hello World".
  • Direktori lib/daos adalah tempat Anda menyimpan objek ActiveModel Anda jika Anda menggunakan ActiveRecord, atau objek akses data lainnya yang mungkin nantinya Anda buat, seperti model Sekuel Anda.
  • Direktori lib/dtos menyimpan objek transfer data Anda. Objek-objek ini adalah objek yang akhirnya dikirim kembali ke klien layanan.
  • Direktori lib/repositories menyimpan repositori Anda. Repositori adalah objek yang memungkinkan layanan mengakses data dan merupakan satu-satunya objek yang diizinkan untuk menangani DAO. Jadi, jika suatu layanan menginginkan sekelompok instance "Hello World", ia akan meminta repositori untuk mereka. Repositori, pada gilirannya, menggunakan DAO yang sesuai untuk mengambil data yang relevan dari database. Data tersebut kemudian dipetakan ke dalam kumpulan DTO “HelloWorld” atau DTO “HelloWorld” yang sesuai yang dikembalikan ke layanan.
  • Direktori lib/repositories/mappers adalah tempat Anda menyimpan pembuat peta. Pemeta adalah objek yang mengubah DAO menjadi DTO, dan sebaliknya.

File application.yml dari direktori config terlihat seperti ini:

 defaults: &defaults broker: backend: tcp://127.0.0.1:7776 frontend: tcp://127.0.0.1:7777 logging: console: level: info development: <<: *defaults test: <<: *defaults production: <<: *defaults

Pengaturan ini hanya mengatur alamat back-end dan front-end broker, dan tingkat logging.

Jika semua ini terdengar membingungkan sejauh ini, jangan khawatir karena ini akan menjadi lebih jelas saat kita melanjutkan.

Layanan "Orang"

Jadi, mari lanjutkan dengan layanan "Orang" kami. Mari kita mulai dengan mengkonfigurasi koneksi database. Buka file config/initializers/active_record.rb dan batalkan komentar satu-satunya baris di sana. Kemudian, tambahkan entri berikut ke konfigurasi pengembangan Anda di application.yml sehingga terlihat seperti ini:

 defaults: &defaults broker: backend: tcp://127.0.0.1:7776 frontend: tcp://127.0.0.1:7777 logging: console: level: info database: adapter: postgresql database: zss-tutorial-development

Sekarang setelah Anda menambahkan konfigurasi database, Anda harus membuat database. Saat ini, tidak ada cara untuk melakukan ini secara otomatis kecuali Anda menggunakan database PostgreSQL default, dalam hal ini Anda cukup menjalankan:

 $ rake db:create

Jika Anda lebih suka database lain, Anda harus menambahkan permata yang sesuai ke file gem dan kemudian bundel menginstal proyek.

Selanjutnya adalah migrasi. Untuk itu, cukup buat file db/migrate bernama 000_creates_persons.rb :

 $ touch db/migrate/000_creates_persons_table.rb

Buka file dan buat migrasi seperti yang Anda lakukan dengan migrasi Rails biasa:

 class CreatesPersons < ActiveRecord::Migration def change create_table :persons do |t| t.name t.timestamps end end end

Selanjutnya, jalankan:

 $ rake db:migrate == 0 CreatesPersons: migrating ================================================ -- create_table(:persons) DEPRECATION WARNING: `#timestamp` was called without specifying an option for `null`. In Rails 5, this behavior will change to `null: false`. You should manually specify `null: true` to prevent the behavior of your existing migrations from changing. (called from block in change at /Users/francisco/Code/microservices-tutorial/db/migrate/000_creates_persons.rb:6) -> 0.0012s == 0 CreatesPersons: migrated (0.0013s) =======================================

Sekarang setelah tabel kita dibuat, mari buat model untuknya. Buat file lib/daos/person.rb :

 $ touch lib/daos/person.rb

Sunting seperti ini:

 module DAO class Person < ActiveRecord::Base end end

Ada model Anda. Sekarang Anda perlu membuat model DTO untuk "Orang" sehingga Anda dapat mengembalikannya ke klien. Buat file lib/dtos/person.rb :

 $ touch lib/dtos/person.rb

Sunting seperti ini:

 module DTO class Person < Base attr_reader :id, :name end end

Selanjutnya Anda harus membuat Mapper untuk mengubah DAO “Orang” menjadi DTO “Orang”. Buat file lib/repositories/mappers/person.rb , dan edit seperti ini:

 module Mapper class Person < Mapper::Base def self.to_dao dto_instance DAO::Person.new id: dto_instance.id, name: dto_instance.name end def self.to_dto dao_instance DTO::Person.new id: dao_instance.id, name: dao_instance.name end end end

Di sini, Mapper::Base mengharuskan Anda untuk mengimplementasikan self.to_dao dan self.to_dto . Jika Anda tidak ingin melakukannya, Anda dapat mengimplementasikan self.map sebagai gantinya dan mengganti Mapper::Base.map yang memanggil to_dao atau to_dto , tergantung pada apakah atribut yang diterimanya adalah DAO atau DTO.

Sekarang Anda memiliki DAO untuk mengakses database Anda, DTO untuk mengirimkannya ke klien, dan Mapper untuk mengkonversi satu ke yang lain. Anda sekarang dapat menggunakan ketiga kelas ini dalam repositori untuk membuat logika yang memungkinkan Anda mendapatkan orang dari database dan mengembalikan koleksi DTO yang sesuai.

Mari kita buat repositorinya. Buat file lib/repositories/person.rb :

 $ touch lib/dtos/person.rb

Sunting seperti ini:

 module Repository class Person < Repository::Base def get DAO::Person.all.map do |person| Mapper::Person.map(person) end end end end

Repositori ini hanya memiliki metode instance get yang hanya mengambil semua orang dari database dan memetakannya ke dalam kumpulan DTO orang - cukup sederhana. Mari kita membawa ini semua bersama-sama sekarang. Yang tersisa sekarang adalah membuat layanan dan titik akhir yang memanggil repositori ini. Untuk melakukannya, mari buat file lib/person_service.rb :

 $ touch lib/person_service.rb

Sunting seperti ini:

 class PersonService < BaseService attr_reader :person_repo def initialize @person_repo = Repository::Person.new end def get payload, headers persons = person_repo.get() if persons.empty? raise ZSS::Error.new(404, "No people here") else persons.map &:serialize end end end

Layanan "Orang" menginisialisasi repositori di penginisialisasinya. Semua metode instans publik dari layanan "Orang" memiliki muatan dan tajuk yang dapat Anda hilangkan jika Anda tidak membutuhkannya. Keduanya adalah Hashie::Mash dan mereka menyimpan variabel yang dikirim ke titik akhir, baik sebagai atribut atau header, dan balasannya meniru respons HTTP karena setiap respons memiliki kode status yang dapat digunakan klien untuk mengetahui hasil permintaan yang dikirim ke layanan, bersama dengan muatan respons layanan. Kode respons sama seperti yang Anda harapkan dari server HTTP. Misalnya, permintaan yang berhasil akan mengembalikan kode status 200, bersama dengan payload respons. Jika terjadi kesalahan layanan, maka kode status akan menjadi 500, dan jika ada yang salah dengan parameter yang dikirim ke server, kode status akan menjadi 400. Layanan dapat membalas dengan sebagian besar kode status HTTP beserta muatannya. Jadi, jika misalnya Anda ingin layanan Anda memberi tahu kliennya saat mereka tidak diizinkan mengakses titik akhir tertentu, Anda dapat melakukannya dengan merespons dengan kode 403. Anda dapat melihat contoh lain dari kode respons jika Anda melihat kembali kode layanan kami di atas. Di titik akhir get , kami mengembalikan kode status 404 bersama dengan pesan opsional "Tidak ada orang di sini" ketika tidak ada orang yang ditemukan, sama seperti server HTTP akan mengembalikan 404 jika tidak ada sumber daya yang tersedia. Jika repositori memang mengembalikan orang, maka layanan membuat serial DTO dan mengembalikannya ke klien. Setiap DTO memiliki serializer default yang mengembalikan objek JSON dengan kunci dan nilai terkait yang didefinisikan sebagai attr_reader atau attr_accessible dalam definisi DTO. Anda tentu saja dapat mengganti serializer dengan mendefinisikan metode serialisasi Anda di kelas DTO Anda.

Sekarang kami memiliki layanan yang ditentukan, kami perlu mendaftarkannya. Ini adalah langkah terakhir. Buka file lib/service_register.rb dan ganti semua kemunculan “HelloWorld” dengan “Person”, sehingga file tersebut akhirnya terlihat seperti ini:

 module ZSS class ServiceRegister def self.get_service config = Hashie::Mash.new( backend: Settings.broker.backend ) service = ZSS::Service.new(:person, config) personInstance = PersonService.new service.add_route(personInstance, :get) return service end end end

Seperti yang mungkin Anda perhatikan, ada sedikit perubahan pada panggilan add_route . Kami menghapus string "HELLO/WORLD". Itu karena string hanya diperlukan jika service verb tidak cocok dengan metode yang mengimplementasikannya. Dalam kasus kami, saat memanggil layanan orang dengan kata kerja GET, metode yang akan dipanggil adalah get , jadi kami dapat menghilangkan string.

Kelas ServiceRegister adalah tempat Anda harus mendefinisikan metode self.get_service . Metode ini menginisialisasi layanan dan menghubungkannya ke backend broker. Ini kemudian mencocokkan rute pada layanan itu ke metode dalam satu atau lebih definisi layanan. Misalnya, dalam kasus berikut, ia membuat layanan dan mengikatnya ke broker:

 config = Hashie::Mash.new( backend: Settings.broker.backend ) service = ZSS::Service.new(:person, config)

Kemudian itu membuat penangan layanan:

 personInstance = PersonService.new

Selanjutnya, penangan layanan terikat ke layanan:

 service.add_route(personInstance, :get)

Akhirnya, itu harus mengembalikan instance layanan.

 return service

Sekarang, hanya ada satu langkah terakhir sebelum kami dapat meluncurkan layanan "Orang" kami; kita perlu membuat skrip yang dapat dieksekusi untuk itu. Kami sudah punya satu untuk "HelloService". Jadi, buka file bin/zss-service , ganti "hello-word" dengan "person", dan simpan file tersebut. Kembali ke konsol dan jalankan:

 $ bin/zss-service run Starting person: PID: ./log LOGS: ./log Started person daemon... 15-29-15 19:29:54 | INFO | ZSS::SERVICE - Starting SID: 'PERSON' ID: 'person#d3ca7e1f-e229-4502-ac2d-0c01d8c285f8' Env: 'development' Broker: 'tcp://127.0.0.1:7776'

Itu dia. Anda baru saja memulai layanan "Orang" Anda untuk pertama kalinya. Sekarang mari kita uji. Buka file bin/zss-client , ubah variabel sid menjadi “person” dan ubah panggilan klien dari hello_world() menjadi get() . Setelah selesai, jalankan klien di jendela baru:

 $ bin/zss-client /Users/francisco/.rvm/gems/ruby-2.1.2/gems/zss-0.3.4/lib/zss/client.rb:41:in `new': No people here (ZSS::Error) from /Users/francisco/.rvm/gems/ruby-2.1.2/gems/zss-0.3.4/lib/zss/client.rb:41:in `call' from /Users/francisco/.rvm/gems/ruby-2.1.2/gems/zss-0.3.4/lib/zss/client.rb:55:in `method_missing' from bin/zss-client:12:in `<main>'

Seperti yang Anda lihat, Anda telah menangkap ZSS::Error . Ini karena kami memunculkan kesalahan ketika tidak ada orang yang ditemukan oleh layanan dan kami belum memiliki orang di database layanan kami.

Mari kita tangani kesalahan ini. Buka zss-client dan edit seperti ini:

 begin client = ZSS::Client.new(sid, config) p client.get() rescue ZSS::Client => e if e.code == 404 p e.message else raise e end end

Sekarang kami mencetak pesan kesalahan ketika kode kesalahan 404, sambil meningkatkan kesalahan jika berbeda. Mari kita lihat beraksi dengan menjalankan klien kami lagi:

 $ bin/zss-client "No people here"

Bagus sekali. Sekarang mari tambahkan beberapa orang ke meja kita dan lihat apakah mereka dikembalikan oleh layanan ke klien kita. Untuk melakukan ini, cukup buka konsol layanan:

 $ rake service:console

Tambahkan beberapa orang:

 $ rake service:console [1] pry(main)> DAO::Person.create name: 'John' => #<DAO::Person:0x007fe51bbe9d00 id: 1, name: "John", created_at: 2015-12-16 13:22:37 UTC, updated_at: 2015-12-16 13:22:37 UTC> [2] pry(main)> DAO::Person.create name: 'Mary' => #<DAO::Person:0x007fe51c1dafe8 id: 2, name: "Mary", created_at: 2015-12-16 13:22:42 UTC, updated_at: 2015-12-16 13:22:42 UTC> [3] pry(main)> DAO::Person.create name: 'Francis' => #<DAO::Person:0x007fe51bc11698 id: 3, name: "Francis", created_at: 2015-12-16 13:22:53 UTC, updated_at: 2015-12-16 13:22:53 UTC> [4] pry(main)> exit

Sekarang, jalankan klien Anda lagi.

 $ bin/zss-client [{"id"=>1, "name"=>"John"}, {"id"=>2, "name"=>"Mary"}, {"id"=>3, "name"=>"Francis"}]

Di sana Anda memilikinya.

Pertimbangan Akhir

Melalui kode yang disediakan dalam panduan ini, Anda mungkin berpikir ada banyak langkah yang tidak perlu, seperti membuat repositori atau DTO, dan Anda benar. Yang Anda perlukan untuk memiliki layanan "Orang" yang berfungsi adalah kelas layanan dan DAO Anda, yang dapat Anda hubungi langsung dari kelas layanan. Namun demikian, ini adalah praktik yang baik untuk mengikuti pola yang dijelaskan dalam artikel ini, karena memungkinkan Anda untuk menjaga logika layanan terpisah dari manipulasi penyimpanan data Anda. Layanan seharusnya hanya difokuskan pada logikanya, dan repositori harus menangani semua interaksi dengan penyimpanan data Anda. DTO menentukan muatan dan serialisasi layanan Anda, dan DAO hanya peduli dengan mendapatkan data dari penyimpanan. Konvensi dan teknik yang dijelaskan dalam panduan ini dikenal sebagai pola repositori, yang dapat Anda lihat pada gambar di bawah.

Saya ingin mengakhiri dengan meminta siapa saja yang menganggap ini berguna untuk berkontribusi pada rangkaian layanan SOA, dengan memperluas dan meningkatkannya dengan cara apa pun. Semua permintaan garpu dan tarikan Anda dipersilakan.

Saya harap ini akan membantu Anda memulai layanan mikro. Jika Anda ingin melihat kode layanan, versi lengkap tersedia di GitHub.