Bagi sebagian orang, layanan microser adalah kemampuan untuk mengulang dan memperbaiki aplikasi ke gaya yang relatif modern. Solusi arsitektur ini tidak cocok untuk orang lain karena kekhasan interaksi berbagai bagian aplikasi. Dalam kasus apa pun, memilih arsitektur, akan berguna untuk mempelajari pengalaman orang lain dari transisi dari monolit ke serangkaian layanan.
Kami diminta untuk berbagi studi kasus kami tentang pengembangan dan pengiriman layanan mikro Alexei Baitov, insinyur utama 2GIS. Mari kita bicara tentang solusi arsitektur, penyebaran, dan skalabilitas. Mari kita bertanya tentang trending dan alat yang nyaman untuk bekerja.
- Alexey, tolong beri tahu kami sedikit tentang diri Anda dan tentang tim Anda di 2GIS . Apa yang sedang kamu kerjakan sekarang?
Saya datang ke IT pada tahun 2003 sebagai administrator sistem, saya terjun ke pengembangan pada tahun 2011. Selama ini, ia bekerja di PHP, JavaScript, mengimplementasikan serangkaian layanan RESTful dan driver Python untuk Git. Saya telah bekerja di 2GIS sejak 2015.
Dia berpartisipasi dalam pengembangan dua arsitektur layanan-mikro. Yang pertama terdiri dari satu layanan. Itu adalah proxy terbalik asinkron dengan cache. Bahkan, dia terlibat dalam pengiriman pesan. Saya adalah satu-satunya yang terlibat dalam mengerjakan persyaratan, mengembangkan dan membangun DevOps, tetapi para ahli dari perusahaan 2GIS kami membantu saya.
Layanan ini ditulis dalam Go. Kompilasi cepat memungkinkan saya untuk tidak menunggu, dan saya dapat berkonsentrasi pada Penerapan Berkelanjutan. Kemudian kami baru mulai menggunakan
GitLab CI ,
Prometheus ,
Grafana dan
Deis (analog open source
Heroku ). Kami memiliki tim Infrastruktur dan Operasi, yang pada saat pengembangan saya membawa semua solusi infrastruktur ini ke tingkat siap produksi. Saya memutuskan untuk mencoba semua ini dan berhasil mengimplementasikan microservice independen.
Dua tahun lalu, saya pindah ke tim lain pada proyek baru, di mana saya mulai terlibat dalam pemrograman fungsional di Scala. Tim kami dari awal telah mengembangkan arsitektur layanan mikro untuk penyimpanan materi iklan 2GIS di Scala, C # dan JavaScript. Saya meletakkan dasar semua layanan dengan alat dan pengalaman yang diperoleh untuk membangun praktik DevOps (Penyebaran dan pemeliharaan berkelanjutan). Arsitektur telah berubah dari prototipe ke operasi industri. Dia menyerap dua monolit, sekarang terdiri dari 15 layanan dan terus berkembang.
- Apakah Anda setuju bahwa layanan microser pada dasarnya adalah serangkaian layanan yang disebarkan secara independen yang memiliki karakteristik umum, yaitu, serangkaian fitur tertentu memberi mereka tampilan layanan mikro? Apakah definisi ini perlu diperluas? Atau, pada kenyataannya, apakah perusahaan memiliki pemahaman yang berbeda tentang arsitektur layanan-mikro?Saya suka
definisi berikut. Arsitektur microservice adalah gaya arsitektur yang menyusun aplikasi sebagai kumpulan layanan yang digabungkan secara longgar yang menerapkan logika bisnis tertentu. Layanan dalam arsitektur layanan mikro mungkin tidak memiliki karakteristik umum, tetapi digabungkan dalam logika bisnis bersama.
Tentu saja, setiap perusahaan akan memiliki microservice sendiri. Ini adalah seperangkat praktik: arsitektur terdistribusi, integrasi dan pengiriman berkelanjutan, dan sebagainya. Jika Anda memperluas konsep praktik ke alat yang digunakan, opsi untuk mengimplementasikan layanan microser akan sangat beragam.
- Ada berbagai pendapat tentang komposisi tim, yang harus dilibatkan dalam penulisan dan dukungan layanan mikro. Apa yang Anda pikirkan tentang ini? Berapa ukuran tim yang optimal dan bagaimana seharusnya dibangun oleh interaksi di dalamnya ketika mengembangkan arsitektur layanan mikro? Apakah ada contoh kerja tim yang baik dari latihan Anda?Itu dianggap benar untuk mengembangkan layanan sedemikian rupa sehingga seluruh area subjeknya dapat masuk dalam kepala satu pengembang. Pada saat yang sama, beberapa orang dapat berpartisipasi dalam pengembangan layanan ini. Ini akan membantu untuk menghindari faktor bus ketika pengembang pergi berlibur atau jatuh sakit. Rincian yang benar ke dalam layanan memungkinkan orang baru untuk dengan cepat memasuki konteks.
Arsitektur microservice memberi tahu kita bahwa sering menyertakan beberapa layanan. Dengan demikian, satu pengembang tidak bisa melakukannya. Arsitektur microservice dibangun berdasarkan model produk (atau logika bisnis umum). Pengembang dipilih sehingga ternyata mengimplementasikan model ini dan pada saat yang sama fokus pada klien.
Berfokus pada klien diatur melalui kontak langsung antara pengembang dan klien. Pengembang perlu melihat bagaimana produk mereka digunakan. Dari ini, keinginan untuk pengetahuan di bidang teknologi, kemampuan untuk mengirimkan produk kepada klien dan menemani produk sesegera mungkin mengikuti.
Sulit untuk mengatakan tentang ukuran tim. Semua orang mungkin sudah mengetahui pernyataan Jeff Bezos, pendiri Amazon, bahwa ukuran tim dalam pengembangan berorientasi layanan harus cukup kecil sehingga setiap orang dapat diberi makan dua pizza. Dalam komentar di Habré, ada diskusi tentang topik ini, dan mereka menulis bahwa satu orang mungkin tidak memiliki cukup satu pizza dan oleh karena itu tim harus terdiri dari satu atau dua orang. Martin Fowler, mengutip pernyataan tentang dua pizza, mengatakan bahwa itu tentang pizza besar Amerika, setelah itu ia menetapkan bahwa tim tidak boleh memiliki 50, tetapi sekitar 12 orang. Saya percaya bahwa itu semua tergantung pada model produk. Tetapi klarifikasi Fowler tentang "tidak lebih dari 12 orang" telah memenangkan latihan saya sejauh ini. Saya perhatikan bahwa di dalam tim diinginkan untuk membagi sesuai dengan minat teknologi, untuk menemukan orang yang berpikiran sama.
Tidak perlu bahwa setiap orang di tim tahu semua bidang teknologi yang digunakan dalam pekerjaan, tetapi pengetahuan total tim harus mendalam secara seragam. Misalnya, dua orang terlibat dalam pembangunan awal penyebaran dan di masa depan, kemungkinan besar, mereka juga akan meningkatkannya secara signifikan. Tetapi pada saat yang sama, seluruh tim harus memiliki pemahaman yang baik tentang proses penempatan. Ini akan memungkinkannya untuk mengekspresikan keinginannya dan membuat perubahan. Kenapa dua orang? Karena kadang-kadang satu orang bisa jatuh pingsan secara kreatif. Dan dalam diskusi, kebenaran lahir.
Kami secara alami membangun berdasarkan prinsip ini, disatukan oleh kepentingan teknologi. Pada saat yang sama, pengembang juga dapat terlibat dalam membangun praktik-praktik DevOps, dan insinyur QA dapat mengembangkan layanan tambahan, non-produksi (misalnya, memanaskan cache atau layanan mencari anomali dalam data di lingkungan yang berbeda).
- Hampir setiap laporan tentang layanan-layanan microser dimulai dengan cerita bahwa “di sini kami memiliki gunung es dan kami menggergaji, menggergaji, menggergaji ... Bagian-bagian baru dari aplikasi dibuat berdasarkan pada layanan-layanan mikro, dan kemudian kami mulai memisahkan“ potongan-potongan ”dari mesin utama ... "
Katakan padaku, apakah Anda seorang pendukung pengembangan dari awal atau dapatkah ada situasi ketika layak membuat kesimpulan bertahap dari sebuah monolit? Bagaimana cara menentukan strategi keluar?Saya seorang pendukung pengembangan dari awal. Tapi ini hanya berfungsi jika himpunan fungsi tidak terlalu rumit. Biasanya monolit MVP kecil dibuat. Dan kadang-kadang perlu untuk secara radikal mengubah implementasi internal beberapa kali. Ini dapat disebabkan oleh perubahan dalam tugas teknis, dan oleh kenyataan bahwa pemahaman implementasi datang - abstraksi tingkat tinggi muncul di tingkat model bisnis. Setelah itu, Anda dapat beralih ke arsitektur microservice.
Tetapi jika Anda mengerjakan abstraksi ini di awal dan menggambarnya dalam notasi yang berbeda (UML, BPMN, IDEF), sehingga semua peserta dalam proses memahami apa yang mereka kerjakan, sangat mungkin untuk mengimplementasikan arsitektur layanan mikro segera.
Jalan kami ke arsitektur layanan mikro tidak lurus. Awalnya ada monolit. Dia memproses materi iklan tekstual. Tiga setengah tahun yang lalu, kami perlu bekerja dengan materi iklan grafis (gambar, logo). Ada keinginan untuk memperkenalkan ke dalam logika bisnis apa yang kurang ketika bekerja dengan materi iklan teks.
Untuk menguji model bisnis baru, kami menerapkan pekerjaan dengan materi iklan grafis sebagai monolit kedua pada tumpukan teknologi lainnya. Setelah satu setengah tahun beroperasi, kami menyadari bahwa pendekatan ini benar.
Selama ini, kami mendapat banyak Daftar Keinginan, mengungkapkan kekasaran logika bisnis.
Implementasi monolit kedua sulit diperluas ke yang pertama. Oleh karena itu, kami memutuskan untuk tidak melakukan pengembangan dalam dua monolit sekaligus, tetapi menggabungkannya dalam kerangka arsitektur ketiga sesuai dengan model bisnis yang sangat baru. Sebuah tim yang terdiri dari tujuh pengembang, satu insinyur QA dan dua analis telah dibuat. Dua pengembang dari tim ini sebelumnya membuat dan mendukung monolit pertama, dan satu lagi - monolit kedua. Artinya, tim kami yang sudah di pintu masuk tahu betul perangkap dari monolith sebelumnya.
Monolit pertama ditulis dalam bahasa C #. Yang kedua adalah di PHP. Kami tidak ingin kehilangan kepingan kode yang beraneka ragam dari monolith pertama, dan pada saat yang sama multithreading, kode aman, dan pengetikan yang kuat diperlukan. Kode PHP sebagian tidak termasuk dalam persyaratan ini. Oleh karena itu, C # tetap sebagai dasar dan menerapkan apa yang dilakukannya dengan baik dalam kerangka monolit pertama - bekerja dengan konten materi iklan - tetapi berdasarkan penyimpanan lain: penyimpanan yang kompatibel dengan S3 dan Kafka.
Untuk bekerja dengan model bisnis yang sangat baru, Scala dan database PostgreSQL dipilih kali ini. Scala memenuhi persyaratan teknis kami. Selain itu, pengembang Scala berada di lantai yang sama dengan pengembang C #. Ini mengurangi waktu untuk komunikasi tim. Hukum Conway berfungsi - struktur perusahaan menentukan struktur aplikasi. Pengembang PHP telah dibangun kembali menjadi pengembang Scala. Saya baru saja menyelesaikan pekerjaan dengan layanan mikro mandiri di Golang dengan siklus CI / CD penuh, setelah itu saya bergabung dengan tim dan juga menjadi pengembang Scala.
Sangat menarik apa sebenarnya yang saya usulkan untuk digunakan untuk bekerja dengan logika bisnis Scala, dan bukan C #. Faktanya adalah bahwa kami tidak memiliki cukup pengembang C #. PHP-shnik dan saya ingin melatih kembali untuk Scala. Plus, kami memiliki kesempatan untuk menarik pengembang Scala yang berpengalaman. Poin lain: jika kita mengimplementasikan semuanya dalam C #, maka kita bisa mendapatkan arsitektur microservice atau monolith lain di output. Pembagian menjadi Scala dan C #, kebutuhan penyimpanan yang berbeda dan ketersediaan pengembang berpengalaman di setiap bidang yang diperlukan - semua ini secara langsung menunjuk ke arsitektur layanan-mikro. Dan kami hanya mendapat manfaat dari ini. Setahun yang lalu, arsitektur microservice untuk bekerja dengan bahan grafis dan tekstual masuk ke operasi komersial dan telah berhasil beroperasi hingga hari ini.
Untuk pertanyaan apakah mungkin untuk membuat arsitektur layanan microser dari awal. Setahun setengah yang lalu, dalam proses mengerjakan arsitektur layanan-mikro, kami muncul dengan permintaan untuk mendukung arah baru dalam produk kami - materi iklan video. Itu perlu untuk dengan cepat menguji model penjualan baru. Arsitektur kami masih bayi. Bekerja dengan materi video mencakup bidang teknologi baru. Kami memutuskan untuk tidak mengubah vektor pengembangan dan mengimplementasikan MVP untuk materi video sebagai arsitektur layanan mikro yang berdiri sendiri di C # dan hosting video tepercaya. Ini adalah pengalaman yang sukses, dan kami memiliki
laporan tentang topik ini. Dengan demikian, kami memiliki dua arsitektur layanan mikro paralel yang ada. MVP tidak berkembang banyak, Wishlist juga terakumulasi di atasnya, dan segera kami akan menggabungkan semuanya dalam kerangka arsitektur layanan-mikro tunggal - kami akan mendapatkan satu repositori teks iklan, grafik, dan materi video.
- Segera, ada dua faktor penting yang mendukung microservices. Yang pertama adalah kemampuan untuk mengeluarkan bagian-bagian individual ke cloud dan, sebagai hasilnya, skalabilitas kolosal. Yang kedua adalah kemampuan untuk membuat layanan terpisah dalam bahasa lain. Apa keuntungan lain dari beralih ke layanan microser yang Anda lihat? Ya, dari minusnya, tentu saja, saya juga ingin mendengar.Jika kita berbicara tentang komponen teknologi, maka kelebihannya, selain yang di atas, termasuk kemungkinan menggunakan tumpukan teknologi lainnya. Dan jika dia tidak cocok dengan kita, kita akan memilih yang lain. Teknologi baru memintas masalah solusi lama. Arsitektur microservice juga memberikan stabilitas dan kemandirian: degradasi satu layanan tidak boleh mengarah pada degradasi lengkap seluruh sistem. Kompabilitas layanan memungkinkan penggunaan kembali fungsionalitas layanan dalam arsitektur layanan-mikro lainnya. Dari sudut pandang komponen organisasi, membagi ke dalam layanan memungkinkan Anda untuk membagi pengembangan dalam tim terdistribusi atau satu tim besar.
Kerugian utama dari arsitektur layanan-mikro: jauh lebih rumit, dan implementasinya lebih mahal.
Anda juga harus siap untuk mendukung kontrak layanan, memilih protokol akses jarak jauh yang benar, menyelesaikan masalah interaksi antar-layanan yang aman, kemungkinan kegagalan, serta menduplikat dan mengelola transaksi yang didistribusikan.
Secara umum, dalam domain publik Anda dapat menemukan banyak informasi dan materi tentang cara bekerja dengannya. Tapi sebenarnya itu semua tergantung tugas. Dalam praktik saya, plus selalu lebih signifikan daripada minus.
Masih layak untuk mengingat kata-kata Sam Newman: semakin sedikit layanannya, semakin banyak semua kelebihan dan kekurangan dari arsitektur layanan-mikro dimanifestasikan.
- Anda memiliki beberapa laporan menarik tentang layanan mikro. Penerapan layanan microser dan Pendekatan Penerapan Berkelanjutan dalam arsitektur layanan microser . Pada salah satu slide yang pertama ada templat penyebaran, dan dalam laporan Anda mengatakan bahwa bagi Anda pendekatan tren adalah distribusi melalui kontainer. Selama ini, tidak ada yang berubah? Sekelompok Docker + Kubernetes belum kehilangan relevansinya?Kami mentransfer semakin banyak layanan ke bundel ini. Saya pikir kami telah memilih arah yang benar dan untuk saat ini kami berencana untuk mematuhinya. Jika ada perubahan, saya akan memberi tahu Anda tentang hal itu dalam laporan atau wawancara baru.
- Seberapa halus penyebaran dan transfer layanan microser yang berkelanjutan ke prod?Itu semua tergantung pada bagaimana membangun proses. Pada awalnya tampaknya semuanya sederhana. Layanan bersifat independen, digunakan secara terpisah. Koherensi yang lemah dijamin oleh berbagai pendekatan untuk bekerja dengan evolusi kontrak. Dan di sini Anda harus memilih. Misalnya, Anda dapat menerapkan versi kontrak atau menambahkan layanan untuk memutuskan kontrak (decoupling kontrak).
Jika dalam arsitektur microservice dalam pengembangan aktif ada 10 atau lebih layanan sekaligus dan masing-masing memiliki versi sendiri, maka ada masalah konsistensi versi. Kita harus berusaha untuk tidak menjadi bingung dalam kompatibilitas layanan dari versi yang berbeda.
Penerapan berkelanjutan berarti bahwa kami dapat mengirimkan aplikasi kapan saja ke lingkungan apa pun.
Aplikasi dalam arsitektur microservice adalah kumpulan layanan. Jadi, pada waktu tertentu, kita perlu mengetahui kombinasi stabil dari versi layanan. Dan di tempat lain kita harus memiliki satu set alamat domain dan parameter lain khusus untuk lingkungan yang berbeda untuk mengkonfigurasi layanan dan menghubungkannya satu sama lain.
Semua ini perlu disimpan di suatu tempat, untuk memperbaiki perubahan di beberapa tempat (layanan microser independen setelah semua) dan tidak menjadi bingung.
Penerapan berkelanjutan berarti kemampuan untuk memutar kembali ke versi apa pun kapan saja. Oleh karena itu, mungkin Anda perlu memutar kembali beberapa layanan sekaligus dan Anda harus memperhatikan urutan terbalik penyebaran layanan yang benar.
Dalam salah satu laporan saya, saya berbicara tentang pendekatan kami terhadap evolusi kontrak, bagaimana mereka memecahkan masalah konsistensi versi dan bagaimana mereka membangun proses penyebaran dalam arsitektur layanan mikro lebih dari sepuluh layanan. Penempatan berkelanjutan mungkin tidak bebas masalah, tetapi semuanya dapat dipecahkan.
- Apa yang bisa menjadi seperangkat alat awal untuk penyebaran microservices yang berkelanjutan? Opsi apa yang akan Anda rekomendasikan untuk digunakan dengan bekerja dengan layanan microser?Penyebaran berkelanjutan adalah urutan jalur pipa, termasuk integrasi berkelanjutan, tes integrasi, dan pengiriman layanan ke lingkungan orkestrasi. Alat urutan langkah yang paling populer adalah
Jenkins 2 Pipelines ,
TeamCity Build Chains ,
Pipelines Bitbucket dan
Pipeline GitLab CI . Pertama, Anda perlu mengotomatiskan integrasi berkelanjutan (CI). Kami membutuhkan server CI jarak jauh untuk membangun dan menjalankan tes pada perakitan ini.
Alat yang terdaftar menawarkan solusi mereka. Kami menggunakan GitLab CI, dan GitLab Runners bertindak sebagai server seperti itu. Artefak build adalah gambar
Docker . Sebagai bagian dari tes integrasi, Anda dapat melakukan tes beban dan kapasitif menggunakan
Gatling , khususnya, untuk menentukan sumber daya yang dibutuhkan (prosesor dan memori) untuk berfungsi dalam lingkungan orkestrasi (misalnya,
Kubernetes ).
Helm banyak digunakan untuk penyebaran, memungkinkan Anda untuk menggambarkan arsitektur layanan mikro untuk lingkungan yang berbeda. Di perusahaan kami, kami tidak menggunakan Helm. Kami memiliki alat penyebaran kami sendiri, yang dibuat ketika Helm dalam versi Klasik dan tidak mendukung lingkungan yang berbeda. Kedua alat ini memiliki kualitas bermanfaat yang serupa, tetapi implementasi dan distribusinya berbeda. Dan alat kami sendiri memungkinkan kami untuk melakukan perbaikan dan menyesuaikan segalanya dengan infrastruktur kami.
- Teknologi apa yang optimal untuk perusahaan kecil dan menengah yang ingin mengimplementasikan layanan microser? Apakah ini terlalu mahal untuk kesenangan mereka?Semakin banyak, saya menemukan konfirmasi bahwa perusahaan kecil dan menengah tidak pantas untuk meningkatkan lingkungan orkestrasi mereka sendiri (misalnya,
Kubernetes ,
Docker Swarm atau
Apache Mesos ). . (
Google Cloud Platform ,
Amazon Web Services ,
Microsoft Azure Oracle Cloud ) .
GitLab GitLab CI. . GitLab Helm . Helm . Helm , , , .
, , , open source, .
Spinnaker Heroku — , , .
— , , , . . ?, . , , .
( ) . .
. . , (package). .
( ) Docker-, Git. , . ,
. , .
, . : API. . : . , API. , API , — . , API, .
. , ; API, ; , , .
, , . , ?— - .
, API, , . . .
, , . , , . , , .
— , . 2. , ? ?. .
Mesosphere ,
OpenShift PaaS IaaS . Deis
,
Deis . open source
Heroku , Heroku Buildpack', Dockerfile' Docker-. . make Deis. .
Deis2 . Deis, Kubernetes.
Infrastructure & Operations , , Kubernetes Deis2. , , Deis2, , — Kubernetes. . Deis2 : , pod pod' namespace. Infrastructure & Operations. Kubernetes . Deis2 Kubernetes. Deis2 Kubernetes.
— , , , ? ?Helm. , . Helm .
Helm , — : , .
Helm chart' chart, , .
2 , 10 . ( backing : Postgres, Kafka, Zookeeper, Ceph). - , yaml- , IDE, . , . Python, Python . , . , . , . , , . . , , , ( ) . , , Helm, Kubernetes - , yaml.
API
API Gateway . , — .
, : . , , .
DevOps , . DevOpsConf Russia .
DevOpsConf Russia 1 2 RootConf, , , , . DevOps , .
DevOps , , – . 15 .