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

前言

首先說一下為什麼這兩個月又沒訊息了，因為這兩個月忙啊。

首先是接收上半年系統分析師的證書，並完成總結。其次是九月份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來解決。還有我們採用的負載均衡演算法是加權輪轉演算法，過於簡單，常常出現資源分配不合理的現象，可以將演算法改為加權最小連線數演算法來解決。這些都是我在今後的系統設計和開發中需要注意與改進的地方，也是日後我應該努力的方向