四虎影视精品,成人在线观看av,中日韩一区二区三区

2008年7月18日

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

在這篇文章中將我們一起來(lái)探討當(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è)組件可以說(shuō)是必不可少的，那就是微服務(wù)網(wǎng)關(guān)，微服務(wù)網(wǎng)關(guān)處理了負(fù)載均衡，緩存，路由，訪問(wèn)控制，服務(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è)來(lái)說(shuō)有可能實(shí)施上是困難的，企業(yè)有很多遺留系統(tǒng)，要全部抽取為微服務(wù)器改動(dòng)太大，對(duì)企業(yè)來(lái)說(shuō)成本太高。但是由于不同系統(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)可以解決這些問(wèn)題，我們可以認(rèn)為如果沒(méi)有大規(guī)模的實(shí)施微服務(wù)架構(gòu)，那么對(duì)企業(yè)來(lái)說(shuō)微服務(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í)別、訪問(wèn)方式也不一樣。因此在我的設(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)來(lái)說(shuō)，一般合作伙伴要以應(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)行訪問(wèn)。如下架構(gòu):

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

2、對(duì)于內(nèi)網(wǎng)的API網(wǎng)關(guān)，在起到的作用上來(lái)說(shuō)可以認(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)管理起來(lái)，那么API網(wǎng)關(guān)就起到了微服務(wù)網(wǎng)關(guān)的作用。而當(dāng)企業(yè)只是將系統(tǒng)與系統(tǒng)之間的調(diào)用使用rest api的方式進(jìn)行訪問(wè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)來(lái)處理這部分內(nèi)部公網(wǎng)應(yīng)用，如果想比較簡(jiǎn)單的處理，也可以是使用面向合作伙伴的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)爭(zhēng)方案

1、對(duì)于Open API平臺(tái)的API網(wǎng)關(guān)，我分析只能選擇API網(wǎng)關(guān)作為解決方案，業(yè)界沒(méi)有發(fā)現(xiàn)比較好的可以用來(lái)作為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，這是新興的基于無(wú)API網(wǎng)關(guān)的架構(gòu)，通過(guò)在客戶端上的代理完成屏蔽網(wǎng)絡(luò)層的訪問(wèn)，這樣達(dá)到對(duì)應(yīng)用層最小的改動(dòng)，當(dāng)前Service Mesh的產(chǎn)品還正在開發(fā)中，并沒(méi)有非常成熟可直接應(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è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è)開源程序是國(guó)人開發(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模型。通過(guò)網(wǎng)上搜索可以看到國(guó)內(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)用核心，因此性能和可用性是必須要求的。

從性能上來(lái)說(shuō)，需要讓網(wǎng)關(guān)增加的時(shí)間消耗越短越好，個(gè)人覺(jué)得需要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)用接入、合作伙伴門戶集成、訪問(wèn)次數(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)品大多離很好的使用有一定的距離，如：沒(méi)有提供管理功能的UI界面、監(jiān)控功能弱小，不支持OpenAPI平臺(tái)，沒(méi)有公司運(yùn)營(yíng)與運(yùn)維的功能等。當(dāng)然開源產(chǎn)品能獲取源代碼，如果公司有比較強(qiáng)的研發(fā)能力，能hold住這些開源產(chǎn)品，經(jīng)過(guò)二次開發(fā)kong、zuul應(yīng)該還是適應(yīng)一些公司，不過(guò)需求注意以下一些點(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由于沒(méi)有被大量使用，同時(shí)是國(guó)內(nèi)個(gè)人在開源，在可持續(xù)性和社區(qū)資源上不夠豐富，出了問(wèn)題后可能不容易找到人問(wèn)。

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

5、公有云還是私有云
現(xiàn)在的亞馬遜、阿里、騰訊云都在提供基礎(chǔ)公有云的API網(wǎng)關(guān)，當(dāng)然這些網(wǎng)關(guān)的基礎(chǔ)功能肯定是沒(méi)有問(wèn)題，但是二次開發(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)用，無(wú)法做到定制的合作伙伴門戶，這也不適合于部分企業(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)只有滿足一部分簡(jiǎn)單客戶的需求，對(duì)于很多企業(yè)來(lái)說(shuō)私有云的API網(wǎng)關(guān)才是正確的選擇。

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

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

虞美人李煜

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

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

雨霖鈴 ·柳永

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

posted @ 2009-01-19 10:48 Coolfiry 閱讀(271) | 評(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 閱讀(1079) | 評(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.

#

說(shuō)明：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來(lái)實(shí)現(xiàn)). 在總結(jié)方式下(-V ) , 將僅顯示最高層的相關(guān)協(xié)議, 例如一個(gè)NFS 包將僅顯示NFS 信息, 其低層的RPC, UDP, IP, Ethernet 幀信息將不會(huì)顯示, 但是當(dāng)加上相應(yīng)的參數(shù)(-v ), 這些信息都能被顯示出來(lái).

-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ù)流的全部?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 抓來(lái)自192.168.1.0/24的數(shù)據(jù)

# snoop from net 192.168.0.0 抓來(lái)自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 閱讀(730) | 評(píng)論 (0) | 編輯收藏

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

在項(xiàng)目使用CXF的過(guò)程中,遇到了有關(guān)List作為傳輸參數(shù)的時(shí)候,如果WebService端沒(méi)有明確給出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);

這樣就完全解決問(wèn)題了。

posted @ 2008-08-05 20:09 Coolfiry 閱讀(4966) | 評(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í)其他語(yǔ)言的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 閱讀(598) | 評(píng)論 (2) | 編輯收藏

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

在項(xiàng)目開發(fā)過(guò)程中，遇到在本機(jī)和windows環(huán)境中部署用CXF框架開發(fā)的的webService沒(méi)有任何問(wèn)題，但是當(dāng)將工程部署到solaris 的SUN ONE application上時(shí)，再用本機(jī)的cxf Web服務(wù)客戶端訪問(wèn)對(duì)應(yīng)的web服務(wù)時(shí)，如果傳輸?shù)臄?shù)據(jù)量小于大約4K不會(huì)出問(wèn)題，否則則會(huì)報(bào)一些數(shù)據(jù)綁定的異常如：
Marshalling Error: Error writing request body to server。
解決這個(gè)問(wèn)題花了我足足兩天時(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è)問(wèn)題的解決方案是我在cxf的官網(wǎng)上找了很久才找到的，雖然問(wèn)題解決了，但是我感到很迷惑。主要在windows tomcat環(huán)境下沒(méi)有問(wèn)題，而到了SUN ONE的環(huán)境就有問(wèn)題，經(jīng)過(guò)的思考和找了一資料，我認(rèn)為問(wèn)題出于solaris對(duì)于HTTP數(shù)據(jù)傳輸?shù)哪承┫拗疲绻嬉ジ闱宄脑捒赡芤⒖碿xf的source code了，但是我不想花這個(gè)時(shí)間去研究這個(gè)問(wèn)題了。

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

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

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

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

簡(jiǎn)單的提高硬件性能并不能真正解決這個(gè)問(wèn)題，因?yàn)閱闻_(tái)服務(wù)器的性能總是有限的，一般來(lái)講，一臺(tái)PC服務(wù)器所能提供的并發(fā)訪問(wèn)處理能力大約為1000個(gè)，更為高檔的專用服務(wù)器能夠支持3000-5000個(gè)并發(fā)訪問(wèn)，這樣的能力還是無(wú)法滿足負(fù)載較大的網(wǎng)站的要求。尤其是網(wǎng)絡(luò)請(qǐng)求具有突發(fā)性，當(dāng)某些重大事件發(fā)生時(shí)，網(wǎng) 絡(luò)訪問(wèn)就會(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ù)器來(lái)分擔(dān)負(fù)載的時(shí)候，最簡(jiǎn)單的辦法是將不同的服務(wù)器用在不同的方面。按提供的內(nèi)容進(jìn)行分割時(shí)，可以將一臺(tái)服務(wù)器用于提供新聞頁(yè)面，而另一臺(tái)用于提供游戲頁(yè)面；或者可以按服務(wù)器的功能進(jìn)行分割，將一臺(tái)服務(wù)器用于提供靜態(tài)頁(yè)面訪問(wèn)，而另一些用于提供CGI等需要大量消耗資源的動(dòng)態(tài)頁(yè)面訪問(wèn)。然而由于網(wǎng)絡(luò)訪問(wèn)的突發(fā)性，使得很難確定那些頁(yè)面造成的負(fù)載太大，如果將服務(wù)的頁(yè)面分割的過(guò)細(xì)就會(huì)造成很大浪費(fèi)。事實(shí)上造成負(fù)載過(guò)大的頁(yè)面常常是在變化中的，如果要經(jīng)常按照負(fù)載變化來(lái)調(diào)整頁(yè)面所在的服務(wù)器，那么勢(shì)必對(duì)管理和維護(hù)造成極大的問(wèn) 題。因此這種分割方法只能是大方向的調(diào)整，對(duì)于大負(fù)載的網(wǎng)站，根本的解決辦法還需要應(yīng)用負(fù)載均衡技術(shù)。

負(fù)載均衡的思路下多臺(tái) 服務(wù)器為對(duì)稱方式，每臺(tái)服務(wù)器都具備等價(jià)的地位，都可以單獨(dú)對(duì)外提供服務(wù)而無(wú)須其他服務(wù)器的輔助。然后通過(guò)某種負(fù)載分擔(dān)技術(shù)，將外部發(fā)送來(lái)的請(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ǔ)空間等方法來(lái)完成，因此負(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è)功能來(lái)設(shè)計(jì)一種負(fù)載均衡的服務(wù)器。任何時(shí)候 Web服務(wù)器認(rèn)為自己負(fù)載較大的時(shí)候，它就不再直接發(fā)送回瀏覽器請(qǐng)求的網(wǎng)頁(yè)，而是送回一個(gè)Locaction指令，讓瀏覽器去服務(wù)器集群中的其他服務(wù)器上獲得所需要的網(wǎng)頁(yè)。

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

例如如果希望使用三個(gè)Web服務(wù)器來(lái)回應(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)是簡(jiǎ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ù)器之間的差異，它不能做到為性能較好的服務(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)頁(yè)的訪問(wèn)速度。因此也可以考慮使用這種技術(shù)，讓代理服務(wù)器將請(qǐng)求均勻轉(zhuǎn)發(fā)給多臺(tái)內(nèi)部Web服務(wù)器之一上，從而達(dá)到負(fù)載均衡的目的。這種代理方式與普通的代理方式有所不同，標(biāo)準(zhǔn)代理方式是客戶使用代理訪問(wèn)多個(gè)外部Web服務(wù)器，而這種代理方式是多個(gè)客戶使用它訪問(wèn)內(nèi)部Web服務(wù)器，因此也被稱為反向代理模式。

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

使用反向代理的好處是，可以將負(fù)載均衡和代理服務(wù)器的高速緩存技術(shù)結(jié)合在一起，提供有益的性能，具備額外的安全性，外部客戶不能直接訪問(wèn)真實(shí)的服務(wù)器。并且實(shí)現(xiàn)起來(lái)可以實(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èn)外部網(wǎng)絡(luò)，而當(dāng)外部網(wǎng)絡(luò)中的計(jì)算機(jī)訪問(wèn)地址轉(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)換可以通過(guò)軟件方式來(lái)實(shí)現(xiàn)，也可以通過(guò)硬件方式來(lái)實(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)來(lái)講，當(dāng)前負(fù)載均衡主要是解決Web服務(wù)器處理能力瓶頸的，而非網(wǎng)絡(luò)傳輸能力，很多站點(diǎn)的互聯(lián)網(wǎng)連接帶寬總共也不過(guò)10MB，只有極少的站點(diǎn)能夠擁有較高速的網(wǎng)絡(luò)連接，因此一般沒(méi)有必要使用這些負(fù)載均衡器這樣的昂貴設(shè)備。

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

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

上圖來(lái)自Linux Virtual Server Project，為他們使用IP隧道實(shí)現(xiàn)的這種負(fù)載分擔(dān)能力的請(qǐng)求/回應(yīng)過(guò)程，此時(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)起來(lái)比較困難，它的起點(diǎn)也很高，當(dāng)前情況下網(wǎng)站并不需要這么大的處理能力。

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

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

coolfiry

導(dǎo)航

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

Firend

Programing

搜索

最新評(píng)論

閱讀排行榜

評(píng)論排行榜