轉載自：https://www.cnblogs.com/Tiancheng-Duan/p/10646028.html
首先談談架構師考試的論文通用問題，分別是素材（包括實踐與理論），心態，技巧。
本人是不提倡押題的，但是素材的准備是必要的。素材包含兩個部分，第一是挑一個你熟悉並且適合的項目。熟悉是指你要了解這個項目的功能，技術要點，開發背景等。而適合是指項目屬於商業項目（不是什么圖書管理系統那樣的學習項目），並且便於在多個論文題目中使用（這個項目可以談架構，也可以談需求什么的）。第二是理論知識的充分准備。需要熟悉多個方面的論文理論知識，包括架構，需求，數據庫等方面相關的理論儲備。
論文准備最重要的是心態。因為題目是不固定的，每年都有新鮮的技術考察，所以我們需要穩定的心態，來不變應萬變。拿我自己舉個例子吧。我之前由於時間關系，實際寫出來的論文，只寫了三篇（當然我做了五篇論文的理論素材）。實際考試時，我發現沒有我寫過的論文。唯一能寫出較為完整的論文理論的是微服務方面，所以我在慎重思考了兩分鍾后，我將原來有關架構風格的論文迅速轉為微服務方面的論文，最后通過了考試。
架構師考試的論文技巧，其實准確說是論文的格式，就像畢業論文也有其格式要求。說實話，論文如果有可能的話，最好還是讓專業的人批改一下。無論你是通過培訓班，培訓老師，又或者是讓一些學員幫你提交，提交兩篇論文，心里會有底氣一些。論文技巧，就是內容的分布要合理。一篇論文一般會有三個論點，其中會有一個核心論點。另外兩個論點往往分別一個段落即可，而核心論點往往需要五個段落（相關理論一段，中心要點一段，分要點三段）。除了這六個段落，正文還有背景介紹一段，總結一段。最后，別忘了還有一個摘要，摘要建議最后寫。
通用方面主要就這三個方面，如果還有什么需要問的，可以@我。
架構方面的知識作為系統架構設計師的絕對核心，其知識點幾乎占到整個架構師考試的一半。而架構方面的論文，可以說每年都有，所以是必須准備的。
一，理論：
二，論文：
摘要：
本人於2015年11月參與浙江省某在線教育平台“外教一對一在線教育”項目，該項目為客戶提供了一對一歐美外教視頻教學，社交圈，公眾直播等功能提供全方位的軟件支撐，在該項目組中我擔任系統架構師崗位，主要負責整體架構設計與中間件選型。本文以該教育平台為例，主要討論了軟件架構風格在該項目中的具體應用。整個系統采用具有三層的層次式軟件架構的設計思想，分別是應用層，服務層，數據層。在應用層中的業務邏輯層的設計中，將整個業務系統划分為十余個子系統。服務層以dubbo服務框架為核心，數據采用了Mybatis框架。整個系統開發工作歷時18個月。目前，該系統已經穩定運行近一年半的時間。實踐證明，這種架構設計有效地降低了維護成本，提高了系統的開放性，可拓展性，可復用性和可移植性。
正文：
隨着國家對教育對越發重視，英語教育的市場份額逐步上升，其中用戶口語提升的需求越來越大。為此，一些公司開始提供與外國人聊天的平台。我公司決定從國際通訊領域進軍口語教育領域。為了這項戰略轉變，公司於2015年11月設計在線教育平台系統（以下簡稱為“系統“）。該系統幫助人們與歐美外教進行面對面的口語交流與教學。其中隨意聊提供了一個類似QQ視頻通話，而正式課程還提供了H5互動課件以提高教學質量。與此同時，還有公眾直播用於拉新，AI測試用於評測學員能力，降低成本。我參與了該項目的開發工作，擔任系統架構設計師職務，主要負責設計系統架構。本項目組全體成員共9人，我主要負責項目計划制定，需求分析，整體架構設計與技術選型，以及底層設計。該項目的架構工作於次年2月完成，整個項目耗時18個月，於2017年5月完成。
在架構工作的開始階段，我們便意識到，架構風格定義了用於描述系統的術語表和一組指導構建系統的規則，是系統組織方式的慣用模式，可以為我們的項目提供架構級的通用解決方案。這種架構級的軟件重用可以極大提高我們的系統建設進程。軟件系統開發中常用的軟件架構風格有數據流風格，調用/返回風格，獨立構件風格，虛擬機風格，倉庫風格。數據流風格包括批處理序列與管道-過濾器，其每一步處理都是獨立，順序執行的，適用於簡單的線性流程。調用/返回風格包括主程序/子程序風格，面向對象風格，層次結構風格，其進一步降低系統耦合度，明確系統層次。獨立構件風格包括進程通信，事件驅動系統（隱式調用），其構件特點為軟件重用提供了支持。虛擬機風格包括解釋器風格，基於規則的系統風格，其具有良好靈活性，可自定義規則。倉庫風格包括數據庫系統風格，超文本系統風格，黑板系統風格，其以數據為中心。除此之外，還有dssa，soa等架構風格。
在了解需求后，我們決定在公司技術顧問的建議下，采用層次架構風格。為了解決公司原通訊系統代碼冗余問題，我們進行了系統服務化，中間層不同的服務中心提供不同的業務服務。最終，我們將系統分為應用層，服務層，數據層。應用層負責具體業務和視圖展示，如網站首頁，app內搜索輸入與結果展示等，其又分為視圖層與業務邏輯層。服務層負責為應用層提供通用服務支持，如賬戶管理服務，session管理服務等，其又細分為邏輯處理層與數據接口層。而數據層負責提供數據存儲訪問服務，如數據庫服務，緩存服務，文件服務，搜索服務等。接下來，我將分層次詳細介紹三層層次體系結構的設計過程。
首先是應用層。在應用層中，我們將系統根據應用進行水平划分，這有助於代碼管理與維護。我們將系統分為課件管理系統，公眾直播系統，學員測試系統，課程管理系統等十余個子系統，這里以課件管理系統為例。課件管理系統負責學員上課所用的課件，有課件編輯，課件預覽，課件交互，課件展示等多個功能模塊。功能模塊調用服務層的服務支撐，如課件交互需要調用服務層由ActiveMQ實現的stomp通信服務，通過該通信服務，實現教師端與學生端的課件的同步，從而使得課件交互變得有趣，生動，具有互動性。另一方面為了區別教師端與學生端的交互權限，課件模塊還需要調用服務層的賬戶服務，確定用戶身份，從而明確用戶在課件交互中的交互權限。與此同時，為提高課件的可修改性，可互動性等，課件采用H5編寫。應用層主要采用structs這一基於J2EE平台的MVC框架，主要通過Servlet與JSP技術實現。另外還有動靜分離，動態資源靜態化等，這里不再贅述。
其次是服務層。服務層采用了dubbo服務框架等技術實現。隨着服務器規模的擴大，開發人員的增多，每個應用都變得復雜，臃腫，存在大量代碼重復。為解決這個問題，提出了兩個方案。一個是將應用拆分得更小，確保每個應用都保持在一個合適的大小。好處是設計能夠較快地完成，代碼也較容易實現。這個方案存在一些問題，一方面數據庫的連接數壓力依舊存在，另一方面，代碼的冗余依舊存在。所以我們采用了第二個方案-服務化方案。服務化方案，即應用層和數據層中增加一個服務層。首先從結構上來看，系統結構更為清晰明了，更為立體。穩定性上來看，許多散落的代碼成為了通用服務，並交付專門的團隊負責運維。出於對成本與技術成熟度的考慮，我們采用了阿里研發的dubbo服務框架。在服務框架實際操作時有兩個問題：服務框架自身的部署方式問題與實現服務框架所依賴的一些外部jar包與應用自身依賴的jar包之間的沖突。前者，我們通過Tomcat作為Web容器，而服務框架作為容器的一部分。后者，我們通過Java的ClassLoader將服務框架自身用的類與應用用的類進行隔離。除此之外，還有服務線程池隔離，分布請求合並，服務調用端的流控處理，異步服務調用，通過Future方式對遠程服務調用的優化等問題，限於篇幅，不再贅述。
最后是數據層。數據層涉及緩存，文件系統，數據庫，數據通知服務，搜索系統等模塊。由於用戶對數據的訪問具有集中性，所以我們基於SpringCache與Redis實現了緩存機制。由於系統的業務特性，數據庫往往是讀操作遠多於寫操作，所以我們對數據庫進行了讀寫分離。數據訪問方面，Java已經有很多成熟技術，大致分為三種。第一種是為用戶提供專有API，這種方法便於實現功能，但是通用性較差。第二種是通過JDBC方式訪問數據庫，數據層本身作為一個JDBC的實現，也就是暴露出JDBC的接口給服務層。該方法成本很低，遷移成本也非常低，但開發成本相對高一些。第三種方式是基於ORM或類ORM接口的方式。我們采用的就是這種方式，使用數據庫時使用ORM框架-Mybatis框架，再將框架包裝一層，用於實現數據層功能，對外暴露的仍然是Mybatis的接口。該方法開發高效，敏捷，成本較低，而且兼容性不錯。此外，我們采用solr作為數據層搜索引擎，數據訪問層物理部署采用Proxy方式等。限於篇幅，不在贅述。
最終項目成功上線，正常運行了近一年半，收到各方好評。尤其是H5課件的良好互動性，使得大量業界同行爭相模仿，改用H5制作課件。還有我們的服務化方案架構被作為許多傳統互聯網企業系統重構的經典方案。在系統的架構設計中，我們引入了層次架構的設計思想，有效地降低了維護成本，提高了系統的開放性，可擴展性，可重用性以及可移植性。當然還是存在一些問題的。如H5課件采用http協議，易被非法劫持，嵌入廣告，可以將協議修改為https來解決。還有我們采用的負載均衡算法是加權輪轉算法，過於簡單，常常出現資源分配不合理的現象，可以將算法改為加權最小連接數算法來解決。這些都是我在今后的系統設計和開發中需要注意與改進的地方，也是日后我應該努力的方向。
三，總結：
這個論文的項目，其實我不是很熟悉。但是當時這個項目最好接觸，體量也足夠。囧。
但是總體的技術架構是沒有太大問題的，技術點也是沒有問題的。
最后的最后，說一個要點，不要抄論文，不要抄論文，不要抄論文。我之所以將我的這篇論文放上來，是為了令你們能夠熟悉論文的結構（心疼我當初寫論文的時候，網上找不到太多適合的相關博客）。
附錄：
早期未修改的論文：
摘要：
本人於2015年11月參與浙江省某在線教育平台“外教一對一在線教育”項目，該項目為客戶提供了一對一歐美外教面對面視頻教學，以及相關的社交圈，外教公眾直播等功能提供全方位的軟件支撐，在該項目組中我擔任系統架構師崗位，主要負責整體架構設計與中間件選型。本文以該教育平台為例，主要討論了軟件架構風格在該項目中的具體應用。整個系統采用具有四層的層次式軟件架構的設計思想，分別是接入層，應用層，服務層，數據層。在應用層中的業務邏輯層的設計中，將整個業務系統划分為十余個子系統。子系統根據其環境與特點采用相同或不同的架構。整個系統開發工作歷時18個月。目前，該系統已經穩定運行近一年半的時間。實踐證明，這種架構設計有效地降低了維護成本，提高了系統的開放性，可拓展性，可復用性和可移植性。
正文：
隨着國家對教育對越發重視，英語教育的市場份額逐步上升，其中用戶口語提升的需求越來越大。為此，一些公司開始提供與外國人聊天的平台。我公司決定從國際通訊領域進軍口語教育領域。為了這項戰略轉變，公司於2015年11月設計在線教育平台系統（以下簡稱為“系統“）。該系統幫助人們可以與歐美外教進行面對面的口語交流與教學。其中隨意聊提供了一個類似QQ視頻通話，而正式課程還提供了H5互動課件以提高教學質量。與此同時，還有公眾直播用於拉新，AI測試用於評測學員能力，降低成本。我參與了該項目的開發工作，擔任系統架構設計師職務，主要負責設計系統架構。本項目組全體成員共9人，我主要負責整體架構設計與技術選型，以及底層設計。該項目的架構工作於次年2月完成，整個項目耗時18個月，於2017年5月完成。
在架構工作的開始階段，我們便意識到，架構風格定義了用於描述系統的術語表和一組指導構建系統的規則，是系統組織方式的慣用模式，可以為我們的項目提供架構級的通用解決方案。這種架構級的軟件重用可以極大提高我們的系統建設進程。
了解需求后，我們決定在公司技術顧問的建議下，采用層次架構風格。為了解決公司原通訊系統代碼冗余問題，我們進行了系統服務化，中間層不同的服務中心提供不同的業務服務。最終，我們將系統分為接入層，應用層，服務層，數據層。接入層負責應對PC端，移動端等的接入。應用層負責具體業務和視圖展示，如網站首頁，app內搜索輸入與結果展示等，其又分為視圖層與業務邏輯層。服務層負責為應用層提供通用服務支持，如賬戶管理服務，session管理服務等，其又細分為邏輯處理層與數據接口層。而數據層負責提供數據存儲訪問服務，如數據庫服務，緩存服務，文件服務，搜索服務等。
接入層采用了CDN，WAF，SLB等技術實現。由於系統核心是跨國一對一視頻聊天，所以用戶對網絡延遲非常敏感。為此，我們采用CDN技術。CDN通過全局負載技術將用戶的訪問指向距離最近的邊緣服務器，由邊緣服務器響應用戶請求。這使得用戶就近獲取所需內容，降低網絡擁塞，提高用戶響應速度。為了防止來自DDOS等惡意網絡攻擊，我們采用了WAF技術實現一系列針對HTTP/HTTPS的安全策略來保護我們的Web應用。為了應對日益提高的數據吞吐量，系統擴展性，系統可用性，我們采用了負載均衡技術。負載均衡技術的實現有多種手段，有通過硬件技術實現的F5，專業的負載均衡軟件LVS，HAproxy等。經過討論，之后出於對成本與技術成熟度等方面的考慮，我們決定采用Nginx實現負載均衡。通過對Nginx中upstream模塊的配置，實現了在多台服務器的反向代理加載負載均衡。並且要讓配置生效，我們不需要重啟Nginx服務器，只需要reload配置即可。除此之外，還有API網關等問題，這里就不再贅述了。
應用層中，我們將系統根據應用進行水平划分，這有助於代碼管理與維護。我們將系統分為課件管理系統，公眾直播系統，學員測試系統，課程管理系統等十余個子系統，這里以課件管理系統為例。課件管理系統負責學員上課所用的課件，有課件編輯，課件預覽，課件交互，課件展示等多個功能模塊。功能模塊調用服務層的服務支撐，如課件交互需要調用服務層由ActiveMQ實現的stomp通信服務，通過該通信服務，實現教師端與學生端的課件的同步，從而使得課件交互變得有趣，生動，具有互動性。另一方面為了區別教師端與學生端的交互權限，課件模塊還需要調用服務層的賬戶服務，確定用戶身份，從而明確用戶在課件交互中的交互權限。與此同時，為提高課件的可修改性，可互動性等，課件采用H5編寫。應用層主要采用structs這一基於J2EE平台的MVC框架，主要通過Servlet與JSP技術實現。另外還有動靜分離，動態資源靜態化等，這里不再贅述。
服務層采用了dubbo服務框架等技術實現。隨着服務器規模的擴大，開發人員的增多，每個應用都變得復雜，臃腫，代碼存在大量重復。為解決這個問題，提出了兩個方案。一個是將應用拆分得更小，確保每個應用都保持在一個合適的大小。好處是設計能夠較快地完成，代碼也較容易實現。這個方案存在一些問題，一方面數據庫的連接數壓力依舊存在，另一方面，代碼的冗余依舊存在。比如，在課件系統的交互應用與個人中心的計費應用都需調用賬戶相關的功能，這就造成了代碼的冗余。所以我們采用了第二個方案-服務化方案。服務化方案，即應用層和數據層中增加一個服務層。首先從結構上來看，系統結構更為清晰明了，更為立體。穩定性上來看，許多散落的代碼成為了通用服務，並交付專門的團隊負責運維。一方面提高了代碼質量，另一方面由於核心模塊，修改和發布的次數將減少，這也會提高穩定性。最后，底層資源統一由服務層管理，結構更為清晰，也更有利於提高效率。出於對成本與技術成熟度，以及技術支持的考慮，我們采用了阿里研發的dubbo服務框架。在服務框架實際操作時有兩個問題：服務框架自身的部署方式問題與實現服務框架所依賴的一些外部jar包與應用自身依賴的jar包之間的沖突。前者，我們通過Tomcat作為Web容器，而服務框架作為容器的一部分。后者，我們通過Java的ClassLoader將服務框架自身用的類與應用用的類進行隔離。為了提高服務層效率，我們采用了不同服務的線程池的隔離以及通布式環境中的請求合並。這有效降低了整個系統的負載，提高處理效率。除此之外，服務調用端的流控處理，異步服務調用，通過Future方式對遠程服務調用的優化等問題，限於篇幅，不再贅述。
數據層涉及緩存，文件系統，數據庫，數據通知服務，搜索系統等模塊。由於用戶對數據的訪問具有集中性，所以我們基於SpringCache與Redis實現了緩存機制。由於系統的業務特性，數據庫往往是讀操作遠多於寫操作，所以我們對數據庫進行了讀寫分離。數據訪問方面，Java已經有很多成熟技術，大致分為三種。第一種是為用戶提供專有API，這種方法便於實現功能，但是通用性較差。第二種是通過JDBC方式訪問數據庫，數據層本身作為一個JDBC的實現，也就是暴露出JDBC的接口給服務層。該方法成本很低，遷移成本也非常低，但開發成本相對高一些。第三種方式是基於ORM或類ORM接口的方式。我們采用的就是這種方式，使用數據庫時使用ORM框架-Mybatis框架，再將框架包裝一層，用於實現數據層功能，對外暴露的仍然是Mybatis的接口。該方法開發高效，敏捷，成本較低，而且兼容性不錯。此外，我們采用solr作為數據層搜索引擎，數據訪問層物理部署采用Proxy方式等。限於篇幅，不在贅述。
最終項目成功上線，正常運行了近一年半，並受到業界爭相模仿。在系統的架構設計中，我們引入了層次架構的設計思想，有效地降低了維護成本，提高了系統的開放性，可擴展性，可重用性以及可移植性。當然還是存在一些問題的。如H5課件采用http協議，易被ISP等劫持，嵌入廣告，可以將協議修改為https來解決。