系統架構設計師-軟體水準考試（進階）-論文-架構風格

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

前言：

這三個月由于工作等方面的事情，是以沒有更新部落格。

其實我是有做許多總結的。但是寫部落格，就需要整理格式，好麻煩啊。。。。

不過接下來，我會慢慢整理出來的，包括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來解決。