03.07 為什麼有些公司的server不願意微服務化?

shoujiweitu2961


微服務是這幾年比較火的概念了,很多 IT 公司也都在做微服務轉型,那麼微服務化適合所有的公司麼?微服務架構可以解決一切問題麼?我覺得並不是這樣的,企業是否需要做微服務轉型還是要從實際情況出發。


01. 微服務化倒逼組織架構

說到微服務,很多人會認為這是個技術架構,但我認為微服務不只是技術架構這麼簡單,它甚至會涉及到組織架構。

通常 IT 公司的崗位都會分成產品、開發、測試、運維,有些公司甚至會分成不同的部門,一個需求的開發到上線,會從前到後經過四個部門的流轉,而進行微服務的轉型,目的是為了加速業務的響應,快速開發,快速上線,縮短迭代週期,快速試錯並糾正。

如果企業想做服務化轉型,那麼組織架構也需要做相應的調整,否則還像以往一樣,部門和部門之間、崗位和崗位之間需要很大的溝通成本,那麼微服務是“快不起來”的;比較理想的是把不同的崗位揉在一起,一個團隊中包含產品、開發、測試、運維四種角色,團隊成員彼此協作負責一個或幾個微服務的迭代和運維。


02. 設計更為複雜

判斷是不是適合微服務化,也要看自己的業務場景,如果服務做拆分,只是為了拆分而拆分,是沒有意義的,通常要考慮:

拆分之後的服務,能否被複用?如果一個功能在 A 系統,只被 A 系統自己使用,那麼沒有拆出來的價值,如果 B/C/D 系統都需要使用這個功能,那麼可以拆分出來複用;微服務的優勢之一,增加複用,減少重複開發,縮短開發時間,進而降低成本;

訪問量大還是小?如果訪問量不大且平穩,未來很長時間訪問量也不會有很大的增長,那就沒必要微服務化,如果有高併發、流量不可預計,那麼可以做微服務化。

微服務在設計上也存在著一定的難度,拆成幾個微服務?新需求來了,是新建一個微服務,還是在老服務上改造?這些設計層面的考慮,也是非常複雜的。


03. 技術上的難度

雖然我們的服務容易複用了,一個新需求的開發可能做一個頁面,調幾個接口就完成了,但是微服務的開發和維護,也給 IT 帶來了很大的挑戰。

  • 服務被拆成了多個微服務,每個微服務又會部署很多套,這時候才使用人肉運維就不合適了;

  • 以前 A 系統的一個接口,變成 A->B->C->D 這樣的調用鏈路了,如果一個環節出現問題,可能導致整個鏈路上的系統都不可用,而且問題的定位也會變得更難;

  • 單個系統做數據的增改刪很簡單,通過事務就很容易控制,但微服務化之後,就變成了多個系統的分佈式事務,這個難度很大,大多數系統只能做到數據的最終一致;

  • 因為一個功能可能會涉及多個系統,那麼測試也變得複雜了。

  • 總之,很多公司不原因做微服務轉型,第一就是微服務化的難度比較大,企業沒有能力做;第二就是,企業可能真正地思考和評估過,現有架構足以滿足業務,沒必要做微服務。


我將持續分享Java開發、架構設計、程序員職業發展等方面的見解,希望能得到你的關注。


會點代碼的大叔


微服務和單體服務都有各自的優勢場景,微服務並不是普適一切場合的銀彈。

對既有系統的微服務改造往往需要面臨巨大的成本和風險,所需要的承擔的責任和勇氣超過很多資源不充裕的團隊的最大承受能力。

微服務的學習曲線較高,相關工具鏈的成熟度相對差一些,現階段可能需要有一定實力的團隊才可以駕馭。

微服務的運維也需要額外的成本,對規模太小的團隊和複雜度有限的單體服務進行微服務改造,大多數時候相當於脫了褲子放屁。

哪怕當前系統的技術再濫,作為已經熟練掌握它的人來說,離開溫飽有餘舒適區、去擁抱破舊立新的新技術,都需要獵奇之外更正當充分的理由、優秀的技術品味和有擔當的心態。精緻利己主義盛行的時代,能夠很好的平衡所有這些要素、願意有條件的主動離開舒適區的領導者和決策者並不多。


晴月浩新雪


有可能會涉及到整體架構的修改,不是不願意,而是變動很大可能會成為一個曠日持久的工程,或者因為現在業務正在運行在服務器上,沒有足夠的時間來切換到微服務架構,如果切換本身導致的損失超過了切換微服務的收益的話,肯定不會去做這樣的修改的,但不代表沒有這樣的方案。

而且微服務並非適用於所有的產業,確實對於一部分互聯網依賴產業微服務是很好的解決方案,因為可以實現模塊解耦,保證了模塊之間的依賴性和影響降到最低,但是很多放在雲上的可能是企業自己的服務,並不需要解耦,或者至少目前不需要,那麼服務商自然不會做這樣的事情,除非用戶有所依賴,形成一個相當大的趨勢,否則服務商的策略變化會影響所有的用戶,導致用戶流失就不是一件好事了。


榻榻米的榻榻


你們家灶臺是和酒店裡大廚們用的一樣麼,各種灶具、鍋具、案臺……都全麼,有必要麼?


手機用戶54444147856


微服務化是需要很大成本的,如果一個公司開始是使用ssm框架開發,你突然要他微服務話,就相當於讓他把之前框架棄用,開始一個不熟悉的新框架。之前的框架都是有很多技術沉澱的,花了公司的很多心血,成本是巨大的,並且微服務不一定是最好的,很多公司的業務並不是很複雜,現如今的服務足以支撐他的業務,完全沒有必要微服務化,在加上微服務話是需要時間的,並不能馬上就轉換,就算是轉化了,軟件運維也是讓人頭疼的東西。這就是很多公司不願意微服務話的原因之一。

希望我的回答對你有幫助,謝謝


逆光的背影


首先應該瞭解下什麼叫微服務,

1. 一組小服務。

2. 獨立進程 。

3. 輕量級通信 。

4. 基於業務能力。

5. 獨立部署 。

6. 無集中式管理,不用統一技術棧。

什麼時候才需要微服務呢?

1. 業務變複雜了。

2. 團隊變大了。

3. 開發效率低下了。


分享到:


相關文章: