自動駕駛網絡系列二： 從哲學源頭開始思考架構設計（自動駕駛 網絡）

從哲學源頭開始思考

本篇我重點講方法論，自動駕駛網絡關鍵在架構創新，創新不是漫無邊際，毫無邏輯和實現可能性的瞎想，沒有約束和方法論的瞎想是民科干的事情。我們要通過堅實的架構設計方法，鋪就一個通往愿景的路。

下面講的方法論既是一種知識，也是一種技能。通過知識學習可以更好的理解架構設計技巧。但是作為技能，卻需要不斷磨練才能掌握。就像學游泳一樣，沒有知識你很難游好，但是你有了再多知識，進入水中一樣不會游。

在講架構設計之前，先學習點邏輯知識。先用一個例子幫助大家理解一下什么是概念的內涵以及語境的知識。我們有時討論問題經常整擰巴了，大家討論不到一塊去，很多時候是因為概念理解的不一樣。講個小故事，有一次我講課時，說管理老外和管理中國人差不多，結果很多人反對，覺得我不了解老外，然后講了很多老外不同的地方，我反問了一句，那中國人是不是管理方式就一樣呢？當你從人的一般特點看老外的時候，其實大家都一樣，都有七情六欲，都需要愿景，都需要尊重，都需要指導，都需要鞭策，這和中國人有啥不一樣？人面對事情需要尋找共性才能高效處理。如果要尋找個性，那就麻煩了，這世界有完全一樣的人嗎？昨天的你和今天的你是一樣的嗎?

我說老外一樣的時候顯然是在講一般原則，而對具體的事情處理上，不止老外，其實面對每個個體，每個個體的不同時刻，都要區分處理。而說話時到底是指“一般原則”還是“特殊原則”，這個隱含的背景信息就是語境，語境一般在對話中并不出現，而是靠溝通雙方根據理解來自動補充。人對語境處理的能力非常強，但是對話有時語境理解會發生錯誤，這個就是平時所說的溝通不在一個頻道上了。

軟件開發要求邏輯非常清晰，特別是大型軟件的架構設計更是如此，需要非常好的抽象思維能力，所以深入理解邏輯方法很重要。

在理解邏輯方法之前，首先要理解我們說的客觀世界就是由實體、實體屬性和關系三種要素確定的。明確這三種要素，事物就唯一確定了。而軟件世界其實就是實體世界的映像，所以也是這三種要素。我畫了一張簡圖，先看一下，后面會用到。

關于思維方法有比較、分類、分析、抽象、概括、綜合幾種方法，在傳統的哲學中，“比較”方法一般和其他方法并列，其實不是這樣的，比較是最基礎的思維過程，是“分析”“抽象”等其他方法的基礎。人是通過比較才能確定事物的邊界的，然后根據邊界進行劃分類別，也就是“分類”。比如一堆雜糧你可以通過分析看出有黑豆，紅豆，綠豆，薏米，蓮子，小米，大米等等，這個過程就是你對圖像進行了不斷比較，找到圖像的邊緣，和記憶中圖像比較確定雜糧種類。只是對圖像的比較分析都是用神經網絡一瞬間完成的，人沒有心理意識，而對抽象事物的分析過程是可以知覺的，你回想一下，分析事物過程是不也這樣，就是不停的比較各個情況。

所以分析就是通過不停的比較，根據比較結果對事物進行劃分，分解出各種實體，實體屬性和實體間關系。

哲學上“抽象”的方法理解也簡單，實體不是有很多屬性嗎，比如人有人格特征，社會關系，生物等很多屬性，生物屬性下面還有形態和DNA等屬性。抽象就是根據需要選擇屬性的過程，這種“需要”的理解有時就是雙方的默契，如果估計溝通的時候沒有默契就要明確抽象到什么程度。例如剛開始我講了老外都是一樣的，我就是選了老外的人格特征屬性，而忽略了社會關系屬性。我哪天說其實人和狗也一樣，就是選了兩種的生物屬性的共性。要是哪天我說其實石頭和人也是一樣的，只要抽象到質子和中子一級就行了。我要說今天的我的昨天的我不一樣也行，因為想法和年齡都變了嘛。

還是用一堆雜糧舉例，通過分析這個篩子把黑豆，紅豆，綠豆，薏米，蓮子，小米，大米這些米豆都分開了。抽象的動作就像你認為小米和大米都不算粗糧，只留了薏米，蓮子、各種豆子。但是也有另外的抽象方法，就是我只選可以解毒的粗糧，那就只抽象出綠豆了，其他就都是次要的了。所以抽象什么不是絕對的，而是根據需要進行的。

抽象往往和本質一詞有關聯，順便說一下什么是事物本質屬性。抽象一般是根據需要把沒用的屬性去掉，只留關鍵的屬性是，例如簡筆畫為了區分梨和蘋果，一般抽象到形狀就能分出來了，這種抽象就夠用了，但是如果哪天要畫蘋果梨（真有這種水果的），形狀的抽象就不行了，所以顯然形狀不是蘋果和梨的本質區別。那是什么是這兩者的本質區別呢，口味顯然也不行，我們現在可以改良品種搞成口味差不多。梨和蘋果最本質的區別是他們的DNA不同。所以事物本質屬性就是能抽象到用于對事物進行分類的最少特征屬性。

總結一下，抽象就是根據需要選擇屬性和關系的思維過程。至于怎么選擇屬性和關系、需要到什么程度，主要看實際場景了，這個才是難點。就像畫畫一樣，顏料，筆，紙都一樣，理工科的你畫的和徐悲鴻畫的那價值可是差遠了。你畫的能被大家看到欣賞一下已經很不錯了，徐悲鴻一張畫就夠一般人奮斗一輩子，這就是差別，是吧！

如果抽象的對象是像蘋果一樣的實物，你可以識別出畫的蘋果的，畫的最抽象的情況下就是一個簡筆畫。如果把抽象結果和語言符號連接起來，就成了概念“蘋果”這個詞了。而如果抽象的對象是像文章這種本身也是抽象的和復雜的，那么這個過程我們可以稱作概括方法。換一句話說，“概括”就是一種特殊的抽象。

剛剛講的方法都是把事物分解開的方法，那么“綜合”是反過來的過程，是把各個部分組織起來進行思維的方法。綜合不是各個部分的簡單相加，而是一種再加工過程，會產生從各個部分分別看無法生成的新知識來。不知道大家看油畫時有沒有注意到，你走進油畫細看，就是一些色塊，看不出啥東西來，但是走遠一點，看到全貌的時候，一副栩栩如生的畫就出現了，這個就是綜合。綜合思維在底層用到了“比較”和“頓悟”兩個思維方法。

2.1?????? 如何做業務抽象建模

理解了看起來哲學看起來很High的思維方法，我們開始討論業務建模方法了，業務建模的本質就是對業務進行抽象和重構。先看一下建模過程簡圖，之后我再打開講。

2.1.1???????? 業務抽象與分類

實際業務建模過程可分為以下幾個步驟：

第一個步驟就是堆砌材料，很多人理解業務有點不知道怎么入手，其實也很簡單，就是到處收集材料，有幾類：

1. 已經有的框架，前人的智力成果肯定要參考的。

2. 通用知識，可以幫助理解背景。

3. 如下圖的7P類資料，這是引用我以前寫的一個業務調研框架。

這些材料拿到后先通讀一遍，有個大概印象，等需要時再細讀。

第二個步驟就是對業務功能進行抽象，確定思考最大的思考框架。比如自動駕駛網絡需要哪些大的功能。

第三個步驟是在框架下分類，分類維度可以按照：時間，空間，人際，業務類型等分解。這個步驟先不用做細，大概分分，便于進一步進行思考。現存的業務功能一般都是互相交叉的，你中有我，我中有你。這種情況有時就是沒想清楚引起的，有時是環境變化引起的。比如以前可以說西紅柿是蔬菜，但是新的圣女果西紅柿卻變成水果了，嚴格講就不能再說西紅柿是蔬菜了。當存在這種交叉時就要進一步細分維度，只要足夠細分維度，事情最終總是可以找到MECE（互相獨立，完全窮盡）可分的維度。西紅柿分類這個就比較簡單了，以后給小朋友介紹時就變成傳統西紅柿是蔬菜和圣女果西紅柿是水果了。這個過程最重要，一定要把所有交叉去掉。

第四個步驟，再進行抽象，把一些不關鍵的內容去掉。

上面這些過程要迭代好多次，反復提煉才行，經過這個過程一般就比較清晰了。

2.1.2???????? 組件建模

抽象完之后下一步工作就是按最簡潔原則對分類進行聚類，聚類要考慮將各類別統一到一個層次上，并對聚類進行命名便于管理。最后再識別一下各個聚類間關系，形成關系圖。

還是用雜糧舉例。我們開始會把分出來的黑豆，紅豆，綠豆，薏米，蓮子分別打包。但是這樣分類比較多，賣的時候不好介紹。這時覺得黑豆，紅豆，綠豆作用差不多，就再統一打成一個豆類的大包，和薏米、蓮子包并列，就成了下面情況。黑豆，紅豆，綠豆合并的過程就是一種聚類。這樣介紹起來就清晰一點。

2.1.3???????? 系統重構

上面分類打包完了如果要賣，顯然要看看是不是和市場匹配了，如果不合適還要調整關系。比如豆子打包后發現綠豆有消毒的特殊功能，可以多賣錢，這個時候就要把綠豆拿出來單獨賣。這個就是系統重構了。

2.2?????? 業務抽象的技巧-角色扮演方法

當一個非常復雜的業務要做業務梳理時是困難的，關鍵是涉及的東西太多了，如果真要從各種細節了解起，那工作量是不可承受的，而且最后效果還不一定好。這個時候就可以使用角色扮演方法，這個也是通用的學習方法，可以高速的掌握一個領域的新知識。具體過程就是在了解事物前，不著急從實際入手，而是根據經驗先自我設計一個框架，再根據假設框架去對照實際事物，如果一致就說明理解正確，如果不一致就找到原因，這樣既可以快速了解業務，又可以發現現存的問題。這個是理解事物的一個非常快捷的方法。

2.3?????? 業務梳理工具XMind

梳理業務肯定要有一個合適的工具。我經常用XMind。XMind可以導出各種漂亮的圖，但是這個工具最大的作用是方便的進行屬性和關系調整，對復雜的事情人一下子可能很難想清楚，所以可以把所有想法都列到工具里，然后慢慢進行邏輯調整，這樣會保證效率。

3.1?????? 架構設計過程

在設計架構前首先知道啥是架構，很多人一般把架構設計等同于軟件架構設計，不過我這里把架構范圍稍微擴大一點，把IT，流程，組織這類比較復雜的系統都納入架構設計的范圍，因為這三者往往是互相關聯的。不過很遺憾的是，盡管很多人都談架構，我卻沒有找到一個很好的架構定義。套用一句關于大數據的笑話，放在架構上也適用：

Architecture is like **age sex，everybody talks about it，nobody really knows what is it

本文借鑒TOGAF架構定義，重新進行了定義：

架構：是復雜系統組織形式的抽象描述，包括系統內部的組成模塊，內部模塊之間的關系及系統與環境之間的關系。

架構設計：是為了滿足系統的業務使用需求，在業務價值空間、歷史積累、架構發展的約束下，通過業務抽象、組件建模、系統重構方式構建架構，使系統的穩定性，靈活性，可演進性，成本實現具有最優解的過程。輸出包括設計原則，架構和演化原則三個部分。

架構的設計的需求理解，業務建模方法在前面的小節中已經講過了。下面再講講我對設計約束和架構師要求的理解。

架構不是憑空出來的，架構要考慮能不能實現和實現的代價，我剛剛買了一個智能音箱，發現音箱的音量調節邏輯很亂，我建議做音箱的兄弟把音量調節和使用場景綁定。這樣從使用界面看最簡單。但架構要不要這樣做呢？架構師這個時候就要考慮關鍵點，因為音箱的音量可以在不同地方調節，如何保持各軟件音量狀態一致，就需要底層支持。他就一定要了解底層的實現能力，如果是以前的android版本，實現這個功能可能很困難，界面好用也得舍棄，而如何新的服務架構可能會支持，就值得試試，有困難也可以突破一下，所以架構設計一定是在充分理解系統能力的基礎上的一種取舍。

還有架構設計也一定要考慮未來架構的穩定性，比如我們有的大型軟件系統在服務化已經成為明顯趨勢的情況下還是采用了傳統架構，干了幾年后有不得不重新進行服務化設計。所以軟件架構設計就要綜合架構不同設計的收益大小，歷史的積累情況，架構的未來發展幾個因素綜合考慮。

架構設計還是很復雜的，有時候就是一種藝術，需要各自平衡。如果想干架構師，那么有幾個特點就不能少了。一個是開放，不能墨守成規，啥事看看老祖宗咋說，沒自己的見解肯定不行。一個是要有洞察力，知道去粗存精，不能眉毛胡子一把抓，把架構越搞越復雜。業務也要精通，要善于學習，要知識多，知識越多考慮越全面。作為架構師不得不既懂業務，又懂軟件。不然沒法做出很好的設計。

架構設計師是非常關鍵的角色，往往決定了軟件應用生死，承擔如此之重的責任，大家會有疑問，那這么牛的人不是很難找？其實完全不用擔心，架構設計說到底還是工程型問題，不像相對論除了天才誰也搞不了。這世界搞工程型問題的人才濟濟，不可能找不到的，只是看怎么找，給多少錢的問題。當然還有另外的擔心，那成本會不會很高，其實也不用擔心，架構師人數要求也很少，相對系統的成本并不高，所以蘋果才會竭盡全力找最優秀的人才。

3.2?????? 業界的架構設計方法

上面講了最一般的架構設計的框架，下面這個ADM（Architecture Development Method）是TOGAF（The Open Group Architecture Framework）的企業架構設計方法，是The Open Group在美國國防部信息管理技術架構的基礎上發布的，非常完善和詳細，很值得學習。

現代知識搜索非常容易，如果知道哪些知識不知道，一搜索就查到了，關鍵是有時根本不知道自己哪些東西不知道。所以這里大家只要知道有這個很好的方法就行了，具體我就不講了，有興趣的話網上資料很多。

4.1?????? 軟件架構設計

我這里不講具體的軟件架構設計本身，著重講一下軟件架構設計的理念。從很流行的領域驅動設計方法（DDD:Domain-Driven Design）的理念看，本質上，業務軟件設計就是用軟件對現實業務的模擬，設計軟件的過程就是對業務的理解過程。

DDD首先是一種設計思想，所謂思想就是回答“設計的本質是什么，主要邏輯是什么”這類大的問題。DDD強調要從業務視角思考怎么設計軟件架構，設計一定要知道業務是什么樣子的，業務的需求和問題是什么，有什么內在邏輯，而不是從軟件技術本身出發設計，這個對設計而言就是大的方向問題。雖然這個方向說出來好像沒什么，但是實踐上很多軟件人員更多是從軟件本身開始設計，一遇到業務問題容易繞道走，所以強調從業務出發是這個方法最有價值的地方。

自動駕駛網絡的參考設計，下面架構可以對比了解一下。

5.1?????? TOGAF EA和Frameworx

Frameworx是TMF的NOSS框架，相當于TOGAF EA的電信版實例。

5.2?????? TMF自治網絡架構

下面是TMF的自治網絡參考架構：

下面全文引自：中國電信《001-CTGMBOSS-OSS-2.5-概念體系分冊(終審稿)》，這個文檔比較老，但是現在問題依舊沒變。

“業界對OSS的概念描述的比較清晰的TMF SID對概念的描述。在SID的體系中，包括了產品(Product)、服務(Service)、資源(Resource)三個主要概念，其中服務又細分成面向客戶的服務CFS(Customer Facing Service)和面向資源的服務RFS(Resource Facing Servcie)。其中產品可以包含多個面向客戶的服務、面向客戶的服務由多個面向資源的服務組成，面向資源的服務由資源組成。具體關系如圖所示。TMF在eTOM中對各個概念的定義原文如下：

Product?is what an entity (supplier) offers or provides to another entity (customer). Product may include service, processed material, software or hardware or any combination thereof. A product may be tangible (e.g. goods) or intangible (e.g. concepts) or a combination thereof. However, a product ALWAYS includes a service component.

Services?are developed by a Service Provider for sale within Products. The same service may be included in multiple products, packaged differently, with different pricing, etc.

Resources?represent physical and non-physical components used to construct Services. They are drawn from the Application, Computing and Network domains, and include, for example, Network Elements, software, IT systems, and technology components.

本篇從哲學的角度闡述了架構設計的方法，下篇我將介紹一個我自己理解的網絡運行功能的新ISOAP（我的香皂）模型，歡迎大家一起探討。

網絡智能體 人工智能

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。