| 腾讯 |
完全自研；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 |
封装在服务框架中，直接调用远端的服务注册\路由系统 |
不开源 |
| google |
整个公司使用比较统一的解决方案
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服务不可用的大事故）
很多逻辑不再放到客户端，避免升级更新周期过长，难以一致的问题。
增加流控；增加丰富的调用监控、数据可视化图表等功能。
研发团队：云平台-系统技术部-服务框架组 |
|
|
|
