在中國，各類運輸方式中公路運輸佔比高居首位，公路運輸既支撐社會和經濟發展的基礎產業，也存在着巨大的市場潛力。
有着“貨運版滴滴"之稱的滿幫集團，在合併後繼續高歌猛進。在今年 4 月份完成新一輪 19 億美元的融資後，滿幫集團的多個事業羣陸續亮相，包括無人駕駛的多個領域通過併購、投資的方式進行了資源整合，開始對物流全產業鏈條進行佈局。
在這過程中，滿幫技術團隊如何進行微服務技術落地？架構上有哪些亮點和突破？接下來有什麼業務發展上帶來的挑戰？TGO 鯤鵬會帶着這些問題，對滿幫集團高級技術總監 & TGO 鯤鵬會成都分會會員李昊進行了專訪。
“戰爭”停止，內外兼修，全面發力
2017 年 11 月 27 日，一場昔日勁敵間的長期“戰爭”戛然而止，物流行業兩大巨頭 —— 貨車幫和運滿滿宣佈合併，滿幫集團成立。這一合併，也被評爲“2017 年物流領域最大的一樁合併案”。當提到這件事時，李昊表示，“當時兩家公司佔據了行業頭部資源，但這些資源都被拉去做車貨匹配業務的競爭，結果不僅影響到了兩個公司的全面發展，而且對用戶造成了一定的傷害。合併，能爲用戶帶來更多的價值和更好的體驗。”
事實證明，合併是正確的決定。今年，滿幫集團順利完成融資進行了業務劃分，並陸續成立了會員、交易、自營、能源、金融、智能駕駛等多個事業羣，推出了一系列新業務。
發展自身的同時，滿幫集團還進行了一系列資源整合。2018 年初，爲了彌補自身在自營業務上的不足，同時希望給客戶提供更好的服務，滿幫集團收購了志鴻物流，佈局大車隊。之後，滿幫集團又投資了中國貨運卡車自動駕駛企業——智加科技，智加科技成爲了滿幫集團在自動駕駛領域的獨家戰略伙伴，雙方將圍繞高精地圖數據採集、大型安全自動駕駛車隊商業化運營支持和賦能全國長途重卡的智能化改造等方面展開深入合作，爲推進幹線物流場景自動駕駛的產業落地進程而努力。近段時間，滿幫集團還與交通部信息中心、國家交戰辦等一系列國家部委和企業展開了數據方面的共建和合作，打造國家級的物流指數和數據標準。
業務情況磨鍊架構，實戰微服務落地
在聊到關於架構的問題時，李昊認爲，“好的架構都不是設計出來的，而是根據團隊實際情況和業務情況磨出來的。”具體到落地微服務架構，李昊分享了落地微服務的四個建議：
1、判斷是否需要落地微服務架構的條件
在落地微服務架構之前，李昊認爲，要明白解決的核心問題是如何做分佈式系統，而不是如何做微服務。
做分佈式系統的過程中，可能會遇到很多難點，比如 partial failure 如何感知和監控，流量和資源如何進行調度，數據和狀態如何管理等。而微服務只是在分佈式系統的建設過程中，爲了應對需求的快速變更，在高增速的公司內部構建高效、自治、響應迅速的“創業風格”團隊的一些嘗試。它的外延涉及到組織、技術、流程等多個方面，而不僅僅是一個技術架構，甚至可以說，技術在其中並不起決定性作用。
其次，我們還需要考慮到微服務對於組織的要求：
個體：需要提前做好知識儲備；
團隊：需要對目標達成共識。
落地微服務是一件極其複雜的事情，因爲會把原來一個單體的應用拆分爲很多個服務，而每個服務會產生大量的實例。這不僅需要開發、測試、運維等各個職能的同學們在工作思路上進行轉變，而且對於組織和個體的能力也有很大的挑戰。
最後在流程方面，CI/CD 是否足夠代碼化、自動化，是否有端到端全鏈路的監控、告警和響應機制，能不能基於一個功能足夠完備的網關進行靈活的灰度和藍綠部署等問題，都將決定一個公司是否具備落地微服務架構的基礎。
基於以上三方面，滿幫集團做了充分的準備，才決定啓動微服務架構的落地工作。如若沒有相對應的組織、流程上的準備，建議不要追趕潮流做微服務，否則獲得的受益比帶來的問題少得多。
做決定之前，李昊建議大家多問問自己，“你的業務需要微服務嗎？你的規模需要微服務嗎？你的團隊能駕馭微服務嗎？”
2、理解微服務架構的實際價值
微服務雖誕生的時間不長，卻因爲適應現今互聯網的高速發展和敏捷、DevOps 等文化而備受衆多企業寵愛。那麼我們該如何認清微服務架構的實際價值？
李昊談到，我們首先需要理解微服務架構並不是一個具體標準的技術框架，當 Martin Fowler 等人提出微服務架構時，就已經強調微服務架構是一種架構風格。
其中，微服務中更細的粒度、去中心化、輕量通信機制等要素，都不算新穎的思路。它能夠變成可操作的實踐，主要是因爲：
1.必要組件的成熟，如服務的註冊發現，分佈式的配置中心等；
2.理論方法的成熟，如 DDD、SAGA、CQRS 等；
3.關鍵技術的成熟，如輕量化容器，分佈式存儲等。
因此，每個公司在落地微服務架構時，都需要根據自己業務和團隊的實際情況進行一系列的技術決策。同時，針對各種不同階段的項目，也需要不同對待。比如對於運行良好的 Legacy 項目，如果規模很大，業務邏輯複雜，那麼沒有必要去進行拆分；但是如果項目還處於創新階段，那麼也不一定需要用微服務。因爲本來可以在一個進程裏的通信，如果拆成多個服務就需要跨進程調用，那麼可能會導致爲開發、部署和運維帶來額外的複雜度。
李昊認爲，落地微服務架構真正的收益在於，完成組織和思維方面的迭代，在公司裏形成小而美，能勝任各種職能的扁平化、自組織、自管理的團隊，支撐在傳統組織和技術架構下無法實現的拓展和創新。
3、中小型公司如何具體落實微服務
除了上述所具備的先決條件之外，李昊建議中小型公司落實微服務時，還需注意取捨和節奏。
一開始落地微服務時，可以考慮先做最基礎的組件：比如端到端全鏈路的監控系統，分別基於 K8S 的容器管理平臺和 API Gateway，基本上能滿足你所有的需求。如果技術能力有限，甚至可以先從監控系統做起，因爲它不會影響主幹業務。確定系統建設和架構目標時，不妨多關注雲原生平臺的構成和分層，以及作爲一種架構風格的微服務相比，雲原生平臺具有完整的體系結構，很容易拆分和細化具體的工作內容。
擁有一套基礎組件後，則可以圍繞服務的設計、開發、測試、上線和運維等工作，開始構建企業自身的 PaaS 平臺。平臺可以有三個方面的屬性：
1.面向可用率和高併發；
2.面向複雜度；
3.面向測試開發。
根據公司自身的特點，可以考慮這三部分如何落地實施，節奏如何掌控。李昊以滿幫集團舉例，因爲滿幫集團業務並不會出現類似於 C 端電商應用那麼高的併發量，所以滿幫集團一開始主要是提高可用率，解決複雜度問題，然後做了打通測試開發運維全流程的雲平臺。
4、如何看待 Service Mesh
Service Mesh 一開始是作爲一個 Network 層的基礎設施，功能在於處理服務間通信，負責實現請求的可靠傳遞。隨着 Linkerd、Istio 和 Kubernetes 的興起，Service Mesh 演進很快，規模與複雜度顯著增加，將服務發現、負載均衡、指標度量、監控、訪問控制、端到端認證、限速和斷路器等，都納入其中，涵蓋流量面和控制面，跟微服務出現之前 SOA 時代的 ESB 有很多重疊。
基於此，李昊認爲，服務網格背後的想法主要是將網絡抽象，這跟滿幫集團想對物流行業進行的抽象正好是有一個有趣的對應關係，未來，貨物的運輸應該就像一個 TCP 包。我們不再需要關心車的承載物品，前進的方向，使用的燃料等。這種層次上的抽象意味着，它的實施成本和複雜度都是很高的。要不要做 Service Mesh，需要技術決策者考慮投入產出比：
1.本來的技術棧異構程度有多高，是否需要進行這樣的抽象來屏蔽複雜度？
2.對基礎設施，運維都有技術和架構上更多的挑戰，業務卻不會有太多感知，那麼開發人員以及公司的收益有多大？
Q & A
TGO 鯤鵬會：在不同階段遇到不同難題時，請問您是如何解決它？
李昊：“凡是過去，皆是序曲”，我聽完這個問題回想各個階段遇到的困難時，這個感受還挺強烈的。人在生活和工作裏，難免會遇到挫折，特別是現在不是流行說我們處的時代是 VUCA （volatility—易變性，uncertainty—不確定性，complexity—複雜性，ambiguity—模糊性的縮寫）嗎？在當時可能感覺它們要把人壓垮了，但過段時間再回頭看，好像也不是什麼大事，解決的方法也沒有多麼曲折離奇。所以中國人說，“未來不迎，當下不雜，既過不戀”。
至於說具體怎麼解決難題的，在技術領域要不被打垮，當然前提是有好的基本功。這跟踢球一樣，很多人隨着年紀變大、閱歷變多，意識和心理承受力都變強了，知道比賽裏該怎麼辦，但就是停不好、傳不到、射不準，主要是基本功太差。
然後是心態，要把困難當成自己成長的機會。我覺得在比較好、發展比較順利的公司裏，新人能學到的東西相當有限。而人在年輕的時候，從困難和錯誤裏學到的東西比順利和成功裏學到的往往要多。
所以，我們需要具備好奇心，以及一個走出舒適區去挑戰困難的心態。
TGO 鯤鵬會：北上廣深是程序員就業的首選，如果程序員想回非一線城市的家鄉發展，您有什麼建議？
李昊：首先，做好技術本身跟地方沒什麼太大關係。我在各種城市裏都看到了很多優秀的個體和團隊。所以，能不能做好技術，主要跟它是不是你真正的興趣所在有關，張益唐 38 歲還在快餐店收銀呢。
其次，如果你不是有那麼大的興趣，只是當成一個職業，那麼回非一線城市發展也挺好。工作嘛，目的是爲了更好的照顧家庭。非一線城市生活壓力沒那麼大，程序員每個月賺三四萬就可以過得既顧家還富足。當然，如果不能保持基本的學習狀態，要保持這個收入水準，需要運氣。
最後就是非一線也可以分爲好幾個檔次的。這幾年杭州、成都、武漢等城市發展的很快，當地的科技公司和技術活動都在迅速增多，我們可以參考 TGO 鯤鵬會的分會發展速度就知道。以成都爲例，今年頭條、美團、OPPO 都已經開設了研發中心，所以我相信，未來非一線城市的技術氛圍會不斷變好。
TGO 鯤鵬會：產品和技術是“死對頭”，您在集團內部如何協調產品、技術的關係呢？
李昊：客觀來說，每個公司都有自身所處的獨特的發展階段。我們公司從一開始單一的車貨匹配業務，到目前多個事業羣，還沒有出現“技術手刃產品經理”或者“殺個程序員祭天”的情況。現在大家都很愛發的“死對頭”的故事，大多數是誇大其詞的段子。其中一部分是真實發生的事件，我看了後挺心疼這些同行的，因爲這些矛盾大多數可以通過流程去管理和規避。
首先，我們要理解這兩個職能的本質。產品設計用戶價值，技術實現這些價值，兩者缺一不可，又有自己的職責邊界，相互應該是補位而不越位的。如果技術過於強勢地推翻產品設計，或者產品強硬地拍定研發方案或者時間，這就是越位了。
在明確邊界的同時，可以做一些組織架構上的保障。比如我們內部產品是儘量閉環到事業部內部管理的。因爲產品經理的工作是圍繞用戶和爲用戶提供價值的，可以複用的部分不會很多，不可能做一個集中的產品部門很好地服務所有的業務。但我們有統一的技術部，在做好整個基礎服務和基礎設施的同時，對每個事業部有團隊進行定向支撐。這種組織架構也保障了彼此之間既能有配合，也會有挑戰，關係比較良性。
其次，我們來看矛盾的本質。產品對技術最大的不滿無非是，需求排在 backlog 裏面半天上不了線；技術對產品最大的不滿無非是，這需求沒啥用，催這麼急幹嘛，以及需求不斷變動。我的經驗是，確保兩端的管理都要可視化。技術團隊的 Lead time，WIP（進行中的工作）等效率指標，以及回滾率，MTTR 等質量指標；產品經理的需求質量，包括描述是否清晰，字段是否完整，上線後效果如何覆盤，變動是否很多等，可以通過整個團隊隨時可以查看的看板進行公示。
總之，清晰的組織架構、貫徹最佳實踐的流程和管理的可視化，是處理產品和技術問題的關鍵。