分布式架构设计之基础软件系统架构
分布式架構設計之基礎軟件系統架構
原創文章來之不易，轉載請注明出處：
http://blog.csdn.net/why_2012_gogo/article/details/74137631
一個好的系統架構需要從三方面進行設計：首先，我們必須明確系統的整體需求功能是什么，進而再對這些需求分模塊以及構建模塊間的交互設計，同時要明確相關技術的選型；然后，針對物理節點上的拓撲結構是必不可少的，比如：Web Server的負載分發、數據的集群等，這部分是屬于架構的“硬實現”部分；最后，就是整體的軟件系統的設計，這部分是整個系統架構的“軟實現”，主要從系統內部軟件系統角度實現設計，比如：基礎通信服務、數據安全服務等。對于前兩者的設計，讀者可以參考上一篇文章《分布式架構設計之電商平臺》中提到的業務架構和物理拓撲角度的設計，而這里主要介紹的是軟件層面的技術架構設計。好了，還是和往常一樣，對于架構的設計，這里不做細節的實現介紹（讀者可參考相關資料學習），只介紹核心的技術實現點。
?
l? 體系架構
l? 注意事項
l? 總結小序
?
?
一、體系架構
本部分為通用的軟件整體架構設計，至于不同行業的軟件架構設計是不同的，基礎部分均可在此基礎上進行拓展設計，而拓展部分與行業緊密相關。這里我主要從八個部分來介紹軟件的整體架構設計、各部分的實現機制及相關的技術選型。
?
1、基礎通信（Basic Communication Service）
基礎通信是整個系統軟件的通信機制，主要支持長短連接兩種類型，其通信協議分別為基于TCP和基于HTTP的通信。對于Java語言環境，我們一般選用Nio或是Netty來實現，而后者就是普遍使用的HTTP通信。
?
上面是基礎實現部分，可以滿足多線程并發訪問的需求，而如果想要以消息驅動并可監控執行線程次序的方式實現軟件通信的話，我們可選用MQ技術實現，但需要注意的是MQ的即時和非即時通信的區別實現。
?
2、API通信(RestfulAPI)
這里的API指的是供前端調取，并渲染其返回數據的接口服務。在這里，我個人建議采用獨立的API服務，并且基于Rest風格的資源定位進行API設計，大大提高API的通用和拓展。如果可以的話，我們也可以自行實現或約定通信規則，定義自己的通信協議，采用目前高性能的數據格式。這里以json數據為例，我們可以選用阿里開源的fastjson，也可以選用谷歌的protobuf等數據格式，作為通信內容的載體協議格式，他們都具備易用，高性能的特性。
?
3、安全處理(Security)
軟件的安全處理是一個很重要的部分，如果未作安全防護或是防護出現漏洞，那么面臨的就是資金、信息的流失，造成不可彌補的損失。所以，一個合理的架構設計，其中必有一安全處理的模塊，專門處理相關安全的問題。
?
軟件安全處理，一般包含自定義處理和安全框架處理。前者主要是我們自行對敏感或重要的數據進行加密處理，比如：md5和base64等。后者則是引用市面開源的安全框架，比如：Spring Security，雖然存在相關的漏洞，但可以解決很多系統漏洞，并且我們都會有針對性的優化漏洞問題。
?
4、業務服務(Business Service)
顧名思義，該層主要負責業務邏輯的計算實現，并與數據訪問層溝通，實現業務數據到緩存及持久化存儲介子中。當然，一般第三方的服務也可以包含在這里，并與系統原生的服務區分開來。
?
5、數據訪問(Data Access Service)
數據訪問層，主要是用來處理業務層的業務數據，并將該業務數據存儲到RDBS介子中的通道，它不負責業務邏輯，只負責與數據庫API接口對接，一般被稱之為DAO層。
?
6、文件日志（CSV/Log）
這里的文件日志比較簡單，指的是程序或是業務操作產生的日志信息，報表數據等，它與下面的緩存數據及數據存儲共同構成龐大的“數據中心”，主要供在后續的大數據分析使用。需要說明的是，日志信息的搜集并非業務操作，需要與程序軟件流分離開來，不要阻塞主程序流的執行，比如：在Spring中，一般使用Aop技術實現。
?
7、緩存機制(Cache Data)
緩存機制，是軟件架構設計必不可少的環節，它一般用來緩解關系型持久化數據庫的IO壓力而來，也有用在某些業務數據的持久化存儲方面，比如：Redis、Memcached及Mongo等。而對于大數據方面，Redis和Mongo的使用比較多，當然也需要結合HBase、Hive及Hadoop等一同完成大數據的搜集和分析工作。另外，分布式軟件架構中，我們必須考慮到緩存的集群搭建。
?
8、數據存儲(RDBS)
數據存儲，目前一般指的是關系型數據存儲，如：Mysql、Oracle等，而現在流行的非關系型存儲機制，如：Redis、Mongo等，一般只用在緩存的場景，持久化方面，也局限在某些數據領域。而我個人也建議，將某些非敏感數據和配置數據存放在非關系存儲介子中。當然，RDBS也必須考慮主備、集群的設計，以便適應分布式系統的需求及高并發訪問帶來的壓力沖擊。
?
?
二、注意事項
這里談到的注意事項，主要包括兩方面，分別為分布式相關和大數據相關。那么，具體內容如下：
?
1、分布式相關
第一部分主要介紹的是單機環境下的軟件架構設計，而多機環境的設計，略有不同，主要體現在多機環境的數據同步方面，比如：單點登錄、Session共享及多個RDBS實例的ID序列等問題，而對于多個機器的數據同步問題，我們可以采用Keepalived技術解決，這些方面的設計后續文章中會一一介紹。
?
2、大數據相關
正如第一部分的架構圖所示，橙色部分代表的是“數據中心”，它存儲記錄了所有的數據（業務及程序），完全可以作為后期大數據分析的數據源頭。
?
?
三、總結小序
本篇文章的架構設計，主要指在軟件系統的角度設計，其中包含了基礎通信服務、數據安全、數據中心及獨立API等方面，同時，也提出了在分布式環境及大數據環境的架構引導設計，但只是介紹了架構每個層面的一個點，距離實際設計，還有不少工作要做，這里只是一個方向的引導和某些注意事項的說明。
?
一個軟件架構的設計，并沒有上面架構圖所展示的那么簡單，而這個架構圖設計的背后，隱藏了許多方面的考慮和思索，所以就本文而言，并沒有全面的介紹，需要各位讀者，將此文章作為一個好的引導，慢慢踏進架構師之路。
?
?
?
?
?
?
?
?
?
?
?
由于作者水平有限，如有不正確或是誤導的地方，請不吝指出討論（技術交流群：497552060（新））
?
?
?
?
?
?
?
總結
以上是生活随笔為你收集整理的分布式架构设计之基础软件系统架构的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 加密软件那个好用？国内加密软件排行版
- 下一篇： 运用IPXE技术引导PE系统（CentO