pugWoo's Life   All-Posts  About

SOA的构成要素

SOA,面向服务架构,是构建中大型项目的必备架构,以下分析SOA的主要构成要素,并对比腾讯内部使用的SOA框架和阿里巴巴内部使用的SOA框架的优劣。

1. 协议

协议的序列化性能要好,这个是肯定的,一般用google的protobuf之类的协议,有一个java protobuf协议和google的完全兼容同时不需要预先处理。

协议非常重要,它负载着接口传递的信息,从扩展性和兼容性考虑都非常重要。

最重要的则是协议的版本控制:

1)协议有版本字段version,可以是自增也可以是时间戳,协议的每个字段会注解(或注释)是哪个版本起加入的。如果协议里面有List等更深层嵌套,如果嵌套结构不被复用,那么就可以用个自增版本控制;如果嵌入的结构是复用的,那就推荐使用时间戳作为版本。

2)对于低版本客户端请求高版本服务器,高版本服务器应该兼容低版本协议,根据协议版本由服务器端来决定怎样处理业务逻辑。对于返回数据,到底是高服务器端适配低版本返回数据,还是低版本客户端忽略高版本数据字段,这个都可以考虑。对于Java自带的序列化,它对上对下都是兼容的,但没有手工指定版本那样好依靠版本做不同的业务逻辑处理。

3)对于高版本客户端请求低版本服务器,低版本服务器会忽略高版本协议中新的数据,并处理业务逻辑返回低版本的数据,高版本客户端应该有能力处理低版本的返回数据。

腾讯的AppServer/AppPlatform是由协议的版本来服务版本的,服务器本身没有版本号控制。服务器都是同一批升级的,没有办法控制调用某个服务时,只请求指定版本的机器。如果要实现这样的效果,就修改下服务名称,例如叫XXXv2。

阿里的HSF,协议是依靠Java(Hessian)做到上下都兼容,但是没有版本区分,只能看某个字段能不能拿到值来判断,比较弱。但是服务器机器是有版本和分组的,调用方需要指定服务器版本和分组。但在实际开发过程中,线上一直是1.0.0和HSF分组,依靠版本/分组做升级的情况就没有使用过,aone2的发布也不支持部分机器1.0.0部分机器2.0.0这样的情况,所以HSF的协议版本控制是不太完善的,没有办法监控客户端和服务端的协议版本统计。当然好处就是灵活,直接Java的序列化类,不需要维护一个单独的版本。

从协议版本的设计上,腾讯胜。但从实战的角度上,打平。

2. 注册中心与环境: 本地、开发、测试、预发、线上等

在实际项目开发过程中,需要搭建各种环境,至少线下线上是免不了的,测试和预发一般也是要的。SOA也需要提供这样的环境隔离。目前知道的腾讯和阿里的两种做法:

1)腾讯是靠服务器上的agent来控制环境。例如有一个SOA服务,名称叫queryService,这个名称是全局唯一的,在开发环境,它对应的服务器是A:3888端口,在测试环境,它对应的服务器是B:3999端口,线上对应的是C:3888和D:3888两台机器。这些信息,可以在配置中心网页配置,配置中心以环境为单位分开配置。配置完之后,配置中心会推送给每台机器的agent程序。而对于每台机器上的应用,假如它要调SOA服务queryService,应用会拿本机的agent数据,知道要调用的SOA服务的机器端口,然后直接访问。对于本地开发,可以直接指定机器的ip端口直接调用。

所以,agent维护了整个系统的环境,这个事情由运维负责。相同的代码和配置,放到A机器上它就访问了开发的服务,放到B机器上它就访问了测试的服务。这个减少了很多服务的配置项。不足是目前环境的ip需要手工配置到配置中心,实际上可以搞成自动注册的,本地环境的自动注册功能则可以关掉。

2)阿里的HSF也有各种环境,但是环境里面还是需要指定HSF服务的版本号和分组(一般配置在Spring bean,这也使得每次用hsf服务都要配置,比较麻烦)。例如开发和测试环境在HSF是同一个大环境,所以应用如果依赖N个应用的服务,就需要为服务各配置N项开发和N项测试的版本。预发、线上等同理。服务提供者本身也要配置HSF版本和分组,但是会自动注册到配置中心。例如SOA服务com.xx.IQueryService,服务提供者开发环境和测试环境各部署一台服务器,开发服务器配置版本是1.0.0.daily,测试服务器配置版本是1.0.0.test,这两台服务器起来之后,会把自己的ip地址和端口自动发送给配置中心。而服务使用者的应用,如果是开发环境,那需要配置1.0.0.daily,如果是测试环境,则配置1.0.0.test,需要手工配置。

这个自动注册的功能的便捷性,实际上已经被各种配置破坏完了。还好阿里是以应用为单位的,应用包含web和SOA服务层,应用上所有的服务一般都一个版本,所以像一达通后台BOSS这种规模的应用,一般十几个版本号就可以维护。

其实更好的做法是一个环境自己用一个注册中心,这样就免去每个环境要用不同的版本的问题。

总结一下注册中心和环境应该具备的特性:

1)区分环境并感知环境的能力 2)自动负载均衡,自动下线失效机器,自动恢复上线机器 3)服务自动注册、手动注册

从设计上看,腾讯的agent是非常规整的模型。 - agent应该有能力识别当前的环境,例如dev/test/pre/idc - agent可以扩展为拿配置项(阿里Diamond)、mysql地址密码(保护线上mysql密码)等 - agent的维护有自己的门户和权限控制。如果是大公司使用时,agent可以增加命名空间来隔离不同部门。 - agent支持windows、linux各种操作系统。

从注册中心设计和环境使用方面,腾讯胜。

3. 监控、治理

SOA框架会采集所有调用的耗时,调用量(分每台机器和总体),这些数据就可以做实时监控也可以做历史趋势比较。

监控是简单的特性,而SOA治理才是大头。SOA应该有能力检测到从页面或定时任务开始的一个SOA调用,它后续一路下去的所有SOA调用(包括调用的服务名次、次数和时间)。通过这些数据,就可以分析调用量有没有出现循环、会不会太长、有没有良好的层次关系。这些指标可以作为系统复杂度的指导。

阿里的EagleEye设计,就是通过调用链来采集数据。从页面或定时任务开始(实际上只要没有traceId,就创建一个)就创建一个随机的128位字母的traceId,此后的SOA调用或notify消息传递,都会带上这个信息。根据这个traceId,就可以找到一条调用的全过程。比扁平化的SOA监控更强大的是,这个可以对一个功能的全链路进行统计。例如用户点击提交订单的按钮后,后台会调用一系列SOA、请求一系列SQL、发送一系列信息等,哪个比较慢,一目了然。

实际上,页面框架Webx、SOA框架HSF、消息notify、数据库TDDL这4个点都有EagleEye的采集,所以系统的全链路基本清晰了。

强弱依赖统计、瓶颈分析:

调用来源分析:

还有个RpcId记录了调用的顺序,因为时间每台机器不一样,是不准的。

Google有这类产品的设计:http://research.google.com/pubs/pub36356.html twitter的:http://engineering.twitter.com/2012/06/distributed-systems-tracing-with-zipkin.html

在SOA治理方面,阿里胜。

4. 管理调用方、自我保护

服务提供应该有能力保护自己。SOA的服务提供方,应该可以提供密钥和调用者标识符给调用者,并设置该调用者的调用频率,如果超过调用频率,就禁止为其提供服务并报警。

另外一个是来自Google的理念,对于导致多次服务超时的异常参数,应该有屏蔽的能力。也称熔断。

在这方面,目前阿里的HSF好像没有涉及,连安全性都没有。这方面,腾讯胜。