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

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

前言

首先說一下爲何這兩個月又沒消息了，由於這兩個月忙啊。

首先是接收上半年系統分析師的證書，並完成總結。其次是九月份PMP考試（4A經過，尚需努力），而後是十一月的軟考高項的考試。工做的事情就不談了，還好沒什麼私人事情須要處理。因此這兩個月沒什麼空寫博客，不過接下來應該會有一些時間來寫博客。

關於系統架構師這個分支，本來都打算完結了的。而後忽然發現你們對系統架構師的論文比較感興趣，而且自從我上次透露了我有一個架構師/分析師的羣后，陸陸續續不斷有人私信我加羣。因此，就回過頭，再發一篇系統架構師的論文。並打算找時間，將本身系統分析師，PMP，項目管理師的知識整理出來。畢竟在過去的一年的時間，我連續經過系統架構師，系統分析師，PMP，並完成，參加了高項（雖然目前還不知道經過沒），我認爲個人學習方法，知識體系等仍是有必定做用的，但願對你們有所幫助。嘻嘻。

哦。差點忘了。因爲個人架構師/分析師羣是邀請制的，因此給大家羣號，也是沒法添加的。因此，若是有參加架構師/分析師的朋友，請私聊我。謝謝。

一，理論

（強調一下，圖片絕對清晰。若是看不清，請重新的頁面打開，或者下載下來）

論文

摘要：
本人於2015年11月參與浙江省某在線教育平臺「外教一對一在線教育」項目，該項目爲客戶提供了一對一歐美外教視頻教學，社交圈，公衆直播等功能提供全方位的軟件支撐，在該項目組中我擔任系統架構師崗位，主要負責總體架構設計與中間件選型。本文以該教育平臺爲例，主要討論了該系統有關可靠性方面的設計與應用，以及遇到的問題與解決方案。一方面經過負載均衡進行容錯技術中冗餘設計的實現，另外一方面經過層次架構風格來明確系統結構體系，從而下降系統設計複雜度，提升系統可靠性。整個系統開發工做歷時18個月。目前，該系統已經穩定運行近一年半的時間。實踐證實，經過容錯設計，下降複雜度設計等，系統有效提升了可靠性，從而爲公司業務提供持續穩定的服務支撐。

正文：
隨着國家對教育的愈加重視，英語教育的市場份額逐步上升，其中用戶口語提高的需求愈來愈大。爲此，一些公司開始提供與外國人聊天的平臺。我所在公司決定從國際通信領域進軍口語教育領域。爲了這項戰略轉變，公司於2015年11月設計某在線教育平臺系統（一下簡稱爲「系統」）。該系統幫助人們與歐美外教進行面對面的口語交流和教學。其中隨意聊提供了一種相似QQ視頻通話，而正式課程還提供了H5互動課件與課後點評等，以提升教學質量。與此同時，還有公衆直播用於拉新，AI測試用於評定學院能力，下降成本。我參與了該項目的開發工做，擔任系統架構設計師職務，負責設計系統架構。本項目組全體成員共9人，我主要負責項目計劃制定，需求分析，總體架構設計與技術選型，以及部分底層設計。該項目的架構工做與次年2月完成，選擇了層次架構風格。整個項目耗時18個月，於2017年5月完成。
目前主流的可靠性設計技術有容錯設計，檢錯設計，下降複雜度設計等技術。容錯設計技術分爲恢復塊設計，N版本程序設計和冗餘設計。其中恢復塊設計是選擇一組軟件操做做爲容錯設計單元，將普通的程序塊編程恢復塊。N版本程序設計的核心是經過設計出多個模塊或不一樣版本，對於相同初始條件和相同輸入的操做結果，實現多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務，以實現軟件容錯。冗餘設計是在一套完整的軟件系統以外，設計一種不一樣路徑，不一樣算法或不一樣實現方法的模塊或系統做爲備份，在出現故障時可使用冗餘的部分進行替換，從而維持軟件系統的正常運行。缺點是費用和資源的消耗會有所增長。檢錯技術是在軟件出現故障後能及時發現並報警。其缺點是不能自動解決故障。下降複雜度設計是由於軟件複雜性與軟件可靠性有着密切關係，是產生軟件缺陷的重要根源。在設計時考慮下降軟件的複雜性，是提升軟件可靠性的有效方法。

在瞭解系統需求後，咱們決定遵從公司技術顧問的建議，容錯設計主要應用在冗餘設計方面，經過負載均衡，雙機容錯等機制完成冗餘設計。檢錯設計則是經過對Java異常處理機制的設計與封裝處理完成。至於下降複雜度方面，採用層次架構風格，使得系統的結構明確，立體，從而提升系統可靠性。接下來，我將從系統的冗餘設計，複雜度下降設計介紹可靠性在系統中的設計與應用，以及應用過程當中遇到的問題與解決方案。

1.冗餘設計：

首先說冗餘設計，冗餘包含邏輯冗餘，數據冗餘，應用冗餘等。這裏以應用冗餘爲例。爲了提升系統的性能，可靠性，可拓展性等，咱們採用了負載均衡技術。常見的負載均衡技術有F5硬件，LVS軟件，Nginx服務器配置等。出於便捷與成本的考慮，咱們採用了Nginx服務器配置負載均衡技術。經過對Nginx服務器中upstream模塊的配置，就能夠實如今多臺服務器的反向代理家在負載均衡。採用負載均衡後，應用服務器集羣存在Session問題沒法統一的問題。解決方法有Session Sticky，Session Replication，Session數據集中存儲，Cookie Based四個方案。Session Sticky是經過確保同一個會話的請求都在同一個Web服務器上處理實現。Session Replication是增長Web服務器間會話數據的同步來保證不一樣Web服務器間的Session數據的一致。Cookie Based就是經過Cookie傳遞Session數據完成。通過考慮，咱們採用了Session數據集中存儲。Session數據集中存儲經過令每臺服務器從專門的session服務器獲取session數據來解決問題。優勢是可靠性，可移植性與可拓展性的大幅提升。缺點是一方面讀寫Session數據引入了網絡操做，對數據讀取存在時延和不穩定性，但對於使用內網通訊的系統並無太大影響。另外一方面，若是Session服務器或集羣出現問題，將會影響整個應用。咱們經過雙機容錯機制解決該問題。除此以外，還有心跳線，看門狗等技術。限於篇幅，再也不贅述。

2.下降複雜度設計：

再者就是下降複雜度設計，因爲系統的複雜性和綜合性，咱們決定採用層次架構風格，將系統架構分爲接入層，應用層，服務層，數據層四個層次。這裏以應用層與服務層爲例。應用層分爲視圖層與業務邏輯層，視圖層負責App與網站的表現效果，業務邏輯層負責業務層的邏輯處理。爲了解決系統日益複雜，應用日益臃腫問題，咱們將系統按照應用橫向劃分，將系統劃分爲課件管理系統，課程管理系統等十餘個子系統。如課件管理系統負責學員上課所用課件，有課件編輯，課件預覽，課件交互等多個功能模塊。功能模塊需調用服務層的服務支撐，如課件交互模塊須要調用stomp通訊服務，實現學生與老師間課件的交互功能。另外，課件交互模塊經過對帳戶服務的調用，確立課件雙方的身份，從而明確雙方在課件交互過程當中對課件交互部分的交互權限。該劃分使得系統體系變得清晰明瞭，極大下降系統複雜度，提升系統可靠性。應用層採用基於J2ee的MVC框架-Structs框架，主要經過Servlet和JSP技術實現。另外還有動靜分離，動態資源靜態化等，這裏再也不贅述。

服務層提供通用服務。系統在應用層中按照應用橫向劃分，有效下降系統複雜度。但系統代碼仍然存在冗餘，好比用戶信息的調用在諸多應用子系統中都有相關模塊。另外應用的大小依舊十分巨大，複雜，而太小的應用劃分會增長數據庫鏈接數負擔，故咱們提出服務化解決方案。服務化方案就是提取出各個應用的通用服務，如帳戶服務，Session服務等。出於技術成熟度與技術支持等考慮，咱們最終採用了阿里的dubbo服務框架，創建服務層。開發過程當中，產生了服務框架部署問題與實現服務框架的jar包和應用自身依賴的jar包衝突的問題。前者，咱們經過Tomcat做爲Web容器，而服務框架做爲容器的一部分來解決。後者，咱們經過Java的ClassLoader將服務框架自身用的類與應用的類進行隔離。除此以外，咱們經過服務線程池隔離，分佈請求合併，服務調用端的流程控制來下降系統複雜度，提升系統可靠性。詳情限於篇幅，再也不贅述。

最終項目成功上線，正常運行了近一年半，收到各方好評。尤爲是H5課件的良好互動性，使得大量業界同行爭相模仿，改用H5製做課件。還有咱們的服務化方案架構被做爲許多傳統互聯網企業系統重構的經典方案。在系統的架構設計中，咱們引入了層次架構的設計思想，有效地下降了維護成本，提升了系統的開放性，可擴展性，可重用性以及可移植性。固然仍是存在一些問題的。如H5課件採用http協議，易被非法劫持，嵌入廣告，能夠將協議修改成https來解決。還有咱們採用的負載均衡算法是加權輪轉算法，過於簡單，經常出現資源分配不合理的現象，能夠將算法改成加權最小鏈接數算法來解決。這些都是我在從此的系統設計和開發中須要注意與改進的地方，也是往後我應該努力的方向。

三，總結

這篇論文的項目，依舊是以前那片論文的項目-在線教育系統。可是其中不少技術，其實在原有項目中是沒有涉及的。

另外這篇論文與以前論文存在一個結構上的不一樣之處，那就是此次的核心論點只有兩個分論點。不過，第二個論點-下降複雜度設計，是經過兩個方面進行闡述的。這也算是論文中核心論點的一種回答方式。每每論文的核心論點，推薦使用三個分論點進行論述，而部分論文的核心論點就只能拆分爲兩個分論點（或者，三個論點的拆分維度，本身不熟悉）。這時候就須要靈活的轉變本身的思想，將核心論點的兩個分論點氛圍主次論點回答，實際體現就是主論點兩個段落，次論點一個段落。

既然說到這裏，也說一下，若是核心論點能夠拆分出多個分論點。如架構風格的層次架構徹底能夠拆分爲接入層，應用層，服務層（基礎服務層，通用服務層，業務服務層），數據接入層，數據源等。那麼這種狀況，咱們徹底能夠從中挑選三點本身熟悉的部分，進行闡述。若是擔憂這樣寫，文章顯得比較僵硬，就在相關位置寫上「此處，咱們以XXX,XXX,XXX爲重點，進行論述"這樣的話語便可。

附錄

早期未修改的論文：

摘要：
本人於2015年11月參與浙江省某在線教育平臺「外教一對一在線教育」項目，該項目爲客戶提供了一對一歐美外教視頻教學，社交圈，公衆直播等功能提供全方位的軟件支撐，在該項目組中我擔任系統架構師崗位，主要負責總體架構設計與中間件選型。本文以該教育平臺爲例，主要討論了該系統有關可靠性方面的設計與應用。一方面經過負載均衡與應用服務器集羣實現容錯技術中冗餘設計的實現，另外一方面經過創建了接入層，應用層，服務層，數據層四層層次的架構來下降明確系統結構，從而系統設計複雜度，提升系統可靠性。整個系統開發工做歷時18個月。目前，該系統已經穩定運行近一年半的時間。實踐證實，經過容錯設計，下降複雜度設計等，系統有效提升了可靠性，從而爲公司業務提供持續穩定的服務支撐。

正文：
隨着國家對教育的愈加重視，英語教育的市場份額逐步上升，其中用戶口語提高的需求愈來愈大。爲此，一些公司開始提供與外國人聊天的平臺。我所在公司決定從國際通信領域進軍口語教育領域。爲了這項戰略轉變，公司於2015年11月設計某在線教育平臺系統（一下簡稱爲「系統」）。該系統幫助人們與歐美外教進行面對面的口語交流和教學。其中隨意聊提供了一種相似QQ視頻通話，而正式課程還提供了H5互動課件與課後點評等，以提升教學質量。與此同時，還有公衆直播用於拉新，AI測試用於評定學院能力，下降成本。我參與了該項目的開發工做，擔任系統架構設計師職務，負責設計系統架構。本項目組全體成員共9人，我主要負責項目計劃制定，需求分析，總體架構設計與技術選型，以及部分底層設計。該項目的架構工做與次年2月完成，選擇了層次架構風格。整個項目耗時18個月，於2017年5月完成。

目前主流的可靠性設計技術有容錯設計，檢錯設計，下降複雜度設計等技術。容錯設計技術分爲恢復塊設計，N版本程序設計和冗餘設計。其中恢復塊設計是選擇一組軟件操做做爲容錯設計單元，將普通的程序塊編程恢復塊。N版本程序設計的核心是經過設計出多個模塊或不一樣版本，對於相同初始條件和相同輸入的操做結果，實現多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務，以實現軟件容錯。冗餘設計是在一套完整的軟件系統以外，設計一種不一樣路徑，不一樣算法或不一樣實現方法的模塊或系統做爲備份，在出現故障時可使用冗餘的部分進行替換，從而維持軟件系統的正常運行。缺點是費用和資源的消耗會有所增長。檢錯技術是在軟件出現故障後能及時發現並報警。其缺點是不能自動解決故障。下降複雜度設計是由於軟件複雜性與軟件可靠性有着密切關係，是產生軟件缺陷的重要根源。在設計時考慮下降軟件的複雜性，是提升軟件可靠性的有效方法。

在瞭解系統需求後，咱們決定遵從公司技術顧問的建議，在容錯設計，檢錯設計，下降複雜度設計三個主流方向分別做出相應處理和應用。容錯設計主要應用在冗餘設計方面，經過負載均衡，雙機容錯等機制完成冗餘設計。檢錯設計則是經過對Java異常處理機制的設計與封裝處理完成。至於下降複雜度，咱們應用層次清晰的四層層次架構。經過將系統劃分爲接入層，應用層，服務層，數據層，使得系統的結構明確，立體，從而下降系統複雜度。限於篇幅，接下來，我將從系統的冗餘設計，複雜度下降設計兩個方面介紹可靠性在系統中的設計與應用，以及應用過程當中遇到的問題。

首先說冗餘設計，冗餘包含邏輯冗餘，數據冗餘，應用冗餘等。這裏以應用冗餘爲例。一方面爲了提升應用服務器性能，另外一方面爲了提升系統的可靠性，可拓展性等，咱們採用了負載均衡技術。常見的負載均衡技術有F5硬件，LVS軟件，Nginx服務器配置等。出於便捷與成本的考慮，咱們採用了Nginx服務器配置負載均衡技術。經過對Nginx服務器中upstream模塊的配置，就能夠實如今多臺服務器的反向代理家在負載均衡。爲了提升負載均衡服務器可靠性，咱們採用雙機熱備機制。但採用負載均衡後，應用服務器集羣出現了Session問題沒法統一的問題。解決方法有Session Sticky，Session Replication，Session數據集中存儲，Cookie Based四個方案。Session Sticky是經過確保同一個會話的請求都在同一個Web服務器上處理實現。Session Replication是增長Web服務器間會話數據的同步來保證不一樣Web服務器間的Session數據的一致。但一方面同步Session數據會形成網絡帶寬的開銷。另外一方面，每臺Web服務器都要保存全部Session數據，消耗大量內存。通過考慮，咱們採用了第三種方案-Session數據集中存儲。Session數據集中存儲經過令每臺服務器從專門的session服務器獲取session數據來解決問題。優勢是可靠性，可移植性與可拓展性的大幅提升。缺點是一方面讀寫Session數據引入了網絡操做，對數據讀取存在時延和不穩定性，但對於使用內網通訊的系統並無太大影響。另外一方面，若是Session服務器或集羣出現問題，將會影響整個應用。咱們經過雙機容錯機制解決該問題。Cookie Based就是經過Cookie傳遞Session數據完成。實現簡單，可是存在如Cookie長度限制等問題。除此以外，還有心跳線，看門狗等諸多技術。限於篇幅，再也不贅述。

再者就是下降複雜度設計，咱們從架構風格選擇，技術選型等角度實現。因爲系統的複雜性和綜合性，咱們決定採用層次架構風格，將系統架構分爲接入層，應用層，服務層，數據層四個層次。接入層負責多平臺的接入，以及API網關，負載均衡等方面。API網關的使用使得對外資源與服務得到統一，保持系統結構的明確，從而提升了系統可靠性。應用層分爲視圖層與業務邏輯層，視圖層負責App與網站的表現效果，業務邏輯層負責業務層的邏輯處理。爲了解決系統日益複雜，應用日益臃腫問題，咱們將系統按照應用橫向劃分，將系統劃分爲課件管理系統，課程管理系統等十餘個子系統。這樣的劃分使得系統體系變得清晰明瞭，極大下降系統複雜度，提升系統可靠性。應用層採用基於J2ee的MVC框架-Structs框架。服務層提供通用服務。系統在應用層中按照應用橫向劃分，有效下降系統複雜度。但系統代碼仍然存在冗餘，好比用戶信息的調用在諸多應用子系統中都有相關模塊。另外應用的大小依舊十分巨大，複雜，而太小的應用劃分會增長數據庫鏈接數負擔，故咱們提出服務化解決方案。服務化方案就是提取出各個應用的通用服務，如帳戶服務，Session服務等。出於技術成熟度與技術支持等考慮，咱們最終採用了阿里的dubbo服務框架，創建服務層。數據層涉及緩存，文件系統，數據庫，數據通知服務，搜索系統等模塊。因爲用戶對數據訪問具備集中性，故咱們基於Spring Cache與Redis實現緩存機制。數據訪問方面，Java已經有不少成熟技術，大體分爲專用API方式，JDBC方式，給予ORM或類ORM接口方式三種。最終咱們採用了成熟的ORM框架-Mybatis框架，再將框架包裝一層。這樣一方面提升系統開發效率，另外一方面提升系統可移植性與可靠性。除此以外，還採用了solr做爲數據層搜索引擎，數據訪問層物理部署採用Proxy方式。限於篇幅，再也不贅述。

最終項目成功上線，正常運行了近一年半，收到各方好評。尤爲是H5課件的良好互動性，使得大量業界同行爭相模仿，改用H5製做課件。還有咱們的服務化方案架構被做爲許多傳統互聯網企業系統重構的經典方案。在系統的架構設計中，咱們引入了層次架構的設計思想，有效地下降了維護成本，提升了系統的開放性，可擴展性，可重用性以及可移植性。固然仍是存在一些問題的。如H5課件採用http協議，易被非法劫持，嵌入廣告，能夠將協議修改成https來解決。還有咱們採用的負載均衡算法是加權輪轉算法，過於簡單，經常出現資源分配不合理的現象，能夠將算法改成加權最小鏈接數算法來解決。這些都是我在從此的系統設計和開發中須要注意與改進的地方，也是往後我應該努力的方向。