能用最少的概念,最精簡易懂的概念模型來抽象系統,多一個概念就多一份別人瞭解系統以及維護系統的複雜度,別人也會質疑多一個概念的意義所在,本身若是沒想清楚就容易被diss。web
特別是在類的設計中,會發現其實不少時候用一個類就能夠表達要乾的單一職責了,每一個類職責清晰,類於類之間關係易於理解及維護。編程
對於這點深有體會, 特別是在對設計此類系統沒有業務經驗的時候,不要嘗試第一次就構建一個所謂「完美」系統,系統是要面向迭代的,永遠都是隨時準備修改或增長功能,因此設計系統的目標不在於追求一次性構建完美全面的功能,而在於追求系統對功能支持的擴展性,是否能具備快速cover新業務需求,從而分秒迭代自身的能力。後端
而且業務是多變的,設計時知足好當前的功能需求,並預留擴展點,即便目前功能不完備,也能在將來快速構建它。機器學習
不必過分設計,特別是在自身經驗不豐富的狀況下,意淫的美好都是太自我,雖然多思考勇於嘗試是好事情,但仍是要找高手明確好要作的事情,不然對開發人力的浪費。開發暫時不須要的功能會致使最「重要且緊急」的需求delay或bug風險異步
先學會爬,而後再學會走,最後學會跑。換句話說,先保證可以正常運行,而後優化它使其更好,最後逐漸讓它變得完美。爲每一個功能制定一個開發週期(最多2周),而後不斷迭代。編程語言
工做中會發現任務都是排着隊的,至於任務隊列的 compare方法怎麼寫,對於事情的四象限法則,事情的投資回報率是評估是否重要的重要考量。分佈式
功能的設計和測試儘量獨立。若是在設計時考慮到這一點,長遠來看,它將省去不少麻煩,不然只有一切構建完成時你才能夠開始測試整個系統。不少時候直到要測試某個功能的時候,才發現代碼相互依賴,而沒法獨立測試某模塊。微服務
該理念的核心在於:先制定一些用例,完成用例所涉及的相關功能,當即發佈產品,而後根據反饋和經驗對產品進行優化。工具
在需求評審階段儘量明確要作的事情,知悉pm需求的業務意義,才能更好更明確的帶着目標作事情,技術評審階段,儘可能想清楚需求邊界及所需的技術和業務資源來評估好開發時間,並乘以一個係數做爲交付時間(主要是爲後期忽然插入的事情留buffer),從項目生命週期開始,直到上線期間,和相關人員常常進行 關鍵步驟同步和確認,你們不會每天盯着你在作的事情,要主動同步進度,尋求反饋,能夠避免方向走偏,同時方便對於領導也能掌控全局信息。學習
在多人協做過程當中,流程規範化的意義,好比結論文檔化,分支管理按照契約。你們都有了common sense,辦公效率也是極大提升。
試想微服務系統節點較少,倆人協做的時候,信息的溝通等價於最簡單的的Pub/Sub模型,信息的傳遞較爲簡單,你們都會把對方同步給本身的事情處理好,甚至還閒着沒事兒催促你好幾遍,由於每一個人只訂閱對方的消息,來源單一,處理起來不會遺忘。後來的後來系統複雜了(同事多了),你做爲生產者有了好多個消費者同事,好比你要改一個接口,涉及到好幾個其餘模塊開發者,你推進此次升級須要每階段都push各方同事這時候有個問題:
除了其它端,發現 支付端 也須要升級你的接口,而後屁顛屁顛跑人家那又巴拉巴拉描述如何升級——每一個消費者接入,都須要生產者開發適配新消費者的消息發送代碼。
別忘了工做中你自己做爲生產者同時也在訂閱別人,總之你做爲一個節點,你的全部peer消息你都要處理,消息量大還處理不過來,容易遺漏。要麼是push消息,要麼是處理別人的消息,對於push別人的消息,你還要作好「降級」,由於你告訴別人這樣作了,你確保不了別人必定按你說的作,消息一多這個時候人腦子會很容易亂的,別人若是作錯了,若是不認可你給他push過消息怎麼辦?你要背鍋嘛。。。
怎麼辦呢? 引入業務消息中間件~
因此人多了就得學會解耦,每一個模塊都有人專門負責,模塊間的溝通工做,須要一種協議來確保溝通準確性和解耦,上面說的是典型的同步rpc協議,意味着你要了解全部的消費者,還要處理新來的消費者,沒有消息落盤,不可追溯。若是這個時候有一些文檔或消息羣來承載結論性的消息變動,你們都只須要跟蹤這個文檔或這個羣就能夠了,生產者就往裏push消息,剩下的分佈式消息處理一致性讓別人來保證就能夠了,哪一端沒處理好,怪不了你了可。
首先不用處理對別方的降級,都按文檔約定的來的,也同步給你了,對於新的消費者接入,看文檔就行了。 每一個人就只須要push消息到文檔落盤,訂閱別人的文檔watch變動,大量消息落盤,我的能夠異步消費,而不會丟消息,落盤的消息可重複消費,可記錄歷史,避免溝通的扯皮,確保研發環節的有條不紊。當系統更大的時候,每一個人工做消息模式複雜度保持不變,這也是 消息中間件 消息消峯 解耦的意義。
還沒關注個人公衆號?