系統架構設計師屬於
軟考高階
，系統架構
設計師論文
是
四選一
。
從給出的4道試題（
試題一至試題四
）中任選1道解答，
需在答題紙上的指定位置處將所選擇的試題的題號框塗黑
，若多塗或者未塗題號框，則對題號最小的一道試題進行評分。
架構論文常考，軟體外部架構：
系統整合
，SOA（微服務），
微服務
（2017年架構已考過）及軟體內部架構：
架構風格
（幾乎必考！！！但可能像13年指定架構風格出題），設計模式！
軟考系統分析師論文寫作通用模板
論文要求在
兩個小時內
，寫一篇
2000~2500字
的論文，估算一下，
兩個小時120分鐘
，除去審題，構思，寫作時間可能
只有100分鐘
，
每分鐘需要寫20~25個字
，每2~3秒寫一個字，你可以感受一下。
所以，所以，要想一想，如何才能在段時間內，寫出一篇高質量，易出彩的架構論文？是值得準備參加系統架構設計師考試同學思考的問題！
下面就是一遍較為優秀的
軟考系統分析師論文寫作通用模板，主旨是論述
採用微服務構建中臺系統的架構。可以供準備參加系統架構設計師考試同學，
參考與思考及套用。
可以參考這篇論文的結構，學習這篇論文的形式，套用這篇論文的格式……
01
摘要部分
要求：200字以上，簡單且明確，對結尾承上啟下
基於目前中臺市場呈現積極上升態勢，國家正大力發展健康產業，經過我所在的公司對中臺市場的調研，以及我所在的公司在通訊領域的多年耕耘經驗，我所在的公司決定於XX年YY月開始開發以服務於通訊的資料中臺系統，我有幸以
系統架構設計師
的身份，參與了此專案的建設工作。該專案的工期為16個月，參與人數65人，開發了包括概覽、資料同步、資料開發、多租戶等功能模組。透過該專案的建設，我所在的公司不僅打開了在中臺行業的軟體市場，同時也擴大了我所在的公司在通訊業務規模。該專案於XX年YY月成功推廣到相關通訊中，並受到通訊公司的一致好評。本文結合作者的實際經驗，以資料中臺系統為例，透過微服務思想討論了資料中臺系統在構建過程中的建設性方案，
主要以在專案構建中的需求階段、技術選型階段、設計階段、開發階段、測試階段、部署及運維階段進行了闡述。
02
正文部分
下述是正文中的過渡階段，尤為重要。（500字左右）
基於目前中臺市場呈現積極上升態勢，國家正大力發展健康產業，經過我所在的公司對中臺市場的調研以及我所在的公司在通訊領域的多年耕耘經驗，我所在的公司決定於XX年YY月開始開發以服務於通訊的資料中臺系統，我有幸以
系統架構設計師
的身份參與了此專案的建設工作。該專案的工期為16個月，參與人數65人，開發了包括概覽、資料同步、資料開發、多租戶等功能模組。
透過該專案的建設，我所在的公司不僅打開了在中臺行業的軟體市場，同時也擴大了我所在的公司在通訊業務規模。
該專案以
微服務架構
為思想，採用JDK1。8版本的Java語言開發，以springcloud的F版本，為微服務核心開發框架，以zuu1。5作為閘道器，
以eureka1.2作為服務註冊中心
，以hystrix1。5作為服務熔斷，
以Apollo1.2作為分散式配置中心
，以sentinel1。3作為服務限流工具，
以zipkin1.5作為服務的鏈路跟蹤工具
，以關係型資料庫MySQL5。7儲存重要業務資料，
透過MySQL中介軟體maxscale2.2來自動識別
讀寫分離，以記憶體型資料庫
redis4.0作為分散式鎖
以及儲存熱點資料，以
阿里雲SLB作為一級負載均衡
來代理nginx1。10。2，以
nginx1.10.2作為二級負載
均衡來代理閘道器並作為域名對映、儲存靜態檔案的容器，以64位阿里雲centos7。2作為作業系統。
由於本專案的順利上線涉及到我所在的公司在中臺行業中的推廣，因此，
本專案的整體架構設計和後端服務效能尤為重要。
在本專案中，我作為系統架構設計人員，除了對系統架構的基本設計以外，特別從以下幾個方面對整體系統進行了梳理。
下述是正文中的解釋說明階段，比較重要。（2000字左右）
一，需求階段。
根據我所在的公司在通訊行業的多年經驗，經相關人員在市場調研之後，與產品、研發、測試等人員進行了需求對接工作。這裡對需求分成了三大步驟，分別是需求分析、需求定義、需求解決策略。
1，在需求分析方面，我們考慮了市場調研的需求，是否符合法律法規、是否符合使用者利益、是否符合企業目標、是否超出目前企業資源、是否符合相關者利益、是否負面性、是否變更、是否延期以及預估市場規模等幾個方面。
2，在需求定義方面，
首先確定了面向的使用者為通訊而不是個體，然後基於通訊服務中使用者流失嚴重、通訊服務投資力度不夠、通訊資料丟失過大、通訊頻寬延時過高、通訊使用者管理混亂、通訊通話質量相對偏低等棘手問題
，最後從需求中拆分出了概覽、資料同步、資料開發、多租戶等幾大主要業務模組。
3，在需求解決策略方面，產品人員確定最終需求，預估上線時間，並根據這些模組，以及衍生模組，劃分需求優先順序，專案經理根據最終需求，預估開發週期，並把業務模組精確到各個小組的成員。
二，技術選型階段。
基於現階段的業務劃分、人員分配及其技術水平以及系統架構的發展趨勢，首先是研發方面，最終選定前後端分離的開發模式，在前端方面，基於node環境，透過VUE框架來構建前端介面；在後端應用方面，基於jdk1。8環境，透過微服務框架springcloud來構建後端應用，在作業系統方面，基於centos7。2來部署前端和後端工程。
選用
前後端分離
的關鍵因素：頁面的佈局複雜、頁面的複雜業務邏輯、頁面的渲染資料量較大、後端的業務複雜、業務模組過多導致介面過多，
優點:並行開發、專注開發工作、提升開發效率、易於應對需求變化、增強程式碼可維護性和重複性、易於測試；
缺點：效能問題、增加前端工作量、安全風險、模板適配性、增加公司成本。
選用
微服務架構部署
和設計資料中臺系統的關鍵因素：業務模組眾多、降低各個模組的耦合性，
優點：主要是微服務的優勢，比如高內聚性、自治性、技術異構性、彈性擴充套件、獨立部署、可組合性、可替代性；
缺點：主要是微服務的劣勢，比如服務數量多、管理服務複雜、問題跟蹤困難等。
然後是資料庫方面，透過關係型資料庫MySQL5。7儲存核心業務資料，透過
MySQL中介軟體maxscale做讀寫分離
，透過記憶體型資料庫redis4。0儲存熱點資料。
最後是系統架構部署方面，基於公司現有生產伺服器部署及業務應用的執行情況，直接購買阿里雲伺服器即可。
三，設計階段。
首先在
資料庫表設計層面
，在需求對接時，資料庫管理員參與了需求的學習，為了表設計的合理性、加快開發進度，以及吸取以往的設計經驗，各個業務表的初始設計，由資料庫管理員來設計，在後續的開發階段，如開發人員需要對錶結構進行修改，需與資料庫管理員直接商議。
然後在
前端開發方面
，一是
基於業務模組
，劃分業務邊界，確定業務模型和公共模型，二是
合理定義與後端互動的restful
形式的介面模板，三是做好與產品設計的對接工作。
再次在
應用開發方面
，一是基於業務模組，劃分業務邊界，確定業務模型和公共模型，二是基於阿里巴巴Java編碼規範進行程式碼編寫，三是基於阿里巴巴資料庫sql規範來編寫sql，四是基於前端提交的restful形式的介面模板的填寫測試資料以便於前端介面測試。
然後在
架構部署方面
，以阿里雲SLB作為
一級負載均衡來代理nginx1.10.2
，以nginx1。10。2作為二級負載均衡來代理閘道器並作為域名對映、儲存靜態檔案的容器。
最後，上述的每項內容都會以培訓的形式對相關研發人進行統一的
技能培訓
。
四，開發階段。
首先在後端應用開發框架方面，基於springcloud-F版本的整套框架為核心，來開發業務模組，前期開發階段，
springcloud整合的eureka1.2、zuul1.5、hystrix1.5、zipkin1.5、sentinel1.3等外掛
，都暫時以預設值來設定，
當開發進度進行到中期
，對上述外掛進行對應的調參處理，並加入
Apollo1.2分散式配置中心
來統一管理各個業務模組的屬性值。
然後在透過微服務思想對業務進行建模方面，
前期開發階段
，以
比較粗的粒度
，找出業務邊界，並把業務模型進行初步劃分；當各業務模組開發出
基本成型的應用體系時
，此時
準確找出業務邊界
，並確定
業務模型
和
公共模型
，在此期間，逐步劃分業務功能的同時，來逐步劃分，業務上下文和邊界。
再次在
業務變更方面
，與領導、產品、小組開發組長和測試即時溝通，
適當延長開發週期
，相關模組分給其他人員。
之後在
核心人員流失方面
，即時與將要離職人員進行挽留與工作對接，即時與人事溝通重新招新人的事宜，即時從其他專案組臨時抽調人員，來頂替現有職位，並即時對新人進行培訓和指導，
將要離職人員，要即時做好交接工作
。
最後，
開發人員
每開發出一個單獨的模組要與
產品
、
前端
和
測試
人員即時對接，即時把相應介面引數提供給前端人員，即時跟領導彙報開發進度。
五，測試階段。
首先在
業務模組
測試方面，
測試人員
與
前端
和
後端開發人員
對接，即時反饋各個模組的BUG，對各個BUG的問題反饋要精確，對督促開發人員對BUG的修改，即時與產品，與專案負責人對接測試情況。
最後在
效能測試
方面，
一是
，測試人員需與架構設計人員、產品與後端設計人員對接；
二是
，要基於產品，提供的市場反饋資料，作出合理的效能壓測報告；
三是
，要對
後端應用
整合的zuul1。5、hystrix1。5、zipkin1。5、sentinel1。3的核心屬性值，進行動態調整，
四是
，在效能測試時，出現的任何問題要，與
架構設計人員
和
後端開發人員
即時反饋。
六，部署及運維階段。
首先在部署方面，前端程式碼
基於npm編譯
，後端程式碼
基於maven編譯
。
二者均透過jenkins等自動化部署工具整合，並對各個應用，
做到自動化部署。
然後在高可用和高效能設計部署方面，
一是
基於測試人員的測試結果，對軟硬體資源進行適當的擴充套件，
二是
最佳化各個業務模組中
不規範的程式碼
，
三是
最佳化sql。之後藉助
監控工具
，對部署的各個應用，及軟硬體資源的相關情況，進行監控和報告彙總。
最後，對整個中臺的系統架構進行不斷的演化和改進，
即時解決
引發的問題，
預測將要出現
的問題，
即時研究
相關技術適配到業務場景中，並對現有的系統架構
進行總結和培訓。
03
結尾部分
要求：200字以上，簡短且精煉，突出知識域，與摘要承上啟下
經過我們團隊不懈的努力，歷時16個月，本專案終於於XX年YY月通過了領導的審批，上線後受到各通訊行業的一致好評，為通訊
解決了使用者流失嚴重、通訊服務投資力度不夠、通訊資料丟失過大、通訊頻寬延時過高、通訊使用者管理混亂等棘手問題。
當然，在本專案中還有一些不足之處，比如在zuul閘道器層由於hystrix熔斷屬性值的偏差，
導致閘道器效能出現些許異常
；在應用層由於sentinel限流屬性值的偏差，
導致個別業務出現些許異常
，不過透過我後續的糾察，並沒有對專案產生什麼影響。在後續的學習和工作中，我會繼續對此中臺系統架構進行最佳化，與同事進行交流，也會進行不斷的學習，把知識運用到工作中的各個領域中，作出自己的一份貢獻。