一 soa架構
'支持海量的併發'
互聯網的發展趨勢
######單機時代
lnmp -->所有的服務都在一臺機器上,是'單機時代','所有的雞蛋放大一個籃子裏面'
######集羣時代
特點：把單機的服務做了拆分
linux：CDN *2('回源')
linux0: nginx *2
linux1：httpd+php *5(session共享)
linux2：mysql *2(主從複製和高可用)
問題1：'性能不夠'或者單點故障,多臺服務器('高可用架構')-->5個服務器('nginx作爲負載均衡提供訪問入口')，解決用戶訪問的問題
問題2：用戶上傳圖片,不可能有的web服務器有上傳圖片,有的web服務器沒有
解決：共享存儲,用分佈式存儲('ceph'和'GFS'以及'MFS')
##分割線
問題3：集羣要解決session共享問題
方案1：'寫到數據庫中',公用一個數據庫就解決了-->'wordpress','discuss論壇'
方案2：'以文件形式存在',需要把文件所在共享目錄共享出來
##分割線
服務器數量多-->意味着用戶量上來了-->數據庫的I/O性能會變差！
'數據庫瓶頸'：把IDE硬盤換成固態硬盤,增加讀寫性能,能緩解下
進一步'緩存'：加緩存(redis實現,用哨兵做高可用)
數據庫會成爲最終的瓶頸--->進一步緩解-->'讀寫分離','分庫分表'的手段
問題：'業務耦合'
######SOA時代
以前是服務的拆分,現在是'業務的拆分'
'秒殺的業務-->有上面所有的結構,數據庫的表(此時只需要10個)'-->只跑某一個'功能'
'優惠券業務'-->也有上面完整的集羣結構
'京東的二級域名',已經快突破兩位數(max-99),業務'完全拆分'
以前500張表(所有的業務),現在10張表(每個業務)
需求1：使用了秒殺不能用優惠券
事務：'銀行卡轉賬'
A 1000
B 5000
B給A轉1000 --->B - 1000;A + 1000 -->B轉玩錢突然停電了(A沒有增加) ,B肯定不願因了！
'B轉錢和A增加錢是一個整體',不能滿足則回滾,到賺錢前的狀態！
'同一個庫''不同的表'可以實現'事務的一致性'
'不同庫的不同表'不能實現'事務的一致性' --->用'消息隊列'來解決
消息隊列
功能之一：完成事務的'一致性',還有其他的功能
消息隊列的功能：在'SOA架構上'實現'數據的一致性'
#######如何完成事務的的'一致性'
'場景'：用戶買東西,從'錢包'扣錢,由於使用了優惠券,所以會少扣錢
'重點'：涉及多業務之間的相互調用問題,這個步驟不可能一下完成,需要分別完成,'完成的進度'都在'寫在消息隊列裏面',只要這個事情'沒有最終完成就回滾'-->'開發寫代碼來實現的'
跨網站的登錄問題
需求：登錄一個網站,在其他網站也是登錄的--->'授權中心(登錄認證)'
每次在'授權中心登錄',那麼登錄其他相關聯的業務網站就認爲'已經登錄了'
SOA解決的問題
## SOA解決的問題
'面向服務的架構'（SOA）是一個組件模型
授權中心：'完成中心登錄認證,token(令牌),授權中心完成令牌的分發'
消息隊列：'完成事務的一致性'
二 openstack架構
openstack是'基於soa架構'的
############分割線
keystone：'授權中心'-->認證服務
glace： '鏡像服務'-->創建雲主機你得有一個模板,不可能當前裝系統,提前裝好系統,做成模板-->管理模板
nova： '計算服務'-->提供'雲主機的'
neutron: 爲計算服務提供'網路服務'-->雲主機是否能上網('內網和外網'),用的電信或者聯通
cinder: 存儲服務-->雲主機用着用着,硬盤不夠,需要擴硬盤-->專門管理塊存儲
horizon: 'web界面'--->可視化這麼多服務,操作特別不方便,提供一個web界面,點一點就可以創建雲主機
以上'最簡單的'6個服務
補充
既然是soa架構,每個服務都有'自己的數據庫,緩存'
由於'服務器資源比較緊張',每個服務的數據庫放在一個裏面
原理圖
補充說明
## 新版本的openstack把下面三個去掉了
Heat： 編排去掉了;不習慣它的'語法',手動啓
Cellometer: openstack定位'私有云',不租給別人,不收自己錢,不用監控了;多一個服務多資源'
Swift: '對象存儲';私有云不使用了
