170
架構師論文
如何寫論文
用10分鍾在草稿紙上寫出思維導圖， 例如下麵是分布式緩存係統設計的導圖。
如何提高係統架構師寫作水平：
https://www.cnblogs.com/muhongxing/archive/2010/10/10/1847476.html
素材
敏捷（scrum，XP），MVC，插件結構（OSGI），雲（PaaS, IaaS, SaaS），SOA（Restful）
論文構思
- 使用思維導圖
- 仔細閱讀題目
- 頭腦風暴，將能想到的素材寫作草稿紙的右方（好的關鍵詞，或句子）
- 擬定總論點 （在紙的左邊使用思維導圖）
可以從以下角度進行思考：
- 軟件的開發流程（需求分析，係統設計，詳細設計，編碼 + 單元測試，測試（功能測試，集成測試，回歸測試，性能測試，驗收測試），部署） 整個過程迭代。
- 軟件的架構風格 （MVC，分層，事件驅動）
- 軟件的質量屬性（性能，可靠性，可用性，安全性，可修改性，互操作性）
- 擬定分論點，回答試題中的提到的問題
- 劃分章節
- 大體估計字數
摘要撰寫
- 摘要應控製在300~400字的範圍內。
- 摘要八股文
（1）本文討論......係統項目的.........（論文主題）。該係統.........(項目背景、簡單功能介紹）。在本文中首先討論了...........(技術、方法、工具、措施)，最後............(不足之處、如何改進、特色之處、發展趨勢）。
在本項目的開發過程中，我擔任了..........
正文撰寫
- 字數在2000~3000之間
- 論文結構
| 過程 | 字數 |
|---|---|
| 項目概述 * 開發項目概述 * 我承擔的角色和工作 * 項目的架構情況概述 |
400~600字 |
| 采用的手段 * 麵臨的問題 * 解決方案和策略 |
1000 ~ 1400 |
| 實施的效果 | 200 ~ 300 |
| 不足之處和改進方案 | 200 ~ 300 |
| 總結 | 100 ~ 200 |
公司係統概述：
在全球有97Million的活躍用戶，Web表現層平均每天會收到20億次的瀏覽請求，監控係統每天分析的日誌在TB級，有200多個SOA服務堆棧，每天被調用10億次，係統存儲的數據在PB級。支付係統每天接受用戶請求在10M以上，訪問數據庫在100M以上。構建的係統需要保證數10億交易的99.999%的可用性。公司是采用基於Java和J2EE技術的Web架構，Web服務器選用的是WAS CE（WebSphere Application Server Community Edition 一個基於Apache Geronimo的輕量級JEE 容器），數據庫是Oracle 11g。 16,000應用服務器，220個應用集群（Pool）
MMP項目，在MMP之前隻有EMS，後麵被拆分為OPMS，EL，PGW。
公司的基礎架構件（中間件）有CAL, DAL, BES。
監控很重要，是係統運維，故障定位，性能分析的基礎。
論分布式數據庫設計：
數據拆分，數據訪問層設計，分布式事務管理（CAP（Consistency, Availability, Partition Tolerance)，BASE(Basically Available, Soft Sate, Eventually Consistency).
分布式係統設計：
分布式應用的優點：
1. 性能和可伸縮性
2. 高可用性
3. 可以並行開發
4. 分離關注點
論基於構件的開發（Component-Based Software Development)：
基於構件的組裝，可以更快地構造係統，提高係統可維護性，減輕係統維護負擔，降低軟件開發費用。
需求分析，係統建模往往是自上而下的方式，開發構件是自下而上的。
構件可以是商用成品構件COTS（Commercial-Off-the-Shelf)，也可以是OpenSource的，也可以是自行開發的。
CBSD真個過程是，用傳統需求獲取技術建立係統的需求規約（Requirement Specification），在完成體係結構設計後，並不立即開始詳細設計，而是確定哪些部分可有構件組裝完成。
構件鑒定：也就是去發現構件，難度較大，在內部發現，在外部發現。
構件適配：如果被複用的構件不符合目標係統的架構，就可能導致構件無法正常工作，甚至影響整個係統的運行，這種情況稱為失配（Mismatch)。 調整構件使之滿足體係結構要求的行為就是構件適配。構件適配可通過白盒、灰盒和黑盒的方式。
構件更新：基於構件的係統演化往往表現為構件的替換或增加。
購買的構件（Oracle 數據庫）對 JDBC driver 的灰黑擴展，使其具有connection pool.
開源的構件 （Junit，Jaxb，apache utility).
自己開發的構件（kernal，CAL，DAL）
構件和中間件類似，都是可以複用的組件。由於中間件的出現，軟件開發可以變得十分專業，例如通信中間件，消息中間件，數據庫中間件，他們屏蔽了許多繁瑣的細節，使得應用程序開發人員可以專注於質量和業務邏輯優化，各種不同的勞動得以在自己熟悉的領域得到發展，不用分散精力，這就是分工帶來的優勢，專業化帶來的好處，如今，在計算機軟件科學中，這就是基於構件開發（中間件）帶來的好處。
論基於服務的軟件體係結構SOA:
SOA 的作用：
1. 解決信息孤島
2. 實現功能重用
3. 可以並行開發
SOA的設計原則：
1. 無狀態性
2. 功能單一性
3. 明確定義的接口
4. 鬆耦合性
5. 粗粒度
6. 功能重用，互操作性
SOA的主要實現方式：webservice， REST
消息格式： NVP（Name Value Pair), JSON, XML, SOAP
論企業應用集成：
自己開發的消息中間件BES（Business Event System)，使用消息處理方式，有諸多好處，1. 異步調用，減少響應延遲，任何可以晚點再做的事情都應該晚做，如活動跟蹤，決算，日誌和報表等。
2. 調用者 和 被調用者之間徹底的解耦。增強係統的可修改性
3. 增強係統的可用性，同步調用中，組件A調用組件B，如果組件B不可用，那麼組件A也不可用，異步調用中A和B的可用性是獨立的。
4. 消峰，同步調用迫使你用負載的峰值來配置基礎設施，異步可以緩解峰值壓力。
為什麼不使用已有的產品例如IBM的MQ呢？公司的業務流量非常龐大，而且數據是高度分布式的，如果使用集中式的MQ產品，勢必會給消息服務器帶來巨大的壓力，會影響消息處理性能，這種以數據庫為核心的輕量級消息中間件實現方式，真好利用了現有的分布式數據庫的優勢，將消息處理壓力分攤到各應用自己所使用的數據庫上，提供了更好的性能和可擴展性。例如，支付應用的消息由支付應用程序產生，並存儲在支付數據庫中，而其它應用所產生的消息也分別在各自的數據庫中。其缺點是，這種實現方式高度依賴公司內部的數據庫，不具備可移植性，以及和外部企業的互操作性。這也真是作為架構所要做的權衡，鑒於公司更換數據庫的可能性不大，和企業外部通信業基本不會用MQ的方式，所以最後還是選擇了用自己開發的輕量級、分布式的消息中間件。
論基於**體係結構的軟件開發。ABSD ( Achitecture Based Software Design)
體係結構設計6個過程：
架構需求 （1.滿足業務上的功能性需求； 2. 同時，還要獲得軟件質量屬性，滿足一些非功能需求）
架構設計（選擇合適的架構風格很重要。架構設計是一個迭代的過程。）
架構文檔化（文檔要從使用者的角度進行編寫，主要輸出結果是體係結構規格說明書和測試體係結構需求的質量說明書）
架構複審（每次迭代要安排一次由外部人員（用戶代表和領域專家）參加的複審，搭建一個可運行的最小化係統用於評估和測試架構是否滿足要求）
架構實現
架構演化。
論軟件安全性設計：
Https 對 login 和 敏感信息進行安全保障。公鑰，私鑰。
session管理：
sessionId被保存在cookie中，如何防止用戶偽造sessionId，用HMAC-SHA1對其進行加密/解密，密鑰是periodical的
SOA Security：
使用SSL確保通信安全。
需要API userName， Password（知道什麼）。
（擁有什麼）：
- Signature（簽名）
- File-based Certificate（文件證書）
最後更新：2017-04-02 15:15:16