我可能不會需要微服務?!
微服務所帶來的彈性,以及它與CI/CD,與敏捷等所帶來的效率,讓你心動不已嗎? 微服務和容器、CI/CD、Kubernetes、敏捷等概念有著互相增強彼此所帶來效益的能力。這幾年伴隨著各類技術的發展,台灣自然也沒少了這股熱潮,而這樣的趨勢仍然還在沸騰中。身為一個技術工作者,或許早已看不慣公司裡陳年的大系統,正想一展長才,響應潮流,而管理者或許因為數位轉型與創新的壓力,開始希望從這熱潮中,找尋成功的方程式。 微服務並不是去年才出來的概念,而自家的系統也不是今天才開始運行。先想想「值得嗎?」 微服務是首要之務嗎? 重構系統將其微服務化是一件極大的工程。相信大家對於微服務所帶來的好處朗朗上口,然而分散式系統的管理複雜度和資源的額外開支,在朗朗上口之餘,也必須認真對待。另外,在過程中可能帶來的業務穩定性衝擊與業務發展資源不足的問題。更重要的是,它所帶來的效益不見得如你所想像的!這幾年穿梭在各類系統架構中,常常必須苦惱不已地進行抉擇,分享幾個思考點,或許能夠在大家踏上旅程前,先想想是否已經可以無悔走上重構: 原先系統的狀態 向原先系統磨刀霍霍之前,先想想「目前原先系統修改的需求高,修改頻繁的發生嗎?」、「大多數新的實作是否仍然增加在原先系統,還是其他服務裡?」如果,原先系統已經處在維護狀態,或者是新的實作大都與原先系統無關,那麼或許更重要的是在流程或其他面向上的優化。 系統已經可預期或已出現容量瓶頸 原先的設計已經限制住系統本身處理當前或者是未來的使用量。如果時常進行尖峰調度,而且調度應變困難,抑或者調度也很難再處理使用量的增長。那麼首要之務,找出瓶頸的服務接口與對應功能類別。作為之後,首要改善之所。 工程資源 任何的改善變更都需要人。如果工程人員已經吃緊,而又另外增加重構改善等任務,那麼下場很可能是不減反增的技術債、業務進展發生開發瓶頸、與惡化的勞動條件。人永遠不是資源,而是企業成長的夥伴!持續性地超支所衍生的代價,恐怕會降低重構的成功機率,以及削減重構所帶來的效益。 原始設計是否良善 單體式(Monolith)架構其實也沒什麼罪惡。如果原始設計已經維持著良好結構,也能正確體現低耦合與高凝聚等特性。那麼它的後續維護其實不見得比較難。難以維護往往是因為求快的實作,導致軟體內部設計耦合度過高,牽一髮動全身,發生問題還無處找之類的狀況。因此,不管在任何時候都好好設計軟體,會讓自己後顧之憂少許多。一個隨便實作的微服務,其實也沒比良善實作單體服務高明到哪?更甚而是不僅要面對可怕的設計外,還要負擔分散式管理的複雜,恐怕問題只是雪上加霜。 如果面對一個既有系統時,已經發生容量問題,設計又差,時常又要新增功能,往往耗損在應對,而非新發展,那麼或許重構是幾乎是你首選了,盤點一下人力狀況和工作配比,為自己重構之路爭取一些支援,反而是你現在該煩惱的,而非是要重構或不重構了。 然而,世事總是讓人陷入兩難,大多數情況都是有點糟,但不是太糟,那麼?
繼續閱讀