[[440455]]

本文轉(zhuǎn)載自微信公眾號「人月聊IT」，作者人月聊IT。轉(zhuǎn)載本文請聯(lián)系人月聊IT公眾號。

這個周末我去參加了2021年華南CIO大會，發(fā)現(xiàn)基本上每年大會都有一個熱點(diǎn)，比如今年的熱點(diǎn)就是低代碼開發(fā)平臺。

我們可以回顧下最近幾年的熱點(diǎn)變化。

• 17-18年：微服務(wù)
• 18-19年：中臺
• 19-20年：RPA，數(shù)字化營銷
• 20-21年：低代碼，云原生

就我自己的文章輸出來看，基本上也和這個大趨勢符合。比如我17年左右會更多地寫微服務(wù)架構(gòu)設(shè)計(jì)和實(shí)施方面的文章，18，19年輸出了不少關(guān)于中臺建設(shè)的文章。而最近幾年關(guān)注重心則是云原生整體解決方案和低代碼開發(fā)平臺。

在IT行業(yè)，各種新興技術(shù)層出不窮，互聯(lián)網(wǎng)大廠的各種造詞能力也相當(dāng)強(qiáng)大，也讓每年基本都有新熱點(diǎn)和新技術(shù)產(chǎn)生。

類似19年可能剛興起低代碼開發(fā)，而到了今年可以看到做低代碼平臺的各種廠商，不論是做SaaS服務(wù)的，還是傳統(tǒng)toB實(shí)施的，還是圍繞騰訊，釘釘生態(tài)的。估計(jì)至少有上100家企業(yè)在做低代碼方面的產(chǎn)品。導(dǎo)致低代碼整個行業(yè)也處于群雄逐鹿和混亂的局面。

在上半年，ThoughtsWork的徐昊寫了一篇文章，談到低代碼平臺是行業(yè)毒瘤，首先這個看法我個人不認(rèn)同，任何新事物都有其存在的價值和道理，也不可能去解決你所有的問題。而是應(yīng)該在合適的時候采用最合適的方法。

低代碼平臺本身是好東西，但是很多廠商將低代碼平臺吹噓來無所不能，再復(fù)雜的系統(tǒng)和規(guī)則都能夠零代碼，拖拖拽拽就實(shí)現(xiàn)，這就是完全不講武德了。所以低代碼平臺不是行業(yè)毒瘤，反而是廠商競爭中的信口開河和瞎吹噓才是行業(yè)毒瘤。

回顧下中臺的概念也是同樣的道理。

中臺本身是一個很好的概念和思想，強(qiáng)調(diào)將企業(yè)共性業(yè)務(wù)能力下沉，然后形成可復(fù)用的業(yè)務(wù)能力中心提供給上層應(yīng)用，讓上層應(yīng)用能夠靈活敏捷的去開發(fā)。

這個思路本身沒有任何問題。

但是很多做中臺的廠商，特別是很多互聯(lián)網(wǎng)出來創(chuàng)業(yè)的廠商，一味地去夸大中臺的作用，給企業(yè)畫大餅，搞個中臺就無所不能，企業(yè)原來已有的IT系統(tǒng)也要全部改一遍，去建大而全的中臺能力而不是考慮如何保留企業(yè)遺留IT資產(chǎn)。這些也導(dǎo)致了大量的中臺項(xiàng)目最終建設(shè)失敗，或者根本沒有起到預(yù)想的效果。

這并不是中臺的思路不好，而是廠商夸大宣傳最終又沒有實(shí)現(xiàn)最終的效果和目標(biāo)，導(dǎo)致了用戶持續(xù)大量反噬，這不能怪用戶只能怪廠商。

再回來談微服務(wù)也是同樣的道理。

倒退個3到5年，估計(jì)很多企業(yè)也被微服務(wù)搞死過。

原因也很簡單，本身一個單體應(yīng)用運(yùn)行得好好的，最終被拆分為20多個微服務(wù)，導(dǎo)致多個微服務(wù)間集成復(fù)雜，分布式事務(wù)失控，后續(xù)的問題排查困難，運(yùn)維監(jiān)控困難等一系列的問題。

這本身不是微服務(wù)思想不對，而是應(yīng)用不對。

其一就是企業(yè)在沒有達(dá)到一定的IT治理管控能力的時候盲目上微服務(wù)，其二就是前期的架構(gòu)建模階段對微服務(wù)拆分不合理導(dǎo)致拆分太細(xì)，或者拆分后的微服務(wù)間緊耦合。

微服務(wù)思想本身不應(yīng)該去背這個鍋。

在去年我參加華南CIO大會的時候，RPA機(jī)器人火的一塌糊涂，聽說今年有些RPA廠商或團(tuán)隊(duì)已經(jīng)解散。

那么RPA機(jī)器自動化這個究竟好不好?

同樣的道理，任何一個新鮮事物的存在都有其道理。RPA機(jī)器人和自動化技術(shù)整合解決了傳統(tǒng)業(yè)務(wù)系統(tǒng)底層集成困難的問題，將重復(fù)的工作自動化掉。

這個思路沒有任何問題。一定有其應(yīng)用場景和應(yīng)用價值。但是要意識到的是RPA更多是一個折中方案，而不是目標(biāo)方案。

為何這樣說?

如果一個甲方企業(yè)本身有能力去做底層業(yè)務(wù)系統(tǒng)間的數(shù)據(jù)集成和接口集成，但是你自己偷懶不做，而是通過上層RPA的思路去解決問題。那么就是一種明顯的治標(biāo)不治本的方法。

一根大樹，本身底層的多個樹根應(yīng)該集成和盤錯在一起形成合力，支撐上層的枝繁葉茂。但是現(xiàn)在底層這個樹根間集成不做了，前面在樹枝和樹葉上拉繩子，捆線條。雖然這樣可以臨時解決問題，但是最終這個樹后面越難再發(fā)展和成長，哪天突然倒下也不是不可能。

所以當(dāng)我重新思考這些火熱概念后，給出一些關(guān)鍵的思考總結(jié)如下。

微服務(wù)

重申原則，就是你在沒有明確需求的情況下不要隨意去拆分微服務(wù)。即使你用微服務(wù)開發(fā)框架，也可以不做大的拆分。大部分企業(yè)來說，實(shí)際業(yè)務(wù)并發(fā)量都還沒有到必須要微服務(wù)化才能夠解決問題。

其次，應(yīng)用擴(kuò)展優(yōu)先考慮傳統(tǒng)單體模式下的擴(kuò)展方法，類似集群擴(kuò)展，數(shù)據(jù)庫讀寫分離等。也可以采用按子組織水平擴(kuò)展。

中臺

如果你的企業(yè)本身已經(jīng)有一定的信息化建設(shè)基礎(chǔ)，那么構(gòu)建中臺的最佳做法是對已有遺留IT系統(tǒng)中可復(fù)用的業(yè)務(wù)能力進(jìn)行梳理，基于SOA的思路來構(gòu)建一個業(yè)務(wù)服務(wù)共享中心。而不是全新去構(gòu)建一個中臺。

對于數(shù)據(jù)中臺來講，如果沒有做細(xì)粒度的微服務(wù)拆分，數(shù)據(jù)反哺業(yè)務(wù)的問題也不需要數(shù)據(jù)中臺來解決，直接在業(yè)務(wù)中臺或傳統(tǒng)遺留業(yè)務(wù)系統(tǒng)里解決即可。因此傳統(tǒng)企業(yè)構(gòu)建數(shù)據(jù)中臺，不是追求數(shù)據(jù)服務(wù)開放并反哺業(yè)務(wù)，而是數(shù)據(jù)整合后的分析和利用，思路仍然可能是傳統(tǒng)的BI系統(tǒng)構(gòu)建思路。

RPA機(jī)器人和自動化

對于RPA是一個折中方案而非目標(biāo)方案。當(dāng)企業(yè)面臨諸多遺留系統(tǒng)底層接口集成困難的場景的時候，可以采用RPA方式來解決重復(fù)工作的自動化協(xié)同問題。但是在有條件的情況下，仍然還是以底層數(shù)據(jù)和接口集成為主而非上層的界面協(xié)同集成。

RPA不要越做越大，這個后期維護(hù)將是一個大問題。一個是核心邏輯本身不清楚，一個是底層業(yè)務(wù)系統(tǒng)本身也處于變更的不穩(wěn)定狀態(tài)。

低代碼開發(fā)平臺

在低代碼平臺本身的行業(yè)標(biāo)準(zhǔn)規(guī)范，成熟度沒有達(dá)到前。企業(yè)不要將核心的業(yè)務(wù)系統(tǒng)放到低代碼開發(fā)平臺上。

低代碼平臺企業(yè)可以做一些嘗試，可以將類似OA，項(xiàng)目管理，運(yùn)維管理等偏工單和流程類的業(yè)務(wù)系統(tǒng)構(gòu)建在低代碼開發(fā)平臺上，積累相關(guān)的實(shí)踐和應(yīng)用經(jīng)驗(yàn)。

最后就是低代碼開發(fā)平臺在選擇的時候要考慮不要被平臺廠商綁架的情況，任何低代碼開發(fā)平臺開發(fā)完成的應(yīng)用一個基本要求就是能夠脫離低代碼平臺運(yùn)行，并具備足夠的高可用和擴(kuò)展性要求。