現在開發業務都是微服務，api呼叫rpc，rpc之間互相呼叫。除了常規的鏈結失敗或超時以外，還有很多業務上的錯誤。為了使返回的錯誤碼容易判斷和查錯，通常會靠乙個統一定義的錯誤**對映表。其實我們平時http的各種錯誤碼也就是乙個對映表。
有一種做法是**裡寫死乙個對映表檔案，每次有新增去修改這個檔案。
但是當系統漸漸變大。業務可能會按模組進行拆分並接耦合，業務之間可能只是乙個對接，**repo不會有乙個公有的錯誤碼包。這樣返回的錯誤就比較難定位了。再加上每次要去修改檔案，彼此之間合**還可能會出現錯誤碼衝突，然後還要fix merge，很麻煩。
想到乙個相對簡單的方式，提供乙個錯誤碼的微服務，每次**中要增加新的錯誤型別就向該微服務請求乙個錯誤碼。而所有服務啟動時都會呼叫錯誤碼微服務拉到線上所有的錯誤碼拉到記憶體，這樣就可以實時的保證對各種錯誤碼的對映，可以在捕捉下游呼叫出錯時直接用記憶體裡的錯誤碼對映表列印出錯誤型別的詳細資訊，如果下游做的有心的話甚至可以把可能的錯誤原因都列出來，便於新同學接手。
專案中的思考
從2.0上線，一夜之間湧入20w 使用者，對於我們這種經常看不到併發的應用，壓力隨之而來，在緊急情況下，使用了最為暴力的擴容方案，堆機器，當機器堆到近20台時，使用者反饋卡頓降低了。但是隨之而來的另乙個問題又出現了，因為某乙個模組對資料操作的頻繁程度太高，大約每乙個使用者每秒插入5條記錄 本身這一模...
軟體專案中常見的錯誤
飲彈症候群 過於相信以前沒有採用的技術的宣傳 過高估計了新技術或方案帶來的節省量 專案中切換工具 缺少自動的源 控制手段 挫傷積極性 人員素質低 對有問題的員工失控 英雄主義 專案後期加入人員 辦公環境差 開發人員與客戶 需求方 的摩擦 不現實的預期 缺乏有效的高層對專案的支援 缺乏個角色之間有效合...
IT專案中客戶需求定義的原則和方法
聚傑網需求管理 it專案中客戶需求定義的原則和方法 在企業的銷售隊伍中，經常聽到的抱怨是 我們的客戶不需要 我們的客戶沒有錢 客戶說要等一段時間 等等一些無法開發和征服客戶的聲音，根本的原因是由於不了解客戶的真實需求，銷售人員在銷售時盲無目的地向客戶介紹或者演示產品，結果徒費口舌，不但沒有把自己產品...