從哲學源頭思考自動駕駛網絡架構設計

摘要：本篇從哲學的角度闡述自動駕駛網絡架構設計的方法。

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

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

01 從哲學源頭開始思考

在講架構設計以前，先學習點邏輯知識。先用一個例子幫助你們理解一下什麼是概念的內涵以及語境的知識。咱們有時討論問題常常整擰巴了，你們討論不到一塊去，不少時候是由於概念理解的不同。講個小故事，有一次我講課時，說管理老外和管理中國人差很少，結果不少人反對，以爲我不瞭解老外，而後講了不少老外不一樣的地方，我反問了一句，那中國人是否是管理方式就同樣呢？當你從人的通常特色看老外的時候，其實你們都同樣，都有七情六慾，都須要願景，都須要尊重，都須要指導，都須要鞭策，這和中國人有啥不同？人面對事情須要尋找共性才能高效處理。若是要尋找個性，那就麻煩了，這世界有徹底同樣的人嗎？昨天的你和今天的你是同樣的嗎?

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

軟件開發要求邏輯很是清晰，特別是大型軟件的架構設計更是如此，須要很是好的抽象思惟能力，因此深刻理解邏輯方法很重要。

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

關於思惟方法有比較、分類、分析、抽象、歸納、綜合幾種方法，在傳統的哲學中，「比較」方法通常和其餘方法並列，其實不是這樣的，比較是最基礎的思惟過程，是「分析」「抽象」等其餘方法的基礎。人是經過比較才能肯定事物的邊界的，而後根據邊界進行劃分類別，也就是「分類」。好比一堆雜糧你能夠經過分析看出有黑豆，紅豆，綠豆，薏米，蓮子，小米，大米等等，這個過程就是你對圖像進行了不斷比較，找到圖像的邊緣，和記憶中圖像比較肯定雜糧種類。只是對圖像的比較分析都是用神經網絡一瞬間完成的，人沒有心理意識，而對抽象事物的分析過程是能夠知覺的，你回想一下，分析事物過程是不也這樣，就是不停的比較各個狀況。

因此分析就是經過不停的比較，根據比較結果對事物進行劃分，分解出各類實體，實體屬性和實體間關係。

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

仍是用一堆雜糧舉例，經過分析這個篩子把黑豆，紅豆，綠豆，薏米，蓮子，小米，大米這些米豆都分開了。抽象的動做就像你認爲小米和大米都不算粗糧，只留了薏米，蓮子、各類豆子。可是也有另外的抽象方法，就是我只選能夠解毒的粗糧，那就只抽象出綠豆了，其餘就都是次要的了。因此抽象什麼不是絕對的，而是根據須要進行的。

抽象每每和本質一詞有關聯，順便說一下什麼是事物本質屬性。抽象通常是根據須要把沒用的屬性去掉，只留關鍵的屬性是，例如簡筆畫爲了區分梨和蘋果，通常抽象到形狀就能分出來了，這種抽象就夠用了，可是若是哪天要畫蘋果梨（真有這種水果的），形狀的抽象就不行了，因此顯然形狀不是蘋果和梨的本質區別。那是什麼是這二者的本質區別呢，口味顯然也不行，咱們如今能夠改良品種搞成口味差很少。梨和蘋果最本質的區別是他們的DNA不一樣。因此事物本質屬性就是能抽象到用於對事物進行分類的最少特徵屬性。

總結一下，抽象就是根據須要選擇屬性和關係的思惟過程。至於怎麼選擇屬性和關係、須要到什麼程度，主要看實際場景了，這個纔是難點。就像畫畫同樣，顏料，筆，紙都同樣，理工科的你畫的和徐悲鴻畫的那價值但是差遠了。你畫的能被你們看到欣賞一下已經很不錯了，徐悲鴻一張畫就夠通常人奮鬥一生，這就是差異，是吧！

若是抽象的對象是像蘋果同樣的實物，你能夠識別出畫的蘋果的，畫的最抽象的狀況下就是一個簡筆畫。若是把抽象結果和語言符號鏈接起來，就成了概念「蘋果」這個詞了。而若是抽象的對象是像文章這種自己也是抽象的和複雜的，那麼這個過程咱們能夠稱做歸納方法。換一句話說，「歸納」就是一種特殊的抽象。

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

0 2業務建模方法

2.1 如何作業務抽象建模

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

2.1.1 業務抽象與分類

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

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

1. 已經有的框架，前人的智力成果確定要參考的。
2. 通用知識，能夠幫助理解背景。
3. 以下圖的7P類資料，這是引用我之前寫的一個業務調研框架。

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

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

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

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

上面這些過程要迭代好屢次，反覆提煉才行，通過這個過程通常就比較清晰了。

2.1.2 組件建模

抽象完以後下一步工做就是按最簡潔原則對分類進行聚類，聚類要考慮將各種別統一到一個層次上，並對聚類進行命名便於管理。最後再識別一下各個聚類間關係，造成關係圖。

仍是用雜糧舉例。咱們開始會把分出來的黑豆，紅豆，綠豆，薏米，蓮子分別打包。可是這樣分類比較多，賣的時候很差介紹。這時以爲黑豆，紅豆，綠豆做用差很少，就再統一打成一個豆類的大包，和薏米、蓮子包並列，就成了下面狀況。黑豆，紅豆，綠豆合併的過程就是一種聚類。這樣介紹起來就清晰一點。

2.1.3 系統重構

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

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

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

2.3 業務梳理工具XMind

梳理業務確定要有一個合適的工具。我常常用XMind。XMind能夠導出各類漂亮的圖，可是這個工具最大的做用是方便的進行屬性和關係調整，對複雜的事情人一會兒可能很難想清楚，因此能夠把全部想法都列到工具裏，而後慢慢進行邏輯調整，這樣會保證效率。

0 3如何進行架構設計

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在美國國防部信息管理技術架構的基礎上發佈的，很是完善和詳細，很值得學習。

現代知識搜索很是容易，若是知道哪些知識不知道，一搜索就查到了，關鍵是有時根本不知道本身哪些東西不知道。因此這裏你們只要知道有這個很好的方法就好了，具體我就不講了，有興趣的話網上資料不少。

0 4架構設計應用示例

4.1 軟件架構設計

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

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

0 5架構參考設計

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

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（個人香皂）模型，歡迎你們一塊兒探討。

點擊關注，第一時間瞭解華爲雲新鮮技術~