亚洲一区二区三区免费观看,亚洲精品无码不卡在线播HE,亚洲国产精品成人精品小说

2008年7月18日

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

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

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

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

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

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

一個企業(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)用的安排級別、訪問方式也不一樣。因此在我的設(shè)計中將這三種應(yīng)用分別用不同的網(wǎng)關(guā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、對于OpenAPI使用的API網(wǎng)關(guān)來說，一般合作伙伴要以應(yīng)用的形式接入到OpenAPI平臺，合作伙伴需要到 OpenAPI平臺申請應(yīng)用。因此在OpenAPI網(wǎng)關(guān)之外，需要有一個面向合作伙伴的使用的平臺用于合作伙伴，這就要求OpenAPI網(wǎng)關(guān)需要提供API給這個用戶平臺進行訪問。如下架構(gòu):

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

2、對于內(nèi)網(wǎng)的API網(wǎng)關(guān)，在起到的作用上來說可以認(rèn)為是微服務(wù)網(wǎng)關(guān)，也可以認(rèn)為是內(nèi)網(wǎng)的API服務(wù)治理平臺。當(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的方式進行訪問時使用API網(wǎng)關(guān)對調(diào)用進行管理，那么API網(wǎng)關(guān)起到的就是API服務(wù)治理的作用。架構(gòu)參考如下：

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

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

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

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

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

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

Service Mesh，這是新興的基于無API網(wǎng)關(guān)的架構(gòu)，通過在客戶端上的代理完成屏蔽網(wǎng)絡(luò)層的訪問，這樣達到對應(yī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ù)使用進展。

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

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

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

Kong kong是基于Nginx+Lua進行二次開發(fā)的方案， https://konghq.com/
Netflix Zuul，zuul是spring cloud的一個推薦組件，https://github.com/Netflix/zuul
orange,這個開源程序是國人開發(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都是基于這個方案
基于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)，那么需要從以下幾個方面去考慮。

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

從性能上來說，需要讓網(wǎng)關(guān)增加的時間消耗越短越好，個人覺得需要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ù)一臺服務(wù)器的crash都應(yīng)該不影響整體系統(tǒng)的可用性。
多套網(wǎng)關(guān)應(yīng)該支持同一管理平臺和同一監(jiān)控中心。如：一個企業(yè)的OpenAPI網(wǎng)關(guān)和內(nèi)部應(yīng)用的多個系統(tǒng)群的不同的微服務(wù)網(wǎng)關(guān)可以在同一監(jiān)控中心進行監(jiān)控。

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

kong是基于ngnix+lua的，從公司的角度比較難于找到能去維護這種架構(gòu)產(chǎn)品的人。需求評估當(dāng)前公司是否有這個能力去維護這個產(chǎn)品。
zuul因為架構(gòu)的原因在高并發(fā)的情況下性能不高，同時需要去基于研究整合開源的適配zuul的監(jiān)控和管理系統(tǒng)。
orange由于沒有被大量使用，同時是國內(nèi)個人在開源，在可持續(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ā)，擴展功能、監(jiān)控功能可能就不能滿足部分用戶的定制需求了。另外很多企業(yè)因為自身信息安全的原因，不能使用外網(wǎng)公有網(wǎng)的API網(wǎng)關(guān)服務(wù)，這樣就只有選擇私有云的方案了。
在需求上如果基于公有云的API網(wǎng)關(guān)只能做到由內(nèi)部人員為外網(wǎ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)只有滿足一部分簡單客戶的需求，對于很多企業(yè)來說私有云的API網(wǎng)關(guān)才是正確的選擇。

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

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

虞美人李煜

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

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

雨霖鈴 ·柳永

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

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

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

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

posted @ 2008-12-11 15:48 Coolfiry 閱讀(1072) | 評論 (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的名字時，代表www.163.com回答的主機的域名。

抓 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ù)，只抓廣播、主播、目的為本機的數(shù)據(jù)
Using device /dev/pcn0 (non promiscuous)
15 ^C                         15的含義是：顯示目前抓了多少個數(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)容

抓主機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

輸入（的時候要加轉(zhuǎn)義符號\

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

-C

-D

-N

-P 在非混雜模式下抓包

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

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

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

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

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

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

表達式：

根據(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的端口號或者 /etc/services里定義的名字

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

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

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

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

1 public boolean updateMessageStatus(List batchIds);

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

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

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

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

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

這樣就完全解決問題了。

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

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

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

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

這是第一個shell程序小例子，就相當(dāng)于一個學(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

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

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

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

在項目開發(fā)過程中，遇到在本機和windows環(huán)境中部署用CXF框架開發(fā)的的webService沒有任何問題，但是當(dāng)將工程部署到solaris 的SUN ONE application上時，再用本機的cxf Web服務(wù)客戶端訪問對應(yīng)的web服務(wù)時，如果傳輸?shù)臄?shù)據(jù)量小于大約4K不會出問題，否則則會報一些數(shù)據(jù)綁定的異常如：
Marshalling Error: Error writing request body to server。
解決這個問題花了我足足兩天時間，原因是有關(guān)CXF的資料太少了，而且有關(guān)于這個錯誤的解決都必須使用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>

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

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

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

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

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

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

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

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

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

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

例如如果希望使用三個Web服務(wù)器來回應(yīng)對www.exampleorg.org.cn的HTTP請求，就可以設(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
```
此后外部的客戶機就可能隨機的得到對應(yīng)www的不同地址，那么隨后的HTTP請求也就發(fā)送給不同地址了。

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

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

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

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

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

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

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

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

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

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

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

比較上面的負(fù)載均衡方式，DNS最容易，也最常用，能夠滿足一般的需求。但如果需要進一步的管理和控制，可以選用反向代理方式或NAT方式，這兩種之間進行選擇主要依賴緩沖是不是很重要，最大的并發(fā)訪問數(shù)量是多少等條件。而如果網(wǎng)站上對負(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 閱讀(255) | 評論 (0) | 編輯收藏

coolfiry

導(dǎo)航

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

Firend

Programing

搜索

最新評論

閱讀排行榜

評論排行榜