奈學P7業務架構師

愛共享 愛生活 加油 2021

  百度網盤

提取碼：qhhv 

 

1、架構師的平常職責是什麼 ？
整體而言，架構師負責軟件領域的頂層設計。 架構師須要根據公司的發展，規劃企業將來若干年的架構，制定可落地的架構方案，解決技術難題，作技術選型與攻關，落地具體的架構。優秀的架構師既能作架構方案，也能寫具體的架構代碼。

2、開發工程師和架構師有何區別？
工做重點不一樣：架構師重點在於前期的架構規劃，須要制定可落地的架構方案，結合公司的業務場景、團隊的技術水平等因素作技術選型，解決技術難題等等；而開發工程師重點在於具體的落地，特別的， 開發工程師的工做重點落地具體的功能。

能力要求不一樣：架構師要求比較高，要有架構的廣度、深度，須要掌握一系列的架構技術棧，要求有架構實戰經驗，要有很強的系統分析、系統架構、系統設計的能力。 開發工程師主要是要求熟悉基本的技術棧，熟悉相關業務，快速落地產品的相關功能。

3、 如何走上架構之路？
首先要有架構師的思惟，對分佈式、高併發、高性能、高可用、可擴展、鬆耦合、高內聚、可複用、系統邊界、安全等方面有深入的理解 。
技術面要廣，熟悉架構技術棧，好比:熟悉微服務，緩存，分佈式消息中間件，分佈式任務中間件，數據層中間件，分佈式監控中間件，網關中間件，分佈式配置中心等等，並非全部的技術棧要很是精通，但重要的技術，必定要掌握得很是深 。
注重架構技術實踐，這是開發童鞋很是缺失的。建議多和架構師多交流，多落地相關技術的實踐，集中火力多實戰成長會很快的。理論看100遍，不如實踐一遍。
掌握好uml,提高我的系統分析、系統架構、系統設計、畫業務架構圖、技術架構圖、寫架構方案等方面的能力 。
從架構思惟，架構技術棧，架構職責等角度寫好一份架構師的簡歷，重點突出我的掌握的架構技術棧，重點突出項目的架構亮點，難點 。
在企業內部轉架構，或者去別的企業轉型架構。架構面試方面多實踐，若是沒經驗，可讓架構師老司機們多模擬面試幾輪。
4、業務架構師與基礎架構師區別
對於java程序猿而言，架構師分爲業務架構師，基礎架構師兩大類，從高級開發轉成業務架構師，難度小，出成績快。業務架構和基礎架構有70%是同樣的，那就是都要求有架構能力，剩下的30%是業務架構要求熟練掌握業務，制定架構方案，架構落地，基礎架構則是100%要求純技術。短時間而言，看似基礎架構更風光，其實否則。業務架構發展前景更好一些，由於35歲之後，拼的是綜合能力，再也不是純架構能力。業務架構要求有更好的溝通能力，架構規劃，架構落地能力，必定的行業業務背景，甚至管理能力，因此從業務架構更容易作到技術總監或cto。若是一直作基礎架構，那麼多是首席架構師。通常的架構老司機是業務架構，基礎架構通吃的，好就業，到什麼山唱什麼歌。

5、 UML對系統架構重不重要？
UML是架構基本功，但又容易被開發童鞋忽視。架構師要有很強的系統分析，系統架構，系統設計，架構表達能力，經過掌握UML，提升這些能力。業務架構師 經過 UML能夠抽象出業務平臺的核心用例，能夠把複雜的業務流程以分析模型表達清楚，高階設計階段，利用包圖，組件圖，部署圖把設計，部署表達清楚。基礎架構師設計中間件，能夠畫uml協做圖，或活動圖表達技術功能的流程，設計階段，能夠畫包圖，表達各個包的功能，而後多人能夠一塊兒擼技術中間件的具體代碼，作具體架構落地。

6、Springcloud和Dubbo用哪一個？
Dubbo相對而言，成熟穩定，文檔齊全門檻低一些，可是不少服務治理方面的功能是缺失的。Springcloud大而全，但不少功能不強大，不成熟。長期而言，我的更看好Spring cloud,雖然目前還有一些坑，並且門檻也比Dubbo高，但總體發展趨勢比Dubbo強，Spring cloud生態體系比Dubbo更好，功能更全面。掌握Dubbo和Spring cloud是不衝突的，兩者有不少相同的地方，又有不少地方不一樣。

7、分佈式定時任務和通常的任務都什麼區別？
分佈式定時任務通常是多臺服務器能夠同時跑定時任務，效率要比通常的任務高，可用性要比通常的任務高(能夠作失效轉移，架構上沒有單點問題，任務節點能夠監控)，性能要比通常任務的強（架構是強伸縮性，多臺機器一塊兒運行，執行時間要短），支持的併發能力遠遠超過通常的任務（多臺機器執行，能夠把海量數據分配給不一樣的機器執行，併發能力很是好）。

8、高併發和高性能的區別和聯繫是什麼？
簡單而言，高併發是訪問數量，高性能是訪問響應時間，兩個不一樣的角度。 併發量化的常見參數指標，qps,tps等等，性能量化指標通常是處理時間，好比:接口響應時間是10ms和5分鐘，性能是徹底不同的。qps爲100和qps爲50萬的併發架構徹底不同。若是架構不合理，併發量越大，性能越差。若是架構合理，併發量的大小對性能基本沒影響，加機器便可，軟件架構不須要任何改變。

9、爲啥項目經理在國內實際上是很危險的職業？
項目管理其實沒啥含金量，項目經理工做替代性其實很強，能夠被產品經理，技術經理，核心開發等干係人替代。特別是到中年之後，項目經理很難找到合適的工做。

10、reactor線程指的是reactor模型中的哪一個部分？
這個問題自己是有問題的。 reactor線程模型分爲單線程，多線程，主從多線程。 實際編程過程當中，第二種用的是最多的，

11、消息中間件目前使用頻率最大是RabbitMQ嗎？
技術選型是從技術的使用場景，優缺點等方面綜合評估的。不少企業用RocketMQ和kafka,大數據基本100%選kafka.

12、 服務限流有哪些算法？
服務限流常見算法有併發計數器算法，漏桶算法，令牌桶算法。前兩種算法不支持突發流量的限流，令牌桶算法支持突發流量的限流。 通常用谷歌guava落地令牌桶算法，用sentinel做爲服務限流的中間件。

十3、 數據同步有哪些方式 ？
這個問題其實涉及到不少場景的。 若是是數據庫方面的，能夠用SqlLoader、GoldenGate等相關工具同步數據； 大數據方面的，能夠用ETL、Hadoop等相關技術同步數據；若是是定時調度發起的，能夠考慮用SpringBatch，Quartz，Elastic-Job等分佈式任務中間件發起同步數據；若是是異步的場景，能夠用mq來實現監聽而且同步增量數據。 大批量的數據狀況下，儘量地考慮用mq、線程池、多線程、數據批量操做等相關技術手段提高性能。

十4、上億數據如何大規模更新 ？
能夠用分佈式任務調度中間件的大任務分片來作，把上億的數據分給多臺機器來作。 若是實時性要求不高，徹底能夠設置必定的時間間隔，減小DB壓力；若是實時要求高，數據層須要分庫。若是天天增量數據較多，能夠考慮週期性地作數據歸檔。

十5、dubbo是否有什麼缺陷
dubbo缺陷不少呀，特別是服務治理方面，服務限流算法有缺陷，突發流量有問題的，服務熔斷纔剛剛有，但也有缺陷，監控方面只支持點到點的監控，不能作到分佈式鏈路監控，沒有服務網關，服務分組能力太弱。dubbo性能還有提高的空間，編解碼不支持messagpack，通訊方式有待改進。監控中心功能太簡單，監控中心和管理後臺沒有整合。dubbo纔剛剛和springcloud打通，支持還不是很友好。

十6、在分佈式環境下，如何防止RocketMQ消息重複消費？
消費方能夠基於分佈式鎖來解決rocketmq的消息冪等性的問題。用分佈式鎖能夠從純技術角度messageid,或者業務角度業務主鍵惟一性均可以實現rocketmq消息消費的冪等性。另外，rocketmq生產方發送消息，自己就保證了消息的冪等性，主要是消費方消費消息要保證冪等性。

十7、MongoDB和Redis有什麼區別？
定位不同，前者是基於分佈式文件存儲的數據庫，後者是緩存，不少公司是禁止把redis當數據庫來使用的，通常而言，有經驗的架構團隊會規定把緩存失效時間至多設置爲7天。超過7天，再從新生成熱點數據。

十8、rocketmq是否會丟消息
rocketmq通常是不會丟消息，所謂的rocketmq丟消息，有兩種常見的緣由，一、開發童鞋寫的消費者代碼邏輯有bug,好比，消費消息的代碼邏輯有異常，卻把異常吃掉了，且返回成功的狀態，人爲的致使丟消息。二、運維層面有問題，把消息寫到分佈式存儲有問題，致使丟消息。 這兩種狀況致使所謂的丟消息，以第一種居多，有很多開發童鞋會犯第一種錯誤。

十9、Spring cloud 和dubbo用哪一個？
dubbo相對而言，成熟穩定，文檔齊全門檻低一些，可是不少服務治理方面的功能是缺失的。spring cloud大而全，但不少功能不強大，不成熟。長期而言，我的更看好spring cloud,雖然目前還有一些坑，並且門檻也比dubbo高，但總體發展趨勢比dubbo強，spring cloud生態體系比dubbo更好，功能更全面。掌握dubbo和spring cloud是不衝突的，兩者有不少相同的地方，又有不少地方不一樣。而且阿里技術團隊開發了spring-cloud-alibaba，爲dubbo向spring-cloud靠攏，整合作了技術準備。

二10、如何作技術選型？
技術選型是個能力活兒，架構師常常作技術選型，會出有答案的選擇題，有幾種方案，給到技術高管或者開發團隊。而不是一上來就是寫架構代碼。失職的架構師是給技術領導或者技術團隊出問答題，長期出問答題，基本能夠走人了。架構師要有必定的架構功力，會給領導或技術團隊出選擇題，總有一款技術適合的，比較每一種技術（方案）的優缺點，技術領導或者技術團隊會很喜歡的，以技服人。架構思路通常是 ： 問題（背景）--》技術調研（選型）---》規劃（方案）---》落地（擼代碼），任何架構或者技術，都要解決問題的，要有價值。

二11、那技術選型主要是誰來負責，誰來背鍋呢？
誰選誰負責，好比，若是是架構師選的，架構師確定要負責。 技術選型，要從公司的業務場景，技術多方面去比較每一種技術的優缺點，好比，對於幾種MQ，kafka，rocketmq，rabbitmq，activemq，從技術適用場景，技術的成熟度，技術門檻，可維護性，性能，併發，擴展性等角度去比較每一種MQ技術在以上多個角度的優缺點，作選型的人，儘可能作選擇題，比較每一種技術的優缺點，作到以技服人，讓相關人或相關團隊，心服口服。

二12、如何走上架構之路？
一、首先要有架構師的思惟，對分佈式、高併發、高性能、高可用、可擴展、鬆耦合、高內聚、可複用、系統邊界、安全等方面有深入的理解 二、技術面要廣，熟悉架構技術棧，好比:熟悉微服務，緩存，分佈式消息中間件，分佈式任務中間件，數據層中間件，分佈式監控中間件，網關中間件，分佈式配置中心等等，並非全部的技術棧要很是精通，但重要的技術，必定要掌握得很是深 三、注重架構技術實踐，這是開發童鞋很是缺失的。建議多和架構師多交流，多落地相關技術的實踐，集中火力多實戰成長會很快的。理論看100遍，不如實踐一遍。 四、掌握好uml,提高我的系統分析、系統架構、系統設計、畫業務架構圖、技術架構圖、寫架構方案等方面的能力 五、從架構思惟，架構技術棧，架構職責等角度寫好一份架構師的簡歷，重點突出我的掌握的架構技術棧，重點突出項目的架構亮點，難點 六、在企業內部轉架構，或者去別的企業轉型架構。架構面試方面多實踐，若是沒經驗，可讓架構師老司機們多模擬面試幾輪。

二十3、領域驅動模型平時設計的時候用不用？
不建議用，特別不適合互聯網企業。領悟驅動設計是老美髮明的一套設計方法論，針對複雜的業務，進行代碼分層，不建議用，門檻很高，我的認爲不太適合國內的國情，特別不適合互聯網的敏捷開發，它對開發人員的素質要求很高。貧血模型，充血模型，失血模型，脹血模型這些模型很複雜、很繞，領悟驅動設計會把代碼分層作的比較複雜，開發效率比傳統的四層代碼分層的效率要低。我之前工做過的一家公司實施過領悟驅動設計，效果差，後來仍是改成傳統的四層模型。當時有一位架構師同事牽頭落地的領域驅動設計的代碼分層效果並很差，開發人員落地實際代碼有不少困惑，容易產生混亂，開發效率也不高。好的架構是大道至簡，簡單、易用的架構纔有生存空間。

1. 從層次設計結構角度說明：

咱們使用mvp這種層級結構進行劃分：

Mvp的介紹：

隨着UI建立技術的功能日益加強，UI層也履行着愈來愈多的職責。爲了更好地細分視圖(View)與模型(Model)的功能，讓View專一於處理數據的可視化以及與用戶的交互，同時讓Model只關係數據的處理，基於MVC概念的MVP(Model-View-Presenter)模式應運而生。

在MVP模式裏一般包含4個要素：

• View:負責繪製UI元素、與用戶進行交互(在Android中體現爲Activity);

• View interface:須要View實現的接口，View經過View interface與Presenter進行交互，下降耦合，方便進行單元測試;

• Model:負責存儲、檢索、操縱數據(有時也實現一個Model interface用來下降耦合);

• Presenter:做爲View與Model交互的中間紐帶，處理與用戶交互的負責邏輯。

Mvp這種模式使模塊與模塊之間下降耦合度，模塊職責劃分明顯，實現了代碼複用機制以及結構更靈活

2. 從代碼設計結構角度說明：

代碼結構咱們使用常見的模板方式設計模式，抽取一些通用的基類：
好比：BaseActivity， BaseFragment， BaseAdapter，BaseDao，BasePresenter等經過這種方式抽取，使咱們的代碼更加簡潔，便於維和。

除了以上的設計，咱們這裏使用了：
單例模式：減小對象的建立，避免了內存的沒必要要的開銷
工廠模式：用於隱藏多個Fragment的建立過程，使代碼更加靈活和簡潔
建造者模式：封裝了一些輔助工具類。將複雜的建立，放在內部，外部只關注業務邏輯的實現。

3. 從總體UI結構角度說明：

UI結構咱們採用了市面比較流程的設計結構
就是底部導航 + ViewPager + Fragments 來實現。

這裏面咱們並無使用大量的Activity，而是使用Fragment來代替多個Activity。

由於當業務邏輯或者功能模塊比較多時，若是使用大量的Activity，會帶來內存泄漏，

從而致使內存開銷比較大。這裏就使用了ViewPager + 多個Fragments來代替Actiivty。

Fragment在加載數據時，能夠對Fragment的數據進行緩存，這樣就避免的內存的開銷，同時，界面加載速度很快，從而提升了用戶體驗。