「面試題」介紹你做過最復雜的系統

經常有人會問：能介紹下你做過最復雜的系統嗎？對此，你被人問起過嗎，你思考過什么標準才算復雜嗎？

系統的復雜性包括了技術復雜性和業務復雜性。

有人抱怨道：我做的系統一點都不復雜，你看我們數據量不大，用不上分庫分表，業務也不復雜，單體系統就夠了，什么負載均衡和集群也沒有，流量也不大，高并發和分布式也沒接觸過。

何為技術復雜性，我上面提到的都算，隨著業務的發展，我們的系統架構需要支持大數據和高并發，因此復雜的系統架構孕育而生，在數據庫層面要考慮分庫分表，讀寫分離，主備切換；

為了提高查詢性能和單點問題，分布式緩存必不可少；

為了銷峰限流和服務解耦，分布式消息中間件也要用上；

大促期間，為了保證穩定性，還要機器自動伸縮，服務降級、服務隔離、服務熔斷、服務限流等都是常用套路。

此外，分布式還有分布式調度系統，分布式監控系統，分布式日志系統，分布式鏈路采集等等。事實上，所以系統都是分布式的，單點故障是無法忍受的。說到這里，你覺得這系統太復雜啦。對的，為了構建高可用，可伸縮的分布式系統確實復雜。

但是，技術架構只是技術復雜性的其中一塊罷了。

試想，一個復雜的算法算不算技術復雜性呢？我覺得也算。一個好的算法，可以幫助我們解決很多復雜的業務問題。

這里，對于我們非算法工程師而言，如果能把業務問題轉換成算法問題，我就可以把人工問題轉換成智能化，那么我們的業務離商業智能又邁進的一大步。

說 AI 可能遠啦，聊點近的，比如延遲隊列的“時間環”算法，ZK的會話分桶算法，限流的令牌桶等，很多偏業務實戰方面的落地也可以讓我們做得事情充滿含金量，換句話說，吹逼層次可以提高了好幾個 Level 哈。技術復雜性，還可以是解決多數據源的聚合查詢問題，解決數據多寫同步以及一致性問題等。拋磚引玉，僅供參考。

業務的復雜性在于：不同業務與業務之前相互作用與干擾。

做過 2B 產品或者項目的小伙伴應該非常理解我所說的含義，因為適配不同企業和商家做定制化需求會導致產品越來越無法通用化，尤其 ERP 這種強業務定制的系統。

那么，為了維護多套類似的邏輯和代碼是成本巨大的，因此設計可擴展性的系統尤為重要。很多時候，我們對需求的變化是不可預期的。這種不可預期性恰恰是業務復雜性所在。

事實上，架構設計都是基于當下的設計，一個設計的好壞在于：它是否可以快速地支持業務。換句話說，我設計的系統滿足了當前的業務，但是它后期無法可擴展，那么這個設計是好是壞呢？此外，我們根據領域模型作出了良好的設計，但是隨著業務的發展，每個模型耦合越來越重。

那么，請思考是領域模型不合理，還是架構設計的不合理，還是業務發展的太快了呢？或者，再思考一個問題。一個公司覺得業務中臺的概念很好，也打算落地實踐，但是呢，它的業務比較單薄，那么，此時它設計的業務中臺具有通用性嗎？我個人感覺，不太好說。

事實上，需要不停的業務滋養，只有滋養中才能從最初僅提供單薄業務功能的服務逐漸穩定成一個解決具體問題的業務領域模型。設計模式的有一個模式叫做「模版方法模式」，它的核心思路在于把公共的流程固化下來，把差異點移交給具體的業務方去實現。是吧，只有我們有足夠多的業務場景，我們才能沉淀出那些是公共的邏輯，那些是可擴展點，然后在業務設計過程中，我們可以在本業務實現子類做自定義實現，或者提供 SPI 給業務介入方擴展。

總結一下，業務的復雜性在于：不同業務與業務之前相互作用與干擾，以及我們對需求的變化是不可預期性。

你以為我說到這里就結束了嗎？當然，不是。我更多的是想引發你的思考以及我們思維的碰撞。例如，很多人抱怨自己是 CRUD 工程師。

我覺得這些人太小看自己的價值了。業務的價值和復雜往往不是 CRUD，而是業務背后的價值思考。線下的業務線上化，傳統的東西在線化，那么它就具有結構化存儲的能力，可以和其他數據協同，那么，它就有價值。

此外，你是不是可以把 CRUD 的流程自動化，本來一天搞定的東西，你1分鐘就搞定了，然后在花59分鐘來實現業務差異性。可以了嗎，當然不行。你是不是可以把59分鐘在壓縮壓縮，寫一個框架，把多分支的問題通過策略模式+工廠模式搞定呀，固化流程通過模版方法模式搞定哈，然后觀察者模式、適配器模式、代理模式、責任鏈模式、狀態模式都可以用一用。事實上，很多設計模式是解決復雜業務場景的可擴展經驗套路。

最后總結一下，系統的復雜性包括了技術復雜性和業務復雜性。我們一起暢聊，學習，成長，打破認知的局限性！！！