從去年開始(可能更早)，SOA的概念在汽車軟件行業逐漸蔓延開來，很多公眾號都發過講汽車SOA的文章，很多車廠都要開始(或者已經在)搞SOA。但我覺得吧，在開搞新技術之前，是不是先花點時間弄明白這個技術到底是什么，它解決的是什么樣的問題，然后再談架構，再談開發，很多時候我們連問題是什么都沒整明白，就急著去做解決方案，最后的結果只能是一地雞毛。對個人來說，要搞SOA開發，需要夯實哪些基礎知識，看了很多SOA文章，卻很少有人梳理這些，這段時間我陸續思考了一些，盡管可能不全面(更偏向SOC開發涉及的技術點)，但仍然試圖寫出來，以期逐步構建出自己的領域知識體系。
①
SOA設計難點
個人覺得，汽車SOA的設計難點，主要在于以下幾點：
服務的定義和劃分，要把業務需求分析透徹，從中提煉出服務的功能，數據流向理清，定義服務的邊界，把握服務的粒度，怎么做到“低耦合，高內聚”，我以前很討厭研究需求，覺得那些不過就是些業務，沒啥技術含量，后來才慢慢認識到，這種想法很危險啊，脫離需求的軟件設計不可能很好地滿足需求，如果不能很好地服務于產品功能，那么再牛逼的技術都沒有機會實現它應有的價值，事實上，能夠把需求文檔轉化為可實施的軟件設計，也是一種能力；
不同系統中，要實現中間件框架或者底層通信基礎設施，Adaptive AutoSAR有ARA::COM組件，Android有Framework，但不能跨域，QNX/Linux就不用說了。要實現一個中間件框架，本身并不是件容易的事，需要比較強的技術實力，一旦出了問題一般都是重大問題；
服務接口標準化，接口描述語言化(IDL)，能夠通過工具自動生成RPC樁的代碼(最好能夠關聯整車通信矩陣，e.g. ARXML->C++ API)，能夠跨平臺，支持多語言，畢竟UI層可能不是C++寫的，時至今日，沒幾個應用愿意去解析原始消息，遠程調用接口不香嘛~；
如何兼容一些沒有與時俱進的設備和模塊，如何兼容舊的傳輸通道，如何盡可能復用以前的業務邏輯，理論上任何兼容都是可以實現的，抽象一層不夠，那就再來一層，但兼容得越多，系統就越復雜，出問題的概率就越大，維護起來就越費勁，這意味著成本的升高，質量卻不見得變好；
評估性能影響，怎么保證安全性，……，如果是基于開源項目，可能還要做二次開發，來滿足這些非功能性質的需求~；
所以，汽車SOA真不是SOME/IP，也不是DDS，更不是Adaptive AutoSAR，這些都是汽車SOA技術棧中的一環，并不是全部。
很多時候，純技術的部分并不是最難的，新的架構方案要達成共識，要真正落地，需要博弈和取舍，需要天時地利人和。作為一名工程師，心態是極為重要的，要分清理想與現實，技術與工作，所以在這里我只想談技術，本來打算梳理一下做汽車SOA開發的基礎知識體系，以后公眾號的內容大致也會圍繞著這個體系去寫，沒想到寫著寫著這么長了，于是分成上下篇了，下面先開個頭吧。
SOA是架構，做SOA的設計和開發，其實也是做架構的設計和開發，在這里我想引用陳皓老師為《架構整潔之道》作的推薦序里的一段話，我常想起這段話，挺有鞭策的功效，分享給每個不想成為PPT架構師的工程師，以共勉：
問題：如果你要成為一名架構師，你需要明確地區分幾組詞語，否則你不可能成為一名合格的工程師或架構師。這幾組詞語是簡單vs.簡陋、平衡vs.妥協、迭代vs.半成品。如果你不能很清楚地定義出其中的區別，那么你將很難做出正確的決定，也就不可能成為一名優秀的工程師或架構師。
陳皓，《架構整潔之道》推薦序一
之前很長一段時間，我經常感到焦慮，一方面不想成為PPT黨，開會黨，另一方面，除了工作還要生(帶)活(娃)，留給學習的時間并不多，而想學的知識又如同汪洋大海，今天想好好梳理一下某個技術點，明天搜到某個開源項目蠻感興趣想寫個Demo跑跑看，年輕的時候覺得日子一天天刷刷地過去，也不是什么事兒，現在愈發有種緊迫感。在做了一些架構方面的設計和開發工作以后，更是深刻體會到構建個人的領域知識體系，尤其是一些基礎技術，真的非常重要。
今年伊始，聽了李運華老師關于“如何打好基礎”的講座，核心觀點是：“基礎≠底層，基礎≠源碼，基礎≠不變”，很是醍醐灌頂~結合個人實際情況，我覺得可以這么去構建我的領域知識體系：首先，定義出哪些是與我工作相關的領域知識(比如現階段是SOA)；其次，進一步細化要學習的知識范圍，也就是下篇要梳理的SOA相關知識；最后，分別從廣度和深度(根據工作內容去判別學習的深度)，有針對性地學習，并在實際工作和項目中把知識和技術串起來，從而系統性地提升技術能力。
就像前面說的，要分清理想與現實，因為這個世界從來都不是我所能想象的，很多PPT黨開會黨，基礎不扎實甚至很水，設計出焦油坑一樣的架構，坑自己，坑別人，坑項目，也不耽誤他們升職加薪跳槽。但是“世界上只有一種英雄主義，那就是認清生活的真相后依然熱愛它”，不是么，于是才有了寫公眾號的初心和決心。
②
SOA開發梳理
今天要做的梳理，沒有思維導圖，沒有PDF，沒有表格，是結合了我的實際經歷和體會，總結得出的一些基礎知識點，這是現階段的這個我所了解的所認為的，隨著時間的流逝，我又會經歷更多一些，現在梳理的可能也會跟著改變一些。這種極其個性化的梳理，對我，是梳理(其實，寫這篇比想象中艱辛，要不是前面給自己埋下了坑，都想放棄了~)，對你，看看便好，就當是聽我絮叨絮叨，侃侃大山，輕松愉快，真心不能提供什么參考。以下梳理分為四個維度：編程，架構，網絡，工具。
1、編程：多看，多寫，多折騰
目前，智能座艙的生態圈主要包括Android、Linux、QNX等操作系統，因此，我認為做SOA開發，至少需要熟練掌握C++和Java兩種編程語言。C++是必須要會的，Linux/QNX主要用C++開發，Android其實也涉及C++開發，尤其是對性能要求較高的模塊，通常會下沉到Native或HAL實現。Java也是必須要會的：第一，Android的App和Framework是用Java開發的，需要設計和開發SOA接口，提供給位于這兩層的應用和服務使用；第二，設計SOA架構，要對系統各層級之間的接口如何設計和調用有足夠的了解，代碼都看不明白，怎么設計易用的接口；第三，寫Demo是架構設計過程中重要的步驟，總不能你設計的方案等著別人寫Demo驗證吧，更重要的是，通過寫Demo可以發現很多想法上的不足，設計文檔寫得不嚴謹的地方。
對于C++編程，要掌握的一些基礎知識：
語法基礎：構造，繼承，虛函數，內聯，多態，類型轉換，STL容器，…；
C++11新特性：時至今日，應該學會使用至少C++11常用的特性，比如：類型推導(auto,decltype)，右值引用，智能指針，泛型/模板，type_taits，函數式編程(lambda)，C++11多線程，future，promise，…，用它們使代碼更簡潔，改進代碼質量，提升程序性能，不是為了炫技，而是用到實處；
應用開發：Linux/QNX網絡編程、多線程編程、進程間通信等編程手法，常用實現如無鎖，消息隊列、線程池等，常見開源庫的使用，選擇感興趣的如Libevent、Muduo等，深入學習其設計和實現；
項目開發：代碼結構，接口封裝方式，常用幾種設計模式的實現(如單例模式、觀察者模式等)；
對于Java編程，要掌握的一些基礎知識：
語法基礎：包，類，接口，反射，泛型，異常，集合，注解，常用類，…；
并發編程：原子操作，Exexutor，線程池，阻塞隊列，synchronized，鎖，volatile，CompletableFuture，…，常見模型如Thread-Per-Message，CopyOnWrite，生產者-消費者，…；
應用開發：Java中的網絡編程(JDK API)，Android應用開發基礎(四大組件，不研究UI，只要能整出個正常點兒的DemoApp就行~)，Android進程間通信機制，AIDL、JNI和HIDL接口的設計和開發；
項目開發：常用代碼結構，常用幾種設計模式的實現(如工廠模式、代理模式、門面模式、觀察者模式、策略模式等)，注意，這里和前面C++說的都是實現，期望達到的水平：做到真正的理解，談到某種設計模式，腦子里能夠想到其適用的應用場景是什么，落實到代碼上，一個大致思路是怎樣的，反之亦然；在閱讀一些開源項目時，能夠看出用了什么設計模式，這樣用的好處什么，不用可能會產生什么問題。
2、架構：保持好奇心，平常心
架構和編程的不同之處在于，編程是容易看見結果和成效的，你寫的代碼有沒有Bug很快能被證明，你寫的模塊擴展性和穩定性怎么樣，經過一些時日，也能看出個一二。架構不是，有多少人能在短時間內落地幾種架構方案的，更不用說評價架構設計得好不好了，就拿通信框架來說，很少聽應用說滿意當前的通信框架的，為什么擴展個接口這么麻煩，為什么不支持同步調用，為什么沒有消息緩存，…，能被吐槽的點太多了。即使如此，我們還是要致力于做出好的架構，也許無法得到所有人的滿意，但設計和開發出好的SOA架構，可以讓系統中每一個應用和模塊在交互通信與數據共享的問題上獲得不錯收益，反之，糟糕的SOA架構可能就是所有人必須面對的一場災難。
在架構設計這件事上，我也是剛開始有一點點經歷，以下所想完全沒有參考價值。
設備：跳出單個模塊的視野范圍，嘗試去了解這個通信系統里的每一個設備(可以是車機，儀表，T-Box，網關等等)，他們的軟件系統，他們的硬件，硬件之間的連接，他們的功能業務，他們的開發模式，他們的數據需求，他們以往采用過的通信方案，…；
車載以太網：了解相關知識，如：CAN，LIN，診斷，標定，CP，AP，…，重點關注整車以太網與智能座艙的對接，或者說智能座艙未來如何接入中央計算單元。至于最近很火的AP，沒有計劃作深入研究，從編程角度來說，基礎是相通的，CP用的C，AP用的C++，很多東西并不是本身難度有多大，而是學習的資源和工具難以獲得，人為形成了所謂的技術壁壘，個人開發者想要學習研究，幾乎不可能搭建環境。我覺得開源是時代的進步，一定會是大勢所趨，1202了，我們都要擁抱開源呀~；
系統：Linux/QNX系統調用(如輸入/輸出，存儲，文件，網絡，線程，進程間)，Android系統架構，座艙的整體架構，模塊的架構，比如，車機中Android原生模塊(如BT，WiFi，Audio，Location，…)的數據源有什么不同，車機中這些基礎模塊都是怎么適配的，車機中較復雜的APP如導航、語音等的架構是什么樣的。不要覺得別人負責的模塊我了解了干嘛，說白了，SOA就是模塊與模塊之間的交互，對每個模塊了解一下一定是有益的；
中間件：基于幾種通信模型(可參考DDS 介紹)的中間件框架，RPC技術的原理和實現，各種開源RPC框架：grpc，brpc，srpc，…，各種中間件架構方案：GENIVI，ROS2，…，如何技術選型，如何驗證可行性，如何做性能評估；
設計原則：SOLID，KISS，迪米特，…，結合具體業務的前提下追求原則，知易行難，沒有定式，如何做出正確的決策，需要在實踐中不斷思考和總結；
溝通表達：面向不同受眾的架構視圖，SOA是需要傳播的，“咱們用TCP通信”和“咱們用SOMEIP通信”，對于不熟悉SOMEIP的小伙伴來說，是兩碼事。正確地傳達架構的設計，高效地溝通和解決過程中的沖突，清晰地表述技術實現的細節，畫的UML要能指導開發，盡可能說經過驗證的結論，即便是預估的，也要有一些數據作為依據，不要說出諸如“應該沒問題”這樣的結論；
項目+產品：做架構設計，可以是一個人的事，但架構的落地，是需要一群人一起完成的，能否保質保量完成不是項目經理該去操心的事嗎？我覺得并不是，能否落地也是架構設計中可以考慮的一個視角，適當了解一些項目管理和產品思維的知識，會使你能更好地理解這個世界，理解一個項目的運作，理解一個產品從無到有所要經歷的過程，理解架構不止是一個技術問題，這些都會幫助你設計一個好的架構。
3、網絡：實踐出真知，重視細節
如果說架構是宏觀，那么網絡通信的設計和開發，是件要扣細節的事兒。不要想當然，不要把網絡狀況想得過于理想，不要把服務端想得過于強大，不要對任何錯誤掉以輕心，試圖找到每個錯誤背后的根源，解決的過程就是一次收獲。
網絡基礎：OSI，TCP/IP，五層協議，各層作用和常見協議；
開發基礎：TCP和UDP建立連接的流程，阻塞與非阻塞Socket API，同步與異步，IO多路復用，epoll的水平觸發與邊緣觸發；
通信協議：SOME/IP，DDS，HTTP/RESTful，SSL/TLS，MQTT，對于SOME/IP和DDS，準備死磕：協議標準，開源項目的應用，源碼剖析，二次開發，封裝接口；多媒體傳輸：AVB，RTP/RTCP/RTSP/RTMP；
序列化：JSON，Protobuf，Franca IDL，MsgPack，…，各自優缺點、性能效率、適用場景、開源庫選型；
細節：私有通信協議如何設計，如何解決粘包和分片；心跳機制如何設計；收發緩沖區如何設計；如何優雅地關閉連接；斷線重連機制如何設計；流量控制如何設計；…；
實踐：分析當前網絡連接狀態；定位通信鏈路中出錯位置，分析其出錯原因；抓包，分析數據包；如何設計Benchmark，測試和分析通信架構的各項指標如傳輸時延、CPU占用、內存消耗、負載壓力等；
4、工具：發現，嘗試，積累
寫工具，會讓人覺得很Low吧，實際上，很多人低估了學會使用工具的重要性。為什么別人花一小時搭建實驗環境，而你要一天？為什么別人花半小時定位問題改好代碼，而你要一周？為什么別人花半天完成了某個第三方庫的平臺移植，而你要花幾天，甚至搞不定？…？其實不是別人有多厲害，而是你不善于運用各種工具去解決問題，也沒有注重積累，舉個栗子：一次重裝Ubuntu系統時遇到某個問題，查了好幾篇CSDN文章，總算給搞定了，可什么都沒記下，下次再重裝時，又遇到同樣的問題，這個問題我好像碰到過！然后，就沒有然后了，如果那篇之前幫到你的文章還找不到了，…，總在這樣又那樣的事情上，浪費了太多的精力和時間，這些時間原本可以用來做更多有價值的事情啊~
開發：VSCode，IDEA，Android Studio
構建：Shell，CMake，Gradle，Maven；
調試(測試)：GDB，UT框架，靜態代碼檢測，內存泄漏檢測，tcpdump，Wireshark，MQTT X，JMeter，Docker；
文檔：Markdown，PPT，Excel，筆記，Visio，EA，draw.io，錄屏，…，；
自動化：一直覺得SOA開發工具是值得研究的，比如API文檔自動生成工具、API代碼自動生成工具、回環測試工具等(在互聯網領域已經有一些類似的工具，看過幾個開源的，比如ShowDoc，感覺都不太能用到汽車領域，有好用的歡迎推薦啊~)；
終于，寫完了，好多沒有寫進來，比如算法與數據結構、JVM、Linux內核、數據庫等，當然不是說它們不重要。但對現階段的我來說，上面列的這些已經很夠我學的了，能把這些搞透徹，我已經非常非常滿足了。術業有專攻，先把能做好的事做到最好，不是每個人都能成為技術大牛，也不是每個人的目標都是要成為技術大牛吧，人生的路長著呢，以后的事以后再想好了。有句話不是很扎心么，“以大部分人的努力程度，根本還輪不上拼天賦”，有時候只是態度就足夠拉開差距了。
轉載汽車電子相關文章
轉自汽車電子與軟件
