Pilih Bahasa

Seni Bina Mikroperkhidmatan: Konsep, Pendorong, dan Corak Pelaksanaan

Analisis seni bina mikroperkhidmatan berdasarkan transkrip podcast IEEE Software, merangkumi definisi, motivasi, corak penerimaan, dan pertimbangan praktikal.
apismarket.org | PDF Size: 0.3 MB
Penilaian: 4.5/5
★ ★ ★ ★ ★
Penilaian Anda
Anda sudah menilai dokumen ini
Sampul Dokumen PDF - Seni Bina Mikroperkhidmatan: Konsep, Pendorong, dan Corak Pelaksanaan
Lihat Dokumen PDF Muat Turun PDF Terjemah PDF
Laman Utama » Dokumentasi » Seni Bina Mikroperkhidmatan: Konsep, Pendorong, dan Corak Pelaksanaan

1. Pengenalan & Gambaran Keseluruhan

Kandungan ini berasal daripada satu episod podcast Software Engineering Radio (episod 213), menampilkan perbincangan antara Johannes Thönes dan James Lewis mengenai topik mikroperkhidmatan. Perbualan ini meneroka definisi, motivasi, dan pertimbangan praktikal berkaitan gaya seni bina ini, yang mendapat sambutan meluas pada awal 2015 sebagai tindak balas kepada cabaran mengekalkan aplikasi monolitik yang besar.

2. Mendefinisikan Mikroperkhidmatan

Mikroperkhidmatan dikonsepsikan sebagai komponen aplikasi yang kecil dan fokus.

2.1 Ciri-ciri Teras

Menurut perbincangan, mikroperkhidmatan mempunyai beberapa atribut utama:

  • Pelaksanaan Bebas: Boleh dilaksanakan tanpa memerlukan perubahan pada perkhidmatan lain.
  • Penskalaan Bebas: Boleh dilaraskan secara mendatar atau menegak berdasarkan beban khususnya.
  • Pengujian Bebas: Boleh disahkan secara terpencil.
  • Tanggungjawab Tunggal: Mempunyai satu sebab utama untuk berubah atau diganti. Ia melaksanakan satu tugas yang kohesif dan mudah difahami.

2.2 Contoh Tanggungjawab Tunggal

"Satu perkara" yang dilakukan oleh mikroperkhidmatan boleh bersifat fungsian atau silang-fungsian (bukan fungsian):

  • Fungsian: Menyediakan sumber domain tertentu (contohnya, perkhidmatan Pengguna, perkhidmatan Artikel, perkhidmatan pengiraan Risiko dalam insurans).
  • Silang-fungsian: Pemproses barisan yang membaca mesej, menggunakan logik perniagaan, dan meneruskannya. Tanggungjawab untuk keperluan bukan fungsian tertentu seperti caching atau log.

3. Kebangkitan Mikroperkhidmatan

3.1 Pendorong Kepopularan

Kepopularan mikroperkhidmatan dikaitkan dengan titik kesakitan industri yang meluas: aplikasi monolitik yang tidak dapat diuruskan. Organisasi menghadapi aplikasi yang telah berkembang selama 5-10 tahun, menjadi terlalu sukar untuk diubah suai, dilaksanakan sebagai SaaS, atau dilaraskan dengan berkesan dalam awan.

3.2 Menangani Hutang Teknikal

Mikroperkhidmatan muncul sebagai penyelesaian untuk membahagikan monolit ini kepada komponen yang lebih kecil dan bekerjasama yang berjalan di luar proses. Pendekatan ini, yang ditunjukkan pada skala besar oleh syarikat seperti Netflix, membolehkan penyelenggaraan, penskalaan, dan penggantian yang bebas. Pendorong teras adalah keperluan untuk menyampaikan perisian dengan lebih pantas dan mengambil kesempatan daripada amalan seperti penghantaran berterusan, yang dihalang oleh seni bina monolitik.

4. Corak Penerimaan & Pelaksanaan

4.1 Greenfield vs. Brownfield

Satu soalan utama adalah sama ada untuk memulakan projek baharu dengan mikroperkhidmatan (greenfield) atau mengubah suai monolit sedia ada kepada mikroperkhidmatan (brownfield). Perbincangan menyatakan bahawa secara empirikal, kebanyakan organisasi bermula dengan monolit dan kemudian mengubah suai, menghadapi cabaran mengenal pasti konteks terikat dan jahitan dalam kod sedia ada.

4.2 Kerumitan Operasi

Petikan podcast menyebut bahawa batasan ruang menghalang perbincangan penuh mengenai kerumitan operasi dan kesannya terhadap DevOps. Ini membayangkan bahawa walaupun mikroperkhidmatan menyelesaikan masalah pembangunan dan kebolehskalaan, ia memperkenalkan cabaran baharu dalam pemantauan, orkestrasi pelaksanaan, dan kebolehpercayaan rangkaian.

5. Wawasan Utama & Analisis

Wawasan Teras

Mikroperkhidmatan bukanlah teknologi penyelesaian ajaib; ia adalah tindak balas organisasi dan ekonomi terhadap kesesakan pembangunan monolitik. Proposisi nilai sebenar, seperti yang diisyaratkan oleh contoh Netflix, adalah membolehkan aliran penghantaran nilai yang bebas dan selari. Seni bina ini secara langsung menyasarkan kos penyelarasan dan geseran pelaksanaan yang membelenggu pasukan besar yang bekerja pada satu kod asas, masalah yang diformalkan oleh pepatah Melvin Conway bahawa "organisasi yang mereka bentuk sistem... terikat untuk menghasilkan reka bentuk yang merupakan salinan struktur komunikasi organisasi ini." Mikroperkhidmatan cuba membalikkan ini dengan mereka bentuk sistem yang memaksa struktur komunikasi yang diingini.

Aliran Logik

Naratif mengikuti rangkaian sebab-akibat yang menarik: (1) Monolit mengumpul hutang teknikal dan menjadi lumpuh perubahan. (2) Perniagaan menuntut kebolehskalaan awan dan penghantaran berterusan. (3) Seni bina monolitik pada dasarnya tidak serasi dengan matlamat ini kerana gandingannya. (4) Penyelesaiannya adalah memecahkan monolit sepanjang konteks terikat, mencipta unit yang boleh dilaksanakan secara bebas. Logik ini kukuh tetapi mengabaikan kerumitan perantaraan yang besar—"bagaimana" pecahan itu berlaku.

Kekuatan & Kelemahan

Kekuatan: Fokus pada kebolehlaksanaan bebas sebagai ciri utama adalah tepat. Ini adalah tuas yang membuka autonomi pasukan dan kitaran pelepasan yang lebih pantas. Sambungan kepada Undang-undang Conway dan CQRS (disebut sebagai topik yang ditinggalkan) menunjukkan kesedaran terhadap corak sosio-teknikal yang lebih mendalam yang sedang berlaku.

Kelemahan: Perspektif 2015 jelas optimistik tentang kemudahan mendefinisikan "tanggungjawab tunggal." Pengalaman industri seterusnya mendedahkan ini sebagai bahagian yang paling sukar—kutuk sempadan perkhidmatan yang tidak jelas membawa kepada monolit teragih. Transkrip ini juga secara berbahaya meremehkan beban operasi. Seperti yang dihuraikan kemudian oleh artikel asas Fowler, anda menukar kerumitan pembangunan dengan kerumitan operasi. Sebutan Docker sebagai "sekeping yang popular" adalah gambaran sejarah; ekosistem kontena adalah pemudah operasi yang hilang yang menjadikan mikroperkhidmatan boleh dilaksanakan secara pragmatik pada skala besar.

Wawasan Boleh Tindak

Untuk pemimpin: Jangan mulakan dengan mikroperkhidmatan kerana ia bergaya. Mulakan dengan mengukur masa utama untuk perubahan dan kekerapan pelaksanaan anda. Jika ia lemah kerana penyelarasan kod asas, pertimbangkan mikroperkhidmatan. Untuk arkitek: Alat reka bentuk utama bukan senarai semak teknologi tetapi peta konteks reka bentuk berasaskan domain (DDD). Tentukan sempadan berdasarkan keupayaan perniagaan, bukan lapisan teknikal. Untuk pasukan: Melabur dalam kejuruteraan platform terlebih dahulu—pelaksanaan automatik, penemuan perkhidmatan, dan kebolehcerapan bukanlah pemikiran lepas; ia adalah asas. Laluan yang dicadangkan—mengubah suai daripada monolit—masih yang paling bijak. Gunakan Corak Arahan Strangler untuk menggantikan bahagian monolit secara beransur-ansur dengan perkhidmatan, kerana ini menguruskan risiko dan membolehkan pembelajaran.

6. Kerangka Teknikal & Model Matematik

Walaupun podcast bersifat perbualan, prinsip asas boleh diformalkan. Satu model utama ialah hubungan antara saiz pasukan (N), laluan komunikasi, dan gandingan seni bina.

Dalam seni bina monolitik dengan N pasukan, laluan komunikasi berpotensi berkembang dengan $O(N^2)$, kerana perubahan dalam satu modul boleh menjejaskan banyak yang lain. Ini mewujudkan beban penyelarasan. Mikroperkhidmatan bertujuan untuk mengurangkan ini dengan menguatkuasakan konteks terikat dan API. Matlamatnya adalah untuk menjadikan kos komunikasi antara perkhidmatan, $C_{comm}$, secara eksplisit tinggi melalui panggilan rangkaian, dengan itu menggalakkan modulariti yang kuat dalam perkhidmatan di mana kos perubahan, $C_{internal}$, adalah rendah.

Model yang dipermudahkan untuk kebarangkalian penyebaran perubahan ($P_{prop}$) mungkin:

$P_{prop} \approx \frac{C_{comm}}{C_{comm} + C_{internal}}$

Di mana seni bina mikroperkhidmatan yang direka dengan baik meminimumkan $P_{prop}$ untuk perubahan yang tidak berkaitan dengan menjadikan $C_{comm}$ (kependaman rangkaian, versi API) faktor dominan untuk perubahan merentasi sempadan.

7. Keputusan Eksperimen & Kajian Kes

Podcast menyebut Netflix sebagai kajian kes utama. Menjelang 2015, Netflix terkenal kerana menguraikan backend monolitiknya kepada ratusan mikroperkhidmatan, membolehkan:

  • Penskalaan Bebas: Perkhidmatan seperti cadangan filem atau pengebilan boleh dilaraskan secara bebas semasa beban puncak.
  • Inovasi Pantas: Pasukan boleh melaksanakan perkhidmatan mereka beberapa kali sehari tanpa penyelarasan penuh.
  • Kepelbagaian Teknologi: Perkhidmatan yang berbeza boleh ditulis dalam bahasa yang paling sesuai untuk tugas mereka (contohnya, Java, Node.js).

Penerangan Carta (Hipotesis): Carta bar membandingkan aplikasi monolitik dengan seni bina mikroperkhidmatan pada dua paksi: (1) Kekerapan Pelaksanaan (Pelaksanaan/Hari): Monolit menunjukkan bar rendah (contohnya, 0.1), Mikroperkhidmatan menunjukkan bar tinggi (contohnya, 50+). (2) Masa Purata untuk Pemulihan (MTTR) daripada kegagalan: Monolit menunjukkan bar tinggi (contohnya, 4 jam), Mikroperkhidmatan menunjukkan bar lebih rendah (contohnya, 30 minit), kerana kegagalan boleh diasingkan kepada perkhidmatan tertentu.

Kajian seterusnya, seperti yang dirujuk dalam Laporan State of DevOps, telah mengaitkan secara statistik seni bina berorientasikan perkhidmatan yang longgar dengan prestasi penghantaran perisian yang lebih tinggi.

8. Kerangka Analisis: Contoh Praktikal

Skenario: Monolit e-dagang bergelut dengan kemas kini. Perubahan ciri "daftar keluar" memerlukan ujian regresi penuh dan bercanggah dengan kemas kini kepada "katalog produk."

Aplikasi Kerangka:

  1. Kenal Pasti Konteks Terikat: Menggunakan Reka Bentuk Berasaskan Domain, kenal pasti domain teras: Pesanan, Katalog, Inventori, Pengurusan Pengguna, Pembayaran.
  2. Tentukan Sempadan Perkhidmatan: Cipta mikroperkhidmatan untuk setiap konteks. Perkhidmatan Pesanan memiliki logik daftar keluar dan data pesanan.
  3. Wujudkan Kontrak: Tentukan API yang jelas. Perkhidmatan Pesanan akan memanggil API processPayment(orderId, amount) Perkhidmatan Pembayaran dan API reserveStock(itemId, quantity) Perkhidmatan Inventori.
  4. Pemilikan Data: Setiap perkhidmatan memiliki pangkalan datanya sendiri. Perkhidmatan Pesanan mempunyai jadual "orders" sendiri; ia tidak terus meminta pangkalan data Inventori.
  5. Pelaksanaan & Kebolehcerapan: Setiap perkhidmatan dikontenakan, dilaksanakan secara bebas, dan menerbitkan metrik (kependaman, kadar ralat) ke papan pemuka pusat.

Hasil: Pasukan daftar keluar kini boleh melaksanakan kemas kini kepada Perkhidmatan Pesanan tanpa melibatkan pasukan katalog atau inventori, mengurangkan beban penyelarasan dengan ketara dan meningkatkan kekerapan pelaksanaan.

9. Aplikasi Masa Depan & Hala Tuju Penyelidikan

Evolusi mikroperkhidmatan berterusan melebihi pandangan 2015:

  • Jaring Perkhidmatan: Teknologi seperti Istio dan Linkerd telah muncul untuk menangani kebimbangan silang (keselamatan, kebolehcerapan, pengurusan trafik) pada lapisan infrastruktur, mengurangkan beban kod pada perkhidmatan individu.
  • Tanpa Pelayan & FaaS: Fungsi-sebagai-Perkhidmatan (contohnya, AWS Lambda) mewakili bentuk mikroperkhidmatan yang melampau, menolak kerumitan operasi sepenuhnya kepada pembekal awan dan membolehkan penskalaan yang lebih halus.
  • Integrasi AI/ML: Mikroperkhidmatan menjadi corak de facto untuk melaksanakan model ML sebagai perkhidmatan ramalan bebas, membolehkan ujian A/B dan lelaran algoritma yang pantas.
  • Pengkomputeran Pinggir: Melaksanakan mikroperkhidmatan ringan ke peranti pinggir untuk pemprosesan kependaman rendah dalam senario IoT dan analisis masa nyata.
  • Fokus Penyelidikan: Penyelidikan masa depan diperlukan dalam alat penguraian perkhidmatan automatik, ramalan kerosakan pintar dalam sistem teragih, dan pengesahan formal interaksi dalam koreografi perkhidmatan.

10. Rujukan

  1. Lewis, J., & Fowler, M. (2014). Microservices. MartinFowler.com. Diperoleh daripada https://martinfowler.com/articles/microservices.html
  2. Newman, S. (2015). Building Microservices. O'Reilly Media.
  3. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
  4. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28-31.
  5. Google Cloud. (2019). The 2019 Accelerate State of DevOps Report. DORA.
  6. Netflix Technology Blog. (Various). https://netflixtechblog.com/