摘要：本篇從哲學的角度闡述自動駕駛網絡架構設計的方法。
自動駕駛網絡關鍵在架構創新，創新不是漫無邊際，毫無邏輯和實作可能性的瞎想，沒有限制和方法論的瞎想是民科幹的事情。我們要通過堅實的架構設計方法，鋪就一個通往願景的路。
下面講的方法論既是一種知識，也是一種技能。通過知識學習可以更好的了解架構設計技巧。但是作為技能，卻需要不斷磨練才能掌握。就像學遊泳一樣，沒有知識你很難遊好，但是你有了再多知識，進入水中一樣不會遊。
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（我的香皂）模型，歡迎大家一起探讨。
點選關注，第一時間了解華為雲新鮮技術~