Startups, Adakah anda benar-benar mahu membayar cukai Microservices?

Mengapa membahagikan pangkalan kod anda terlalu awal boleh diam-diam memusnahkan kelajuan pasukan anda - dan apa yang perlu dilakukan sebaliknya. . Mengapa membahagikan pangkalan kod anda terlalu awal boleh diam-diam memusnahkan kelajuan pasukan anda - dan apa yang perlu dilakukan sebaliknya Dalam sebuah startup, Ini adalah di mana seni bina asas startup anda memainkan peranan yang besar; di samping itu, perkara-perkara seperti tumpukan teknologi anda dan pilihan bahasa pemrograman secara langsung mempengaruhi kelajuan pasukan anda. your survival depends on how quickly you can iterate, ship features, and deliver value to end-users Saya mempunyai pengalaman ini ketika bekerja pada projek greenfield untuk permulaan peringkat awal, di mana keputusan yang dipertanyakan dibuat dalam hal seni bina perisian yang membawa kepada perkhidmatan separuh selesai dan dan yang berjuang untuk mengekalkan kompleksiti yang tidak perlu. pengaturan tempatan yang rapuh, over-engineered dan rosak demoralized teams Sebelum menyelam ke dalam perangkap tertentu, di sini adalah apa yang anda benar-benar mendaftar apabila memperkenalkan microservices prematur: Microservices Early On: What You’re Paying For Pain Point Real-World Manifestation Developer Cost Deployment Complexity Orchestrating 5+ services for a single feature Hours lost per release Local Dev Fragility Docker sprawl, broken scripts, platform-specific hacks Slow onboarding, frequent breakage CI/CD Duplication Multiple pipelines with duplicated logic Extra toil per service Cross-Service Coupling "Decoupled" services tightly linked by shared state Slower changes, coordination tax Observability Overhead Distributed tracing, logging, monitoring Weeks to instrument properly Test Suite Fragmentation Tests scattered across services Brittle tests, low confidence Kerumitan Penyebaran Orkestrasi 5+ perkhidmatan untuk satu ciri Hours lost per release Kegagalan Dev Penyebaran Docker, skrip pecah, hack spesifik platform Slow onboarding, frequent breakage CI / CD Duplikasi Pelbagai paip dengan logik duplikat Extra toil per service Perkhidmatan Cross Coupling Perkhidmatan "terpisah" yang terhubung rapat oleh keadaan bersama Slower changes, coordination tax Pengawasan Overhead Penjejakan, logging dan pemantauan Weeks to instrument properly Ujian Suite Fragmentasi Ujian tersebar di seluruh perkhidmatan Brittle tests, low confidence Mari kita membongkar mengapa microservices sering backfire awal, di mana mereka benar-benar membantu, dan bagaimana untuk membina sistem startup anda untuk kelajuan dan kelangsungan hidup. Monolit Bukan Musuh Jika anda membina beberapa produk SaaS, walaupun pembungkusan pangkalan data SQL yang mudah pada akhirnya boleh membawa banyak kerumitan dalaman dalam cara logik perniagaan anda berfungsi; Di samping itu, anda boleh mendapatkan pelbagai integrasi dan tugas latar belakang yang membolehkan anda menukar satu set data kepada yang lain. Dengan masa, kadang-kadang ciri-ciri yang tidak perlu, ia tidak dapat dielakkan bahawa aplikasi anda boleh menjadi berantakan. : Monoliths, even when messy, keep your team focused on what matters most kekal hidup Memberikan nilai pelanggan Kelebihan terbesar monoliths ialah kesederhanaan dalam pengenalan mereka. Secara amnya, projek-projek sedemikian dibina di sekitar kerangka kerja sedia ada — ia boleh menjadi Django untuk Python, untuk C#, Nest.js untuk aplikasi Node.js, dan lain-lain Apabila memegang kepada seni bina monolit, anda mendapat kelebihan terbesar berbanding microservices yang cemerlang - sokongan yang luas daripada komuniti sumber terbuka dan pemelihara projek yang terutama direka bentuk kerangka kerja itu untuk berfungsi sebagai satu proses, aplikasi monolit. Perkhidmatan ASP.NET Pada satu pelancaran hartanah di mana saya memimpin pasukan front-end, dan kadang-kadang berkonsultasi dengan pasukan backend mengenai pilihan teknologi, kami mempunyai evolusi yang menarik daripada aplikasi berasaskan Laravel. Seiring waktu, ia berkembang menjadi suite yang kaya ciri yang menangani beratus-ratus gigabyte dokumen dan disepadukan dengan puluhan perkhidmatan pihak ketiga. Pasukan sangat bergantung kepada amalan terbaik yang direkomendasikan oleh komuniti Laravel. disiplin itu berbayar, kami mampu mengembangkan keupayaan aplikasi secara signifikan sambil masih memenuhi keperluan dan harapan perniagaan. Menariknya, kami tidak pernah perlu memisahkan sistem ke dalam microservices atau mengadopsi corak infrastruktur yang lebih kompleks. Kami mengelakkan banyak kerumitan yang kebetulan dengan cara itu. Kesederhanaan seni bina memberi kita leverage. , yang menjelaskan mengapa kesederhanaan adalah kuasa super awal. “Majestic Monolith” ialah Orang sering menunjukkan bahawa ia sukar untuk membuat monoliths scalable, tetapi ia adalah modularisasi yang buruk monolit yang boleh membawa kepada masalah sedemikian. dalam Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting. Tetapi bukankah microservices adalah "praktik terbaik"? Ramai jurutera menjangkau microservices awal, berfikir bahawa mereka adalah "jalan yang betul."Dan pasti - pada skala, mereka boleh membantu. Microservices hanya membayar apabila anda mempunyai hambatan skala sebenar, pasukan besar, atau domain yang berkembang secara bebas.Sebelum itu?Anda membayar harga tanpa mendapat faedah: duplikat infra, setup tempatan yang rapuh, dan iterasi yang lambat. Akhirnya kerana sebab ini – terlalu banyak kos, tidak cukup nilai. Segment membalikkan perpecahan perkhidmatan mikro mereka Takeaway: Microservices are a scaling tool — not a starting template. Di mana microservices pergi salah (terutamanya awal) Dalam satu pasukan peringkat awal yang saya cadangkan, keputusan untuk membahagikan perkhidmatan menghasilkan lebih banyak penyelarasan PM-teknik daripada keuntungan teknikal. arsitektur membentuk bukan sahaja kod, tetapi bagaimana kami merancang, menganggarkan, dan menghantar. Berikut adalah anti-pattern yang paling biasa yang merebak pada awal. Perbatasan Perkhidmatan Arbitrari Secara teori, anda sering melihat cadangan untuk membahagikan aplikasi anda mengikut domain logik perniagaan - perkhidmatan pengguna, perkhidmatan produk, perkhidmatan pesanan, dan sebagainya.Ini sering dipinjamkan daripada konsep Reka bentuk Diri Domain atau Arsitektur Bersih - yang bermakna dalam skala, tetapi dalam produk peringkat awal, mereka boleh mengossifikasi struktur prematur, sebelum produk itu sendiri stabil atau disahkan. pangkalan data yang dikongsi Cross-service memerlukan aliran kerja yang mudah Perpaduan disamar sebagai "perbezaan" Dalam satu projek, saya menyaksikan pasukan memisahkan pengguna, pengesahan, dan pengesahan kepada perkhidmatan yang berasingan, yang membawa kepada kerumitan pemasangan dan kesukaran dalam penyelarasan perkhidmatan untuk mana-mana operasi API yang mereka cipta. Sebenarnya, logik perniagaan tidak secara langsung memaparkan sempadan perkhidmatan. pemisahan awal boleh menjadikan sistem lebih rapuh dan sering kali sukar untuk memperkenalkan perubahan dengan cepat. Sebaliknya, mengasingkan botol secara bedah - berdasarkan kesakitan skala sebenar, bukan keanggunan teori. Apabila saya telah melatih pasukan peringkat awal, kami kadang-kadang menggunakan bendera dalaman atau penambahan tolak untuk mensimulasikan perpecahan perkhidmatan masa depan - tanpa beban operasi segera. Takeaway: Don’t split by theory — split by actual bottlenecks. 2.Repository dan Infrastruktur Sprawl Apabila bekerja pada aplikasi, biasanya satu set perkara berikut adalah penting: Kesesuaian gaya kod (linting) Pengujian infrastruktur, termasuk pengujian integrasi Konfigurasi persekitaran tempatan Dokumentasi Konfigurasi CI/CD Jika projek anda distrukturkan sebagai monorepo, anda boleh menyederhanakan hidup anda dengan mempunyai konfigurasi CI / CD pusat (ketika bekerja dengan GitHub Actions atau GitLab CI). Sesetengah pasukan memisahkan microservices ke dalam repositori berasingan, yang membuatnya lebih sukar untuk mengekalkan konsistensi kod dan set konfigurasi yang sama tanpa usaha tambahan atau alat. Untuk pasukan tiga orang, ini adalah brutal. beralih konteks di antara repositori dan alat menambah sehingga masa pembangunan setiap ciri yang dihantar. Mengurangkan masalah dengan menggunakan monorepos dan bahasa pemrograman tunggal Terdapat pelbagai cara untuk mengurangkan masalah ini.Pada projek awal, satu perkara yang paling penting ialah - menyimpan kod anda dalam monorepo.Ini memastikan bahawa terdapat satu versi kod yang wujud pada prod, dan ia lebih mudah untuk mengoordinasikan ulasan kod dan bekerjasama untuk pasukan yang lebih kecil. Untuk projek Node.js, saya sangat mengesyorkan menggunakan alat monorepo seperti atau Kedua-duanya ialah nx turborepo Menyederhanakan konfigurasi CI/CD di antara subprojek Sokongan penyimpanan caching berasaskan grafik Biarkan anda merawat perkhidmatan dalaman sebagai pustaka TypeScript (melalui import ES6) Alat-alat ini menjimatkan masa yang dihabiskan untuk menulis kod limau atau mencipta semula orkestrasi. Pokok ketagihan kompleks boleh tumbuh dengan cepat Tuning prestasi CI bukan trivial Anda mungkin memerlukan alat yang lebih cepat (seperti bun) untuk mengekalkan masa pembinaan Untuk meringkaskan: Tooling like atau memberi pasukan kecil kelajuan monorepo - jika anda bersedia untuk melabur dalam menjaga mereka bersih. nx turborepo Apabila membangunkan microservices, idea yang baik awal dalam pembangunan adalah untuk menggunakan satu ruang kerja dengan Direktif dalam Akhirnya, sebagai perisian skala, ia adalah mungkin untuk memisahkan tanpa usaha Modul dalam repository yang berasingan. go go replace go.mod go Takeaway: A monorepo with shared infra buys you time, consistency, and sanity. Dev yang rosak = kelajuan yang rosak If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity. Projek awal sering menderita daripada: Dokumen yang hilang ketergantungan yang usang Hacks spesifik OS (Hello, setup Linux sahaja) Dalam pengalaman saya, apabila saya menerima projek daripada pasukan pembangunan masa lalu, mereka sering dikembangkan untuk satu sistem operasi sahaja. Sesetengah pengembang lebih suka membina pada macOS dan tidak pernah mengganggu menyokong skrip shell mereka pada Windows. Dalam pasukan saya yang lalu, saya mempunyai jurutera yang bekerja pada mesin Windows, dan seringkali ia memerlukan penulisan semula skrip shell atau pemahaman sepenuhnya dan reverse engineering proses untuk mendapatkan persekitaran tempatan berjalan. Dengan masa, kami menyederhanakan pemasangan persekitaran di seluruh sistem operasi pengembang untuk mengurangkan geseran pada kemasukan — pelaburan kecil yang menjimatkan jam per jurutera baru. Dalam projek lain, seorang pengembang solo telah mencipta setup microservice yang rapuh, bahawa aliran kerja menjalankan kontena Docker dipasang ke sistem fail tempatan. Tetapi memasang pengembang front-end baru dengan laptop Windows yang lebih tua berubah menjadi mimpi buruk. Mereka terpaksa memasang sepuluh kontena hanya untuk melihat UI. Segala-galanya pecah - volume, rangkaian, keserasian kontena - dan pemasangan sangat kurang didokumenkan. Kami akhirnya hack bersama-sama Node.js proxy yang meniru konfigurasi nginx / Docker tanpa wadah.Ia tidak elegan, tetapi ia membenarkan pengembang untuk diblokir dan mula menyumbang. Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster. Idealnya, matlamat untuk Jika tidak mungkin, maka mengekalkan fail README yang terkini dengan arahan untuk Windows / macOS / Linux adalah perlu. hari ini, terdapat beberapa bahasa pemrograman dan rantaian alat yang tidak berfungsi dengan baik pada Windows (seperti OCaml), tetapi tumpukan popular moden berjalan dengan baik pada setiap sistem operasi yang digunakan secara meluas; dengan membatasi setup tempatan anda kepada satu sistem operasi tunggal, ia sering merupakan gejala kurang pelaburan dalam DX. Tip: git clone && make up 4. teknologi penyelewengan Di luar seni bina, tumpukan teknologi anda juga membentuk bagaimana perkhidmatan mikro yang menyakitkan menjadi - tidak setiap bahasa bersinar dalam seni bina perkhidmatan mikro. Node.js dan Python: Baik untuk iterasi yang cepat, tetapi menguruskan membina artefak, versi ketergantungan, dan konsistensi runtime di antara perkhidmatan menjadi menyakitkan dengan cepat. Go: Mengumpulkan kepada binari statik, masa pembinaan yang cepat, dan overhead operasi yang rendah. lebih semulajadi apabila pemisahan benar-benar diperlukan. Ia adalah sangat penting untuk memilih tumpukan teknikal yang betul pada awalnya.Jika anda mencari prestasi, mungkin mencari JVM dan ekosistemnya dan keupayaan untuk mengimplementasikan artefak dalam skala dan menjalankan mereka dalam seni bina berasaskan microservice.Jika anda melakukan iterasi yang sangat cepat dan prototipe dengan cepat tanpa bimbang tentang mengecas infrastruktur pemasangan anda - anda baik dengan sesuatu seperti Python. Ia adalah agak kerap bagi pasukan untuk menyedari bahawa terdapat masalah besar dengan pilihan teknologi mereka yang tidak jelas pada mulanya, dan mereka terpaksa membayar harga membina semula latar belakang dalam bahasa pemrograman yang berbeza (seperti telah dipaksa untuk melakukan sesuatu mengenai codebase Python 2 yang diwarisi dan dipindahkan ke Go). lelaki tu Tetapi sebaliknya, jika anda benar-benar perlu, anda boleh menghubungkan pelbagai bahasa pemrograman dengan protokol seperti atau komunikasi mesej async. Dan ia sering merupakan cara untuk pergi tentang perkara-perkara. Apabila anda mencapai titik bahawa anda ingin memperkaya set ciri anda dengan fungsi pembelajaran mesin atau pekerjaan berasaskan ETL, anda hanya akan membina infrastruktur berasaskan ML anda secara berasingan dalam Python, kerana ekosistem kaya perpustakaan khusus domain, yang secara semulajadi mana-mana bahasa pemrograman lain kekurangan. gRPC Takeaway: Match the tech to your constraints, not your ambition. Kompleks Tersembunyi: Komunikasi dan Pengawasan Microservices memperkenalkan rangkaian keperluan yang tidak kelihatan: Perkhidmatan penemuan Versi api Retries, pemutus sirkuit, fallbacks Pengenalan Distributed Pengekalan dan amaran bersentralisasi Dalam sistem terdistribusi, ia adalah "mengapa perkhidmatan A gagal apabila penyebaran B menangguhkan C dengan 30 saat?" Anda perlu melabur secara menyeluruh dalam tumpukan pengesan anda. Untuk melakukannya "sesuai", ia memerlukan instrumen aplikasi anda dengan cara tertentu, contohnya mengintegrasikan OpenTelemetry untuk menyokong pelacakan, atau bergantung kepada alat penyedia awan anda seperti AWS XRay jika anda pergi dengan sistem tanpa pelayan yang kompleks. berfungsi dalam pengeluaran. actually Sudah tentu, beberapa instrumen pengesan diperlukan untuk dilakukan pada aplikasi monolit, tetapi ia jauh lebih mudah daripada melakukannya dalam hal bilangan perkhidmatan dengan cara yang konsisten. Memahami bahawa Mereka adalah komitmen kepada kelas cabaran kejuruteraan yang sama sekali baru. Tip: distributed systems Bukan percuma Bukan percuma Apabila perkhidmatan mikro buat akal Do ialah Do ialah Walaupun kesukaran yang dinyatakan dengan microservices, terdapat masa di mana pemisahan peringkat perkhidmatan sebenarnya sangat bermanfaat. Isolasi beban kerja: contoh yang biasa untuk itu adalah dalam amalan terbaik AWS mengenai penggunaan pemberitahuan kejadian S3 - apabila imej dimuat ke S3, memicu proses perubahan imej / OCR, dan lain-lain Mengapa ia berguna: kami boleh memisahkan pustaka pemprosesan data yang tidak jelas dalam perkhidmatan yang terisolasi dan menjadikannya API yang memberi tumpuan sahaja kepada pemprosesan imej dan menghasilkan output daripada data yang dimuat naik. Divergent Scalability Needs: — Bayangkan anda sedang membina produk AI. Salah satu bahagian sistem (API web) yang memicu muatan kerja ML dan menunjukkan hasil masa lalu tidak mengandungi sumber, ia ringan, kerana ia berinteraksi terutamanya dengan pangkalan data. Sebaliknya, model ML yang dijalankan pada GPU sebenarnya sukar untuk dijalankan dan memerlukan mesin khas dengan sokongan GPU dengan konfigurasi tambahan. Keperluan Runtime yang berbeza: — Katakanlah anda mempunyai sebahagian daripada kod yang diwarisi yang ditulis dalam C++. Anda mempunyai 2 pilihan — secara ajaib menukarnya ke dalam bahasa pemrograman teras anda atau mencari cara untuk mengintegrasikannya dengan pangkalan kod. Bergantung kepada kerumitan aplikasi yang diwarisi itu, anda perlu menulis kod lip, melaksanakan rangkaian tambahan / protokol untuk mewujudkan interaksi dengan perkhidmatan itu, tetapi garis bawah adalah — anda mungkin perlu memisahkan aplikasi ini sebagai perkhidmatan berasingan kerana ketidaksesuaian runtime. Saya akan mengatakan lebih, anda boleh menulis aplikasi utama anda dalam C++ juga, tetapi kerana konfigurasi kompilator yang berbeza dan ketergantungan pustaka, anda tidak akan dapat dengan mudah menyusun perkara bersama sebagai satu binari. Organisasi kejuruteraan skala besar telah berjuang dengan cabaran yang sama. contohnya, pasukan kejuruteraan Uber — bukan daripada kemurnian teori, tetapi sebagai tindak balas kepada kerumitan sebenar di antara pasukan dan skala sempadan. pos mereka adalah contoh yang baik bagaimana microservices boleh berfungsi apabila anda mempunyai kematangan organisasi dan overhead operasi untuk menyokong mereka. mendokumentasikan peralihan mereka kepada seni bina microservice yang berorientasikan domain Pada satu projek, yang juga berlaku untuk real estate, kami mempunyai kod daripada pasukan terdahulu yang menjalankan beban kerja analitik berasaskan Python yang muat naik data ke dalam db MS-SQL, kami mendapati bahawa ia akan menjadi sia-sia untuk membina di atasnya aplikasi Django. Takeaway: Use microservices when workloads diverge — not just because they sound clean. Panduan praktikal untuk startups Jika anda menghantar produk pertama anda, di sini adalah playbook yang saya cadangkan: Mulakan monolithic. Pilih kerangka kerja biasa dan tumpukan kepada mendapatkan ciri-ciri yang dilakukan. Semua kerangka kerja yang diketahui lebih daripada cukup baik untuk membina beberapa API atau laman web dan berkhidmat kepada pengguna. Jangan mengikuti hype, berpegang kepada cara yang membosankan untuk melakukan perkara-perkara; anda boleh berterima kasih kepada diri anda nanti. Jangan risau membahagikan kod anda ke dalam pelbagai repositori.Saya telah bekerjasama dengan pengasas yang ingin memisahkan repos untuk mengurangkan risiko kontraktor menyalin IP – satu masalah yang sah.Tetapi dalam amalan, ia menambah lebih banyak geseran daripada keselamatan: pembinaan yang lebih lambat, CI / CD yang berpecah-belah, dan kelihatan yang buruk di seluruh pasukan. Perlindungan IP marginal tidak bernilai tarikan operasi, terutamanya apabila kawalan akses yang betul di dalam monorepo lebih mudah dikendalikan. Setup tempatan yang mudah mati. Buat kerja make up. Jika ia mengambil lebih banyak, menjadi sangat spesifik pada langkah-langkah, merekodkan video / Loom, dan menambah screenshots.Jika kod anda akan dijalankan oleh pengembang pelajar atau junior, mereka mungkin akan menjejaskan jalan, dan anda akan menghabiskan masa menjelaskan bagaimana untuk memecahkan masalah.Saya mendapati bahawa mendokumentasikan setiap masalah yang mungkin untuk setiap sistem pengendalian menghilangkan masa yang dihabiskan untuk menjelaskan mengapa perkara-perkara tertentu dalam setup tempatan tidak berfungsi. Berinvestasi awal dalam CI/CD. Walaupun ia adalah HTML yang mudah yang anda hanya boleh scp ke pelayan secara manual, anda boleh mengotomatiskan ini dan bergantung kepada kawalan sumber dengan CI/CD untuk melakukannya. Apabila setup diotomatiskan dengan betul, anda hanya lupa tentang infrastruktur integrasi berterusan anda dan memberi tumpuan kepada ciri-ciri.Saya telah melihat banyak pasukan dan pengasas semasa bekerja dengan pasukan luar biasa sering murah pada CI/CD, dan itu bermakna pasukan yang terdorong dan terganggu oleh proses penyebaran manual. Membahagikan secara bedah. hanya membahagikan apabila ia jelas menyelesaikan masalah botol yang menyakitkan. jika tidak, melabur dalam modulariti dan ujian di dalam monolitik - ia lebih cepat dan lebih mudah untuk mengekalkan. Dan terutamanya : optimize for developer velocity. Microservices prematur bocor oksigen itu perlahan-lahan - sehingga satu hari, anda tidak boleh bernafas. Velocity is your startup’s oxygen. Takeaway: Start simple, stay pragmatic, and split only when you must. Jika anda menggunakan pendekatan berasaskan perkhidmatan mikro Saya mempunyai projek berasaskan perkhidmatan mikro yang dibuat lebih awal daripada yang seharusnya dilakukan, dan di sini adalah cadangan berikut yang boleh saya berikan untuk itu: Menilai tumpukan teknikal anda yang memberi kuasa kepada seni bina berasaskan perkhidmatan mikro anda. Berinvestasi dalam alat pengalaman pengembang. Apabila anda mempunyai pemisahan berasaskan perkhidmatan, anda kini perlu berfikir tentang mengotomatiskan tumpukan microservice anda, mengotomatiskan konfigurasi di kedua-dua persekitaran tempatan dan pengeluaran. Dalam beberapa projek, saya terpaksa membina CLI berasingan yang melakukan tugas pentadbiran pada monorepository. Satu projek yang saya telah mengandungi 15-20 penyebaran microservice, dan untuk persekitaran tempatan, saya terpaksa mencipta alat klik untuk menghasilkan fail docker-compose.yml secara dinamik untuk memulakan satu perintah tanpa disamakan untuk pengembang biasa. Fokus pada protokol komunikasi yang boleh dipercayai di sekitar komunikasi perkhidmatan. Jika ia adalah mesej async, pastikan skim mesej anda adalah konsisten dan standard. Jika ia REST, fokus kepada dokumen OpenAPI. Pelanggan komunikasi antara perkhidmatan mesti melaksanakan banyak perkara yang tidak keluar-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari-dari- Pastikan bahawa unit anda, ujian integrasi, dan seting ujian end-to-end stabil dan berskala dengan jumlah pemisahan peringkat perkhidmatan yang anda masukkan ke dalam kod pangkalan anda. Pada projek-projek yang lebih kecil yang menggunakan beban kerja berasaskan perkhidmatan mikro, anda mungkin akan secara lalai ke perpustakaan bersama dengan pembantu biasa untuk menginstrumen pengesan, kod komunikasi anda dengan cara yang konsisten. Satu pertimbangan penting di sini - menjaga perpustakaan bersama anda sekecil mungkin. sebarang perubahan besar memaksa pembinaan semula di semua perkhidmatan bergantung - walaupun tidak berkaitan. Tambah log JSON terstruktur dan mencipta ID korelasi yang berbeza untuk memulihkan perkara selepas aplikasi anda dilancarkan.Walaupun pembantu asas yang mengeluarkan maklumat log yang kaya (sampai anda mengendalikan aplikasi anda dengan kemudahan log / pelacakan yang betul) sering menjimatkan masa untuk mencari tahu aliran pengguna yang licin. Untuk meringkaskan: jika anda masih pergi untuk microservices, anda harus terlebih dahulu memahami cukai yang anda akan membayar dalam hal masa pembangunan tambahan dan pemeliharaan untuk membuat setup boleh bekerja untuk setiap jurutera dalam pasukan anda. Takeaway: If you embrace complexity, invest fully in making it manageable. Kesimpulan Membahagikan hanya apabila kesakitan membuatnya jelas. Premature microservices are a tax you can’t afford. Stay simple. Stay alive. Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add. Sumber berkaitan Monolith Pertama - Martin Fowler The Majestic Monolith – DHH / Basecamp Selamat Tinggal Microservices: Daripada 100s kanak-kanak bermasalah kepada 1 superstar — Segmen Eng. Menyelesaikan masalah ini - Shopify Eng. Arsitektur Microservice Berorientasikan Domain – Uber Eng. Go + Perkhidmatan = Satu Projek Goliath - Khan Academy