Tim：服务管理框架的尝试
- Shengbin - python.cn(jobs, news)大型软件系统开发需要模块化，在分布式系统中，模块化通常是将功能分成不同的远程服务（RPC）来实现. 比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术. 同样，在一个大型系统中，服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要.
服务管理框架的尝试
标签：
架构
facebook
rpc
thrift
| 发表时间：2011-08-09 22:58 | 作者：Tim zffl
出处：http://timyang.net/
大型软件系统开发需要模块化，在分布式系统中，模块化通常是将功能分成不同的远程服务（RPC）来实现。比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术。同样，在一个大型系统中，服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要。
服务管理目前并无直接解决方案，Thrift作者Mark Slee提到
It’s also possible to use Thrift to actually build a services management tool. i.e. have a central Thrift service that can be queried to find out information about which hosts are running which services. We have done this internally, and would share more details or open source it, but it’s a bit too particular to the way our network is set up and how we cache data. The gist of it, though, is that you have a highly available meta-service that you use to configure your actual application server/clients.
Source: [Thrift] Handling failover and high availability with thriftservices
如果开发一个自己的服务管理框架，需要具备以下功能
- 快速失败，这个在本厂意义重大，很多远程服务调用是在关键路径中，它可以容忍失败，但是不能容忍堵塞
- failover，客户端failover支持，并支持自动失效探测及恢复调用
- 中心化配置及推送功能，所有client在同一时刻配置的一致性，并且client会跟配置中心保持长连
- 负载均衡策略：支持round robin，least active, consistent hash，或者基于脚本的动态路由策略。这个都是由配置中心来控制
- 动态启用及停用服务及节点：可以动态启动及停用服务（热发布），由于有推送功能，相对容易实现
- 跨语言：支持client能使用常见主流语言来访问
- 版本管理：同一服务可以有不同的版本并存
- 访问统计及动态运行参数查看：可以对方法级别进行访问统计及实时观察
访问策略
服务框架倾向于直连的方案，即client是直接连接server，而不会增加中间物理上的代理层，服务框架只做中心配置、访问策略、服务发现、配置通知等职责。
路由的特殊需求
通常的服务访问，使用上述round robin等3种策略即可，但是在实际工程实践中，我们发现有些不同的需求。比如计数这样的远程服务，读操作可随机访问一台远程节点，但写操作需要访问所有的服务节点才能实现。因此我们需要有广播式的访问需求。由于计数服务对实时性和一致性要求较高，不适合采用异步如Pub/Sub这样方式去实现，因此在client还需要支持同步的广播调用。
耦合及侵入的矛盾
在设计服务管理系统之前，我们希望不跟一种具体的技术（如Thrift）绑定，比如client和server服务实现方不需要太多关心底层技术。但是在实际实现过程中碰到不少矛盾。
IDL侵入
在使用Thrift之后服务实现很难绕过Thrift IDL，使用方需要自己维护IDL以及Thrift生成的代码，服务框架支持将Thrift服务注册到配置系统中。虽然也可以绕过IDL来实现服务，但是框架相关功能的实现和维护成本比较高。
RPC框架的侵入
Thrift Transport可以使用TCP（Socket）或者是HTTP
这个也是非常好的特性，在某些情况Transport使用HTTP会带来很多便利，使用HTTP虽然有一些额外开销，但是HTTP的周边配套设施的完善足够抵消这种开销。使用TCP很多状态实时监控都需要服务系统从头做起。
Thrift的Version与服务的version存在一定的重复
服务牵涉到版本管理，我们希望通过发现服务来管理，但是Thrift本身也有版本的设计。
这些矛盾的本质就是服务框架需要的一些功能是自己实现还是依赖Thrift来实现，很多Thrift使用方如Twitter rpc-client干脆就直接在Thrift框架基础上增强。
虽然存在上述一些待解决问题，厂内第一个使用服务框架管理的服务即将上线，很快每天会有数十亿的调用将会在此之上产生，同时也会有新的挑战出现。
Figure 1: Facebook Service Management Console
（来源：http://www.slideshare.net/adityaagarwal/qcon Slide 27）
相关 [服务 管理 框架] 推荐：
服务管理框架的尝试
- mk - Tim[后端技术]大型软件系统开发需要模块化，在分布式系统中，模块化通常是将功能分成不同的远程服务（RPC）来实现. 比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术. 同样，在一个大型系统中，服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要.
微服务框架-基础框架
- - 人月神话的BLOG上面一篇文章对SpringBoot框架做了一下简单验证，在文中也写到SpringBoot重点还是在单个微服务模块的开发，已经对于微服务接口开放的便捷性上，而对于微服务基础架构和管控治理层面没有太多支持. 对于微服务基础框架可以看作是微服务治理架构的核心内容，包括了对微服务模块的全生命周期管理能力，这个能力包括了微服务网关APP，DevOps，Docker和云集成，安全，负载均衡，服务注册和发现等诸多能力.
谈Dubbo服务框架
- - 人月神话的BLOGDubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和
Spring框架无缝集成. 它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）. 从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色.
服务框架演变过程
- rockmaple - BlueDavy之技术blog我们的服务框架已经持续做了三年了，在厂内广泛的使用，目前部署在服务框架上的服务为2k+，每天经过服务框架的服务执行次数为120亿+，摸高到150亿+，三年的发展并非一帆风顺，由于经验的原因，还是摔了不少跤的，在这篇blog中，来给大家分享下，希望能够给要做服务框架或服务化的同学带来一些帮助，少走一些弯路，不一定要一开始就做成完整的服务框架，但至少先做好铺垫，避免在广泛使用后再来挽救.
分布式服务框架：Zookeeper
- - 标点符Zookeeper是一个高性能，分布式的，开源分布式应用协调服务. 它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比如同步，配置管理，集群管理，名空间. 它被设计为易于编程，使用文件系统目录树作为数据模型. 服务端跑在java上，提供java和C的客户端API. Zookeeper是Google的Chubby一个开源的实现，是高有效和可靠的协同工作系统，Zookeeper能够用来leader选举，配置信息维护等，在一个分布式的环境中，需要一个Master实例或存储一些配置信息，确保文件写入的一致性等.
微服务框架和工具大全
- - IT瘾-geek引言：不去重新发明轮子总是更好的. 本文探讨了14个已经可用并能提供使微服务的开发和部署更容易的平台、框架和功能. 本文还补充了每个工具将如何有助于建立良好的微服务架构的简要概述. 在《Java微服务》一书中，我们使用 Spring Cloud，它提供使微服务非常容易地开发所需的所有工具和平台.
服务化框架技术选型
- - 企业架构 - ITeye博客基本的服务化框架包括如下模块：统一的RPC框架，服务注册中心，管理平台. 有了这三个模块，就能实现基本的服务化. 为什么一定要是统一的RPC框架，而不是随便啥框架，这里主要是为了技术对齐，减少开发人员的学习成本，减少团队间沟通成本. 好，那么选择一个RPC框架，我们都需要考量什么东西呢. 代码规范：例如是对已有代码透明，还是代码生成；.
服务间通信之Http框架
- - CSDN博客推荐文章2.jersey代理连接池. 1.1 java原生HttpURLConnection. 这个用的不多，在正式项目中几乎没有用过，写一些小的demo的时候偶尔用过，使用的原因更多是当时懒得再引入其他第三方的http框架了，用法如下：. 不多说，用法还是挺复杂的，简单的请求甚至需要数十行才能完成，并且不易于理解,当时写完调试了半天才通，挺后悔用原生的HttpURLConnection来进行当时功能的测试，感觉比我当时写的一个http-server还要麻烦，在正式的项目中一般不会用到原生http请求类.