系統架構設計師-軟件水平考試（高級）-論文-架構風格

系統架構設計師-論文-架構風格

 

前言：

這三個月因爲工做等方面的事情，因此沒有更新博客。

其實我是有作許多總結的。可是寫博客，就須要整理格式，好麻煩啊。。。。

不過接下來，我會慢慢整理出來的，包括java，spring，數據庫，業務架構等。

四個月，經過工做之餘的學習，今天終於將架構師的證書拿到手了。而後想到我能夠將架構師的論文發上來。

 

首先談談架構師考試的論文通用問題，分別是素材（包括實踐與理論），心態，技巧。

本人是不提倡押題的，可是素材的準備是必要的。素材包含兩個部分，第一是挑一個你熟悉而且適合的項目。熟悉是指你要了解這個項目的功能，技術要點，開發背景等。而適合是指項目屬於商業項目（不是什麼圖書管理系統那樣的學習項目），而且便於在多個論文題目中使用（這個項目能夠談架構，也能夠談需求什麼的）。第二是理論知識的充分準備。須要熟悉多個方面的論文理論知識，包括架構，需求，數據庫等方面相關的理論儲備。

論文準備最重要的是心態。由於題目是不固定的，每一年都有新鮮的技術考察，因此咱們須要穩定的心態，來不變應萬變。拿我本身舉個例子吧。我以前因爲時間關係，實際寫出來的論文，只寫了三篇（固然我作了五篇論文的理論素材）。實際考試時，我發現沒有我寫過的論文。惟一能寫出較爲完整的論文理論的是微服務方面，因此我在慎重思考了兩分鐘後，我將原來有關架構風格的論文迅速轉爲微服務方面的論文，最後經過了考試。

架構師考試的論文技巧，其實準確說是論文的格式，就像畢業論文也有其格式要求。說實話，論文若是有可能的話，最好仍是讓專業的人批改一下。不管你是經過培訓班，培訓老師，又或者是讓一些學員幫你提交，提交兩篇論文，內心會有底氣一些。論文技巧，就是內容的分佈要合理。一篇論文通常會有三個論點，其中會有一個核心論點。另外兩個論點每每分別一個段落便可，而核心論點每每須要五個段落（相關理論一段，中心要點一段，分要點三段）。除了這六個段落，正文還有背景介紹一段，總結一段。最後，別忘了還有一個摘要，摘要建議最後寫。

通用方面主要就這三個方面，若是還有什麼須要問的，能夠@我。

 

架構方面的知識做爲系統架構設計師的絕對核心，其知識點幾乎佔到整個架構師考試的一半。而架構方面的論文，能夠說每一年都有，因此是必須準備的。

 

 

一，理論：

 

 

二，論文：

摘要：

本人於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來解決。