99精品国产一区二区三区不卡,a√资源在线,99re免费视频精品全部

2007年9月25日

API網(wǎng)關(guān)作用、方案及如何選擇

在這篇文章中將我們一起來探討當(dāng)前的API網(wǎng)關(guān)的作用。

一、API網(wǎng)關(guān)的用處

API網(wǎng)關(guān)我的分析中會(huì)用到以下三種場(chǎng)景。

Open API。企業(yè)需要將自身數(shù)據(jù)、能力等作為開發(fā)平臺(tái)向外開放，通常會(huì)以rest的方式向外提供，最好的例子就是淘寶開放平臺(tái)、騰訊公司的QQ開放平臺(tái)、微信開放平臺(tái)。 Open API開放平臺(tái)必然涉及到客戶應(yīng)用的接入、API權(quán)限的管理、調(diào)用次數(shù)管理等，必然會(huì)有一個(gè)統(tǒng)一的入口進(jìn)行管理，這正是API網(wǎng)關(guān)可以發(fā)揮作用的時(shí)候。
微服務(wù)網(wǎng)關(guān)。微服務(wù)的概念最早在2012年提出，在Martin Fowler的大力推廣下，微服務(wù)在2014年后得到了大力發(fā)展。在微服務(wù)架構(gòu)中，有一個(gè)組件可以說是必不可少的，那就是微服務(wù)網(wǎng)關(guān)，微服務(wù)網(wǎng)關(guān)處理了負(fù)載均衡，緩存，路由，訪問控制，服務(wù)代理，監(jiān)控，日志等。API網(wǎng)關(guān)在微服務(wù)架構(gòu)中正是以微服務(wù)網(wǎng)關(guān)的身份存在。
API服務(wù)管理平臺(tái)。上述的微服務(wù)架構(gòu)對(duì)企業(yè)來說有可能實(shí)施上是困難的，企業(yè)有很多遺留系統(tǒng)，要全部抽取為微服務(wù)器改動(dòng)太大，對(duì)企業(yè)來說成本太高。但是由于不同系統(tǒng)間存在大量的API服務(wù)互相調(diào)用，因此需要對(duì)系統(tǒng)間服務(wù)調(diào)用進(jìn)行管理，清晰地看到各系統(tǒng)調(diào)用關(guān)系，對(duì)系統(tǒng)間調(diào)用進(jìn)行監(jiān)控等。 API網(wǎng)關(guān)可以解決這些問題，我們可以認(rèn)為如果沒有大規(guī)模的實(shí)施微服務(wù)架構(gòu)，那么對(duì)企業(yè)來說微服務(wù)網(wǎng)關(guān)就是企業(yè)的API服務(wù)管理平臺(tái)。

二、API網(wǎng)關(guān)在企業(yè)整體架構(gòu)中的地位

一個(gè)企業(yè)隨著信息系統(tǒng)復(fù)雜度的提高，必然出現(xiàn)外部合作伙伴應(yīng)用、企業(yè)自身的公網(wǎng)應(yīng)用、企業(yè)內(nèi)網(wǎng)應(yīng)用等，在架構(gòu)上應(yīng)該將這三種應(yīng)用區(qū)別開，三種應(yīng)用的安排級(jí)別、訪問方式也不一樣。因此在我的設(shè)計(jì)中將這三種應(yīng)用分別用不同的網(wǎng)關(guān)進(jìn)行API管理，分別是：API網(wǎng)關(guān)（OpenAPI合伙伙伴應(yīng)用）、API網(wǎng)關(guān)（內(nèi)部應(yīng)用）、API網(wǎng)關(guān)（內(nèi)部公網(wǎng)應(yīng)用）。

三、企業(yè)中在如何應(yīng)用API網(wǎng)關(guān)

1、對(duì)于OpenAPI使用的API網(wǎng)關(guān)來說，一般合作伙伴要以應(yīng)用的形式接入到OpenAPI平臺(tái)，合作伙伴需要到 OpenAPI平臺(tái)申請(qǐng)應(yīng)用。因此在OpenAPI網(wǎng)關(guān)之外，需要有一個(gè)面向合作伙伴的使用的平臺(tái)用于合作伙伴，這就要求OpenAPI網(wǎng)關(guān)需要提供API給這個(gè)用戶平臺(tái)進(jìn)行訪問。如下架構(gòu):

當(dāng)然如果是在簡單的場(chǎng)景下，可能并不需要提供一個(gè)面向合作伙伴的門戶，只需要由公司的運(yùn)營人員直接添加合作伙伴應(yīng)用id/密鑰等，這種情況下也就不需要合作伙伴門戶子系統(tǒng)。

2、對(duì)于內(nèi)網(wǎng)的API網(wǎng)關(guān)，在起到的作用上來說可以認(rèn)為是微服務(wù)網(wǎng)關(guān)，也可以認(rèn)為是內(nèi)網(wǎng)的API服務(wù)治理平臺(tái)。當(dāng)企業(yè)將所有的應(yīng)用使用微服務(wù)的架構(gòu)管理起來，那么API網(wǎng)關(guān)就起到了微服務(wù)網(wǎng)關(guān)的作用。而當(dāng)企業(yè)只是將系統(tǒng)與系統(tǒng)之間的調(diào)用使用rest api的方式進(jìn)行訪問時(shí)使用API網(wǎng)關(guān)對(duì)調(diào)用進(jìn)行管理，那么API網(wǎng)關(guān)起到的就是API服務(wù)治理的作用。架構(gòu)參考如下：

3、對(duì)于公司內(nèi)部公網(wǎng)應(yīng)用（如APP、公司的網(wǎng)站），如果管理上比較細(xì)致，在架構(gòu)上是可能由獨(dú)立的API網(wǎng)關(guān)來處理這部分內(nèi)部公網(wǎng)應(yīng)用，如果想比較簡單的處理，也可以是使用面向合作伙伴的API網(wǎng)關(guān)。如果使用獨(dú)立的API網(wǎng)關(guān)，有以下的好處：

面向合作伙伴和面向公司主體業(yè)務(wù)的優(yōu)先級(jí)不一樣，不同的API網(wǎng)關(guān)可以做到業(yè)務(wù)影響的隔離。
內(nèi)部API使用的管理流程和面向合作伙伴的管理流程可能不一樣。
內(nèi)部的API在功能擴(kuò)展等方面的需求一般會(huì)大于OpenAPI對(duì)于功能的要求。

基于以上的分析，如果公司有能力，那么還是建議分開使用合作伙伴OPEN API網(wǎng)關(guān)和內(nèi)部公網(wǎng)應(yīng)用網(wǎng)關(guān)。

四、API網(wǎng)關(guān)有哪些競(jìng)爭方案

1、對(duì)于Open API平臺(tái)的API網(wǎng)關(guān)，我分析只能選擇API網(wǎng)關(guān)作為解決方案，業(yè)界沒有發(fā)現(xiàn)比較好的可以用來作為Open API平臺(tái)的入口的其他方案。

2、對(duì)于作為微服務(wù)網(wǎng)關(guān)的API網(wǎng)關(guān)，業(yè)界的選擇可以選擇的解決方案比較多，也取決于微服務(wù)器的實(shí)現(xiàn)方案，有一些微服務(wù)架構(gòu)的實(shí)現(xiàn)方案是不需要微服務(wù)網(wǎng)關(guān)的。

Service Mesh，這是新興的基于無API網(wǎng)關(guān)的架構(gòu)，通過在客戶端上的代理完成屏蔽網(wǎng)絡(luò)層的訪問，這樣達(dá)到對(duì)應(yīng)用層最小的改動(dòng)，當(dāng)前Service Mesh的產(chǎn)品還正在開發(fā)中，并沒有非常成熟可直接應(yīng)用的產(chǎn)品。發(fā)展最迅速的產(chǎn)品是Istio。建議大家密切關(guān)注相關(guān)產(chǎn)品的研發(fā)、業(yè)務(wù)使用進(jìn)展。

基于duboo架構(gòu)，在這個(gè)架構(gòu)中通常是不需要網(wǎng)關(guān)的，是由客戶端直接訪問服務(wù)提供方，由注冊(cè)中心向客戶端返回服務(wù)方的地址。

五、API網(wǎng)關(guān)解決方案

私有云開源解決方案如下：

Kong kong是基于Nginx+Lua進(jìn)行二次開發(fā)的方案， https://konghq.com/
Netflix Zuul，zuul是spring cloud的一個(gè)推薦組件，https://github.com/Netflix/zuul
orange,這個(gè)開源程序是國人開發(fā)的， http://orange.sumory.com/

公有云解決方案：

Amazon API Gateway，https://aws.amazon.com/cn/api-gateway/
阿里云API網(wǎng)關(guān)，https://www.aliyun.com/product/apigateway/
騰訊云API網(wǎng)關(guān)， https://cloud.tencent.com/product/apigateway

自開發(fā)解決方案：

基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于這個(gè)方案
基于Netty、非阻塞IO模型。通過網(wǎng)上搜索可以看到國內(nèi)的宜人貸等一些公司是基于這種方案，是一種成熟的方案。
基于Node.js的方案。這種方案是應(yīng)用了Node.js天生的非阻塞的特性。
基于java Servlet的方案。 zuul基于的就是這種方案，這種方案的效率不高，這也是zuul總是被詬病的原因。

六、企業(yè)怎么選擇API網(wǎng)關(guān)

如果是要選擇一款已有的API網(wǎng)關(guān)，那么需要從以下幾個(gè)方面去考慮。

1、性能與可用性
如果一旦采用了API網(wǎng)關(guān)，那么API網(wǎng)關(guān)就會(huì)作為企業(yè)應(yīng)用核心，因此性能和可用性是必須要求的。

從性能上來說，需要讓網(wǎng)關(guān)增加的時(shí)間消耗越短越好，個(gè)人覺得需要10ms以下。系統(tǒng)需要采用非阻塞的IO，如epoll，NIO等。網(wǎng)關(guān)和各種依賴的交互也需要是非阻塞的，這樣才能保證整體系統(tǒng)的高可用性，如：Node.js的響應(yīng)式編程和基于java體現(xiàn)的RxJava和Future。
網(wǎng)關(guān)必須支持集群部署，任務(wù)一臺(tái)服務(wù)器的crash都應(yīng)該不影響整體系統(tǒng)的可用性。
多套網(wǎng)關(guān)應(yīng)該支持同一管理平臺(tái)和同一監(jiān)控中心。如：一個(gè)企業(yè)的OpenAPI網(wǎng)關(guān)和內(nèi)部應(yīng)用的多個(gè)系統(tǒng)群的不同的微服務(wù)網(wǎng)關(guān)可以在同一監(jiān)控中心進(jìn)行監(jiān)控。

2、可擴(kuò)展性、可維護(hù)性
一款產(chǎn)品總有不能滿足生產(chǎn)需求的地方，因此需求思考產(chǎn)品在如何進(jìn)行二次開發(fā)和維護(hù)，是否方便公司團(tuán)隊(duì)接手維護(hù)產(chǎn)品。
3、需求匹配度
需要評(píng)估各API網(wǎng)關(guān)在需求上是否能滿足，如：如果是OpenAPI平臺(tái)需要使用API網(wǎng)關(guān)，那么需要看API網(wǎng)關(guān)在合作伙伴應(yīng)用接入、合作伙伴門戶集成、訪問次數(shù)限額等OpenAPI核心需求上去思考產(chǎn)品是否能滿足要求。如果是微服務(wù)網(wǎng)關(guān)，那么要從微服務(wù)的運(yùn)維、監(jiān)控、管理等方面去思考產(chǎn)品是否足夠強(qiáng)大。
4、是否開源？公司是否有自開發(fā)的能力？
現(xiàn)有的開源產(chǎn)品如kong，zuul，orange都有基礎(chǔ)的API網(wǎng)關(guān)的核心功能，這些開源產(chǎn)品大多離很好的使用有一定的距離，如：沒有提供管理功能的UI界面、監(jiān)控功能弱小，不支持OpenAPI平臺(tái)，沒有公司運(yùn)營與運(yùn)維的功能等。當(dāng)然開源產(chǎn)品能獲取源代碼，如果公司有比較強(qiáng)的研發(fā)能力，能hold住這些開源產(chǎn)品，經(jīng)過二次開發(fā)kong、zuul應(yīng)該還是適應(yīng)一些公司，不過需求注意以下一些點(diǎn)：

kong是基于ngnix+lua的，從公司的角度比較難于找到能去維護(hù)這種架構(gòu)產(chǎn)品的人。需求評(píng)估當(dāng)前公司是否有這個(gè)能力去維護(hù)這個(gè)產(chǎn)品。
zuul因?yàn)榧軜?gòu)的原因在高并發(fā)的情況下性能不高，同時(shí)需要去基于研究整合開源的適配zuul的監(jiān)控和管理系統(tǒng)。
orange由于沒有被大量使用，同時(shí)是國內(nèi)個(gè)人在開源，在可持續(xù)性和社區(qū)資源上不夠豐富，出了問題后可能不容易找到人問。

另外kong提供企業(yè)版本的API網(wǎng)關(guān)，當(dāng)然也是基于ngnix+lua的，企業(yè)版本可以購買他們的技術(shù)支持、培訓(xùn)等服務(wù)、以及擁有界面的管理、監(jiān)控等功能。

5、公有云還是私有云
現(xiàn)在的亞馬遜、阿里、騰訊云都在提供基礎(chǔ)公有云的API網(wǎng)關(guān)，當(dāng)然這些網(wǎng)關(guān)的基礎(chǔ)功能肯定是沒有問題，但是二次開發(fā)，擴(kuò)展功能、監(jiān)控功能可能就不能滿足部分用戶的定制需求了。另外很多企業(yè)因?yàn)樽陨硇畔踩脑颍荒苁褂猛饩W(wǎng)公有網(wǎng)的API網(wǎng)關(guān)服務(wù)，這樣就只有選擇私有云的方案了。
在需求上如果基于公有云的API網(wǎng)關(guān)只能做到由內(nèi)部人員為外網(wǎng)人員申請(qǐng)應(yīng)用，無法做到定制的合作伙伴門戶，這也不適合于部分企業(yè)的需求。
如果作為微服務(wù)網(wǎng)關(guān)，大多數(shù)情況下是希望網(wǎng)關(guān)服務(wù)器和服務(wù)提供方服務(wù)器是要在內(nèi)網(wǎng)的，在這里情況下也只有私有云的API網(wǎng)關(guān)才能滿足需求。

綜合上面的分析，基礎(chǔ)公有云的API網(wǎng)關(guān)只有滿足一部分簡單客戶的需求，對(duì)于很多企業(yè)來說私有云的API網(wǎng)關(guān)才是正確的選擇。

文章作者介紹：
來自于小豹科技的架構(gòu)師-專注于軟件研發(fā)基于平臺(tái)性軟件的研發(fā)，目前我正在研發(fā)一款基于Netty、響應(yīng)式架構(gòu)的插件式的API網(wǎng)關(guān)，希望能對(duì)行業(yè)帶來一些改變。我希望與對(duì)OpenAPI、微服務(wù)、API網(wǎng)關(guān)、Service Mesh等感興趣的朋友多交流。有興趣的朋友請(qǐng)加我的QQ群244054462。

posted @ 2018-01-05 13:42 Coolfiry 閱讀(4707) | 評(píng)論 (0) | 編輯收藏

虞美人李煜

春花秋月何時(shí)了，往事知多少？小樓昨夜又東風(fēng)，故國不堪回首月明中。雕欄玉砌應(yīng)猶在，只是朱顏改。問君能有幾多愁，恰似一江春水向東流。

posted @ 2009-01-19 10:49 Coolfiry 閱讀(270) | 評(píng)論 (0) | 編輯收藏

雨霖鈴 ·柳永

寒蟬凄切。對(duì)長亭晚，驟雨初歇。都門帳飲無緒，留戀處、蘭舟催發(fā)。執(zhí)手相看淚眼，竟無語凝噎。念去去、千里煙波，暮靄沉沉楚天闊。
多情自古傷離別，更那堪冷落清秋節(jié)！今宵酒醒何處？楊柳岸、曉風(fēng)殘?jiān)隆４巳ソ?jīng)年，應(yīng)是良辰好景虛設(shè)。便縱有千種風(fēng)情，更與何人說？

posted @ 2009-01-19 10:48 Coolfiry 閱讀(264) | 評(píng)論 (0) | 編輯收藏

blog內(nèi)容預(yù)告

1、python的入門級(jí)內(nèi)容。
2、java mail的使用基本用法和注意事項(xiàng)。
3、CXF中相關(guān)BUG的解決方法。
4、UNIX 網(wǎng)絡(luò)編程步步提升系列。

posted @ 2008-12-11 15:48 Coolfiry 閱讀(1076) | 評(píng)論 (5) | 編輯收藏

snoop的用法

轉(zhuǎn)自:http://bbs.chinaunix.net/viewthread.php?tid=691982&extra=&page=1
snoop 抓包
solaris自帶snoop抓包工具,抓所有數(shù)據(jù)流

# snoop
Using device /dev/pcn0 (promiscuous mode)
192.168.8.18 -> 192.168.255.255 NBT NS Query Request for WORKGROUP[1c], Success
192.168.253.35 -> solaris    TELNET C port=1246
   solaris -> 192.168.253.35 TELNET R port=1246 Using device /dev/pc
   solaris -> 192.168.253.35 TELNET R port=1246 Using device /dev/pc
192.168.4.150 -> (broadcast)  ARP C Who is 192.168.4.200, 192.168.4.200 ?
192.168.4.200 -> (broadcast)  ARP C Who is 192.168.4.150, 192.168.4.150 ?
#

抓源地址或目的為 202.101.98.55的數(shù)據(jù)流：

# snoop 202.101.98.55
Using device /dev/pcn0 (promiscuous mode)
192.168.253.35 -> dns.fz.fj.cn DNS C www.163.com. Internet Addr ?
dns.fz.fj.cn -> 192.168.253.35 DNS R www.163.com. Internet CNAME www.cache.split.netease.com.

#

說明：internet cname 后的為解析www.163.com的名字時(shí)，代表www.163.com回答的主機(jī)的域名。

抓 192.168.253.35和202.101.98.55之間的數(shù)據(jù)流（雙向都抓）

# snoop 192.168.253.35 202.101.98.55
Using device /dev/pcn0 (promiscuous mode)
192.168.253.35 -> dns.fz.fj.cn DNS C www.google.com. Internet Addr ?
dns.fz.fj.cn -> 192.168.253.35 DNS R www.google.com. Internet CNAME www.l.google.com.
#

抓完存在當(dāng)前目錄下的cap文件中并查看

# snoop -o cap1 -P    -P表示處在非混雜模式抓數(shù)據(jù)，只抓廣播、主播、目的為本機(jī)的數(shù)據(jù)
Using device /dev/pcn0 (non promiscuous)
15 ^C                         15的含義是：顯示目前抓了多少個(gè)數(shù)據(jù)流
#

# snoop -i cap1
  1 0.00000 192.168.253.35 -> solaris    TELNET C port=1246
  2 0.18198 192.168.253.35 -> solaris    TELNET C port=1246
  3 0.37232 192.168.4.199 -> 192.168.255.255 NBT Datagram Service Type=17 Source=WB-200[20]
  4 0.00016          ? -> (multicast)  ETHER Type=EF08 (Unknown), size = 180bytes
  5 0.62546 192.168.253.35 -> solaris    TELNET C port=1246
  6 0.13822          ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
  7 0.06283 192.168.253.35 -> solaris    TELNET C port=1246
  8 0.90301 192.168.253.35 -> solaris    TELNET C port=1246
  9 0.19781 192.168.253.35 -> solaris    TELNET C port=1246
10 0.81493          ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
11 0.07018 192.168.253.35 -> solaris    TELNET C port=1246
12 0.19939 192.168.253.35 -> solaris    TELNET C port=1246
13 0.90151 192.168.253.35 -> solaris    TELNET C port=1246
14 0.18904 192.168.253.35 -> solaris    TELNET C port=1246
15 0.68422          ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
#snoop -i cap1 -p 10,12          只看10-12條記錄

#snoop -i cap1 -p10                只看第10條記錄

# snoop -i cap1 -v -p101          查看第10條數(shù)據(jù)流的包頭的詳細(xì)內(nèi)容

#snoop -i cap1 -v -x 0 -p101 查看第10條數(shù)據(jù)流的全部的詳細(xì)內(nèi)容

抓主機(jī)192.168.253.35和202.101.98.55之間的tcp或者udp端口53的數(shù)據(jù)

# snoop 192.168.253.35 and 202.101.98.55 and $tcp or udp$ and port 53

輸入（的時(shí)候要加轉(zhuǎn)義符號(hào)\

snoop的詳細(xì)參數(shù)
Snoop 是Solaris 系統(tǒng)中自帶的工具，是一個(gè)用于顯示網(wǎng)絡(luò)通訊的程序，它可捕獲IP 包并將其顯示或保存到指定文件. (限超級(jí)用戶使用snoop)
Snoop 可將捕獲的包以一行的形式加以總結(jié)或用多行加以詳細(xì)的描述(有調(diào)用不同的參數(shù)–v -V來實(shí)現(xiàn)). 在總結(jié)方式下(-V ) , 將僅顯示最高層的相關(guān)協(xié)議, 例如一個(gè)NFS 包將僅顯示NFS 信息, 其低層的RPC, UDP, IP, Ethernet 幀信息將不會(huì)顯示, 但是當(dāng)加上相應(yīng)的參數(shù)(-v ), 這些信息都能被顯示出來.

-C

-D

-N

-P 在非混雜模式下抓包

-S 抓包的時(shí)候顯示數(shù)據(jù)包的大小

-V 半詳細(xì)的顯示抓的數(shù)據(jù)的信息

-t [ r | a | d ] 顯示時(shí)間戳，-ta顯示當(dāng)前系統(tǒng)時(shí)間，精確到毫秒

-v 最詳細(xì)的顯示數(shù)據(jù)的信息

-x offset [ , length] 以16進(jìn)制或ACSII方式顯示某數(shù)據(jù)的部分內(nèi)容，比如 -x 0,10 只顯示0-10字節(jié)

#snoop -i cap1 -v -x 0 -p101 查看被抓獲的第101個(gè)數(shù)據(jù)流的全部內(nèi)容

表達(dá)式：

根據(jù)地址：

#snoop x.x.x.x       IPV4的IP

#snoop 0XX:XX:XX:XX ETHERNET的MAC地址

數(shù)據(jù)的方向：

from x.x.x.x 或者 src x.x.x.x

to x.x.x.x 或者 dst x.x.x.x

可用的數(shù)據(jù)類型的關(guān)鍵詞：

ip, ip6, arp, rarp, pppoed, pppoes，pppoe，broadcast，multicast，apple，decnet

udp, tcp, icmp, icmp6, ah, esp

greater length
   True if the packet is longer than length.

less length
   True if the packet is shorter than length.

net net

# snoop from net 192.168.1.0 抓來自192.168.1.0/24的數(shù)據(jù)

# snoop from net 192.168.0.0 抓來自192.168.0.0/16的數(shù)據(jù)

port xx XX為TCP或者UDP的端口號(hào)或者 /etc/services里定義的名字

#snoop to udp and port 53 抓到UDP53的數(shù)據(jù)

posted @ 2008-10-21 21:30 Coolfiry 閱讀(726) | 評(píng)論 (0) | 編輯收藏

CXF使用中List作為傳輸參數(shù)相關(guān)問題的解決

在項(xiàng)目使用CXF的過程中,遇到了有關(guān)List作為傳輸參數(shù)的時(shí)候,如果WebService端沒有明確給出List的泛型類型會(huì)報(bào)錯(cuò)。
例如
CXF的WebService端口接口的一個(gè)方法為為：

1 public boolean updateMessageStatus(List batchIds);

客戶端的的調(diào)用為：

1 //預(yù)先初始化cxf對(duì)象cxfObj
2 List<String> list=new ArrayList<String>();
3 list.add("1");
4 cxfObj.updateMessageStatus(list);

在客戶端進(jìn)行調(diào)用WebService時(shí)會(huì)發(fā)生錯(cuò)誤，錯(cuò)誤為：unexpected element (uri:"", local:"arg0")等，據(jù)分析生成的wsdl，這是因?yàn)镃XF在進(jìn)行數(shù)據(jù)marshal時(shí)不知道要將要轉(zhuǎn)換的類型。

解決辦法是:在WebService端的接口必須用List的泛型類型參數(shù)，如：

1 public boolean updateMessageStatus(List<String> batchIds);

這樣就完全解決問題了。

posted @ 2008-08-05 20:09 Coolfiry 閱讀(4958) | 評(píng)論 (1) | 編輯收藏

我的第一個(gè)和第二個(gè)unix SHELL學(xué)習(xí)程序

現(xiàn)在正在學(xué)習(xí)linux shell編程
first.sh

while read line
do
echo "$line"
done <"$1"

這是第一個(gè)shell程序小例子，就相當(dāng)于一個(gè)學(xué)習(xí)其他語言的hello world了吧。用法first.sh test，將test文件中的每一行輸出到stdout中。

second.sh

number=0;
while [ "$number" -lt 100 ]
do
echo "$number"
number='expr $number + 1'
done
echo

這是第二個(gè)shell程序小例子，作用是輸出0到99的數(shù)字到stdout中。其中用到的expr的作用是使expr的參數(shù)轉(zhuǎn)化為數(shù)字并相加。兩個(gè)單引號(hào)的作用是引號(hào)所包圍的命令被命令的標(biāo)準(zhǔn)輸出替換，并輸出賦值給我number，得到了如同java中number=number+1的效果。

posted @ 2008-07-20 20:34 Coolfiry 閱讀(592) | 評(píng)論 (2) | 編輯收藏

在使用CXF WebService框架時(shí)遇到的問題與解決方案

在項(xiàng)目開發(fā)過程中，遇到在本機(jī)和windows環(huán)境中部署用CXF框架開發(fā)的的webService沒有任何問題，但是當(dāng)將工程部署到solaris 的SUN ONE application上時(shí)，再用本機(jī)的cxf Web服務(wù)客戶端訪問對(duì)應(yīng)的web服務(wù)時(shí)，如果傳輸?shù)臄?shù)據(jù)量小于大約4K不會(huì)出問題，否則則會(huì)報(bào)一些數(shù)據(jù)綁定的異常如：
Marshalling Error: Error writing request body to server。
解決這個(gè)問題花了我足足兩天時(shí)間，原因是有關(guān)CXF的資料太少了，而且有關(guān)于這個(gè)錯(cuò)誤的解決都必須使用google才能search到，用baidu完全search不到相關(guān)的資料。
解決方案：
在客戶端的class-path中加上cxf.xml。cxf.xml的配置如下：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:http="http://cxf.apache.org/transports/http/configuration"
    xmlns:jaxws="http://cxf.apache.org/jaxws"
    xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd">
    <http:conduit name="*.http-conduit">
        <http:client AutoRedirect="true" />
    </http:conduit>
</beans>

這個(gè)問題的解決方案是我在cxf的官網(wǎng)上找了很久才找到的，雖然問題解決了，但是我感到很迷惑。主要在windows tomcat環(huán)境下沒有問題，而到了SUN ONE的環(huán)境就有問題，經(jīng)過的思考和找了一資料，我認(rèn)為問題出于solaris對(duì)于HTTP數(shù)據(jù)傳輸?shù)哪承┫拗疲绻嬉ジ闱宄脑捒赡芤⒖碿xf的source code了，但是我不想花這個(gè)時(shí)間去研究這個(gè)問題了。

我把這個(gè)解決方案寫出來，希望可以幫助到使用CXF的網(wǎng)友，也希望高手們能幫我解決我的迷惑。

posted @ 2008-07-18 19:11 Coolfiry 閱讀(2573) | 評(píng)論 (0) | 編輯收藏

使用負(fù)載均衡技術(shù)建設(shè)高負(fù)載的網(wǎng)絡(luò)站點(diǎn)(轉(zhuǎn))

Internet的快速增長使多媒體網(wǎng)絡(luò)服務(wù)器，特別是Web服務(wù)器，面對(duì)的訪問者數(shù)量快速增加，網(wǎng)絡(luò)服務(wù)器需要具備提供大量并發(fā)訪問服務(wù)的能力。例如Yahoo每天會(huì)收到數(shù)百萬次的訪問請(qǐng)求，因此對(duì)于提供大負(fù)載Web服務(wù)的服務(wù)器來講，CPU、I/O處理能力很快會(huì)成為瓶頸。

簡單的提高硬件性能并不能真正解決這個(gè)問題，因?yàn)閱闻_(tái)服務(wù)器的性能總是有限的，一般來講，一臺(tái)PC服務(wù)器所能提供的并發(fā)訪問處理能力大約為1000個(gè)，更為高檔的專用服務(wù)器能夠支持3000-5000個(gè)并發(fā)訪問，這樣的能力還是無法滿足負(fù)載較大的網(wǎng)站的要求。尤其是網(wǎng)絡(luò)請(qǐng)求具有突發(fā)性，當(dāng)某些重大事件發(fā)生時(shí)，網(wǎng) 絡(luò)訪問就會(huì)急劇上升，從而造成網(wǎng)絡(luò)瓶頸，例如在網(wǎng)上發(fā)布的克林頓彈劾書就是很明顯的例子。必須采用多臺(tái)服務(wù)器提供網(wǎng)絡(luò)服務(wù)，并將網(wǎng)絡(luò)請(qǐng)求分配給這些服務(wù)器分擔(dān)，才能提供處理大量并發(fā)服務(wù)的能力。

當(dāng)使用多臺(tái)服務(wù)器來分擔(dān)負(fù)載的時(shí)候，最簡單的辦法是將不同的服務(wù)器用在不同的方面。按提供的內(nèi)容進(jìn)行分割時(shí)，可以將一臺(tái)服務(wù)器用于提供新聞頁面，而另一臺(tái)用于提供游戲頁面；或者可以按服務(wù)器的功能進(jìn)行分割，將一臺(tái)服務(wù)器用于提供靜態(tài)頁面訪問，而另一些用于提供CGI等需要大量消耗資源的動(dòng)態(tài)頁面訪問。然而由于網(wǎng)絡(luò)訪問的突發(fā)性，使得很難確定那些頁面造成的負(fù)載太大，如果將服務(wù)的頁面分割的過細(xì)就會(huì)造成很大浪費(fèi)。事實(shí)上造成負(fù)載過大的頁面常常是在變化中的，如果要經(jīng)常按照負(fù)載變化來調(diào)整頁面所在的服務(wù)器，那么勢(shì)必對(duì)管理和維護(hù)造成極大的問題。因此這種分割方法只能是大方向的調(diào)整，對(duì)于大負(fù)載的網(wǎng)站，根本的解決辦法還需要應(yīng)用負(fù)載均衡技術(shù)。

負(fù)載均衡的思路下多臺(tái) 服務(wù)器為對(duì)稱方式，每臺(tái)服務(wù)器都具備等價(jià)的地位，都可以單獨(dú)對(duì)外提供服務(wù)而無須其他服務(wù)器的輔助。然后通過某種負(fù)載分擔(dān)技術(shù)，將外部發(fā)送來的請(qǐng)求均勻分配到對(duì)稱結(jié)構(gòu)中的某一臺(tái)服務(wù)器上，而接收到請(qǐng)求的服務(wù)器都獨(dú)立回應(yīng)客戶機(jī)的請(qǐng)求。由于建立內(nèi)容完全一致的Web服務(wù)器并不復(fù)雜，可以使用服務(wù)器同步更新或者共享存儲(chǔ)空間等方法來完成，因此負(fù)載均衡技術(shù)就成為建立一個(gè)高負(fù)載Web站點(diǎn)的關(guān)鍵性技術(shù)。

基于特定服務(wù)器軟件的負(fù)載均衡
很多網(wǎng)絡(luò)協(xié)議都支持“重定向”功能，例如在HTTP協(xié)議中支持Location指令，接收到這個(gè)指令的瀏覽器將自動(dòng)重定向到Location指明的另一個(gè) URL上。由于發(fā)送Location指令比起執(zhí)行服務(wù)請(qǐng)求，對(duì)Web服務(wù)器的負(fù)載要小的多，因此可以根據(jù)這個(gè)功能來設(shè)計(jì)一種負(fù)載均衡的服務(wù)器。任何時(shí)候 Web服務(wù)器認(rèn)為自己負(fù)載較大的時(shí)候，它就不再直接發(fā)送回瀏覽器請(qǐng)求的網(wǎng)頁，而是送回一個(gè)Locaction指令，讓瀏覽器去服務(wù)器集群中的其他服務(wù)器上獲得所需要的網(wǎng)頁。

在這種方式下，服務(wù)器本身必須支持這種功能，然而具體實(shí)現(xiàn)起來卻有很多困難，例如一臺(tái)服務(wù)器如何能保證它重定向過的服務(wù) 器是比較空閑的，并且不會(huì)再次發(fā)送Location指令？Location指令和瀏覽器都沒有這方面的支持能力，這樣很容易在瀏覽器上形成一種死循環(huán)。因此這種方式實(shí)際應(yīng)用當(dāng)中并不多見，使用這種方式實(shí)現(xiàn)的服務(wù)器集群軟件也較少。有些特定情況下可以使用CGI（包括使用FastCGI或mod_perl擴(kuò) 展來改善性能）來模擬這種方式去分擔(dān)負(fù)載，而Web服務(wù)器仍然保持簡潔、高效的特性，此時(shí)避免Location循環(huán)的任務(wù)將由用戶的CGI程序來承擔(dān)。
基于DNS的負(fù)載均衡
由于基于服務(wù)器軟件的負(fù)載均衡需要改動(dòng)軟件，因此常常是得不償失，負(fù)載均衡最好是在服務(wù)器軟件之外來完成，這樣才能利用現(xiàn)有服務(wù)器軟件的種種優(yōu)勢(shì)。最早的負(fù) 載均衡技術(shù)是通過DNS服務(wù)中的隨機(jī)名字解析來實(shí)現(xiàn)的，在DNS服務(wù)器中，可以為多個(gè)不同的地址配置同一個(gè)名字，而最終查詢這個(gè)名字的客戶機(jī)將在解析這個(gè) 名字時(shí)得到其中的一個(gè)地址。因此，對(duì)于同一個(gè)名字，不同的客戶機(jī)會(huì)得到不同的地址，他們也就訪問不同地址上的Web服務(wù)器，從而達(dá)到負(fù)載均衡的目的。

例如如果希望使用三個(gè)Web服務(wù)器來回應(yīng)對(duì)www.exampleorg.org.cn的HTTP請(qǐng)求，就可以設(shè)置該域的DNS服務(wù)器中關(guān)于該域的數(shù)據(jù)包括有與下面例子類似的結(jié)果：
```
www1		IN		A 		192.168.1.1
```
```
www2		IN		A 		192.168.1.2
```
```
www3		IN		A 		192.168.1.3
```
```
www		IN		CNAME		www1
```
```
www		IN		CNAME		www2
```
```
www		IN		CNAME		www3
```
此后外部的客戶機(jī)就可能隨機(jī)的得到對(duì)應(yīng)www的不同地址，那么隨后的HTTP請(qǐng)求也就發(fā)送給不同地址了。

DNS 負(fù)載均衡的優(yōu)點(diǎn)是簡單、易行，并且服務(wù)器可以位于互聯(lián)網(wǎng)的任意位置上，當(dāng)前使用在包括Yahoo在內(nèi)的Web站點(diǎn)上。然而它也存在不少缺點(diǎn)，一個(gè)缺點(diǎn)是為了保證DNS數(shù)據(jù)及時(shí)更新，一般都要將DNS的刷新時(shí)間設(shè)置的較小，但太小就會(huì)造成太大的額外網(wǎng)絡(luò)流量，并且更改了DNS數(shù)據(jù)之后也不能立即生效；第二點(diǎn) 是DNS負(fù)載均衡無法得知服務(wù)器之間的差異，它不能做到為性能較好的服務(wù)器多分配請(qǐng)求，也不能了解到服務(wù)器的當(dāng)前狀態(tài)，甚至?xí)霈F(xiàn)客戶請(qǐng)求集中在某一臺(tái)服務(wù)器上的偶然情況。
反向代理負(fù)載均衡
使用代理服務(wù)器可以將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部的Web服務(wù)器，使用這種加速模式顯然可以提升靜態(tài)網(wǎng)頁的訪問速度。因此也可以考慮使用這種技術(shù)，讓代理服務(wù)器將請(qǐng)求均勻轉(zhuǎn)發(fā)給多臺(tái)內(nèi)部Web服務(wù)器之一上，從而達(dá)到負(fù)載均衡的目的。這種代理方式與普通的代理方式有所不同，標(biāo)準(zhǔn)代理方式是客戶使用代理訪問多個(gè)外部Web服務(wù)器，而這種代理方式是多個(gè)客戶使用它訪問內(nèi)部Web服務(wù)器，因此也被稱為反向代理模式。

實(shí)現(xiàn)這個(gè)反向代理能力并不能算是一個(gè)特別復(fù)雜的任務(wù)，但是在負(fù)載均衡中要求特別高的效率，這樣實(shí)現(xiàn)起來就不是十分簡單的了。每針對(duì)一次代理，代理服務(wù)器就必須打開兩個(gè)連接，一個(gè)為對(duì)外的連接，一個(gè)為對(duì)內(nèi)的連接，因此對(duì)于連接請(qǐng)求數(shù)量非常大的時(shí)候，代理服務(wù)器的負(fù)載也就非常之大了，在最后反向代理服務(wù)器會(huì)成為服務(wù)的瓶頸。例如，使用Apache的mod_rproxy模塊來實(shí)現(xiàn)負(fù)載均衡功能時(shí)，提供的并發(fā)連接數(shù)量受 Apache本身的并發(fā)連接數(shù)量的限制。一般來講，可以使用它來對(duì)連接數(shù)量不是特別大，但每次連接都需要消耗大量處理資源的站點(diǎn)進(jìn)行負(fù)載均衡，例如搜尋。

使用反向代理的好處是，可以將負(fù)載均衡和代理服務(wù)器的高速緩存技術(shù)結(jié)合在一起，提供有益的性能，具備額外的安全性，外部客戶不能直接訪問真實(shí)的服務(wù)器。并且實(shí)現(xiàn)起來可以實(shí)現(xiàn)較好的負(fù)載均衡策略，將負(fù)載可以非常均衡的分給內(nèi)部服務(wù)器，不會(huì)出現(xiàn)負(fù)載集中到某個(gè)服務(wù)器的偶然現(xiàn)象。
基于NAT的負(fù)載均衡技術(shù)
網(wǎng) 絡(luò)地址轉(zhuǎn)換為在內(nèi)部地址和外部地址之間進(jìn)行轉(zhuǎn)換，以便具備內(nèi)部地址的計(jì)算機(jī)能訪問外部網(wǎng)絡(luò)，而當(dāng)外部網(wǎng)絡(luò)中的計(jì)算機(jī)訪問地址轉(zhuǎn)換網(wǎng)關(guān)擁有的某一外部地址時(shí)，地址轉(zhuǎn)換網(wǎng)關(guān)能將其轉(zhuǎn)發(fā)到一個(gè)映射的內(nèi)部地址上。因此如果地址轉(zhuǎn)換網(wǎng)關(guān)能將每個(gè)連接均勻轉(zhuǎn)換為不同的內(nèi)部服務(wù)器地址，此后外部網(wǎng)絡(luò)中的計(jì)算機(jī)就各自與自己轉(zhuǎn)換得到的地址上服務(wù)器進(jìn)行通信，從而達(dá)到負(fù)載分擔(dān)的目的。

地址轉(zhuǎn)換可以通過軟件方式來實(shí)現(xiàn)，也可以通過硬件方式來實(shí)現(xiàn)。使用硬件方式進(jìn)行操作一般稱為交換，而當(dāng)交換必須保存TCP連接信息的時(shí)候，這種針對(duì)OSI網(wǎng) 絡(luò)層的操作就被稱為第四層交換。支持負(fù)載均衡的網(wǎng)絡(luò)地址轉(zhuǎn)換為第四層交換機(jī)的一種重要功能，由于它基于定制的硬件芯片，因此其性能非常優(yōu)秀，很多交換機(jī)聲稱具備400MB-800MB的第四層交換能力，然而也有一些資料表明，在如此快的速度下，大部分交換機(jī)就不再具備第四層交換能力了，而僅僅支持第三層甚至第二層交換。

然而對(duì)于大部分站點(diǎn)來講，當(dāng)前負(fù)載均衡主要是解決Web服務(wù)器處理能力瓶頸的，而非網(wǎng)絡(luò)傳輸能力，很多站點(diǎn)的互聯(lián)網(wǎng)連接帶寬總共也不過10MB，只有極少的站點(diǎn)能夠擁有較高速的網(wǎng)絡(luò)連接，因此一般沒有必要使用這些負(fù)載均衡器這樣的昂貴設(shè)備。

使用軟件方式來實(shí)現(xiàn)基于網(wǎng)絡(luò)地址轉(zhuǎn)換的負(fù)載均衡則要實(shí)際的多，除了一些廠商提供的解決方法之外，更有效的方法是使用免費(fèi)的自由軟件來完成這項(xiàng)任務(wù)。其中包括 Linux Virtual Server Project中的NAT實(shí)現(xiàn)方式，或者本文作者在FreeBSD下對(duì)natd的修訂版本。一般來講，使用這種軟件方式來實(shí)現(xiàn)地址轉(zhuǎn)換，中心負(fù)載均衡器存在帶寬限制，在100MB的快速以太網(wǎng)條件下，能得到最快達(dá)80MB的帶寬，然而在實(shí)際應(yīng)用中，可能只有40MB-60MB的可用帶寬。
擴(kuò)展的負(fù)載均衡技術(shù)

上面使用網(wǎng)絡(luò)地址轉(zhuǎn)換來實(shí)現(xiàn)負(fù)載分擔(dān)，毫無疑問所有的網(wǎng)絡(luò)連接都必須通過中心負(fù)載均衡器，那么如果負(fù)載特別大，以至于后臺(tái)的服務(wù)器數(shù)量不再在是幾臺(tái)、十幾臺(tái)，而是上百臺(tái)甚至更多，即便是使用性能優(yōu)秀的硬件交換機(jī)也回遇到瓶頸。此時(shí)問題將轉(zhuǎn)變?yōu)椋绾螌⒛敲炊嗯_(tái)服務(wù)器分布到各個(gè)互聯(lián)網(wǎng)的多個(gè)位置，分散網(wǎng)絡(luò)負(fù) 擔(dān)。當(dāng)然這可以通過綜合使用DNS和NAT兩種方法來實(shí)現(xiàn)，然而更好的方式是使用一種半中心的負(fù)載均衡方式。

在這種半中心的負(fù)載均衡方式下，即當(dāng)客戶請(qǐng)求發(fā)送給負(fù)載均衡器的時(shí)候，中心負(fù)載均衡器將請(qǐng)求打包并發(fā)送給某個(gè)服務(wù)器，而服務(wù)器的回應(yīng)請(qǐng)求不再返回給中心負(fù)載均衡器，而是直接返回給客戶，因此中心負(fù)載均衡器只負(fù)責(zé)接受并轉(zhuǎn)發(fā)請(qǐng)求，其網(wǎng)絡(luò)負(fù)擔(dān)就較小了。

上圖來自Linux Virtual Server Project，為他們使用IP隧道實(shí)現(xiàn)的這種負(fù)載分擔(dān)能力的請(qǐng)求/回應(yīng)過程，此時(shí)每個(gè)后臺(tái)服務(wù)器都需要進(jìn)行特別的地址轉(zhuǎn)換，以欺騙瀏覽器客戶，認(rèn)為它的回應(yīng)為正確的回應(yīng)。

同樣，這種方式的硬件實(shí)現(xiàn)方式也非常昂貴，但是會(huì)根據(jù)廠商的不同，具備不同的特殊功能，例如對(duì)SSL的支持等。

由于這種方式比較復(fù)雜，因此實(shí)現(xiàn)起來比較困難，它的起點(diǎn)也很高，當(dāng)前情況下網(wǎng)站并不需要這么大的處理能力。

比較上面的負(fù)載均衡方式，DNS最容易，也最常用，能夠滿足一般的需求。但如果需要進(jìn)一步的管理和控制，可以選用反向代理方式或NAT方式，這兩種之間進(jìn)行選擇主要依賴緩沖是不是很重要，最大的并發(fā)訪問數(shù)量是多少等條件。而如果網(wǎng)站上對(duì)負(fù)載影響很厲害的CGI程序是由網(wǎng)站自己開發(fā)的，也可以考慮在程序中自己使用Locaction來支持負(fù)載均衡。半中心化的負(fù)載分擔(dān)方式至少在國內(nèi)當(dāng)前的情況下還不需要。
http://galaxystar.javaeye.com/blog/50546

posted @ 2008-07-18 14:23 Coolfiry 閱讀(259) | 評(píng)論 (0) | 編輯收藏

垃圾收集機(jī)制(Garbage Collection)批判

在Java版發(fā)表這篇文章，似乎有點(diǎn)把矛頭指向Java了。其實(shí)不是，GC是所有新一代語言共有的特征，
Python, Eiffel，C#，Roby等無一例外地都使用了GC機(jī)制。但既然Java中的GC最為著名，所以天塌
下來自然應(yīng)該抗著。

這篇短文源于comp.lang.java.programmer跟comp.lang.c++上發(fā)生的一場(chǎng)大辯論，支持C++和Java
的兩派不同勢(shì)力展開了新世紀(jì)第一場(chǎng)沖突，跟貼發(fā)言超過350，兩派都有名角壓陣。C++陣營的擂主是
Pete Becker，ACM會(huì)員，Dinkumware Ltd. 的技術(shù)副總監(jiān)。此君精通C++和Java，開發(fā)過兩種語言的
核心類庫，但是卻對(duì)C++狂熱之極，而對(duì)于Java頗不以為然。平時(shí)談到Java的時(shí)候還好，一旦有人膽
敢用Java來批判C++，立刻忍不住火爆脾氣跳將出來，以堅(jiān)韌不拔的毅力和大無畏精神與對(duì)手周旋，
舌戰(zhàn)群儒，哪怕只剩下一個(gè)人也要血戰(zhàn)到底。這等奇人當(dāng)真少見！我真奇怪他整天泡在usenet上，
不用工作么？他的老板P.J. Plauger如此寬宏大量？Java陣營主角是一個(gè)網(wǎng)名Razzi的兄弟，另外有
Sun公司大名鼎鼎的Peter van der Linden助陣，妙語連珠，寸土必爭，加上人多勢(shì)眾，一度占據(jù)優(yōu)勢(shì)。
C++陣營里大拿雖然很多，但是大多數(shù)沒有Pete那么多閑工夫，例如Greg Comeau，Comeau公司老板，
每次來個(gè)只言片語，實(shí)在幫不了Pete多大忙。但是自從C++陣營中冒出一個(gè)無名小子，網(wǎng)名Courage(勇氣)，
發(fā)動(dòng)對(duì)Java GC機(jī)制的批判，形勢(shì)為之一變。C++陣營眼下處于全攻之勢(shì)，Java陣營疲于防守，只能
招架說：“你們沒有證據(jù)，沒有統(tǒng)計(jì)資料”，形勢(shì)很被動(dòng)。

垃圾收集(GC)不是一直被Java fans用來炫耀，引以為傲的優(yōu)點(diǎn)么？怎么成了弱點(diǎn)了？我大惑不解，定睛
一看，才覺得此中頗有道理。

首先，Java Swing庫存在大量資源泄漏問題，這一點(diǎn)SUN非常清楚，稱之為bugs，正在極力修正。但是看來
這里的問題恐怕不僅是庫編寫者的疏忽，可能根源在于深層的機(jī)制，未必能夠輕易解決，搞不好要傷筋動(dòng)骨。
不過這個(gè)問題不是那么根本，C++陣營覺得如果抓住對(duì)方的弱點(diǎn)攻擊，就算是占了上風(fēng)也沒什么說服力。誰
沒有缺點(diǎn)呢？于是反其道而行之，猛烈攻擊Java陣營覺得最得意的東西，Java的GC機(jī)制本身。

首先來想一想，memory leak到底意味著什么。在C++中，new出來的對(duì)象沒有delete，這就導(dǎo)致了memory
leak。但是C++早就有了克服這一問題的辦法——smart pointer。通過使用標(biāo)準(zhǔn)庫里設(shè)計(jì)精致的auto_ptr
以及各種STL容器，還有例如boost庫(差不多是個(gè)準(zhǔn)標(biāo)準(zhǔn)庫了)中的四個(gè)smart pointers，C++程序員只要
花上一個(gè)星期的時(shí)間學(xué)習(xí)最新的資料，就可以拍著胸脯說：“我寫的程序沒有memory leak!”。

相比之下，Java似乎更優(yōu)秀，因?yàn)閺囊婚_始你就不用考慮什么特殊的機(jī)制，大膽地往前new，自有GC替你
收拾殘局。Java的GC實(shí)際上是JVM中的一個(gè)獨(dú)立線程，采用不同的算法策略來收集heap中那些不再有
reference指向的垃圾對(duì)象所占用的內(nèi)存。但是，通常情況下，GC線程的優(yōu)先級(jí)比較低，只有在當(dāng)前程序
空閑的時(shí)候才會(huì)被調(diào)度，收集垃圾。當(dāng)然，如果JVM感到內(nèi)存緊張了，JVM會(huì)主動(dòng)調(diào)用GC來收集垃圾，獲取
更多的內(nèi)存。請(qǐng)注意，Java的GC工作的時(shí)機(jī)是：1. 當(dāng)前程序不忙，有空閑時(shí)間。2. 空閑內(nèi)存不足。
現(xiàn)在我們考慮一種常見的情況，程序在緊張運(yùn)行之中，沒喲空閑時(shí)間給GC來運(yùn)行，同時(shí)機(jī)器內(nèi)存很大，
JVM也沒有感到內(nèi)存不足，結(jié)果是什么？對(duì)了，GC形同虛設(shè)，得不到調(diào)用。于是，內(nèi)存被不斷吞噬，而那些
早已經(jīng)用不著的垃圾對(duì)象仍在在寶貴的內(nèi)存里睡大覺。例如：

class BadGc {

    public void job1() {
        String garbage = "I am a garbage, and just sleeping in your precious memory, " +
                  "how do you think you can deal with me? Daydreaming! HAHA!!!";
        ....
    }

public void job2() {...}

...
...

public void job1000() {...}

    public static void main(String[] args) {
        bgc = new BadGc();
bgc.job1();
bgc.job2();
...
bgc.job1000();
    }
}

運(yùn)行中，雖然garbage對(duì)象在離開job1()之后，就再也沒有用了。但是因?yàn)?/span>程序忙，內(nèi)存還夠用，所以GC得
不到調(diào)度，garbage始終不會(huì)被回收，直到程序運(yùn)行到bgc.job1000()時(shí)還躺在內(nèi)存里嘲笑你。沒轍吧！

好了，我承認(rèn)這段程序很傻。但是你不要以為這只是理論上的假設(shè)，恰恰相反，大多數(shù)實(shí)用中的Java程序都有
類似的效應(yīng)。這就是為什么Java程序狂耗內(nèi)存，而且好像給它多少內(nèi)存吃都不夠。你花上大筆的銀子把內(nèi)存
從128升到256，再升到512，結(jié)果是，一旦執(zhí)行復(fù)雜任務(wù)，內(nèi)存還是被輕易填滿，而且多出來的這些內(nèi)存只是
用來裝垃圾，GC還是不給面子地千呼萬喚不出來。等到你的內(nèi)存終于心力交瘁，GC才姍姍來遲，收拾殘局。而
且GC工作的方式也很不好評(píng)價(jià)，一種方法是一旦有機(jī)會(huì)回收內(nèi)存，就把所有的垃圾都回收。你可以想象，這要
花很長時(shí)間(幾百M(fèi)的垃圾啊！)，如果你這時(shí)侯正在壓下開炮的按鈕，GC卻叫了暫定，好了，你等死吧！另一
種方法，得到機(jī)會(huì)之后，回收一些內(nèi)存，讓JVM感到內(nèi)存不那么緊張時(shí)就收手。結(jié)果呢，內(nèi)存里始終有大批垃
圾，程序始終在半死不活的蕩著。最后，GC可以每隔一段時(shí)間就運(yùn)行一次，每次只回收一部分垃圾，這是現(xiàn)在
大部分JVM的方式，結(jié)果是內(nèi)存也浪費(fèi)了，還動(dòng)不動(dòng)暫停幾百毫秒。難啊！

反過來看看C++利用smart pointer達(dá)成的效果，一旦某對(duì)象不再被引用，系統(tǒng)刻不容緩，立刻回收內(nèi)存。這
通常發(fā)生在關(guān)鍵任務(wù)完成后的清理(cleanup)時(shí)期，不會(huì)影響關(guān)鍵任務(wù)的實(shí)時(shí)性，同時(shí)，內(nèi)存里所有的對(duì)象
都是有用的，絕對(duì)沒有垃圾空占內(nèi)存。怎么樣？傳統(tǒng)、樸素的C++是不是更勝一籌？

據(jù)統(tǒng)計(jì)，目前的Java程序運(yùn)行期間占用的內(nèi)存通常為對(duì)應(yīng)C++程序的4-20倍。除了其它的原因，上面所說的是一個(gè)
非常主要的因素。我們對(duì)memory leak如此憤恨，不就是因?yàn)樗鼘?dǎo)致大量的內(nèi)存垃圾得不到清除嗎？如果有了
GC之后，垃圾比以前還來勢(shì)洶洶，那么GC又有什么好處呢？

當(dāng)然，C++的smart pointer現(xiàn)在會(huì)使用的人不多，所以現(xiàn)在的C++程序普遍存在更嚴(yán)重的memory leak問題。
但是，如果我奶奶跟舒馬赫比賽車輸?shù)袅耍隳軌蚵裨鼓禽v車子么？
http://www.594k.com/java/html/y2007m1/12051/

posted @ 2007-10-12 10:43 Coolfiry 閱讀(647) | 評(píng)論 (1) | 編輯收藏

從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法

一、LiveJournal發(fā)展歷程

LiveJournal是99年始于校園中的項(xiàng)目，幾個(gè)人出于愛好做了這樣一個(gè)應(yīng)用，以實(shí)現(xiàn)以下功能：

博客，論壇
社會(huì)性網(wǎng)絡(luò)，找到朋友
聚合，把朋友的文章聚合在一起

LiveJournal采用了大量的開源軟件，甚至它本身也是一個(gè)開源軟件。

在上線后，LiveJournal實(shí)現(xiàn)了非常快速的增長：

2004年4月份：280萬注冊(cè)用戶。
2005年4月份：680萬注冊(cè)用戶。
2005年8月份：790萬注冊(cè)用戶。
達(dá)到了每秒鐘上千次的頁面請(qǐng)求及處理。
使用了大量MySQL服務(wù)器。
使用了大量通用組件。

二、LiveJournal架構(gòu)現(xiàn)狀概況

三、從LiveJournal發(fā)展中學(xué)習(xí)

LiveJournal從1臺(tái)服務(wù)器發(fā)展到100臺(tái)服務(wù)器，這其中經(jīng)歷了無數(shù)的傷痛，但同時(shí)也摸索出了解決這些問題的方法，通過對(duì)LiveJournal的學(xué)習(xí)，可以讓我們避免LJ曾經(jīng)犯過的錯(cuò)誤，并且從一開始就對(duì)系統(tǒng)進(jìn)行良好的設(shè)計(jì)，以避免后期的痛苦。

下面我們一步一步看LJ發(fā)展的腳步。

1、一臺(tái)服務(wù)器

一臺(tái)別人捐助的服務(wù)器，LJ最初就跑在上面，就像Google開始時(shí)候用的破服務(wù)器一樣，值得我們尊敬。這個(gè)階段，LJ的人以驚人的速度熟悉的Unix的操作管理，服務(wù)器性能出現(xiàn)過問題，不過還好，可以通過一些小修小改應(yīng)付過去。在這個(gè)階段里L(fēng)J把CGI升級(jí)到了FastCGI。

最終問題出現(xiàn)了，網(wǎng)站越來越慢，已經(jīng)無法通過優(yōu)過化來解決的地步，需要更多的服務(wù)器，這時(shí)LJ開始提供付費(fèi)服務(wù)，可能是想通過這些錢來購買新的服務(wù)器，以解決當(dāng)時(shí)的困境。
毫無疑問，當(dāng)時(shí)LJ存在巨大的單點(diǎn)問題，所有的東西都在那臺(tái)服務(wù)器的鐵皮盒子里裝著。

2、兩臺(tái)服務(wù)器

用付費(fèi)服務(wù)賺來的錢LJ買了兩臺(tái)服務(wù)器：一臺(tái)叫做Kenny的Dell 6U機(jī)器用于提供Web服務(wù)，一臺(tái)叫做Cartman的Dell 6U服務(wù)器用于提供數(shù)據(jù)庫服務(wù)。

LJ有了更大的磁盤，更多的計(jì)算資源。但同時(shí)網(wǎng)絡(luò)結(jié)構(gòu)還是非常簡單，每臺(tái)機(jī)器兩塊網(wǎng)卡，Cartman通過內(nèi)網(wǎng)為Kenny提供MySQL數(shù)據(jù)庫服務(wù)。

暫時(shí)解決了負(fù)載的問題，新的問題又出現(xiàn)了：

原來的一個(gè)單點(diǎn)變成了兩個(gè)單點(diǎn)。
沒有冷備份或熱備份。
網(wǎng)站速度慢的問題又開始出現(xiàn)了，沒辦法，增長太快了。
Web服務(wù)器上CPU達(dá)到上限，需要更多的Web服務(wù)器。

3、四臺(tái)服務(wù)器

又買了兩臺(tái)，Kyle和Stan，這次都是1U的，都用于提供Web服務(wù)。目前LJ一共有3臺(tái)Web服務(wù)器和一臺(tái)數(shù)據(jù)庫服務(wù)器。這時(shí)需要在3臺(tái)Web服務(wù)器上進(jìn)行負(fù)載均橫。

LJ把Kenny用于外部的網(wǎng)關(guān)，使用mod_backhand進(jìn)行負(fù)載均橫。

然后問題又出現(xiàn)了：

單點(diǎn)故障。數(shù)據(jù)庫和用于做網(wǎng)關(guān)的Web服務(wù)器都是單點(diǎn)，一旦任何一臺(tái)機(jī)器出現(xiàn)問題將導(dǎo)致所有服務(wù)不可用。雖然用于做網(wǎng)關(guān)的Web服務(wù)器可以通過保持心跳同步迅速切換，但還是無法解決數(shù)據(jù)庫的單點(diǎn)，LJ當(dāng)時(shí)也沒做這個(gè)。
網(wǎng)站又變慢了，這次是因?yàn)镮O和數(shù)據(jù)庫的問題，問題是怎么往應(yīng)用里面添加數(shù)據(jù)庫呢？

4、五臺(tái)服務(wù)器

又買了一臺(tái)數(shù)據(jù)庫服務(wù)器。在兩臺(tái)數(shù)據(jù)庫服務(wù)器上使用了數(shù)據(jù)庫同步(Mysql支持的Master-Slave模式)，寫操作全部針對(duì)主數(shù)據(jù)庫（通過Binlog，主服務(wù)器上的寫操作可以迅速同步到從服務(wù)器上），讀操作在兩個(gè)數(shù)據(jù)庫上同時(shí)進(jìn)行(也算是負(fù)載均橫的一種吧)。

實(shí)現(xiàn)同步時(shí)要注意幾個(gè)事項(xiàng)：

讀操作數(shù)據(jù)庫選擇算法處理，要選一個(gè)當(dāng)前負(fù)載輕一點(diǎn)的數(shù)據(jù)庫。
在從數(shù)據(jù)庫服務(wù)器上只能進(jìn)行讀操作
準(zhǔn)備好應(yīng)對(duì)同步過程中的延遲，處理不好可能會(huì)導(dǎo)致數(shù)據(jù)庫同步的中斷。只需要對(duì)寫操作進(jìn)行判斷即可，讀操作不存在同步問題。

5、更多服務(wù)器

有錢了，當(dāng)然要多買些服務(wù)器。部署后快了沒多久，又開始慢了。這次有更多的Web服務(wù)器，更多的數(shù)據(jù)庫服務(wù)器，存在 IO與CPU爭用。于是采用了BIG-IP作為負(fù)載均衡解決方案。

6、現(xiàn)在我們?cè)谀睦铮?/h2>

現(xiàn)在服務(wù)器基本上夠了，但性能還是有問題，原因出在架構(gòu)上。

數(shù)據(jù)庫的架構(gòu)是最大的問題。由于增加的數(shù)據(jù)庫都是以Slave模式添加到應(yīng)用內(nèi)，這樣唯一的好處就是將讀操作分布到了多臺(tái)機(jī)器，但這樣帶來的后果就是寫操作被大量分發(fā)，每臺(tái)機(jī)器都要執(zhí)行，服務(wù)器越多，浪費(fèi)就越大，隨著寫操作的增加，用于服務(wù)讀操作的資源越來越少。

由一臺(tái)分布到兩臺(tái)

最終效果

現(xiàn)在我們發(fā)現(xiàn)，我們并不需要把這些數(shù)據(jù)在如此多的服務(wù)器上都保留一份。服務(wù)器上已經(jīng)做了RAID，數(shù)據(jù)庫也進(jìn)行了備份，這么多的備份完全是對(duì)資源的浪費(fèi)，屬于冗余極端過度。那為什么不把數(shù)據(jù)分布存儲(chǔ)呢？

問題發(fā)現(xiàn)了，開始考慮如何解決。現(xiàn)在要做的就是把不同用戶的數(shù)據(jù)分布到不同的服務(wù)器上進(jìn)行存儲(chǔ)，以實(shí)現(xiàn)數(shù)據(jù)的分布式存儲(chǔ)，讓每臺(tái)機(jī)器只為相對(duì)固定的用戶服務(wù)，以實(shí)現(xiàn)平行的架構(gòu)和良好的可擴(kuò)展性。

為了實(shí)現(xiàn)用戶分組，我們需要為每一個(gè)用戶分配一個(gè)組標(biāo)記，用于標(biāo)記此用戶的數(shù)據(jù)存放在哪一組數(shù)據(jù)庫服務(wù)器中。每組數(shù)據(jù)庫由一個(gè)master及幾個(gè)slave 組成，并且slave的數(shù)量在2-3臺(tái)，以實(shí)現(xiàn)系統(tǒng)資源的最合理分配，既保證數(shù)據(jù)讀操作分布，又避免數(shù)據(jù)過度冗余以及同步操作對(duì)系統(tǒng)資源的過度消耗。

由一臺(tái)（一組）中心服務(wù)器提供用戶分組控制。所有用戶的分組信息都存儲(chǔ)在這臺(tái)機(jī)器上，所有針對(duì)用戶的操作需要先查詢這臺(tái)機(jī)器得到用戶的組號(hào)，然后再到相應(yīng)的數(shù)據(jù)庫組中獲取數(shù)據(jù)。

這樣的用戶架構(gòu)與目前LJ的架構(gòu)已經(jīng)很相像了。

在具體的實(shí)現(xiàn)時(shí)需要注意幾個(gè)問題：

在數(shù)據(jù)庫組內(nèi)不要使用自增ID，以便于以后在數(shù)據(jù)庫組之間遷移用戶，以實(shí)現(xiàn)更合理的I/O，磁盤空間及負(fù)載分布。
將userid，postid存儲(chǔ)在全局服務(wù)器上，可以使用自增，數(shù)據(jù)庫組中的相應(yīng)值必須以全局服務(wù)器上的值為準(zhǔn)。全局服務(wù)器上使用事務(wù)型數(shù)據(jù)庫InnoDB。
在數(shù)據(jù)庫組之間遷移用戶時(shí)要萬分小心，當(dāng)遷移時(shí)用戶不能有寫操作。

7、現(xiàn)在我們?cè)谀睦?/h2>

問題：

一個(gè)全局主服務(wù)器，掛掉的話所有用戶注冊(cè)及寫操作就掛掉。
每個(gè)數(shù)據(jù)庫組一個(gè)主服務(wù)器，掛掉的話這組用戶的寫操作就掛掉。
數(shù)據(jù)庫組從服務(wù)器掛掉的話會(huì)導(dǎo)致其它服務(wù)器負(fù)載過大。

對(duì)于Master-Slave模式的單點(diǎn)問題，LJ采取了Master-Master模式來解決。所謂Master-Master實(shí)際上是人工實(shí)現(xiàn)的，并不是由MySQL直接提供的，實(shí)際上也就是兩臺(tái)機(jī)器同時(shí)是Master，也同時(shí)是Slave，互相同步。

Master-Master實(shí)現(xiàn)時(shí)需要注意：

一個(gè)Master出錯(cuò)后恢復(fù)同步，最好由服務(wù)器自動(dòng)完成。
數(shù)字分配，由于同時(shí)在兩臺(tái)機(jī)器上寫，有些ID可能會(huì)沖突。

解決方案：

奇偶數(shù)分配ID，一臺(tái)機(jī)器上寫奇數(shù)，一臺(tái)機(jī)器上寫偶數(shù)
通過全局服務(wù)器進(jìn)行分配(LJ采用的做法)。

Master-Master模式還有一種用法，這種方法與前一種相比，仍然保持兩臺(tái)機(jī)器的同步，但只有一臺(tái)機(jī)器提供服務(wù)（讀和寫），在每天晚上的時(shí)候進(jìn)行輪換，或者出現(xiàn)問題的時(shí)候進(jìn)行切換。

8、現(xiàn)在我們?cè)谀睦?/h2>

現(xiàn)在插播一條廣告，MyISAM VS InnoDB。

使用InnoDB：

支持事務(wù)
需要做更多的配置，不過值得，可以更安全的存儲(chǔ)數(shù)據(jù)，以及得到更快的速度。

使用MyISAM：

記錄日志（LJ用它來記網(wǎng)絡(luò)訪問日志）
存儲(chǔ)只讀靜態(tài)數(shù)據(jù)，足夠快。
并發(fā)性很差，無法同時(shí)讀寫數(shù)據(jù)（添加數(shù)據(jù)可以）
MySQL非正常關(guān)閉或死機(jī)時(shí)會(huì)導(dǎo)致索引錯(cuò)誤，需要使用myisamchk修復(fù)，而且當(dāng)訪問量大時(shí)出現(xiàn)非常頻繁。

9、緩存

去年我寫過一篇文章介紹memcached，它就是由LJ的團(tuán)隊(duì)開發(fā)的一款緩存工具，以key-value的方式將數(shù)據(jù)存儲(chǔ)到分布的內(nèi)存中。LJ緩存的數(shù)據(jù)：

12臺(tái)獨(dú)立服務(wù)器（不是捐贈(zèng)的）
28個(gè)實(shí)例
30GB總?cè)萘?
90-93%的命中率（用過squid的人可能知道，squid內(nèi)存加磁盤的命中率大概在70-80%）

如何建立緩存策略？

想緩存所有的東西？那是不可能的，我們只需要緩存已經(jīng)或者可能導(dǎo)致系統(tǒng)瓶頸的地方，最大程度的提交系統(tǒng)運(yùn)行效率。通過對(duì)MySQL的日志的分析我們可以找到緩存的對(duì)象。

緩存的缺點(diǎn)？

沒有完美的事物，緩存也有缺點(diǎn)：
增大開發(fā)量，需要針對(duì)緩存處理編寫特殊的代碼。
管理難度增加，需要更多人參與系統(tǒng)維護(hù)。
當(dāng)然大內(nèi)存也需要錢。

10、Web訪問負(fù)載均衡

在數(shù)據(jù)包級(jí)別使用BIG-IP，但BIG-IP并不知道我們內(nèi)部的處理機(jī)制，無法判斷由哪臺(tái)服務(wù)器對(duì)這些請(qǐng)求進(jìn)行處理。反向代理并不能很好的起到作用，不是已經(jīng)夠快了，就是達(dá)不到我們想要的效果。

所以，LJ又開發(fā)了Perlbal。特點(diǎn)：

快，小，可管理的http web 服務(wù)器/代理
可以在內(nèi)部進(jìn)行轉(zhuǎn)發(fā)
使用Perl開發(fā)
單線程，異步，基于事件，使用epoll , kqueue
支持Console管理與http遠(yuǎn)程管理，支持動(dòng)態(tài)配置加載
多種模式：web服務(wù)器，反向代理，插件
支持插件：GIF/PNG互換？

11、MogileFS

LJ使用開源的MogileFS作為分布式文件存儲(chǔ)系統(tǒng)。MogileFS使用非常簡單，它的主要設(shè)計(jì)思想是：

文件屬于類（類是最小的復(fù)制單位）
跟蹤文件存儲(chǔ)位置
在不同主機(jī)上存儲(chǔ)
使用MySQL集群統(tǒng)一存儲(chǔ)分布信息
大容易廉價(jià)磁盤

到目前為止就這么多了，更多文檔可以在http://www.danga.com/words/找到。Danga.com和LiveJournal.com的同學(xué)們拿這個(gè)文檔參加了兩次MySQL Con，兩次OS Con，以及眾多的其它會(huì)議，無私的把他們的經(jīng)驗(yàn)分享出來，值得我們學(xué)習(xí)。在web2.0時(shí)代快速開發(fā)得到大家越來越多的重視，但良好的設(shè)計(jì)仍是每一個(gè)應(yīng) 用的基礎(chǔ)，希望web2.0們?cè)诔砷L為Top500網(wǎng)站的路上，不要因?yàn)榧軜?gòu)阻礙了網(wǎng)站的發(fā)展。

http://blog.csdn.net/xmr_gxcfe/archive/2007/09/14/1785292.aspx

posted @ 2007-09-29 21:26 Coolfiry 閱讀(553) | 評(píng)論 (0) | 編輯收藏

轉(zhuǎn)Windows快速創(chuàng)建大文件的三種方法

posted @ 2007-09-25 14:30 Coolfiry 閱讀(358) | 評(píng)論 (0) | 編輯收藏

coolfiry

導(dǎo)航

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

Firend

Programing

搜索

最新評(píng)論

閱讀排行榜

評(píng)論排行榜

API網(wǎng)關(guān)作用、方案及如何選擇

虞美人李煜

雨霖鈴 ·柳永

blog內(nèi)容預(yù)告

snoop的用法

CXF使用中List作為傳輸參數(shù)相關(guān)問題的解決

我的第一個(gè)和第二個(gè)unix SHELL學(xué)習(xí)程序

在使用CXF WebService框架時(shí)遇到的問題與解決方案

使用負(fù)載均衡技術(shù)建設(shè)高負(fù)載的網(wǎng)絡(luò)站點(diǎn)(轉(zhuǎn))

垃圾收集機(jī)制(Garbage Collection)批判

從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法

從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法

一、LiveJournal發(fā)展歷程

二、LiveJournal架構(gòu)現(xiàn)狀概況

三、從LiveJournal發(fā)展中學(xué)習(xí)

1、一臺(tái)服務(wù)器

2、兩臺(tái)服務(wù)器

3、四臺(tái)服務(wù)器

4、五臺(tái)服務(wù)器

5、更多服務(wù)器

9、緩存

10、Web訪問負(fù)載均衡

11、MogileFS

轉(zhuǎn)Windows快速創(chuàng)建大文件的三種方法