声明:主要内容来自公司内部 对业界的调研,不一定恰当、准确、实时。
表格文字较多,APP阅读体验较差
团队 | 服务相关组件\方案 | 通信框架 | 监控 | 负载均衡\路由 | 是否开源 |
---|---|---|---|---|---|
腾讯 | 完全自研;BG内部自治,每个BG有自己相应的解决方案,单独演进; 包括:服务注册路由中心;流量定义ABTesting方案;日志分布式收集; 配置中心等没有公司级的服务治理组织去统一 | 各个BG也不一样 技术工程TEG\原搜索:自定义二进制协议编解码,或Protocol Buffer(以下简称PB)进行序列化\反序列化,自研服务容器、进程框架(e.g. Poppy – 基于PB的RPC框架) 原电商ECC:自研web container\app container,采用类PB方式auto gen业务代码骨架,通信采用二进制协议 社交SNG、游戏IEG:也都是自研组件+序列化\反序列化工具+二进制协议 QQ后台:msec(Mass Service Engine in Cluster)毫秒服务引擎,使用PB。 | 基础监控公司相对比较统一,使用监控平台itils,每台机器部署单独agent收集业务上报的数据。 部分BG会构建自己的业务统计监控系统 | 公司级组件L5(Aim to High Availabliliy 99.999%),提供系统内各层、各模块间调用的路由决策、负载均衡及容错,以agent模式部署运行 部分BG在用,主要覆盖为SNG的业务 | 个别开源 |
百度 | 之前使用codename为伽利略的系统,负责服务的注册路由、配置管理,基于zookeeper(以下简称zk)构建。 后来由于接口lib调用不稳定等各种问题, 大家逐渐失去信心而改用另一套自研系统BNS,也是类似zk的层次目录树结构存储组织。 没有公司级的服务治理组织去统一 | 主要采用ub通信框架(基础架构部提供,lbs等部门在用) 采用的协议为mcpack 一种类似json文本协议(据说内部当时争议较大),优势是可读性好, 缺点是数据交换传输量大,效率不高。 网页PS部门采用sofa-pbrpc,基于pb实现轻量级rpc服务框架:https://github.com/BaiduPS/sofa-pbrpc/wiki;https://github.com/BaiduPS/sofa-pbrpc | 监控系统为noah,所有服务器都部署noah agent。 | 以服务接口形式提供,由业务自己去调用,没有封装在框架内,也没有以单独代理进程形式实现。 | 不开源,除了sofa-pbrpc |
阿里巴巴 | 各子公司(淘宝、1688、阿里云、阿里妈妈等)在基础组件、服务治理组件方面复用不多,基本也自成体系,有各自方案。 | dubbo(2008年底开始设计,2011.11开源 https://github.com/alibaba/dubbo;http://alibaba.github.io/dubbo-doc-static/User+Guide-zh.htm ) 阿里内部已放弃。不过外部有一些公司在用,如京东、人人等 现内部主要使用hsf(http://www.doc88.com/p-8866142882055.html),service定义参考了OSGi Hsf vs dubbo:hsf是淘宝团队做的,dubbo是阿里巴巴团队做的,而2011年底时hsf每天的服务调用量是dubbo的20+倍,稳定性、成熟度、使用范围更广(http://www.iteye.com/topic/1116866?page=3 )c\c++开发主要使用arpc基于protocol buffer | N\A | 封装在服务框架中,直接调用远端的服务注册\路由系统 | 不开源 |
整个公司使用比较统一的解决方案 Protocol buffer - 数据通信交换、存储格式,序列化\反序列化工具 BNS - Borg Name Service 名字服务,与gslb负载均衡器进行交互,获取service对应的IP:Port,服务不同权重在gslb中进行登记。 | Stubby - RPC服务框架。 支持基于http的服务状态、健康状态请求访问。在框架中封装了对权限认证服务、BNS服务的接口访问,从而实现权限认证、负载均衡、路由等策略。 | Borg进行集群资源管理、任务调度\监控 | 在框架内会做路由缓存,每次拿到m个下游服务节点进行random access。且watch服务列表或定期到BNS去刷新获取。 | PB开源。其他组件系统耦合依赖太多,没有开源 | |
amazon | Amazon AWS提供了一系列比较成熟的产品组件和一致的解决方案。 Elastic beanstalk - 应用程序部署和管理服务。用户只需上传程序代码, Elastic Beanstalk 即可自动处理从容量预配置、负载均衡、自动扩展到应用程序运行状况监控的部署。 SWF(Simple Workflow) - 工作流框架。协助构建、运行与扩展平行或序列分步的后台作业程序 针对不同的应用场景提供相应的建议解决方案,如电商架构方案http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ecommerce_webfrontend_14.pdf | SQS(Simple Queue Service) - 快速可靠、可扩展且完全托管的消息队列服务 | Amazon CloudWatch - 针对AWS云资源及应用程序进行监控的服务。可以收集和跟踪指标,收集和监控日志文件,设置警报。 | 通过单独部署的负载均衡设备Elastic Load Balancing,在可用区域内,自动分发请求流量到不同的EC2实例中 | 不开源 |
ebay | ebay内部并没有太统一的方案,内部的很多开源方案都是使用的restfull的工具, 很多基于eclipse的开发插件,github路径:https://github.com/ebay 消息队列使用的是bes(Business Event Stream) SOA框架是Turmeric框架:http://www.ebaytechblog.com/2011/02/17/ebay-open-sourced-its-soa-platform/#.U-LYVIAzAf4 | 框架比较多,目前了解到的,可能不太准确,主要有基于Turmeric的客户端方案SIF和SPF,前端同学介绍说还有一个ginger framework:http://www.gingerframework.com/ | Turmeric的监控主要体现在,运行时server和Client的监控,调用监控,存储监控服务数据,查看监控等。但是内部的同学说只有”大的方面的监控“ | N/A | 目前还没有开源,准备开源,另外据几个同学说,目前使用的并不广泛,另外目前的版本还是有很多的rough edges |
京东 | 自2014年初开始研发JSF(Jingdong Service Framework)。前身为SAF(Service Architecture Framework),2012年开始推动SOA,统一rpc调用框架。 SAF: JSF: 详见附件pdf JSF vs SAF,主要改进点: 服务不再直连ZK,注册中心registry不是简单zk cluster,而是多机房分布式部署的server,所有注册信息持久化到DB中。牺牲强一致性,通过定期sync实现最终一致性。 (关于这个点,京东其实发生过几个小时大部分online服务不可用的大事故) 很多逻辑不再放到客户端,避免升级更新周期过长,难以一致的问题。 增加流控;增加丰富的调用监控、数据可视化图表等功能。 研发团队:云平台-系统技术部-服务框架组 |
个人介绍:
高广超:多年一线互联网研发与架构设计经验,擅长设计与落地高可用、高性能互联网架构。
本文首发在 高广超的简书博客 转载请注明!