這是現職的產品架構圖
其實這不算是我規畫的架構，勉強算是補救回來的架構
原本的架構圖是下面這張
比對一下可以知道
1.原本的沒有做load balance
2.沒有HA
3.功能沒有做分散式切割
4.沒有備份機制
修了一段時間之後，勉強解決一些問題
但實際上還是有一些問題需要處理
只能慢慢改進…
想想，能翻掉重來的話還是好事….
Month11 月 2015
某前公司做類似大數據的系統架構概圖
LB由LVS進行(預計，但實際上沒做)
WEB分為抓取數據資料一台
WEB網頁呈現一台
資料收集完後不採用資料庫的方式進行儲存
改由分散式儲存系統(DFS)進行儲存，使用的為MooseFS(簡稱MFS)
網路架構為同一層網段，用分散式設計進行
其中還有進行Indexs索引建立的Server，後台管理的Server，編輯用Server等
就不一一列出，需要功能配合時再增加Server
算是比較特殊的用法，不採用資料庫的大數據
中間當然遇過許多問題，從LVS模式、MFS的CHUNK格式等等
還有儲存空間的格式化問題，inode爆掉等等
就不一一說明了
系統原本採用apache+tomcat7
在進行優化時測試使用 nginx+resin
效果也不錯，但之後的更新我就不清楚了
當然這套系統還是在運作當中~
https://aws.amazon.com/tw/solutions/case-studies/unalis/
這是現職的工作當中
因採用AWS架構而申請上去的案例
其中 Unicloud 的部分，是由我規劃調整的
當然這是一套不完善的系統
正常的資料數據分析應該是由EMR之類的服務去設計
當然希望有時間的時候可以改善這部分
AWS的ELB
與正常的硬體設備不同
假使有 A 與 B 兩台Server
通常負載平衡會擇一導流
例如 User1 => A User2 => B
但AWS ELB 則是
User1 => A+B (各50%)
在公司測試SSO登入的時候就卡到這個問題
登入的資料存在A 但是LOGIN導到B，導致無限迴圈
所以要修改一下設定
修改LBCookies 設定多一個60秒
可以選擇程式的Cookie，或是ELB自己的Cookie
如果是程式的，就不用指定時間
ELB本身的話就需要設定時間
這樣子流量就可以固定導給一台server
參考資料
http://docs.aws.amazon.com/zh_cn/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html
© 2024 Kila's IT Home
Theme by Anders Norén — Up ↑
近期留言