《中小研發團隊架構實踐》精彩問答

問：DDD都這麼多年了，為什麼不用DDD標準五層，還要用傳統三層呢？

答：一個簡單微服務應用為什麼要分五層，分三層不是挺簡單挺實用的嗎？要解決的問題有那麼複雜嗎？還是模式需要。

DDD是2004年Eric那本書開始興起的，是他個人前幾年的工作專案總結，在當今微服務架構模式下，工具和技術已發生很大的變化，它是否適用，我們是否繼續搬抄。

DDD是軟體系統分析和設計建模方法，在分析和設計階段它很實用，但在程式碼實施階段並不一定，成功案例也不多。在設計階段，PPT架構師是畫圖的，自然以模型為中心，畫圖或者模型就是他們的交付物，但實施階段，介面和介面才是程式設計師的交付物。好交付、好驗收、好度量、視覺化，對於整個工程而言是非常重要的。DDD強調的是設計模型，而在微服務架構模式下，業務中臺介面就是模型的體現。整個系統可以分五層，但單個應用而言，三層足以。

問：公司用到Redis 叢集用的哪種方案？什麼考慮？

答：

分片+主備，我知道是當前的主流方案，可為什麼要這樣呢？

分片：Redis最好是一個應用一個例項，資料大到要分片的情況很少。如果真的需要，不同的key也可存到不同的例項中，如果一個Key大到一個例項存不下，也很容易把key再分一下。

主備：什麼情況下用得到主備，一個臨時資料要搞什麼主備，到底有多少價值。

現在大都是瞎用，我自已是這麼覺得的。說這些可能太Challenge權威了，我淺薄、挑刺啦。如果不把Redis當快取用，難道應該把它當DB用，這很牛逼啦。

可以定個架構層面的規範：

1.Redis當快取用，不允許超過24小時

2.一個應用一個Redis例項

3.特殊情況再寫工單，包括：分片+主備、持久化。

簡單、好用!

問：想請教一下博主，你們是如何處理國內航線NFD的特價政策呢？

答：任務打底啊，FD可以每月打一次，然後特別航線、航司可以根據需要打底，NFD因為解析比較複雜，可以每週打一次，它們都屬於第三節的靜態資料與任務打底。這個問題太偏機票領域了，我們後面討論通用的垂直搜尋比較好。

問：國外機票走快取，很難拿到最優票。

答：最優票價是由多供應商和機票政策決定的，快取主要是解決速度問題，對於快取資料的新鮮度可藉助更新頻率、二次確認和補償。

問：這種查詢直接用ELK 加上資料庫日誌訂閱同步ELK 就可以了吧，上面的架構能夠實現，但是感覺複雜度有點高了。

答：ES確實是用來做Search的，但主要解決高併發、大資料量場景下，還有不錯的效能問題，而這是傳統資料庫LIKE不好解決的。對於我們這種垂直搜尋，更多面對的問題是業務場景複雜度，資料量也並不大，當然對於大資料且多表關聯的場景也可以用做ES來解決部分問題。還是文末的那句話： “每一個具體的技術可能並不複雜，但把它們綜合起來，解決具體的實際問題，為公司為行業帶來價值，並不是件容易的事。”

問：如果接觸不到這些包括架構方面的東西，有什麼好辦法深入學習一下麼，總感覺自己折騰沒去實踐的得來終覺淺。

答：非常認同你的觀點，自己折騰，確實沒有工作中實踐得來有價值，實際專案中才有真實的業務場景。而大部分中介軟體的書籍，知識點雖然比較全而，但程式設計師可能只用到20%。怎麼才能獲得這些經驗呢？需要機遇+努力，如果公司內部有機會那就好好把握，如果沒有也可爭取。找公司領導或者自己換個環境，比方說你當前在一個幾百人研發團隊，你很想做卻沒有實踐機會，你可以跳到五十人左右的團隊，然後去主導框架或架構工作，這樣堅持一兩年，這些知識便可過關，我見過類似的成功案例。

問 1：好奇問一下，光這份文件編寫，花了多少時間？整個重構花了多長時間，多少人力？

問2： 我也有個問題比較好奇，當時既然大部分打算重寫，為什麼不直接考慮轉Java生態

答：兩位好，編寫總體架構文件花了1個多月，重構花了5個月。原有的體系是.net的，後期也有部分專案採用java，但第一語言還是以.net為主，主要原因是歷史和團隊結構等。 

問1：沒什麼乾貨，感覺就是把框架的使用文件複製了一遍，然後總結成了一本書，沒必要買。相信我，一下午就可以看完。。。。所有的框架都只是說明。

問2：這是個大話題，是真的很薄，感覺是博文小合集 

問3：適合.Net的人看，Java不合適 

答：

確實不厚，200多頁，但都是精華，是真正經過實戰總結出來的。如果把書中的每篇文章都放大寫的話，每一篇都能夠寫上一本書，沒有必要且大部分人不會看。 對於大部分框架，程式設計師可能只需要懂20%，運維 可能 需要懂另外的20%，而架構師可能多一些。 在多瞭解其工作原理情況下，再學會其常見用法，即可滿足大部分場景可，而其它更高階的知識點，可以實踐中根據問題去搜找答案。以下是摘抄自書中的幾句話，以表明我們的想法。 

“ 框架篇中的每章主要由四部分組成：它是什麼、工作原理、使用場景和可直接除錯的Demo。其中中介軟體及Demo是歷經兩家公司四年時間的考驗，涉及幾百個應用，100多個庫1萬多張表，日訂單從幾萬張到十幾萬，年GMV從幾十億到幾百億。所有中介軟體與工具都是基於開源。早期我們也有部分自主研發如集中式日誌和度量框架，後期在第二家公司時為了快速地搭建、降低成本、易於維護和擴充套件，全部改為開源。這樣不僅利於個人的學習成長、知識重用和職業生涯，也利於團隊的組建和人才的引進。

根據我們以往的經驗，分享者主講一個小時左右，業務研發就可以快速地進入專案實戰。對於後面新加入的團隊成員，也可通過Wiki自主快速學習。這是我們之前對自己的要求，儘量降低工具對研發人員的門檻，簡單實用、降低成本。文章中部分Demo採用C#、Java及Go語言 ，但到了框架與架構層面，與語言本身沒有太多關係。如RabbitMQ、Job、Redis和集中式日誌ELK，它們服務端的部署都是一樣的，只是客戶端語言版本稍有不同。所有Demo在一段時間內都可直接執行，服務地址和管理後臺亦可直接訪問。

使用過分散式中介軟體的人都知道，程式設計師使用起來並不複雜，常用的客戶端API就那麼幾個，比我們日常編寫程式時用到的API要少得多。但是分散式中介軟體在中小研發團隊中使用得並不多，為什麼會這樣呢？原因是中介軟體的職責相對單一，客戶端的使用雖然簡單，但整個環境搭起來卻不容易。所以對於中介軟體的使用，我們重點放在解決門檻問題，把服務端環境搭好(生產環境可直接使用雲或運維解決)，把中介軟體的基本職責和功能介紹好，把客戶端Demo寫好，讓程式設計師抬抬腳，在除錯程式碼中即可輕鬆入門。

本書堅持程式碼比文章重要，簡單實用比炫技重要，基於常用場景而不是特殊場景，追求一篇文章即可快速地入門。文章完全站在程式設計師學習和使用的角度，以及架構師價值輸出的角度，儘量提供Demo和設計案例，並且全部放到GitHub上對讀者開放，希望對公司產生正面、可直接使用的價值。”

以上是我們的初衷，對於問題1中提到的“一下午就可以看完"，那可能是沒有靜下心來。據我幾個做架構師和架構總監的朋友反饋，如果把 文章和Demo練習完，大約需要半年左右。 建議靜心下來、多動手， 附上程式碼地址：https://github.com/das2017