Penafian
Perusahaan kami menjalankan aplikasi pada arsitektur Layanan Mikro yang mencakup ribuan layanan. Saya sedang mengerjakan aplikasi backend "X" yang berbicara dengan 50+ layanan. Layanan frontend memanggil layanan saya "X" untuk menjalankan permintaan pada layanan lain.
Pertama-tama, ribuan layanan acak tidak membuat arsitektur menjadi layanan Microsoft seperti arsitektur. Masih diperlukan rasa "keseluruhan" dan sedikit pengaturan di antara layanan. Pedoman atau aturan praktis.
Kontekstualkan backend dalam 'keseluruhan'
Saya berasumsi, backend Anda bukan gateway atau proxy . Saya kira itu memiliki bisnis sendiri dan konteks terbatas yang didefinisikan dengan baik. Jadi, mengenai layanan lain, backend adalah fasad .
Sebagai fasad, menyembunyikan detail implementasi (seperti misalnya, integrasi dengan layanan jarak jauh) adalah tanggung jawabnya. Untuk front-end (dan karenanya, end-user), satu-satunya lawan bicara yang dapat dipercaya adalah X
dan tidak ada detail implementasi yang harus mencapai lapisan luar. Apa pun yang terjadi di bawah tenda, itu bukan urusan pengguna.
Itu tidak berarti kami tidak dapat memberi tahu pengguna bahwa ada yang tidak beres. Kita bisa, tetapi kita melakukannya dengan mengabstraksikan detail-detail ini. Kami tidak akan memberikan arti sesuatu yang jauh gagal. Justru sebaliknya, sesuatu X
gagal dan hanya itu.
Karena kita berbicara tentang ribuan kemungkinan integrasi (+50 atm), jumlah kesalahan yang mungkin dan berbeda adalah signifikan. Jika kami memetakan setiap pesan ke pesan khusus, pengguna akhir akan diliputi oleh begitu banyak informasi (dan tidak kontekstual). Jika kami memetakan semua kesalahan ke sejumlah kecil kesalahan khusus, kami bias informasi, membuat sulit bagi kami untuk melacak masalah dan menyelesaikannya.
Menurut pendapat saya, pesan kesalahan harus memberikan kepada pengguna dengan perasaan bahwa ada sesuatu yang bisa kita lakukan untuk memperbaiki masalah.
Namun demikian, jika pengguna akhir masih ingin tahu apa yang sedang terjadi di bawah tenda, ada cara lain yang lebih berguna bagi seluruh organisasi.
Akuntabilitas
Layanan lain tidak mengembalikan pesan yang ramah pengguna. Tidak mungkin bagi saya untuk meminta perubahan oleh tim lain karena ada beberapa. Tidak ada kode kesalahan yang disepakati.
Layanan lain mengembalikan pesan kesalahan string. Saat ini, ia dilewatkan kembali ke UI. Terkadang pesan kesalahan adalah referensi penunjuk (kode buruk: /)
Sebagai pengembang, tanggung jawab Anda adalah mengungkap argumen ini kepada para pemangku kepentingan. Ini masalah akuntabilitas. Menurut pendapat saya, ada kebocoran kepemimpinan teknis dan itu masalah nyata ketika menyangkut sistem terdistribusi.
Tidak ada gambaran teknis. Jika ada, layanan akan diimplementasikan berdasarkan aturan praktis yang ditujukan untuk membuat sistem scalable dan memudahkan integrasi antar layanan. Saat ini sepertinya layanan muncul liar, tanpa rasa kontribusi pada "keseluruhan".
Jika saya diminta melakukan apa yang diminta (dan kadang-kadang saya lakukan), saya akan berdebat apakah mengubah anarki saat ini menjadi pesan yang ramah pengguna berada di luar cakupan X
.
Setidaknya, "angkat tangan", buka kekhawatiran Anda, buka alternatif Anda dan biarkan siapa pun yang memiliki tanggung jawab untuk memutuskan.
Jadikan solusi Anda berharga bagi perusahaan
Periksa string pesan kesalahan dan miliki pemetaan dalam layanan saya untuk pesan yang mudah digunakan. Tetapi banyak hal dapat rusak jika layanan callee mengubah pesan kesalahan mereka. Kembali ke pesan kesalahan default ketika pemetaan kesalahan khusus tidak ditemukan.
Kamu benar. Itu solusi yang lemah. Ini rapuh dan tidak efisien dalam jangka menengah panjang.
Saya juga berpikir itu menyebabkan penggandengan karena perubahan dalam string ini mungkin memaksa Anda untuk membiasakan pemetaan. Bukan peningkatan besar.
Adakah lagi gagasan tentang solusi yang dapat diskalakan dan berkelanjutan?
Pelaporan . Tangani kesalahan, berikan kode / tiket / id kepada mereka dan laporkan. Kemudian, izinkan front-end untuk memvisualisasikan laporan. Misalnya, berbagi tautan ke layanan pelaporan .
Kesalahan. <Pesan kesalahan yang mudah digunakan dan sangat default>. Ikuti tautan untuk informasi lebih lanjut
Dengan cara ini, Anda dapat mengintegrasikan sebanyak mungkin layanan yang Anda butuhkan. Dan Anda melepaskan diri Anda dari overhead penanganan dan menerjemahkan string acak menjadi string acak baru, tetapi mudah digunakan.
Layanan pelaporan dapat digunakan kembali untuk sisa layanan sehingga, jika Anda memiliki ID yang berkorelasi, harus memungkinkan Anda untuk memungkinkan pengguna untuk memiliki panorama kesalahan dan penyebabnya. Dalam arsitektur terdistribusi, keterlacakan sangat penting.
Kemudian, layanan pelaporan dapat ditingkatkan dengan sebanyak mungkin pemetaan yang Anda butuhkan untuk memberikan instruksi yang dapat dibaca dan bermanfaat tentang apa yang harus dilakukan jika kesalahan X terjadi . Jika string berubah di sini tidak masalah sama sekali. Apa yang kami miliki (simpan) adalah keadaan akhir dari laporan.
Layanan pelaporan akan membuka pintu bagi kemungkinan normalisasi kesalahan dalam organisasi karena layanan akan mengekspos API publik (karenanya merupakan kontrak).