爲什麼從牛 X 的微服務退回單體架構？

“

兄弟姐妹們，一定要找好自己賴以生存的老窩。南橘北枳，根正才能苗紅，否則你看起來一些主流的技術，可能就會成爲毒藥。

圖片來自 Pexels

接下來我就給你講一個技術降級的故事。怎麼樣由牛 x 的技術，換成老掉牙的單體應用。故事內容真實可靠，因爲它來自一次真實的諮詢。

集中式互聯網特點

這個年頭，ServiceMesh 都已經在大廠開始鋪開，弱一點的也已經是 K8s 驅動的微服務。

這些花架子，全都比 Spring Cloud 這樣的一代維服務框架，高了不止一個檔次。

這很好，新技術踩在舊技術身上，不停的向前蠕動，最終成爲一個有機的整體，也成爲技術革新的根本。

注意，我這裏使用了蠕動兩個字，而不是前進。蠕動意味着醜陋且緩慢，而前進意味着革新和勇往直前。

整個基礎設施，就像一條巨大的毛毛蟲，升級升級邊邊角角，最終破繭成爲新的物種。它的升級過程是緩慢的，系統關係是複雜多變的。

說是微服務，但它們仍然有以下特點：

你會發現，即使部分業務上雲；或者你被某個信仰雲搞怕了，想要遷雲 --- 都會花費較大的力氣。

這麼來說吧。即使把你公司裏的所有代碼，都給偷了出來，你還是不能把項目在你的開發機器上跑起來。

大家默認了這個線上環境是穩定的，各種接口和數據以及 DevOps 工具是完備的。想要數據，直接調其他部門的接口就可以了。

某些公司的痛

但是但是但是，你默認的這個前提，正是某些公司的需求！某些公司的軟肋！

因爲，除了大部分 toC 的互聯網公司，除了能夠集中跑在一個地方的類 SAAS 服務，還有很大比重的實施性項目，在悶頭髮大財。

不要誤解，我說的發財，是說老闆和銷售，而不是程序員。程序員還沒這個資格，因爲這種公司，上面還有項目經理這一層。

這些系統，需要在某個地方（可能是火星，也可能是客戶現場）完成編碼，然後被髮布到未知的環境之中。

同學們注意了，無論公司包裝的再美好，只要是這種模式，那就是外包。比如包裝的漂漂亮亮的 thoughtworks，除了幾個諮詢職位，本質上還是外包。

不是說這種公司不好，只是這種公司不適合走技術路線的程序員。單體應用，是最適合它們的。

有自己產品的也不行。只要是伺候的 B 端大爺，那定製化沒跑了。如果產品模型抽象的亂七八糟，那麼不好意思，就是外包。

今天，你在黑龍江剛實施了一套系統；明天，就就要帶着這套系統去廣西，進行爲期 3 個月的定製改造。光是部署，就廢了九牛二虎之力。

就是在這種場景下，還是有人不加猶豫，選擇了微服務。

外表華麗的微服務

微服務有很好的願景，也有很好的案例。有了微服務的加持，類似奈飛之類的公司，業務得以爆發性的增長。牛 x 的案例也是數不勝數。

微服務要解決的問題，也帶有非常大的迷惑性：

**迷惑性之一，**就可以在 PPT 裏或者年度會議上吹牛逼。微字，分佈式，高併發，存算分離...，只有這些如此豪橫的名詞，才能在技術圈拿得出門面。此時，技術界和忽悠界產生了完美的聯通。

**迷惑性之二，**就是在互聯網環境裏，微服務確實有效。微服務能夠降低某些模塊的風險，部署靈活，穩定性高。服務松耦合，擴展性高。

看到擴展性三個字，某些決策層就開始腦子發熱荷爾蒙上升 --- 這就是我的菜！！

就連不懂技術的老闆，也會笑樂了和猴一樣。救救他們！別 TM 老盯着優點不放啊。

無數的案例表明，任何華麗的表象下面，都需要大量配套去掃地，微服務也不例外。

微服務運行，其實只需要包含註冊中心就行了，其他什麼 RPC、熔斷之類的，其實在框架內部，並沒什麼額外部署成本。

但是，這種閹割性的微服務，幾乎沒什麼作用。要想要發揮它的功效，就要建設服務監控、服務追蹤、服務治理等；如果模塊非常多，還是建設虛擬化...

就這類公司大多數系統的那麼點量來說，這些配套系統都不好意思給它們上。

但是好傢伙，小夥子們一發力，一個項目拆出來 20 多個微服務。

小夥子們記好了，方向錯了，你越努力，效果就越差。你在那加班加點的幹，其實是在害公司。

爲什麼能拆成 20 多個服務？其實，服務粒度是個僞命題。有的人喜歡拆到功能界限；有的人會再加一刀把讀寫分離也拆了；有的人把服務關係畫成一張蜘蛛網；有的人喜歡深入一點的調用 --- 一層套一層。

這些都沒什麼關係，因爲這是水平問題造成的後果，隨着服務治理都可以趨向完美。

意識層面的問題纔是大事 --- 光顧着吹牛逼體驗新技術了，自己技術團隊什麼水平，心裏就沒棵 B 樹。

就那麼幾個人的團隊，拆成 20 幾個服務，還沒有配套的 CI 工具，除了折騰人，就沒點什麼好處。

要命的是，只要你實施一次，這些亂七八糟的東西，就要重新搞一遍嗎，你確定每個人都能搞得定麼？

上 APM 吧，上監控吧，上 CI 吧。互聯網公司在搞的東西，你一樣沒拉下。關鍵是，人家每個方向都是團隊在搞的東西，現在全交給了你一個人。

改回去吧

錯了麼？錯了！外包公司（原諒我這種叫法，你也可以叫項目類公司）最注重的，就是成本。這麼搞，相當於每實施一次，就建立了一個小型公司，把所有的東西重來一遍。

有辦法麼？有啊。上雲就可以了，把這些基礎設置交給雲去做。但是上雲，是另一種形式的中心化，只不過把 SAAS 底層的 IAAS 交給雲了。把雲機器當作普通機器來用，和上不上雲沒什麼區別。

另外，客戶不同意啊。我自己有機器，你給我瞎上雲幹啥，我根本不相信這些雲。

這個時候，你就只能乾瞪眼。

還有一種辦法，那就是把這些拆好的微服務，再 TM 合併起來。最終打包成一兩個 jar 包。發佈的時候，拖到服務器上直接啓動就好了。

這種合併要注意不要把頻率高的小數據量查詢和報表類的服務放在一起，否則共用一套資源（連接池、JVM 等）會相互影響。最終建議分成三個就好了：普通服務、報表服務、定時任務。

這種決定是與主流技術相反的，相當於降級。當下了這種決定，小夥伴們嘴都撅的老高 --- 以後出去找工作也不好吹了。但有什麼辦法呢？

最原始的方法，能夠適應任何惡劣的環境，能夠忍受任何客戶的刁鑽。這是由公司的現狀決定的。

唯一的問題是，很多人就這麼幹廢了。

結語

每一年，我都會看到很多很多傳統行業的人，想要進入到互聯網這個圈子。外包和項目類公司，很多也和傳統公司無異。具體的區分界限，以前也有較深入的比較。

如果你恰巧在這種行業中，不要迷信互聯網公司的技術棧，它們真的水土不服。

互聯網的挑戰主要是量，而你的挑戰是成本。老闆想的是快點完工回款，而不是系統的長治久安。這時候，你用的技術花哨，但是沒人深入去做，最後就會是一團亂麻。

正是由於對微服務特別瞭解，我才推薦這些公司不要採用微服務，很好笑是吧。

當然，微服務很好很有魅力，拿來練手是沒問題的，但是記得啊，練的差不多在系統上線前，趕緊跑啊。否則鍋就是你的了。

_作者：_小姐姐味道

編輯：陶家龍

出處：轉載自公衆號小姐姐味道（ID：xjjdog）

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/jZpPucxjbRPY7gCu28OC1Q

猜你喜歡