聲明：主要內容來自公司內部 對業界的調研,不一定恰當、準確、實時。
表格文字較多，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	封裝在服務框架中，直接調用遠端的服務注冊\路由系統	不開源
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服務不可用的大事故） 很多邏輯不再放到客戶端，避免升級更新周期過長，難以一致的問題。 增加流控；增加豐富的調用監控、數據可視化圖表等功能。 研發團隊：云平臺-系統技術部-服務框架組

---

個人介紹：

高廣超：多年一線互聯網研發與架構設計經驗，擅長設計與落地高可用、高性能互聯網架構。

本文首發在 高廣超的簡書博客 轉載請注明！

image.png 創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的服务框架及服务治理组件——业界调研的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。