coolfiry

认认真真做人,兢兢业业做事!
posts - 39, comments - 17, trackbacks - 0, articles - 0

2007年6月10日

在这篇文章中将我们一起来探讨当前的API网关的作用。 

一、API网关的用处

API网关我的分析中会用到以下三种场景。 

  1. Open API。 企业需要将自身数据、能力等作为开发平台向外开放,通常会以rest的方式向外提供,最好的例子就是淘宝开放平台、腾讯公司的QQ开放平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等,必然会有一个统一的入口进行管理,这正是API网关可以发挥作用的时候。
  2. 微服务网关。微服务的概念最早在2012年提出,在Martin Fowler的大力推广下,微服务在2014年后得到了大力发展。 在微服务架构中,有一个组件可以说是必不可少的,那就是微服务网关,微服务网关处理了负载均衡,缓存,路由,访问控制,服务代理,监控,日志等。API网关在微服务架构中正是以微服务网关的身份存在。 
  3. API服务管理平台。上述的微服务架构对企业来说有可能实施上是困难的,企业有很多遗留系统,要全部抽取为微服务器改动太大,对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用,因此需要对系统间服务调用进行管理,清晰地看到各系统调用关系,对系统间调用进行监控等。 API网关可以解决这些问题,我们可以认为如果没有大规模的实施微服务架构,那么对企业来说微服务网关就是企业的API服务管理平台。

二、API网关在企业整体架构中的地位

一个企业随着信息系统复杂度的提高,必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等,在架构上应该将这三种应用区别开,三种应用的安排级别、访问方式也不一样。 因此在我的设计中将这三种应用分别用不同的网关进行API管理,分别是:API网关(OpenAPI合伙伙伴应用)、API网关(内部应用)、API网关(内部公网应用)。

 

三、企业中在如何应用API网关

1、对于OpenAPI使用的API网关来说,一般合作伙伴要以应用的形式接入到OpenAPI平台,合作伙伴需要到 OpenAPI平台申请应用。 因此在OpenAPI网关之外,需要有一个面向合作伙伴的使用的平台用于合作伙伴,这就要求OpenAPI网关需要提供API给这个用户平台进行访问。 如下架构:

 

当然如果是在简单的场景下,可能并不需要提供一个面向合作伙伴的门户,只需要由公司的运营人员直接添加合作伙伴应用id/密钥等,这种情况下也就不需要合作伙伴门户子系统。 

2、对于内网的API网关,在起到的作用上来说可以认为是微服务网关,也可以认为是内网的API服务治理平台。 当企业将所有的应用使用微服务的架构管理起来,那么API网关就起到了微服务网关的作用。 而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理,那么API网关起到的就是API服务治理的作用。 架构参考如下:

3、对于公司内部公网应用(如APP、公司的网站),如果管理上比较细致,在架构上是可能由独立的API网关来处理这部分内部公网应用,如果想比较简单的处理,也可以是使用面向合作伙伴的API网关。 如果使用独立的API网关,有以下的好处:

  • 面向合作伙伴和面向公司主体业务的优先级不一样,不同的API网关可以做到业务影响的隔离。
  • 内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。
  • 内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。

基于以上的分析,如果公司有能力,那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关。

四、API网关有哪些竞争方案

1、对于Open API平台的API网关,我分析只能选择API网关作为解决方案,业界没有发现比较好的可以用来作为Open API平台的入口的其他方案。 

2、对于作为微服务网关的API网关,业界的选择可以选择的解决方案比较多,也取决于微服务器的实现方案,有一些微服务架构的实现方案是不需要微服务网关的。

  • Service Mesh,这是新兴的基于无API网关的架构,通过在客户端上的代理完成屏蔽网络层的访问,这样达到对应用层最小的改动,当前Service Mesh的产品还正在开发中,并没有非常成熟可直接应用的产品。 发展最迅速的产品是Istio。 建议大家密切关注相关产品的研发、业务使用进展。

  • 基于duboo架构,在这个架构中通常是不需要网关的,是由客户端直接访问服务提供方,由注册中心向客户端返回服务方的地址。

五、API网关解决方案

私有云开源解决方案如下:

  • Kong kong是基于Nginx+Lua进行二次开发的方案, https://konghq.com/
  • Netflix Zuul,zuul是spring cloud的一个推荐组件,https://github.com/Netflix/zuul
  • orange,这个开源程序是国人开发的, http://orange.sumory.com/

公有云解决方案:

  • Amazon API Gateway,https://aws.amazon.com/cn/api-gateway/
  • 阿里云API网关,https://www.aliyun.com/product/apigateway/
  • 腾讯云API网关, https://cloud.tencent.com/product/apigateway

自开发解决方案:

  • 基于Nginx+Lua+ OpenResty的方案,可以看到Kong,orange都是基于这个方案
  • 基于Netty、非阻塞IO模型。 通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案,是一种成熟的方案。
  • 基于Node.js的方案。 这种方案是应用了Node.js天生的非阻塞的特性。
  • 基于java Servlet的方案。 zuul基于的就是这种方案,这种方案的效率不高,这也是zuul总是被诟病的原因。

六、企业怎么选择API网关

如果是要选择一款已有的API网关,那么需要从以下几个方面去考虑。 

1、性能与可用性
如果一旦采用了API网关,那么API网关就会作为企业应用核心,因此性能和可用性是必须要求的。

  • 从性能上来说,需要让网关增加的时间消耗越短越好,个人觉得需要10ms以下。 系统需要采用非阻塞的IO,如epoll,NIO等。网关和各种依赖的交互也需要是非阻塞的,这样才能保证整体系统的高可用性,如:Node.js的响应式编程和基于java体现的RxJava和Future。
  • 网关必须支持集群部署,任务一台服务器的crash都应该不影响整体系统的可用性。
  • 多套网关应该支持同一管理平台和同一监控中心。 如: 一个企业的OpenAPI网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。

2、可扩展性、可维护性
一款产品总有不能满足生产需求的地方,因此需求思考产品在如何进行二次开发和维护,是否方便公司团队接手维护产品。 
3、需求匹配度
需要评估各API网关在需求上是否能满足,如: 如果是OpenAPI平台需要使用API网关,那么需要看API网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OpenAPI核心需求上去思考产品是否能满足要求。 如果是微服务网关,那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。
4、是否开源?公司是否有自开发的能力?
现有的开源产品如kong,zuul,orange都有基础的API网关的核心功能,这些开源产品大多离很好的使用有一定的距离,如:没有提供管理功能的UI界面、监控功能弱小,不支持OpenAPI平台,没有公司运营与运维的功能等。 当然开源产品能获取源代码,如果公司有比较强的研发能力,能hold住这些开源产品,经过二次开发kong、zuul应该还是适应一些公司,不过需求注意以下一些点:

  • kong是基于ngnix+lua的,从公司的角度比较难于找到能去维护这种架构产品的人。 需求评估当前公司是否有这个能力去维护这个产品。
  • zuul因为架构的原因在高并发的情况下性能不高,同时需要去基于研究整合开源的适配zuul的监控和管理系统。
  • orange由于没有被大量使用,同时是国内个人在开源,在可持续性和社区资源上不够丰富,出了问题后可能不容易找到人问。

另外kong提供企业版本的API网关,当然也是基于ngnix+lua的,企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。

5、公有云还是私有云
现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关,当然这些网关的基础功能肯定是没有问题,但是二次开发,扩展功能、监控功能可能就不能满足部分用户的定制需求了。另外很多企业因为自身信息安全的原因,不能使用外网公有网的API网关服务,这样就只有选择私有云的方案了。 
在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用,无法做到定制的合作伙伴门户,这也不适合于部分企业的需求。 
如果作为微服务网关,大多数情况下是希望网关服务器和服务提供方服务器是要在内网的,在这里情况下也只有私有云的API网关才能满足需求。 

综合上面的分析,基础公有云的API网关只有满足一部分简单客户的需求,对于很多企业来说私有云的API网关才是正确的选择。


文章作者介绍:
来自于小豹科技的架构师-专注于软件研发基于平台性软件的研发,目前我正在研发一款基于Netty、响应式架构的插件式的API网关,希望能对行业带来一些改变。 我希望与对OpenAPI、微服务、API网关、Service Mesh等感兴趣的朋友多交流。 有兴趣的朋友请加我的QQ群244054462。

posted @ 2018-01-05 13:42 Coolfiry 阅读(4650) | 评论 (0)编辑 收藏

虞美人 李煜
春花秋月何时了,往事知多少?小楼昨夜又东风,故国不堪回首月明中。雕栏玉砌应犹在,只是朱颜改。问君能有几多愁,恰似一江春水向东流。 

posted @ 2009-01-19 10:49 Coolfiry 阅读(243) | 评论 (0)编辑 收藏

雨霖铃 ·柳永


寒蝉凄切。对长亭晚,骤雨初歇。都门帐饮无绪,留恋处、兰舟催发。执手相看泪眼,竟无语凝噎。念去去、千里烟波,暮霭沉沉楚天阔。
多情自古伤离别,更那堪冷落清秋节!今宵酒醒何处?杨柳岸、晓风残月。此去经年,应是良辰好景虚设。便纵有千种风情,更与何人说?

posted @ 2009-01-19 10:48 Coolfiry 阅读(232) | 评论 (0)编辑 收藏

1、python的入门级内容。
2、java mail的使用基本用法和注意事项。
3、CXF中相关BUG的解决方法。
4、UNIX 网络编程步步提升系列。

posted @ 2008-12-11 15:48 Coolfiry 阅读(1049) | 评论 (5)编辑 收藏

转自:http://bbs.chinaunix.net/viewthread.php?tid=691982&extra=&page=1
snoop 抓包
solaris自带snoop抓包工具,抓所有数据流

# 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的数据流:

# 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之间的数据流(双向都抓)

# 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.
#

抓完存在当前目录下的cap文件中并查看

# snoop -o cap1 -P      -P表示处在非混杂模式抓数据,只抓广播、主播、目的为本机的数据
Using device /dev/pcn0 (non promiscuous)
15 ^C                           15的含义是:显示目前抓了多少个数据流
#

# 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条数据流的包头的详细内容

#snoop -i cap1 -v -x 0 -p101   查看第10条数据流的全部的详细内容

抓主机192.168.253.35和202.101.98.55之间的tcp或者udp端口53的数据

# snoop 192.168.253.35 and 202.101.98.55 and \(tcp or udp\) and port 53

输入(的时候要加转义符号\


snoop的详细参数
Snoop 是Solaris 系统中自带的工具, 是一个用于显示网络通讯的程序, 它可捕获IP 包并将其显示或保存到指定文件. (限超级用户使用snoop)
Snoop 可将捕获的包以一行的形式加以总结或用多行加以详细的描述(有调用不同的参数–v -V来实现). 在总结方式下(-V ) , 将仅显示最高层的相关协议, 例如一个NFS 包将仅显示NFS 信息, 其低层的RPC, UDP, IP, Ethernet 帧信息将不会显示, 但是当加上相应的参数(-v ), 这些信息都能被显示出来.

-C

-D

-N

-P 在非混杂模式下抓包

-S 抓包的时候显示数据包的大小

-V 半详细的显示抓的数据的信息

-t [ r | a | d ] 显示时间戳,-ta显示当前系统时间,精确到毫秒

-v 最详细的显示数据的信息

-x offset [ , length] 以16进制或ACSII方式显示某数据的部分内容,比如 -x 0,10 只显示0-10字节

#snoop -i cap1 -v -x 0 -p101 查看被抓获的第101个数据流的全部内容


表达式:

根据地址:

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

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

数据的方向:

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

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

可用的数据类型的关键词:

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的数据

# snoop from net 192.168.0.0 抓来自192.168.0.0/16的数据

port xx XX为TCP或者UDP的端口号或者 /etc/services里定义的名字

#snoop to udp and port 53    抓到UDP53的数据

posted @ 2008-10-21 21:30 Coolfiry 阅读(703) | 评论 (0)编辑 收藏

在项目使用CXF的过程中,遇到了有关List作为传输参数的时候,如果WebService端没有明确给出List的泛型类型会报错。
例如
CXF的WebService端口接口的一个方法为为:
1 public boolean updateMessageStatus(List batchIds);

客户端的的调用为:
1 //预先初始化cxf对象cxfObj
2 List<String> list=new ArrayList<String>();
3 list.add("1");
4 cxfObj.updateMessageStatus(list);


在客户端进行调用WebService时会发生错误,错误为:unexpected element (uri:"", local:"arg0")等,据分析生成的wsdl,这是因为CXF在进行数据marshal时不知道要将要转换的类型。

解决办法是:在WebService端的接口必须用List的泛型类型参数,如:

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

这样就完全解决问题了。

posted @ 2008-08-05 20:09 Coolfiry 阅读(4910) | 评论 (1)编辑 收藏

现在正在学习linux shell编程
first.sh
while read line
do
        echo 
"$line"
done 
<"$1"
这是第一个shell程序小例子,就相当于一个学习其他语言的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的数字到stdout中。其中用到的expr的作用是使expr的参数转化为数字并相加。两个单引号的作用是引号所包围的命令被命令的标准输出替换,并输出赋值给我number,得到了如同java中number=number+1的效果。


posted @ 2008-07-20 20:34 Coolfiry 阅读(570) | 评论 (2)编辑 收藏

在项目开发过程中,遇到在本机和windows环境中部署用CXF框架开发的的webService没有任何问题,但是当将工程部署到solaris 的SUN ONE application上时,再用本机的cxf Web服务客户端访问对应的web服务时,如果传输的数据量小于大约4K不会出问题,否则则会报一些数据绑定的异常如:
Marshalling Error: Error writing request body to server。
解决这个问题花了我足足两天时间,原因是有关CXF的资料太少了,而且有关于这个错误的解决都必须使用google才能search到,用baidu完全search不到相关的资料。
解决方案:
在客户端的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的官网上找了很久才找到的,虽然问题解决了,但是我感到很迷惑。主要在windows tomcat环境下没有问题,而到了SUN ONE的环境就有问题,经过的思考和找了一资料,我认为问题出于solaris对于HTTP数据传输的某些限制,如果真要去搞清楚的话可能要去参看cxf的source code了,但是我不想花这个时间去研究这个问题了。

我把这个解决方案写出来,希望可以帮助到使用CXF的网友,也希望高手们能帮我解决我的迷惑。



posted @ 2008-07-18 19:11 Coolfiry 阅读(2497) | 评论 (0)编辑 收藏

Internet的快速增长使多媒体网络服务器,特别是Web服务器,面对的访问者数量快速增加,网络服务器需要具备提供大量并发访问服务的能力。 例如Yahoo每天会收到数百万次的访问请求,因此对于提供大负载Web服务的服务器来讲,CPU、I/O处理能力很快会成为瓶颈。

简单的 提高硬件性能并不能真正解决这个问题,因为单台服务器的性能总是有限的,一般来讲,一台PC服务器所能提供的并发访问处理能力大约为1000个,更为高档 的专用服务器能够支持3000-5000个并发访问,这样的能力还是无法满足负载较大的网站的要求。尤其是网络请求具有突发性,当某些重大事件发生时,网 络访问就会急剧上升,从而造成网络瓶颈,例如在网上发布的克林顿弹劾书就是很明显的例子。必须采用多台服务器提供网络服务,并将网络请求分配给这些服务器 分担,才能提供处理大量并发服务的能力。

当使用多台服务器来分担负载的时候,最简单的办法是将不同的服务器用在不同的方面。 按提供的内容进行分割时,可以将一台服务器用于提供新闻页面,而另一台用于提供游戏页面;或者可以按服务器的功能进行分割,将一台服务器用于提供静态页面 访问,而另一些用于提供CGI等需要大量消耗资源的动态页面访问。然而由于网络访问的突发性,使得很难确定那些页面造成的负载太大,如果将服务的页面分割 的过细就会造成很大浪费。事实上造成负载过大的页面常常是在变化中的,如果要经常按照负载变化来调整页面所在的服务器,那么势必对管理和维护造成极大的问 题。因此这种分割方法只能是大方向的调整,对于大负载的网站,根本的解决办法还需要应用负载均衡技术。

负载均衡的思路下多台 服务器为对称方式,每台服务器都具备等价的地位,都可以单独对外提供服务而无须其他服务器的辅助。然后通过某种负载分担技术,将外部发送来的请求均匀分配 到对称结构中的某一台服务器上,而接收到请求的服务器都独立回应客户机的请求。由于建立内容完全一致的Web服务器并不复杂,可以使用服务器同步更新或者 共享存储空间等方法来完成,因此负载均衡技术就成为建立一个高负载Web站点的关键性技术。

  1. 基于特定服务器软件的负载均衡

    很 多网络协议都支持“重定向”功能,例如在HTTP协议中支持Location指令,接收到这个指令的浏览器将自动重定向到Location指明的另一个 URL上。由于发送Location指令比起执行服务请求,对Web服务器的负载要小的多,因此可以根据这个功能来设计一种负载均衡的服务器。任何时候 Web服务器认为自己负载较大的时候,它就不再直接发送回浏览器请求的网页,而是送回一个Locaction指令,让浏览器去服务器集群中的其他服务器上 获得所需要的网页。

    在这种方式下,服务器本身必须支持这种功能,然而具体实现起来却有很多困难,例如一台服务器如何能保证它重定向过的服务 器是比较空闲的,并且不会再次发送Location指令?Location指令和浏览器都没有这方面的支持能力,这样很容易在浏览器上形成一种死循环。因 此这种方式实际应用当中并不多见,使用这种方式实现的服务器集群软件也较少。有些特定情况下可以使用CGI(包括使用FastCGI或mod_perl扩 展来改善性能)来模拟这种方式去分担负载,而Web服务器仍然保持简洁、高效的特性,此时避免Location循环的任务将由用户的CGI程序来承担。

  2. 基于DNS的负载均衡

    由 于基于服务器软件的负载均衡需要改动软件,因此常常是得不偿失,负载均衡最好是在服务器软件之外来完成,这样才能利用现有服务器软件的种种优势。最早的负 载均衡技术是通过DNS服务中的随机名字解析来实现的,在DNS服务器中,可以为多个不同的地址配置同一个名字,而最终查询这个名字的客户机将在解析这个 名字时得到其中的一个地址。因此,对于同一个名字,不同的客户机会得到不同的地址,他们也就访问不同地址上的Web服务器,从而达到负载均衡的目的。

    例如如果希望使用三个Web服务器来回应对www.exampleorg.org.cn的HTTP请求,就可以设置该域的DNS服务器中关于该域的数据包括有与下面例子类似的结果:

    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

    此后外部的客户机就可能随机的得到对应www的不同地址,那么随后的HTTP请求也就发送给不同地址了。

    DNS 负载均衡的优点是简单、易行,并且服务器可以位于互联网的任意位置上,当前使用在包括Yahoo在内的Web站点上。然而它也存在不少缺点,一个缺点是为 了保证DNS数据及时更新,一般都要将DNS的刷新时间设置的较小,但太小就会造成太大的额外网络流量,并且更改了DNS数据之后也不能立即生效;第二点 是DNS负载均衡无法得知服务器之间的差异,它不能做到为性能较好的服务器多分配请求,也不能了解到服务器的当前状态,甚至会出现客户请求集中在某一台服 务器上的偶然情况。

  3. 反向代理负载均衡

    使用代理服务器可以将请求转发给内部的Web服务器,使用这种加速 模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术,让代理服务器将请求均匀转发给多台内部Web服务器之一上,从而达到负载均衡的目的。 这种代理方式与普通的代理方式有所不同,标准代理方式是客户使用代理访问多个外部Web服务器,而这种代理方式是多个客户使用它访问内部Web服务器,因 此也被称为反向代理模式。

    实现这个反向代理能力并不能算是一个特别复杂的任务,但是在负载均衡中要求特别高的效率,这样实现起来就不是十分 简单的了。每针对一次代理,代理服务器就必须打开两个连接,一个为对外的连接,一个为对内的连接,因此对于连接请求数量非常大的时候,代理服务器的负载也 就非常之大了,在最后反向代理服务器会成为服务的瓶颈。例如,使用Apache的mod_rproxy模块来实现负载均衡功能时,提供的并发连接数量受 Apache本身的并发连接数量的限制。一般来讲,可以使用它来对连接数量不是特别大,但每次连接都需要消耗大量处理资源的站点进行负载均衡,例如搜寻。

    使 用反向代理的好处是,可以将负载均衡和代理服务器的高速缓存技术结合在一起,提供有益的性能,具备额外的安全性,外部客户不能直接访问真实的服务器。并且 实现起来可以实现较好的负载均衡策略,将负载可以非常均衡的分给内部服务器,不会出现负载集中到某个服务器的偶然现象。

  4. 基于NAT的负载均衡技术

    网 络地址转换为在内部地址和外部地址之间进行转换,以便具备内部地址的计算机能访问外部网络,而当外部网络中的计算机访问地址转换网关拥有的某一外部地址 时,地址转换网关能将其转发到一个映射的内部地址上。因此如果地址转换网关能将每个连接均匀转换为不同的内部服务器地址,此后外部网络中的计算机就各自与 自己转换得到的地址上服务器进行通信,从而达到负载分担的目的。

    地 址转换可以通过软件方式来实现,也可以通过硬件方式来实现。使用硬件方式进行操作一般称为交换,而当交换必须保存TCP连接信息的时候,这种针对OSI网 络层的操作就被称为第四层交换。支持负载均衡的网络地址转换为第四层交换机的一种重要功能,由于它基于定制的硬件芯片,因此其性能非常优秀,很多交换机声 称具备400MB-800MB的第四层交换能力,然而也有一些资料表明,在如此快的速度下,大部分交换机就不再具备第四层交换能力了,而仅仅支持第三层甚 至第二层交换。

    然而对于大部分站点来讲,当前负载均衡主要是解决Web服务器处理能力瓶颈的,而非网络传输能力,很多站点的互联网连接带宽总共也不过10MB,只有极少的站点能够拥有较高速的网络连接,因此一般没有必要使用这些负载均衡器这样的昂贵设备。

    使 用软件方式来实现基于网络地址转换的负载均衡则要实际的多,除了一些厂商提供的解决方法之外,更有效的方法是使用免费的自由软件来完成这项任务。其中包括 Linux Virtual Server Project中的NAT实现方式,或者本文作者在FreeBSD下对natd的修订版本。一般来讲,使用这种软件方式来实现地址转换,中心负载均衡器存 在带宽限制,在100MB的快速以太网条件下,能得到最快达80MB的带宽,然而在实际应用中,可能只有40MB-60MB的可用带宽。

  5. 扩展的负载均衡技术

上 面使用网络地址转换来实现负载分担,毫无疑问所有的网络连接都必须通过中心负载均衡器,那么如果负载特别大,以至于后台的服务器数量不再在是几台、十几 台,而是上百台甚至更多,即便是使用性能优秀的硬件交换机也回遇到瓶颈。此时问题将转变为,如何将那么多台服务器分布到各个互联网的多个位置,分散网络负 担。当然这可以通过综合使用DNS和NAT两种方法来实现,然而更好的方式是使用一种半中心的负载均衡方式。

在这种半中心的负载均衡方式下,即当客户请求发送给负载均衡器的时候,中心负载均衡器将请求打包并发送给某个服务器,而服务器的回应请求不再返回给中心负载均衡器,而是直接返回给客户,因此中心负载均衡器只负责接受并转发请求,其网络负担就较小了。

上图来自Linux Virtual Server Project,为他们使用IP隧道实现的这种负载分担能力的请求/回应过程,此时每个后台服务器都需要进行特别的地址转换,以欺骗浏览器客户,认为它的回应为正确的回应。

同样,这种方式的硬件实现方式也非常昂贵,但是会根据厂商的不同,具备不同的特殊功能,例如对SSL的支持等。

由于这种方式比较复杂,因此实现起来比较困难,它的起点也很高,当前情况下网站并不需要这么大的处理能力。

比 较上面的负载均衡方式,DNS最容易,也最常用,能够满足一般的需求。但如果需要进一步的管理和控制,可以选用反向代理方式或NAT方式,这两种之间进行 选择主要依赖缓冲是不是很重要,最大的并发访问数量是多少等条件。而如果网站上对负载影响很厉害的CGI程序是由网站自己开发的,也可以考虑在程序中自己 使用Locaction来支持负载均衡。半中心化的负载分担方式至少在国内当前的情况下还不需要。
http://galaxystar.javaeye.com/blog/50546

posted @ 2008-07-18 14:23 Coolfiry 阅读(234) | 评论 (0)编辑 收藏

在Java版发表这篇文章,似乎有点把矛头指向Java了。其实不是,GC是所有新一代语言共有的特征,
Python, Eiffel,C#,Roby等无一例外地都使用了GC机制。但既然Java中的GC最为著名,所以天塌
下来自然应该抗着。

这篇短文源于comp.lang.java.programmer跟comp.lang.c++上发生的一场大辩论,支持C++和Java
的两派不同势力展开了新世纪第一场冲突,跟贴发言超过350,两派都有名角压阵。C++阵营的擂主是
Pete Becker,ACM会员,Dinkumware Ltd. 的技术副总监。此君精通C++和Java,开发过两种语言的
核心类库,但是却对C++狂热之极,而对于Java颇不以为然。平时谈到Java的时候还好,一旦有人胆
敢用Java来批判C++,立刻忍不住火爆脾气跳将出来,以坚韧不拔的毅力和大无畏精神与对手周旋,
舌战群儒,哪怕只剩下一个人也要血战到底。这等奇人当真少见!我真奇怪他整天泡在usenet上,
不用工作么?他的老板P.J. Plauger如此宽宏大量?Java阵营主角是一个网名Razzi的兄弟,另外有
Sun公司大名鼎鼎的Peter van der Linden助阵,妙语连珠,寸土必争,加上人多势众,一度占据优势。
C++阵营里大拿虽然很多,但是大多数没有Pete那么多闲工夫,例如Greg Comeau,Comeau公司老板,
每次来个只言片语,实在帮不了Pete多大忙。但是自从C++阵营中冒出一个无名小子,网名Courage(勇气),
发动对Java GC机制的批判,形势为之一变。C++阵营眼下处于全攻之势,Java阵营疲于防守,只能
招架说:“你们没有证据,没有统计资料”,形势很被动。

垃圾收集(GC)不是一直被Java fans用来炫耀,引以为傲的优点么?怎么成了弱点了?我大惑不解,定睛
一看,才觉得此中颇有道理。

首先,Java Swing库存在大量资源泄漏问题,这一点SUN非常清楚,称之为bugs,正在极力修正。但是看来
这里的问题恐怕不仅是库编写者的疏忽,可能根源在于深层的机制,未必能够轻易解决,搞不好要伤筋动骨。
不过这个问题不是那么根本,C++阵营觉得如果抓住对方的弱点攻击,就算是占了上风也没什么说服力。谁
没有缺点呢?于是反其道而行之,猛烈攻击Java阵营觉得最得意的东西,Java的GC机制本身。

首先来想一想,memory leak到底意味着什么。在C++中,new出来的对象没有delete,这就导致了memory
leak。但是C++早就有了克服这一问题的办法——smart pointer。通过使用标准库里设计精致的auto_ptr
以及各种STL容器,还有例如boost库(差不多是个准标准库了)中的四个smart pointers,C++
程序员只要
花上一个星期的时间学习最新的资料,就可以拍着胸脯说:“我写的
程序没有memory leak!”。

相比之下,Java似乎更优秀,因为从一开始你就不用考虑什么特殊的机制,大胆地往前new,自有GC替你
收拾残局。Java的GC实际上是
JVM中的一个独立线程,采用不同的算法策略来收集heap中那些不再有
reference指向的垃圾对象所占用的内存。但是,通常情况下,GC线程的优先级比较低,只有在当前
程序
空闲的时候才会被调度,收集垃圾。当然,如果JVM感到内存紧张了,JVM会主动调用GC来收集垃圾,获取
更多的内存。请注意,Java的GC工作的时机是:1. 当前
程序不忙,有空闲时间。2. 空闲内存不足。
现在我们考虑一种常见的情况,
程序在紧张运行之中,没哟空闲时间给GC来运行,同时机器内存很大,
JVM也没有感到内存不足,结果是什么?对了,GC形同虚设,得不到调用。于是,内存被不断吞噬,而那些
早已经用不着的垃圾对象仍在在宝贵的内存里睡大觉。例如:

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();
    }
}

运行中,虽然garbage对象在离开job1()之后,就再也没有用了。但是因为程序忙,内存还够用,所以GC得
不到调度,garbage始终不会被回收,直到
程序运行到bgc.job1000()时还躺在内存里嘲笑你。没辙吧!

好了,我承认这段程序很傻。但是你不要以为这只是理论上的假设,恰恰相反,大多数实用中的Java程序都有
类似的效应。这就是为什么Java
程序狂耗内存,而且好像给它多少内存吃都不够。你花上大笔的银子把内存
从128升到256,再升到512,结果是,一旦执行复杂任务,内存还是被轻易填满,而且多出来的这些内存只是
用来装垃圾,GC还是不给面子地千呼万唤不出来。等到你的内存终于心力交瘁,GC才姗姗来迟,收拾残局。而
且GC工作的方式也很不好评价,一种方法是一旦有机会回收内存,就把所有的垃圾都回收。你可以想象,这要
花很长时间(几百M的垃圾啊!),如果你这时侯正在压下开炮的按钮,GC却叫了暂定,好了,你等死吧!另一
种方法,得到机会之后,回收一些内存,让JVM感到内存不那么紧张时就收手。结果呢,内存里始终有大批垃
圾,
程序始终在半死不活的荡着。最后,GC可以每隔一段时间就运行一次,每次只回收一部分垃圾,这是现在
大部分JVM的方式,结果是内存也浪费了,还动不动暂停几百毫秒。难啊!

反过来看看C++利用smart pointer达成的效果,一旦某对象不再被引用,系统刻不容缓,立刻回收内存。这
通常发生在关键任务完成后的清理(cleanup)时期,不会影响关键任务的实时性,同时,内存里所有的对象
都是有用的,绝对没有垃圾空占内存。怎么样?传统、朴素的C++是不是更胜一筹?

据统计,目前的Java程序运行期间占用的内存通常为对应C++程序的4-20倍。除了其它的原因,上面所说的是一个
非常主要的因素。我们对memory leak如此愤恨,不就是因为它导致大量的内存垃圾得不到清除吗?如果有了
GC之后,垃圾比以前还来势汹汹,那么GC又有什么好处呢?

当然,C++的smart pointer现在会使用的人不多,所以现在的C++程序普遍存在更严重的memory leak问题。
但是,如果我奶奶跟舒马赫比赛车输掉了,你能够埋怨那辆车子么?
http://www.594k.com/java/html/y2007m1/12051/

posted @ 2007-10-12 10:43 Coolfiry 阅读(619) | 评论 (1)编辑 收藏

从LiveJournal后台发展看大规模网站性能优化方法

一、LiveJournal发展历程

LiveJournal是99年始于校园中的项目,几个人出于爱好做了这样一个应用,以实现以下功能:

  • 博客,论坛
  • 社会性网络,找到朋友
  • 聚合,把朋友的文章聚合在一起

LiveJournal采用了大量的开源软件,甚至它本身也是一个开源软件。

在上线后,LiveJournal实现了非常快速的增长:

  • 2004年4月份:280万注册用户。
  • 2005年4月份:680万注册用户。
  • 2005年8月份:790万注册用户。
  • 达到了每秒钟上千次的页面请求及处理。
  • 使用了大量MySQL服务器。
  • 使用了大量通用组件。

二、LiveJournal架构现状概况

livejournal_backend.png

三、从LiveJournal发展中学习

 

LiveJournal从1台服务器发展到100台服务器,这其中经历了无数的伤痛,但同时也摸索出了解决这些问题的方法,通过对LiveJournal的学习,可以让我们避免LJ曾经犯过的错误,并且从一开始就对系统进行良好的设计,以避免后期的痛苦。

下面我们一步一步看LJ发展的脚步。

1、一台服务器

一 台别人捐助的服务器,LJ最初就跑在上面,就像Google开始时候用的破服务器一样,值得我们尊敬。这个阶段,LJ的人以惊人的速度熟悉的Unix的操 作管理,服务器性能出现过问题,不过还好,可以通过一些小修小改应付过去。在这个阶段里LJ把CGI升级到了FastCGI。

最终问题出现了,网站越来越慢,已经无法通过优过化来解决的地步,需要更多的服务器,这时LJ开始提供付费服务,可能是想通过这些钱来购买新的服务器,以解决当时的困境。
毫无疑问,当时LJ存在巨大的单点问题,所有的东西都在那台服务器的铁皮盒子里装着。

LJ-backend-7.png

2、两台服务器

用付费服务赚来的钱LJ买了两台服务器:一台叫做Kenny的Dell 6U机器用于提供Web服务,一台叫做Cartman的Dell 6U服务器用于提供数据库服务。

LJ-backend-8.png

LJ有了更大的磁盘,更多的计算资源。但同时网络结构还是非常简单,每台机器两块网卡,Cartman通过内网为Kenny提供MySQL数据库服务。

暂时解决了负载的问题,新的问题又出现了:

  • 原来的一个单点变成了两个单点。
  • 没有冷备份或热备份。
  • 网站速度慢的问题又开始出现了,没办法,增长太快了。
  • Web服务器上CPU达到上限,需要更多的Web服务器。

3、四台服务器

又买了两台,Kyle和Stan,这次都是1U的,都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。

LJ-backend-9.png

LJ把Kenny用于外部的网关,使用mod_backhand进行负载均横。

然后问题又出现了:

  • 单点故障。数据库和用于做网关的Web服务器都是单点,一旦任何一台机器出现问题将导致所有服务不可用。虽然用于做网关的Web服务器可以通过保持心跳同步迅速切换,但还是无法解决数据库的单点,LJ当时也没做这个。
  • 网站又变慢了,这次是因为IO和数据库的问题,问题是怎么往应用里面添加数据库呢?

4、五台服务器

又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式),写操作全部针对主数据库(通过Binlog,主服务器上的写操作可以迅速同步到从服务器上),读操作在两个数据库上同时进行(也算是负载均横的一种吧)。

LJ-backend-10.png

实现同步时要注意几个事项:

  • 读操作数据库选择算法处理,要选一个当前负载轻一点的数据库。
  • 在从数据库服务器上只能进行读操作
  • 准备好应对同步过程中的延迟,处理不好可能会导致数据库同步的中断。只需要对写操作进行判断即可,读操作不存在同步问题。

5、更多服务器

有钱了,当然要多买些服务器。部署后快了没多久,又开始慢了。这次有更多的Web服务器,更多的数据库服务器,存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。

LJ-backend-11.png

6、现在我们在哪里:

LJ-backend-1.png

现在服务器基本上够了,但性能还是有问题,原因出在架构上。

数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内,这样唯一的好处就是将读操作分布到了多台机器,但这样带来的后果就是写操作被大量分发,每台机器都要执行,服务器越多,浪费就越大,随着写操作的增加,用于服务读操作的资源越来越少。

LJ-backend-2.png

由一台分布到两台

LJ-backend-3.png

最终效果

现在我们发现,我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID,数据库也进行了备份,这么多的备份完全是对资源的浪费,属于冗余极端过度。那为什么不把数据分布存储呢?

问题发现了,开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储,以实现数据的分布式存储,让每台机器只为相对固定的用户服务,以实现平行的架构和良好的可扩展性。

为 了实现用户分组,我们需要为每一个用户分配一个组标记,用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个slave 组成,并且slave的数量在2-3台,以实现系统资源的最合理分配,既保证数据读操作分布,又避免数据过度冗余以及同步操作对系统资源的过度消耗。

LJ-backend-4.png

由一台(一组)中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上,所有针对用户的操作需要先查询这台机器得到用户的组号,然后再到相应的数据库组中获取数据。

这样的用户架构与目前LJ的架构已经很相像了。

在具体的实现时需要注意几个问题:

  • 在数据库组内不要使用自增ID,以便于以后在数据库组之间迁移用户,以实现更合理的I/O,磁盘空间及负载分布。
  • 将userid,postid存储在全局服务器上,可以使用自增,数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。
  • 在数据库组之间迁移用户时要万分小心,当迁移时用户不能有写操作。

7、现在我们在哪里

LJ-backend-5.png

问题:

  • 一个全局主服务器,挂掉的话所有用户注册及写操作就挂掉。
  • 每个数据库组一个主服务器,挂掉的话这组用户的写操作就挂掉。
  • 数据库组从服务器挂掉的话会导致其它服务器负载过大。

对于Master-Slave模式的单点问题,LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的,并不是由MySQL直接提供的,实际上也就是两台机器同时是Master,也同时是Slave,互相同步。

Master-Master实现时需要注意:

  • 一个Master出错后恢复同步,最好由服务器自动完成。
  • 数字分配,由于同时在两台机器上写,有些ID可能会冲突。

解决方案:

  • 奇偶数分配ID,一台机器上写奇数,一台机器上写偶数
  • 通过全局服务器进行分配(LJ采用的做法)。

 

Master-Master模式还有一种用法,这种方法与前一种相比,仍然保持两台机器的同步,但只有一台机器提供服务(读和写),在每天晚上的时候进行轮换,或者出现问题的时候进行切换。

8、现在我们在哪里

LJ-backend-6.png

现在插播一条广告,MyISAM VS InnoDB。

使用InnoDB:

  • 支持事务
  • 需要做更多的配置,不过值得,可以更安全的存储数据,以及得到更快的速度。

使用MyISAM:

  • 记录日志(LJ用它来记网络访问日志)
  • 存储只读静态数据,足够快。
  • 并发性很差,无法同时读写数据(添加数据可以)
  • MySQL非正常关闭或死机时会导致索引错误,需要使用myisamchk修复,而且当访问量大时出现非常频繁。

9、缓存

去年我写过一篇文章介绍memcached,它就是由LJ的团队开发的一款缓存工具,以key-value的方式将数据存储到分布的内存中。LJ缓存的数据:

  • 12台独立服务器(不是捐赠的)
  • 28个实例
  • 30GB总容量
  • 90-93%的命中率(用过squid的人可能知道,squid内存加磁盘的命中率大概在70-80%)

如何建立缓存策略?

想缓存所有的东西?那是不可能的,我们只需要缓存已经或者可能导致系统瓶颈的地方,最大程度的提交系统运行效率。通过对MySQL的日志的分析我们可以找到缓存的对象。

缓存的缺点?

  • 没有完美的事物,缓存也有缺点:
  • 增大开发量,需要针对缓存处理编写特殊的代码。
  • 管理难度增加,需要更多人参与系统维护。
  • 当然大内存也需要钱。

10、Web访问负载均衡

在数据包级别使用BIG-IP,但BIG-IP并不知道我们内部的处理机制,无法判断由哪台服务器对这些请求进行处理。反向代理并不能很好的起到作用,不是已经够快了,就是达不到我们想要的效果。

所以,LJ又开发了Perlbal。特点:

  • 快,小,可管理的http web 服务器/代理
  • 可以在内部进行转发
  • 使用Perl开发
  • 单线程,异步,基于事件,使用epoll , kqueue
  • 支持Console管理与http远程管理,支持动态配置加载
  • 多种模式:web服务器,反向代理,插件
  • 支持插件:GIF/PNG互换?

11、MogileFS

LJ使用开源的MogileFS作为分布式文件存储系统。MogileFS使用非常简单,它的主要设计思想是:

  • 文件属于类(类是最小的复制单位)
  • 跟踪文件存储位置
  • 在不同主机上存储
  • 使用MySQL集群统一存储分布信息
  • 大容易廉价磁盘

到目前为止就这么多了,更多文档可以在http://www.danga.com/words/找到。Danga.comLiveJournal.com的 同学们拿这个文档参加了两次MySQL Con,两次OS Con,以及众多的其它会议,无私的把他们的经验分享出来,值得我们学习。在web2.0时代快速开发得到大家越来越多的重视,但良好的设计仍是每一个应 用的基础,希望web2.0们在成长为Top500网站的路上,不要因为架构阻碍了网站的发展。

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

 

posted @ 2007-09-29 21:26 Coolfiry 阅读(533) | 评论 (0)编辑 收藏

posted @ 2007-09-25 14:30 Coolfiry 阅读(341) | 评论 (0)编辑 收藏

UML类图的各种标识法
关键字:   UML    
·------>虚线箭头表示依赖关系(dependency),一个类需要与另外一个类一起工作,是它一种最弱的关联关系,常见于各种工具类之间的关系
·——实线表示联合关系(association),一个类包含对另外一个类对象的引用,这个通常是使用属性来实现的,为了表明之间的包含关系,有时候会在实线的一端加上箭头(navigability arrow)来表示导航关系,如果关联的双方又都和第三个类有关联关系,那么可以在实线的中间加一个虚线和第三个类关联来表示这种association classes关系
·◇——空心菱形加实线表示聚合关系(aggregation),它是一种更强的关联关系,表示一个类可以拥有或者享有一个类的实例对象,在java代码表现上跟联合是一样的。
·◆——实心菱形加实线表示组合关系(composition),它的关联性比聚合更强,被组合的对象是组合对象的一部分,没法跟其他的对象共享,而且如果组合对象销毁的话,被组合的对象也会同时被销毁,其表现形式跟联合一样
·空心箭头加实线,表示泛化generalization(继承inheritance)关系,这个很简单
·在rose中要建立enumeration,只需要在建立的class中将其stereotype设置为enumeration即可。stereotype只是用来做一个标记,并不包含别的意义

posted @ 2007-06-10 18:03 Coolfiry 阅读(471) | 评论 (0)编辑 收藏