軟件架構(gòu)即取舍

這個世界上不可能有通用的架構(gòu)，一切都是取舍的。

任何軟件的設(shè)計都需要明確定義要什么不要什么，任何軟件都會有缺陷，這個世界不存在完美的事情。

對于一個問題不會只有一種標(biāo)準(zhǔn)答案，解法多種多樣，因為不同視角、不同關(guān)注點看待出的問題是不同的。那么解法也就多種多樣。

任何技術(shù)任何設(shè)計都有其使用的地方和場景，所以脫離了場景談軟件設(shè)計或者架構(gòu)設(shè)計是不科學(xué)的，這是紙上談兵的做法，不是工程師的做法。

工程師解決問題的第一件事情是了解要解決什么問題，這個問題的本質(zhì)是什么，這個問題可不可以被簡化和抽象，之后再根據(jù)場景需求來挑選合適的正確的技術(shù)。

微服務(wù)的架構(gòu)有什么特點呢？

優(yōu)勢是開發(fā)快、部署快、隔離性好、功能擴展方便，但集成測試、運維、服務(wù)管理麻煩大一些。所以微服務(wù)架構(gòu)需要有一個好的PaaS平臺，這樣才能用好微服務(wù)。

程序的本質(zhì)是：控制邏輯+業(yè)務(wù)邏輯，控制邏輯是和業(yè)務(wù)不相關(guān)的邏輯，就是讓系統(tǒng)支持的更加穩(wěn)定和快速，我們一般叫做非功能性能力。而功能性能力也就是業(yè)務(wù)邏輯，他的產(chǎn)生是來自于業(yè)務(wù)需求的變化。

所以在系統(tǒng)設(shè)計過程中，很重要的一步就是要區(qū)分系統(tǒng)的功能性邏輯和非功能性邏輯，并且要建立比較好的隔離措施，防止一些低水平的工程師將兩者輕易混淆在一起。一旦將兩者混淆，系統(tǒng)的復(fù)雜度就會上升，很多穩(wěn)定性、技術(shù)債就此埋下。

絕大多數(shù)的系統(tǒng)復(fù)雜度是由于業(yè)務(wù)邏輯與控制邏輯糾纏不清。

很多程序員分不清什么是Logic和Control。

Control是可以標(biāo)準(zhǔn)化的，他的主要面對場景是數(shù)據(jù)的處理，這些東西不需要太多的差異化，標(biāo)準(zhǔn)最好，但不要腦補出一個不存在的標(biāo)準(zhǔn)，聰明的程序員不太需要在這里浪費太多時間解決差異化問題。

Logic是存在差異化的，有可能來自于業(yè)務(wù)發(fā)展階段的重點的變化，有可能來自于上下游兼容邏輯的處理，總之存在一定的差異化，怎么做呢？就是低成本的解決差異化即可。

因為Control是可以標(biāo)準(zhǔn)化的，而Logic是難以標(biāo)準(zhǔn)化的，所以不要妄圖在Logic投入太多時間要求標(biāo)準(zhǔn)化，一種情況可能是得不償失，另一種情況就是根本解決不了，這一階段的所有投入在下一階段都會變成新的問題。

所以要做好Control、Logic、Data的分離與抽象，在腦中要有一個清晰的定義，思維決定行動，思維想不到，根本做不好。一個人的潛力是由思維決定的，有的人溝通下來就感覺潛力不高，盡管很努力，也不過是提高下限，上限難以沖破，所以想明白、怎么想很重要。

一個系統(tǒng)的復(fù)雜度的上限是由業(yè)務(wù)邏輯決定的，如果業(yè)務(wù)邏輯太復(fù)雜，是不能通過控制邏輯來簡化的，而系統(tǒng)的復(fù)雜度下限是由控制邏輯決定的，好的控制邏輯可以盡量讓研發(fā)人員關(guān)注于業(yè)務(wù)邏輯與業(yè)務(wù)需求同頻，而不是在系統(tǒng)演進(jìn)過程中投入過多精力卻解決穩(wěn)定性、性能、分布式等非功能性問題。

微服務(wù)架構(gòu)體系下是同時解決控制邏輯和業(yè)務(wù)邏輯的，所以服務(wù)拆分過程中一定要關(guān)注于業(yè)務(wù)邏輯的合理性，如果忽略了業(yè)務(wù)邏輯的復(fù)雜性，而做微服務(wù)的強拆，最后會發(fā)現(xiàn)業(yè)務(wù)邏輯和控制邏輯交織不堪，導(dǎo)致整個系統(tǒng)復(fù)雜度奇高無比。

所以對于一個復(fù)雜業(yè)務(wù)體系下進(jìn)行微服務(wù)拆分時，首先要做到是業(yè)務(wù)邏輯的簡化和模塊化，而不是直接做微服務(wù)的拆分，因為在這個階段微服務(wù)幫不了你什么忙。

說實話我可能沒有見過所謂的真正的微服務(wù)架構(gòu)是什么樣子，因為服務(wù)在每一年中都會經(jīng)歷合并與拆分，合并也好，拆分也好，背后給出的邏輯都是相似的，當(dāng)時的解決方案，在下一階段變成了新的問題，變成了拆分的原因與理由。

所以我更多的將這些看做是服務(wù)化系統(tǒng)，而不是微服務(wù)，因為拆分出的微服務(wù)單元很難服務(wù)好業(yè)務(wù)發(fā)展。

比如大家討論云原生概念，Serverless和FaaS是其中談的最多的，但用好Serverless和FaaS是需要和其他服務(wù)很好結(jié)合才行，而且需要有很強的業(yè)務(wù)實踐。

現(xiàn)在的很多云原生解決方案其實還是在中心云執(zhí)行的，那么很多人就會覺得新瓶裝舊酒，帶來的價值不大。但我覺得這個背后的根本原因是在于對于云原生的理解上有歧義導(dǎo)致的。

沒人說云原生一定是在中心云，想想，如果Serverless和FaaS能力用在邊緣云計算場景上，這事是不是很酷？

比如在CDN上，5G基站上，或者在APP上，比如banner對于不同地方的用戶展示不同的內(nèi)容，這事其實是一小段函數(shù)要做的事，而且業(yè)務(wù)邏輯簡單，沒必要耦合到業(yè)務(wù)邏輯中心或業(yè)務(wù)領(lǐng)域中心，用Serverless和FaaS這樣的技術(shù)就很方便。

所以Serverless和FaaS這種在微內(nèi)核之外的旁路邏輯上有很好的生存價值，不入侵業(yè)務(wù)內(nèi)核，也可以做很好的旁路邊緣適配。

而如果是一家IOT企業(yè)，這事就天然的成了。不需要用中心云這么笨拙、不實時的方法，在邊緣節(jié)點做一些簡單的處理，即實時成本也更低。它適合邊緣計算。