[[407923]]

圖片來自 包圖網

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

集中式互聯網特點

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

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

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

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

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

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

• 微指的是服務粒度，而不是模塊獨立性。缺了大部分模塊中的某一個，系統就不能正常運行。
• 脫離了自己公司的環境，就無法運行。
• 幾乎無法重建。

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

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

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

某些公司的痛

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

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

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

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

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

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

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

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

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

外表華麗的微服務

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

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

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

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

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

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

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

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

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

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

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

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

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

這些都沒什么關系，因為這是水平問題造成的后果，隨著服務治理都可以趨向完美。

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

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

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

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

[[407924]]

改回去吧

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

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

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

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

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

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

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

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

唯一的問題是，很多人就這么干廢了。

結語

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

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

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

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

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

作者：小姐姐味道

編輯：陶家龍

出處：轉載自公眾號小姐姐味道(ID：xjjdog)