這里匯集書本有關的部分問題和回答，也歡迎在這里提問。
問：你好，我是書籍的讀者，請教一個問題，就是我發現Demo 里無論是Business 還是DataLayer 都沒有使用接口例如IOrderLogic 也未使用Autofac 來進行處理，這個是實際項目中也是如此嗎？
答：我們就是這樣，並且推薦這樣，在真實項目（C#項目，非Java項目）中也是如此。對於業務系統加之在一個應用內部，簡單實用就好。沒必要搞那么多抽象和工具，現在都是微服務，重構起來也不復雜。引入每一個工具和技術都需要考慮成本收益ROI，如果沒有更復雜的業務問題，就沒有必要引用復雜的工具，因為工具又增加本身的復雜度。
問：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
問1：當團隊規模超過幾十人以上，才需要技術總監，當團隊規模超過上百人時，才有設立CTO的必要，是這樣嗎？
問2：技術管理這種崗位等同於工具，一旦業務進入平穩期或衰退期，成本中心的熱點就會凸顯，每個崗位都有Leader在那盯着，維持着正常的業務運行。這時，還有什么規划和平台要做嗎？到這天，什么CTO，什么技術總監，就等着被收拾吧，都是高危職業。
問3：我是技術總監，需要寫代碼嗎？
答：
我知道以上是網絡流行說法，但我是這樣想的。技術管理是能夠出效益的，早一些請CTO或技術合伙人就整個工程而言，是能夠產生更大效益的。如果等出了問題再去請技術總監或CTO，往往已出現比較大的問題，背負較多技術債務。
一個好技術合伙人或CTO，在團隊只有5個人時，讓團隊發揮5個人的價值。在團隊是只有10個人時，能發揮12個人的功效。在團隊有80人時，如果沒有CTO，就會出現混亂，只能產生50人的價值，但如技術管理得好，可以發揮100人的功效。
在《華為基本法》里有一段這樣的話“人力資本増值的目標優先於財務資本増值的目標”。以上做法是滯后的人才策略，會出現職位斷裂和大量工程問題，現在真正成功的互聯網公司應該不是這樣。當然，願意早些找一個好的技術合伙人，需要有潛力有遠見的CEO，馬雲早年不是也在yahoo請技術牛人。
對於技術管理是高危職業的問題，我個人甚至覺得，所有高管都是高危，高管的終極目標就是把自己做沒，不需要自己整個體系也可以運作得很好。把技術管理當做可有可無的工具，而非合作伙伴，這種老板也不值得跟，企業也大都做不大。
文人自輕不可取，跟對人做對事很關鍵。把技術管理當工具的，又能產生幾成價值，把技術管理當合作伙伴，才會產生技術創新。業務要實現十倍、百倍的增長，傳統銷售和管理很難做到，但借助技術往往可以。技術管理也不一定自己要寫代碼，一個IT項目可以做的工作很多，有十幾種包括架構設計、數據表設計、代碼、測試，可行性分析等，而代碼只是其中一種。有一個好的技術合伙人伴隨其長大，如同孩子成長不斷篇，減少空降和技術風險，實現技術創新和長遠戰略式發展。
問1：為什么叫《小團隊構建大網站》，只適合於做網站嗎？
答：
本書所介紹的技術都是基於開源或公用雲，而不是像那樣大廠自己寫一套中間件，這樣中小研發團隊也可快速搭建，降低成本，易於維護和擴展，不僅利於個人的學習成長、知識重用和職業生涯，也利於團隊的組建和人才的引進。這些技術不僅可以用來構建網站，也可以用於做App和小程序的后端，從這個角度而言，叫《小團隊構大平台：中小研發團隊架構實踐》可能更恰當。有些遺憾，但這就是我當時的想法，《小團隊構建大網站》其實也挺好 :)