服务框架及服务治理组件——业界调研

声明：主要内容来自公司内部 对业界的调研,不一定恰当、准确、实时。
表格文字较多，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文本协议（据说内部当时争议较大），优势是可读性好， 缺点是数据交换传输量大，效率不高。