Layanan microser. Penyatuan dan mengapa itu sangat penting. Bagian 1 - Konfigurasi



Pendahuluan


Hari baik untuk semua Saya adalah pengembang Python di sebuah perusahaan yang berurusan dengan solusi kompleks untuk mengotomatisasi proses bisnis, berkembang untuk menyelesaikan tugas tunggal, analitik, dan konsultasi. Tanggung jawab saya meliputi pengembangan dan pemeliharaan arsitektur layanan mikro. Dan hari ini saya ingin memberi tahu bagaimana kita berjuang dengan layanan-layanan mikro dan mengapa penyatuan sangat penting bagi mereka.

Bukan rahasia lagi bahwa pendekatan pengembangan produk ini semakin menangkap pasar. Dan semakin kita terjun ke dalamnya, semakin perlu untuk tidak melupakan aturan dasar untuk bekerja dengan mereka. Untuk menyusun pengalaman kami dalam menulis produk layanan mikro, diputuskan untuk menulis serangkaian artikel tentang cara menggeneralisasi beberapa aspek pengembangan ke semua layanan.

Salah satu aturan tersebut adalah penyatuan. Di perusahaan kami, sebagian besar produk terdiri dari banyak bahasa dan teknologi beragam. Di semua stan ini, Anda harus memikirkan cara menggeneralisasi prinsip-prinsip dasar untuk semua layanan microser untuk dukungan, konfigurasi, dan pengembangan yang mudah. Ini akan dibahas dalam seri artikel ini.

Saya meminta semua orang tertarik pada kucing.

Masalah


Mungkin hal pertama yang Anda temui dalam mengembangkan layanan adalah metode konfigurasinya. Dalam arsitektur microservice, masalah ini menjadi lebih akut.

Bayangkan Anda memiliki dua lusin layanan dan Anda perlu mengubah parameter di masing-masing. Misalnya, nonaktifkan penggunaan CORS. Karena sistem ini multikomponen dan dibangun di atas layanan microser, untuk manajemen yang mudah, yang terbaik adalah menggunakan pendekatan yang seragam untuk konfigurasi semua modul. Oleh karena itu, Anda perlu menggunakan pendekatan yang sama saat mengatur setiap modul.

Anda dapat mengatakan bahwa pengembang setiap layanan harus melakukan ini, tetapi bagaimana jika semua konfigurasi Anda disimpan dalam Kubernet yang sama, di mana tidak dapat diberikan kepada semua pengembang? DevOps yang buruk akan dipaksa untuk menghabiskan banyak waktu hanya mempelajari layanan dan metode konfigurasi mereka. Dan prosedur ini akan diulangi dengan pembaruan layanan, terutama jika seseorang ingin mencoba sesuatu yang baru dalam pengaturan layanan. Dengan pendekatan ini, tim akan terus-menerus menghabiskan sebagian waktu bekerja dengan konfigurasi, dan tidak mengembangkan fitur baru, memperbaiki bug, dll.

Hanya untuk kasus ini, metode konfigurasi umum diperlukan yang tidak akan terikat pada bahasa atau teknologi tertentu dan akan memungkinkan Anda untuk mengkonfigurasi semua layanan dengan perbedaan minimal dalam struktur umum konfigurasi. Untuk tugas ini, kami mengembangkan sistem untuk mengatur "modul" (layanan) menggunakan file yaml, kemampuan untuk menyimpan konfigurasi untuk tahap yang berbeda (dev / prod / lokal dll) dan membagi semuanya menjadi blok yang berbeda terkait dengan hal-hal tertentu.

Spesifikasi


Anda dapat berbicara banyak tentang di mana dan bagaimana menggunakannya, tetapi saya mengusulkan untuk langsung menuju spesifikasi metode konfigurasi ini. Seperti yang mereka katakan, teori itu baik, dan praktiknya bahkan lebih baik.

Persyaratan sistem


Mari kita mulai dengan mendefinisikan sistem kita dan persyaratan untuk itu.
  • Setiap modul adalah komponen independen dalam wadah
  • Kita bisa meneruskan variabel lingkungan ke wadah
  • Kami tidak dapat mengubah konfigurasi dengan cepat tanpa memulai kembali layanan (membuat wadah baru).
  • Semua tindakan mundur (seperti beralih ke database cadangan) dilakukan di luar komponen dan transparan untuk itu.


Persyaratan Metode Konfigurasi


Sekarang mari kita putuskan apa yang ingin kita lihat dari metode konfigurasi kita untuk memenuhi semua persyaratan.

  1. Jenis file konfigurasi adalah YAML dari struktur yang ditentukan. YAML dipilih oleh kami karena beberapa alasan:
    • Kemampuan untuk menulis komentar dan struktur yang nyaman, tidak seperti JSON
    • Kemampuan untuk menggambarkan array yang berbeda dengan ENV
    • Out of the box dapat digunakan untuk dimasukkan dari values.yaml in helm (Kubernetes)

  2. File konfigurasi harus bergabung ke dalam pohon konfigurasi
  3. Konfigurasi harus spesifik-panggung. Setiap tahap memiliki set lengkap sendiri. Di sini ada baiknya membuat beberapa reservasi untuk klarifikasi:
    • Anda tidak dapat menggunakan kembali nilai variabel dari tahap lain , kecuali untuk tahap default , yang dicadangkan untuk nilai default.
    • Saat memuat konfigurasi, Anda perlu melakukan penggabungan rekursif dari lapisan konfigurasi dari tahap yang ditentukan di atas default dengan prioritas lapisan dari tahap yang ditentukan. Nilai (array, dll.) Tidak boleh digabungkan.
    • Jika ada beberapa file konfigurasi untuk satu tahap, kunci di dalamnya harus digabung dan, karenanya, harus unik relatif satu sama lain.

  4. Tahap saat ini yang digunakan harus ditentukan oleh nilai variabel lingkungan "STAGE". Mengubah variabel dalam instance layanan yang sedang berjalan tidak dimaksudkan.
  5. Path absolut ke direktori konfigurasi harus ditentukan oleh nilai variabel lingkungan β€œCONFIG_PATH”. Untuk kenyamanan, fallback dimungkinkan jika tidak ada variabel di jalur default tertentu, yang harus ditunjukkan dalam dokumentasi untuk modul. Dalam hal ini, jalur yang ditentukan harus relatif terhadap akar direktori aplikasi.


Contoh konfigurasi


Misalkan kita memiliki layanan yang perlu menyimpan pengaturan untuk menghubungkan ke Postgres, serta beberapa informasi tentang diri kita sendiri

Pertama, Anda perlu mendefinisikan konfigurasi untuk STAGE = default. Di dalamnya kita akan menggambarkan struktur umum, serta membuat data independen dari tahap.

default


# configuration/defaults/service.yaml defaults: version: 1.0.0 name: "config-example" # configuration/defaults/redis.yaml defaults: redis: host: "host" db: 0 port: 6379 password: "password" 


dev


 # configuration/dev/redis.yaml dev: redis: host: "localhost" password: "hard_pwd" 


Konfigurasi yang dihasilkan


 version: 1.0.0 name: "config-example" redis: host: "localhost" db: 0 port: 6379 password: "hard_pwd" 


Kesimpulan



Sedemikian cerdiknya, kami memecahkan masalah konfigurasi layanan di kebun binatang kami dan membawa semuanya ke pandangan umum. Contoh ini hanyalah titik awal dan dapat dimodifikasi untuk spesifik proyek Anda.

Bagi mereka yang tertarik dengan metode konfigurasi ini dalam "formulir kosong":
Paket kami untuk berbagai bahasa pemrograman


Untuk bantuan dalam menulis menjadi ucapan terima kasih khusus kepada Roque , SMGladkovskiy

Source: https://habr.com/ru/post/id436630/


All Articles