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

這裏聚集書本有關的部分問題和回答，也歡迎在這裏提問。

問：你好，我是書籍的讀者，請教一個問題，就是我發現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和小程序的後端，從這個角度而言，叫《小團隊構大平臺：中小研發團隊架構實踐》可能更恰當。有些遺憾，但這就是我當時的想法，《小團隊構建大網站》其實也挺好 :)