複雜系統設計源自我多年對企業複雜系統的設計的一些思考，類似日記吧，不斷完善。
為什麼從乙個大公司的引入架構師甚至架構師組還是很難架構企業開發中的很多問題？
這些問題表現出架構上的複雜性，和業務上的複雜性。
有時候架構和業務的界限不清晰，非常的模糊。
也可以說是架構設計不合理，也可以說是業務理解不清。
業務實際上是在不斷發育的，自己的理解也是在不斷深化的，所以這個理解過程是動態的。
複雜源自微觀
巨集觀架構+微觀架構
巨集觀架構：大架構，通用架構
微觀架構：小架構。
架構的複雜性首先是多實現，不同實現必然有優劣。
一些解決複雜性問題的手段：微服務化以小博大，服務拆分，流程引擎，規則編排，依賴注入，控制反轉，分層方向。
需要不斷的抽象業務本質背後的架構，而不是一直寫重複的**。
巨集觀通用架構手段：
資料：資料庫持久，快取提速，佇列快取。
資料拆分：資料分片
流量拆分：伺服器集群
乙個假設：伺服器一定會掛，所以還要主從或者主備，或者雙機
為什麼學會很多架構設計理論，一到具體專案就感覺寫**還是很盲目？
例如：軟體設計的開閉原則，依賴倒置原則，黎克特制替換原則，單一職責原則，介面隔離原則
例如單一職責來說，乙個看似單一職責的介面實際上由於引數的多變組合實際上是暗含2個職責。
例如依賴倒置原則，注入和new只是形式上的變化，本質上並沒有理解注入的益處，當然這種益處是客觀存在的，如果面試你去問為什麼要ioc，80%的人不知道，潛意識裡是大家都這樣用，公司要求都這樣用。
高內聚，松耦合
業務不斷的複雜，並不是微服務簡單拆分就可以解決。
微服務的拆分解決了一部分問題，但是依然會引入新問題。
單體的複雜互動如何合理劃分領域，領域即使劃分了並不是沒有耦合，失去耦合本身是乙個偽命題。
如果領域劃分不好必然是高內聚，強耦合。因為本身上不應該做這種拆分。
設計模式是否可以解決問題？
答案是不能，首先且不說設計模式是否已經包含所有的模式，更主要的是模式是否真正的被理解？
ddd領域驅動是否可以解決問題？
回答是不能，因為沒有真正理解業務做出的領域劃分只是乙個看似完美的劃分，實際上用處不大，道理具體的開發的時候發現頭重腳輕，處處滲透。
為什麼從外面挖個大牛也不是馬上就可以讓之前設計不好的複雜系統馬上設計好？
第一，很難短時間理解所有業務；
第二 之前大牛所在公司的業務並不完全匹配現有業務，可以說完全匹配的業務很少，但是也不是沒有。但是也不是非要如此，要時間。
所以，架構師如果並沒有真正理解複雜系統設計，而只是被動接收公司的架構，那麼他去新公司必然沒有太大作用。
簡單
能簡單就不要複雜。
能不引入中介軟體就不要引入中介軟體，比如訊息系統，資料量不大沒問題，資料量大，業務複雜到一定程度就會出現一些難搞的問題：訊息不消費，訊息丟失，重複，消費慢，治理能力弱。
cpu和記憶體的不可控增長，訊息不隔離，其實redis快取也存在這個問題，只看到他的效能和簡單沒有考慮到失控。
所以有些公司自己自研了mq來解決這些問題。
乙個完整的業務線一定要有乙個人懂全部的業務，每一次需求分析，架構設計他一定要參與其中。
並不用去做完整的事情，但是需要對此進行review，特別是領域劃分一定要全域性業務專家。
千萬不要因為政治原因迴避這樣的人，也不要個人英雄主義，用自己片面的業務理解去做全域性的設計。
全域性設計必然需要全域性業務專家。
對稱
世界本身是對稱的，明暗，進出...
在計算機也是一樣的。
處理無序 需要用有序，本質上就是對稱。
序列化:反序列化 編碼:解碼 進:出 動態**:反射
不對稱就會繼續無序下去。
主從複製本質上產生了不對稱，最終是對稱也就是最終一致性。
那麼需要解決這個不對稱，除了最終一致性以外就是需要讀寫對稱！也就是讀還是寫伺服器才可以。
配置 與 實際的效果 也是一種對稱，無處不在的對稱
關於高併發例如秒殺引入佇列機制，實際上還是對稱的應用。三 -> ||| 時間上的旋轉。
同步變異步，更新資料庫之後更新快取引入佇列非同步 ||| ->三 時間上的旋轉。
分布式本質上是對稱的時間，集群：伺服器之間是對稱的。
所以也就出現對稱現象，或者對稱問題。
高併發的必然也會有高流量，解決的問題是需要不對稱，前端系統高流量，到後端需要流量減少。倒三角或者漏洞。
快取和資料庫之間實際上也是對稱的，只是一致性是完全對稱，否則是不對稱。
資料庫，遠端快取，本地快取。
本地快取效能最好，但是不能超過記憶體，最大是和記憶體對稱。
分布式完全資料對稱是不存在的，因為存在時間，就會有延遲，這是無法消除的。
快取key 資料庫不存在的值 這就是 快取和資料庫不對稱，不對稱就必然引發不對稱問題，解決辦法是對稱，讓這種不存在的值快取為null。
不過，如果資料庫又更新了，那麼需要同步雙寫或者重新整理快取為資料庫值，否則引起新的不對稱。
不對稱也是動態變化的。
分布式mq下順序訊息實現，下單 生產3個訊息 abc ，要求按照 a-> b ->c順序消費。
問題 還是 三 -> ||| 鏡面折射 到乙個點 也就是分割槽，然後 消費者加鎖拿佇列鎖
後面需要對稱的獲取 |||
這裡傳送和接受分別出現對稱，產生2面鏡子 也就是 同一分割槽和佇列鎖。
二維空間 -> 一維空間
服務註冊：映象射入
網域名稱負載均衡 ->反射到 註冊中心拿到ip 客戶端負載均衡 ribbon
反射點從服務端轉移到客戶端而已
elk logstash->es->kibana
logstash: input->filter->output
鏡面射入資料，層層鏡面過濾，最後輸出
延遲分配：對稱 先映象 再實像
減少記憶體分配：對稱 單例，減小例項尺寸，常量化，靜態化(列舉) 對稱到乙個點
hadoop namenode datanode:對稱 映像到不同的例項
未完 。
企業軟體領域前端開發的困境
前一段時間，看到阿里幾位前端大師的討論 阿里前端的困局與突圍，對這個職業的發展方向有一些思考，我上次跟winter和dh一起吃飯，也簡單聊到這個話題。winter問了乙個問題，如果在網際網路企業跟遊戲開發的企業同時進行一次針對前端開發的大裁員，對這個企業的核心價值而言，哪種影響更大？這個問題問得很有...
監控系統解圍企業應用整合平台困境
原文 techtarget中國原創 最近我們為一家央企進行了關於基於企業服務匯流排 esb 和面向服務架構 soa 的企業應用整合 eai 平台的諮詢與實施，在此過程中，客戶經常會提出 這樣的問題 應用整合平台通常處於企業資訊平台的核心位置，很多系統都與整合平台關聯，很多需要跨系統實現的業務都要經過...
BYOD 企業的困境與力量
科技發展日新月異，隨著智慧型裝置大規模普及，企業中越來越多的員工，希望可以使用自己熟悉的智慧型手機或平板來工作，byod bring your own device 開始成為了乙個席捲全球的風潮，以此帶來的便利性也漸漸為企業所接受。我們試想一下商店的店員，如果他們的手機可以連線到商店的銷售及庫存系統...