1. 程式人生 > >第二章:演化架構師

第二章:演化架構師

項目 lin 狀態 集成 檢測 設計時 pan 運行 cto

架構師應該設計一個合理的架構,後期可以慢慢的演化出正確的系統,不應該抱著一開始就能設計出完美的產品的想法。 設計出的架構不但能夠保證系統能夠滿足當前的系統要求,還應該可以應對將來的變化。 服務邊界:區分出各個服務的邊界,各個服務中需要關註的重點,以及各個服務之間如何進行交互。 每個服務內部可以使用不同的技術棧或者數據儲存技術。盡可能保證服務之間的交互使用相同的接口方式,保證服務間調用可以比較方便。例如如果服務一使用了restful、服務二使用了protocol buffers、服務三使用Java rmi,這樣三個服務之間調用會比較復雜,不利於開發。 原則:做系統設計時需要需要各個方面的取舍: 為了和定制的的目標保持一樣,我們會指定一些規則,這些規則稱為原則。原則不是一成不變的,原則一般不應該超過10個,可以讓開發人員方便記住。 推薦使用https://www.12factor.net/
可以創建應用的設計原則。 原則可以自己決定,同時要顯示的指出哪些是原則,哪些是約束。 實踐:通過相應的實踐保證原則能夠得到實施,這些實踐能夠直到我們如何完成任務。 實踐包含代碼規範、日誌數據收集或者http/rest作為標準繼承風格等。 由於實踐比較偏技術層面,因此其改變的頻率會高於原則。 原則與實踐結合 重要的原則可以指導系統的演化,同時也要有一些細節來指導如何實現這些原則。 要求的標準 決定原則和實踐的時候,需要註意的一個重要因素是系統允許多少變化。 需要識別出各個服務之間應該遵守的通用規則,可以通過“給出一個服務的例子來闡述服務的特點”。 在優化單個服務的時候也要兼顧全局各個服務,可以通過“定義出一個好服務的屬性”的方式來幫助我們實現平衡的方法。 監控
能夠清晰的描繪出跨服務系統的健康狀態非常重要。這必須在系統級別而非單個服務級別進行考慮。 可以選擇使用“推送機制”,就是每個服務主動把數據推送到某個集中的位置。 也可以選擇使用Nagios來檢測健康狀態,或者使用輪訓系統來從各個節點收集數據。 每個服務的具體實現不同,因此不用為每個服務具體實現而改變監控系統。 日誌功能和監控情況類似,也應該需要進行集中式管理。 接口 選擇少數幾種明確的接口技術有助於新消費者的集成。 可以使用一種、兩種等,但是不用使用過多的技術集成方案。 通常來說使用Http/rest方式時可以優先考慮的。、 架構安全性 一個運行異常的服務可能導致整個系統的奔潰,因此要保證每個服務都可以應對下遊服務的錯誤請求。 沒有處理好下遊服務請求的服務越多,我們系統就會越脆弱。 返回一致的錯誤信息,或者返回碼應該遵守一定的規則。 對一下幾種請求做出正確的處理可以幫助系統及時失敗: 1、正常並且被正確處理的請求; 2、錯誤請求,並且服務識別出了它的錯誤; 3、被訪問的服務宕機了,所以無法判斷請求是否正常; 代碼治理
提供規範和服務代碼模板,可以幫助我們很快的達成共識。 規範 編寫文檔非常有用,如果一個項目中有一個比較好的代碼規範可以用於被模仿,可以保證具體開發時用於模仿,並且即使出錯也不會太離譜。 規範的代碼模板中可以體現出設計的原則。 剪裁服務代碼模板 當需要開發一個新的服務時,所有實現核心屬性的那些代碼應該是現成的。 針對自己的開發實踐剪裁出一個服務代碼模板,不但可以提供開發速度,同時還可以保證服務的質量。 如果不同服務的技術棧不同,那麽也應該為不同的技術棧都提供一個服務代碼模板。 創建服務代碼模板時,需要通過合作的方式定義出具體的實踐。 要註意一個問題:代碼的重用,代碼的重用可能導致服務間的耦合,如果核心服務代碼模板進行升級,可能導致所有的服務都必須升級。 技術債務 有時候可能由於一些緊急的需求特性,而導致無法遵守技術定義的設計原則。這樣做短期會有收益,但是從長期考慮可能會付出大的代價。 不光走捷徑會導致技術債務的發生,有時候系統實現目標的變更,並且與現有的系統不符,這也會導致技術債務的出現。 架構師的職責就是從高層次出發,考慮如何權衡。理解技術債務的層次以及對系統的影響非常重要。

第二章:演化架構師