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