#
、性能要求：
Ø 支持同時在線用戶量（訪問網(wǎng)站頁面）：10000人以上；
Ø 支持并發(fā)量：5000；
Ø 高峰負載時的平均響應時間（指每秒并發(fā)訪問在4000以上）：
u 頁面訪問時間（用戶實測）：1-5秒；
u 運行操作類響應時間（用戶實測，50000個用戶量）：1秒-10秒。
Ø 日常運行時的平均響應時間：
u 頁面訪問時間（用戶實測）：1-3秒；
u 運行操作類響應時間（用戶實測，100000個用戶量）：1秒-6秒。
Ø 有效運行時間：
u 7x24小時：99%；
u 每年因系統(tǒng)本身問題導致的宕機次數(shù)：≤4；
u 因系統(tǒng)本身問題出現(xiàn)故障時的恢復時間：≤24小時。
這種要求有人能做得到嗎？
和老外聊天，會發(fā)現(xiàn)How do u do的搭訕out了。分享我常聽到的：
借助情境What do u think of that book?/Looks like a great drink.What is it?
贊美I like ur posture.It makes u stand out nicely./Nice dress.Where did u get it?
天氣It's so cold today./It's freezing!Do u know the temperature? (Pic)
摘要: 在項目開發(fā)過程中，應該按要求編寫好十三種文檔，文檔編制要求具有針對性、精確性、清晰性、完整性、靈活性、可追溯性。
閱讀全文
1、Web層
主體架構可以基于 Struts 1.X/2.X，當然有很多更好的控制層框架供選擇，以快速敏捷為準則吧。
抽象出核心庫封裝 控制器和中間層的操作。
在大規(guī)模集群環(huán)境下，session復制會引起嚴重的性能問題。考慮用 集群緩存 + cookie驗證 代替session實現(xiàn)權限控制吧。
2、Cache層
配置 Memcache 組成集群緩存
對 Memcache 客戶端進行封裝
Memcached 節(jié)點組成池，調用示意：opList (BizName, 策略 ...)
3、中間層
“中間層”可以理解為基于應用和數(shù)據(jù)之間的層次。它被設計用來為Web應用提供：數(shù)據(jù)緩存 和 對應用透明的數(shù)據(jù)訪問——即應用不需要考慮數(shù)據(jù)表拆分的問題。以服務的方式提供對存儲層的高性能調用以及分布式計算。可供選擇的框架：ICE 、Hadoop 直接基于Memcache開發(fā)（減少復雜度，推薦）
4、存儲
推薦MySQL，理由：免費，經(jīng)過實踐檢驗，有大量成熟的案例、解決方案、技術支持。
小規(guī)模：一個 data table 維護存儲服務器陣列，內容 -> mount ……
大規(guī)模：Master-Slave模式+MySQL Proxy，實現(xiàn)數(shù)據(jù)庫讀寫分離。在中間層的包裝下，可做如下擴展，以支持更大規(guī)模的數(shù)據(jù)存取：
數(shù)據(jù)庫/表水平拆分，例 User -> User33% + User33% + User34%
數(shù)據(jù)庫/表垂直拆分，例 User -> UserBaseInfo + UserAddrInfo
也可考慮使用 LongStore (龍存) 解決方案，由龍存管理存儲陣列……
5、部署
劃分子域名，每個子域名一個Web應用包，互不干擾
靜態(tài)資源（css, js, image ...）使用專門的靜態(tài)服務器
6、負載均衡
小規(guī)模：DNS輪詢。
大規(guī)模：F5， 2*X 臺F5服務器，F(xiàn)5是L4/L7層交換機，每臺至少可處理200萬連接（與服務器內存有關）。
Ngnix是L7層交換，LVS負載均衡也是一種方案
7、Web中間件選擇
Tomcat - 最高400并發(fā)
Apache - 最高2000并發(fā)
Ngnix - 優(yōu)于Apache
采用方案：Ngnix + Resin ，理由：
Resin提供更為快速的servlet引擎 - 選擇Resin。
gzip問題 - Resin在單獨處理gzip時存在內存溢出的隱患，因此要加一層 Ngnix。
Ngnix 能減少單獨使用Resin時的內存占用 - Resin建立1000個連接使用1000個線程；加Ngnix后，透過其“異步連接”、“建立長連接”機制使Resin內存壓力大大減小。
Ngnix 針對Linux系統(tǒng)有性能優(yōu)化措施 - 0 Copy, send file ...
因此采用：1 Ngnix + 1 Resin，一對一。
靜態(tài)服務器采用：Squid + Apache, why? because Squid has cache ability ...
新變化 - Nginx從0.7.48版本開始，支持了類似Squid的緩存功能。這個緩存是把URL及相關組合當作Key，用md5編碼哈希后保存在硬盤上，所以它可以支持任意URL鏈接，同時也支持 404/301/302 這樣的非200狀態(tài)碼。雖然目前官方的Nginx Web緩存服務只能為指定URL或狀態(tài)碼設置過期時間，不支持類似Squid的PURGE指令，手動清除指定緩存頁面，但是，通過一個第三方的Nginx模塊，可以清除指定URL的緩存。
Nginx的Web緩存服務主要由proxy_cache相關指令集和fastcgi_cache相關指令集構成，前者用于反向代理時，對后端內容源服務器進行緩存，后者主要用于對FastCGI的動態(tài)程序進行緩存。兩者的功能基本上一樣。
最新的Nginx 0.8.31版本，proxy_cache和fastcgi_cache已經(jīng)比較完善，加上第三方的ngx_cache_purge模塊（用于清除指定URL的緩存），已經(jīng)可以完全取代Squid。有的網(wǎng)站已經(jīng)在生產(chǎn)環(huán)境使用了 Nginx 的 proxy_cache 緩存功能超過兩個月，十分穩(wěn)定，速度不遜于 Squid。
在功能上，Nginx已經(jīng)具備Squid所擁有的Web緩存加速功能、清除指定URL緩存的功能。而在性能上，Nginx對多核CPU的利用，勝過Squid不少。另外，在反向代理、負載均衡、健康檢查、后端服務器故障轉移、Rewrite重寫、易用性上，Nginx也比Squid強大得多。這使得一臺Nginx可以同時作為"負載均衡服務器"與"Web緩存服務器"來使用。以下是配置片段供參考：
view plaincopy to clipboardprint?
http
{
...
client_body_buffer_size 512k;
proxy_connect_timeout 5;
proxy_read_timeout 60;
proxy_send_timeout 5;
proxy_buffer_size 16k;
proxy_buffers 4 64k;
proxy_busy_buffers_size 128k;
proxy_temp_file_write_size 128k;
...
#注：proxy_temp_path和proxy_cache_path指定的路徑必須在同一分區(qū)
proxy_temp_path /data0/proxy_temp_dir;
#設置Web緩存區(qū)名稱為cache_one，內存緩存空間大小為200MB，1天清理一次緩存，硬盤緩存空間大小為30GB。
proxy_cache_path /data0/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g;
}
server
{
...
location /
{
#如果后端的服務器返回502、504、執(zhí)行超時等錯誤，自動將請求轉發(fā)到upstream負載均衡池中的另一臺服務器，實現(xiàn)故障轉移。
proxy_next_upstream http_502 http_504 error timeout invalid_header;
proxy_cache cache_one;
#對不同的HTTP狀態(tài)碼設置不同的緩存時間
proxy_cache_valid 200 304 12h;
proxy_cache_valid 301 302 1h;
#以域名、URI、參數(shù)組合成Web緩存的Key值，Nginx根據(jù)Key值哈希，存儲緩存內容到二級緩存目錄內
proxy_cache_key $host$uri$is_args$args;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://backend_server;
expires 1d;
}
#用于清除緩存，假設一個URL為http://192.168.1.44/test.txt，通過訪問http://192.168.4.44/purge/test.txt就可以清除該URL的緩存。
location ~ /purge(/.*)
{
#設置只允許指定的IP或IP段才可以清除URL緩存。
allow 127.0.0.1;
allow 192.168.0.0/16;
deny all;
proxy_cache_purge cache_one $host$1$is_args$args;
}
#擴展名以.php、.jsp、.cgi結尾的動態(tài)應用程序不緩存。
location ~ .*\.(php|jsp|cgi)?$
{
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://backend_server;
}
}
同時，對于影響頁面展現(xiàn)的靜態(tài)資源，例如：css, js 等可以放在具有優(yōu)質帶寬的IDC（IDC=互聯(lián)網(wǎng)數(shù)據(jù)中心，優(yōu)質/高速的帶寬也比較貴，正所謂一份價錢一分貨）；其他的靜態(tài)資源，如圖片等可以放在價格相對低廉的IDC中，以域名區(qū)分兩種靜態(tài)資源，節(jié)省每一分錢。
8、網(wǎng)絡拓撲圖
/ Ngnix - 1:1 - Resin
F5 --
\ Squid - 1:n - Apache
9、監(jiān)控統(tǒng)計平臺
業(yè)務統(tǒng)計 - 用戶訪問統(tǒng)計
軟件性能 - 應用系統(tǒng)監(jiān)控，例如：請求響應時間……
硬件/網(wǎng)絡性能 - Ganglia監(jiān)控
10、其它要點
IE瀏覽器對同一域名（包括子域名）只能建立2個連接，連接多了只能排隊……
雙F5架構，兩臺職能劃分不同，鏡像，心跳接管……
Raid存儲陣列……
Linux操作系統(tǒng)及其優(yōu)化……
案例
項目里有個LEADER， 我跟這個LEARDER 做了1年了，合作還算愉快。
----------------------------------
兩邊都不得罪，其實就是得罪兩邊。
--------------------------------
后來最近半年新來了個PM。這時有個新項目，LEADER建議在現(xiàn)有的項目上改，新PM打算重新設計。兩人各執(zhí)己見，一時無法決定。而我是這個新項目的重要CODER，自然我成了拉攏的對象。很難抉擇該怎么站隊。
LEADER算地頭蛇，PM則是新官上任三把火。我是個新來的程序員，如何在這場權利的爭奪中站對啊？怕誤傷，誤殺啊。
堅定的支持leader啊 搞走PM leader升PM
你升leader
慢慢來吧，小伙，與人斗其樂無窮
-------------------------------
這種方法一般程序員也干不了。
兩不靠需要很好的掌握平衡，否則后患不少，不過反正你新來，可以走，也可以調。
選邊的話，需要你花心思了，琢磨人的心思，還要設局。個人覺得對你難度太高。選邊的另外一種辦法是選定一個，無原則支持，但是你是新來的，有這么深厚的默契嗎？
還有一個角度：你有沒有能力去協(xié)調雙方？
---------------------------------
改善非功能需求的最佳實踐冗余負載均衡
方式有網(wǎng)絡切換、集群管理、基于DNS配置的切換
算法有隨機算法、選擇響應時間最快的算法、選擇負載最輕的算法、重型算法
失敗轉移
集群
將服務器組成一組，來統(tǒng)一進行管理，檢測軟、硬件的失敗，處理系統(tǒng)的失敗轉移，自動因失敗事件而重啟
集群配置方式
兩節(jié)點集群、集群對、Ring、N+1、N to N
改善性能性能有兩個關鍵點：
處理時間，從計算、數(shù)據(jù)調度、緩存和網(wǎng)絡傳輸
阻塞時間，來源于資源競爭和另一流程的依賴
處理措施使用好的算法或適用的技術
引入并行計算、限制并發(fā)請求以避免系統(tǒng)過度使用、TIME OUT措施
高可用可用是指隨時才能訪問，不能訪問的原因是硬件、網(wǎng)絡、服務器軟件、和應用組件的失敗；
如果一個應用組件不能提供足夠快的響應時間也是指不可用了，這是指系統(tǒng)正常運行情況下，由于正在同時處理很多任務而導致的延時。
改善措施集群中的復制，有活躍式的復制：發(fā)給所有節(jié)點，節(jié)點都同時進行運算，但只采用其中一個作為響應；被動式的復制，只有主節(jié)點響應請求，其他節(jié)點與主節(jié)點同步。
擴展性改善擴展的原因通常是因為需求的變更。最重要的目標是改善系統(tǒng)開發(fā)以適應快速的變化。
可采取的方法有：定義清晰的范圍、預知可能的變更（如果界面技術，隔離這一區(qū)域使其不能波及到其他地方）、使用高質量的對象模型（使用MVC模式來解耦界面組件和業(yè)務組件）
伸縮性的改善垂直伸縮：增加處理器或內存等，對系統(tǒng)是透明的；
水平伸縮：增加服務器，必須避免對服務器物理位置的依賴。
架構中的層
兩層結構的系統(tǒng)指C/S架構的程序。通常指包含了展示和業(yè)務邏輯的客戶端和服務器上的數(shù)據(jù)庫。展示和業(yè)務邏輯緊密結合。
優(yōu)點安全是一點，由于這些系統(tǒng)是位于防火墻后面，員工不能使用不安全的的PC。性能通常比較好，如果公司不使用比較老的很少內存的電腦的話。
缺點可用性是一個缺點，因為如果一個元件不能工作的時候，整個系統(tǒng)就變得不可用。
伸縮性是一個問題，由于維一能夠增加的元件是數(shù)據(jù)庫。
為了能增加新功能，你很明顯會影響到其他元件，擴展性不行。
可管理性也是一個問題，監(jiān)控所有正在運行客戶端的PC是不可能的。
可維護性和可擴展性一樣。
可靠性不是一個優(yōu)點或缺點，由于請求增加時，所有的這些請求來到數(shù)據(jù)庫，所有的數(shù)據(jù)庫能處理增長的交易吞吐量。
三或多層架構的系統(tǒng)三層架構由WEB，業(yè)務邏輯和資源層組成。多層架構的系統(tǒng)有WEB，業(yè)務邏輯，整合和資源層。在非功能需求方面，三層和多層架構的系統(tǒng)擁有相同的優(yōu)點和缺點。
優(yōu)點當將展示層邏輯從PC客戶端移到服務器端，而能被集群時，伸縮性被改善了。
由于集群層能夠提供失敗轉移機制，可用性也有所改善。
由于功能被分解到不同的層中，擴展性也有所改善。你可以更改表現(xiàn)層又能使得對業(yè)務邏輯影響最小。
對于可維護性也是這樣。
由于各層是部署在服務器上，使得監(jiān)控各個元件變得更容易，這樣可管理性也提高了。
分層對于安全性可以做得更多，但必須小心對性能造成影響。
性能可能是優(yōu)點或缺點。主要還是優(yōu)點，當分割線程到各服務器上時，如果你要在服務器間傳送大數(shù)據(jù)時，這時可能會變成缺點了。
缺點多層系統(tǒng)原生是比較復雜，多層架構的系統(tǒng)其實是沒有所謂的缺點。雖然這樣說，并不會由于你有了多層設計，你就有了很好的架構。必須記得不要過度使用層數(shù)。
小結
架構是一系列的使得系統(tǒng)能夠由一組具有自己的上下文的簡單的子系統(tǒng)組成的結構規(guī)則。
性能是指系統(tǒng)的響應時間，如必須在3秒內響應。
伸縮性是指當訪問量增加時可以增加冗余的組件，部署到增加的服務器上時，原系統(tǒng)無須作更改。C/S結構的系統(tǒng)，由于系統(tǒng)安裝在客戶端，就不能作這種伸縮。
擴展性，是指增加或修改功能時對現(xiàn)有的系統(tǒng)不會構成影響。如MODEL1的情形，系統(tǒng)沒有分層，所有代碼混在一起，更改時會互相影響。
可靠性，是指訪問量增加的時候，事務有保證。通常數(shù)據(jù)庫對增加的請求，事務的保證方面已經(jīng)是有所處理了。
可用性，是指系統(tǒng)中的某個元件失敗時，系統(tǒng)還能訪問。如果是C/S架構的系統(tǒng)，無法分層，某個元件出現(xiàn)問題時，系統(tǒng)就不可用了。
可維護性，是指調整現(xiàn)有的系統(tǒng)流程，不會影響到其他元件。
可管理性，是指能監(jiān)控系統(tǒng)伸縮能力，可靠性，可用性，性能和安全。
安全性，是指系統(tǒng)能夠阻擋非法訪問。
| 云計算技術簡介 |
云計算技術概述，大數(shù)據(jù)時代來臨，Google云計算技術，Amazon云計算技術，微軟云計算技術等。 |
| 初始Hadoop |
Hadoop的起源、解決的問題、
以及它的特點、應用場景和發(fā)展趨勢，企業(yè)應用情況，為什么使用，及其生態(tài)系統(tǒng)介紹。 |
Hadoop
單節(jié)點偽分布式安裝 |
Hadoop
1.0 版本 安裝環(huán)境搭建 |
Hadoop
架構 |
Hadoop
整體架構設計及重要的概念 |
Hadoop
HDFS 體系結構 |
1：HDFS
架構設計目標，設計思想，
2：特點，基本概念，容錯性。
3：HDFS
界面介紹
4：HDFS
服務 |
Hadoop
HDFS 命令行 |
Hadoop
HDFS Shell 基本操作 |
HDFS
Java API 使用 |
1：基于Eclipse開發(fā)環(huán)境搭建
2：Java
API示范 ：比如建立文件，刪除，移動復制等 |
Hadoop
MapReduce 架構 原理 |
1：MapReduce 架構詳解
2：MapReduce
流程
3：MapReduce
特點
4：MapReduce
容錯性
5：MapReduce
服務 |
Hadoop
MapReduce api |
1：Mapper
2：Reducer
3：Driver |
Hadoop
MapReduce 編程實踐 wordcount |
1：WordCount
程序編寫，演示
2：運行MR
Job 示例 |
高級MR
編程 |
1：RecordReader
2：Partitioner
3：Combiner |
Hadoop
MapReduce IO |
1：數(shù)據(jù)完整性校驗
2：壓縮，包括：LZO、GZIP、Snappy
3：序列化
4：基于文件的數(shù)據(jù)結構，包括：SequenceFile、MapFile |
| 調優(yōu) |
調優(yōu)經(jīng)驗分享 |
課程中的HBase部分：
掌握HBase基本原理，應用場景，掌握基本的編程技巧
| 章節(jié)課程 |
內容描述 |
| 初始HBase |
1：NoSql
數(shù)據(jù)庫簡介.
2：HBase
簡介及與傳統(tǒng)關系數(shù)據(jù)庫的對比。
3：HBase
應用場景，企業(yè)應用情況，為什么使用。
4：HBase
特點 |
HBase
環(huán)境搭建 |
HBase
環(huán)境搭建 |
HBase
體系結構 |
1：HBase架構
2：HMaster、RegionServer、 Regoin 等概念 |
HBase
數(shù)據(jù)模型 |
1：表
2：Rowkey
3：Column
Families |
HBase
Shell 命令行 |
1：啟動HBase
Shell
2：建立表
3：訪問數(shù)據(jù)（添加，刪除，查詢）
4：練習 |
HBase
api 簡單編程介紹 |
1：基于Eclipse開發(fā)環(huán)境搭建
2：基本操作（建表，查詢數(shù)據(jù)，刪除）
3：高級操作
（使用過濾器）
4：練習 |
HBase
row-key 設計及Scheme 設計 |
經(jīng)驗分享，設計原則 |
HBase
coprocessor等高級特性介紹 |
1：coprocessor特性分析，使用場景；
2：HBase
優(yōu)化簡單原則 |
課程中的Hive部分：
掌握Hive基本原理，應用場景，掌握基本的編程技巧
| 章節(jié)課程 |
內容描述 |
| 初始Hive |
1：Hive簡介
2：為什么使用Hive
3：Hive
應用場景，企業(yè)應用情況 |
Hive
環(huán)境搭建 |
Hive
偽分布式環(huán)境搭建 |
Hive
體系結構 |
1：Hive主要的組件
2：用戶接口
3：概念 |
Hive
QL |
1：Hive
類Sql
2：DDL
3：DML
4：Select
與連接查詢 |
Hive
Java API |
1：搭建
Hive JDBC 開發(fā)環(huán)境
2：Hive
JDBC 開發(fā)流程 |
Hive
用戶自定義函數(shù)簡單介紹 |
UDF和UADF |
課程中的分布式協(xié)調系統(tǒng)Zookeeper部分：
掌握Zookeeper基本原理，應用場景，掌握基本的編程技巧
| 章節(jié)課程 |
內容描述 |
| 初始Zookeeper |
1：什么是ZooKeeper
2：ZooKeeper特性 |
Zookeeper
體系結構 |
1：ZooKeeper體系結構
2：ZooKeeper存儲結構 |
Zookeeper
選舉與鎖機制 |
1：Zookeeper
選舉機制
2：Zookeeper
選舉算法
3：Zookeeper
鎖機制 |
ZooKeeper
CRUD API |
1：Create
2：Read
3：Update
4：Delete |
| Zookeeper
應用場景 |
Zookeeper
應用場景 |
最近公司要上一個新項目。可能要整合以前的一些系統(tǒng)。現(xiàn)在考慮是用esb企業(yè)總線進行管理。初步定的是wso2。基于apache synapse。
1.一般的esb流程是什么樣子的？
是不是主系統(tǒng)發(fā)生soap請求。esb接收并且轉換成jms然后子系統(tǒng)監(jiān)聽jms。最后得到數(shù)據(jù)。
還是。jms僅僅是內部轉換。soap請求在esb轉成jms后。加入隊列。然后再轉成soap調用子系統(tǒng)？
2.使用jms的考慮是jms對隊列的信息進行持久化。防止比如子系統(tǒng)突然掛掉了。消息丟失。
但是有個問題。是esb自動監(jiān)聽jms的隊列的話。會導致直接消費了。而數(shù)據(jù)沒有存在隊列中。還是會出現(xiàn)消息丟失的問題。
這個應該怎么解決。
3.esb進行協(xié)議之間的轉換。每種方式都需要些一個轉換方式么？有沒有什么通用的。或者是自動轉換的。比如soap和jms的互相轉換。不是協(xié)議切換。是內容轉換。
4.如果大家有討論esb的群。或者有高手愿意指點一下。謝謝了。
------------------------------------------------------------------
1，一般ESB的流程，
先是整理需連接的系統(tǒng)，需要連接的系統(tǒng)功能(一般管它叫服務)，確定服務的依賴關系，支持的協(xié)議(文件，WebService, RPC,...),調用的方式(同步/異步)
然后使用ESB提供的那些協(xié)議組件，一點點串起來就行。串的方式可以參考EIP (www.eaipatterns.com)
你說的兩種異步方式的話都可以，
如果是同步的，也可以直接soap -> soap, 不用JMS。 一般用JMS是為了實現(xiàn)異步通訊
2，JMS，至少我接觸的ActiveMQ， 是可以支持事務的，發(fā)生異常，可以不消費信息
3，協(xié)議轉換是為了配合你那些需要整合的系統(tǒng)，如果都是SOAP，也就不需要轉了。
消息內容轉換(格式，內容)，一般ESB都提供各種工具的。
------------------------------------------------------------------
1、如果你要做同步轉異步，可以在esb上做成ws轉jms，然后起到一個緩沖的作用。
最后可以再同步的返回給調用方。
你也可以修改調用方為jms方式，這樣就是徹底的異步了，在esb端可以jms轉ws，調用業(yè)務服務方的ws。
2、esb都支持事務的，jms中如果不確認消息的話，不會從持久存儲去delete掉的。
一般的esb。也可以做成是esb消費掉消息，然后存入esb自己內置的jms provider中，這樣你再消費的話，也是可靠的。還可以做成補償機制的，即esb中如何消息處理失敗，把消費放回去原來的queue或是一個中間的臨時queue，稍后做recover。
3、從esb的不同transport進去的數(shù)據(jù)，在esb的中介層處理時，其實消息格式都是一致的、通用的。也就是說常見的ws或jms轉換在一般的esb里處理都很簡單。如果稍微復雜點，也很容易擴展transformer（比如通過xslt做xml格式轉換）來實現(xiàn)數(shù)據(jù)內容和格式的轉換。