|
锁定老帖子 主题：高性能服务框架设计方案讨论
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2014-02-28
（1） 服务的监控
|
| 返回顶楼 | |
|
发表时间：2014-02-28
7454103 写道 1、Hessian等成熟的RPC框架 + Apache + Tomcat负载均衡
我们现在就在使用这样的一个设计！ 很多优点 但缺陷也很明显：（业务大的情况下） 1.0 服务的监控 2.0 服务的负载 这两点得自己去实现 而且还很繁琐！ 这正是我说的那个： （1）服务治理是个大问题； （2）性能也会有问题，单点负载均衡器总会成为瓶颈，而简单地增加复杂均衡器并不是解决方法。 |
| 返回顶楼 | |
|
发表时间：2014-02-28
个人理解哈
（1） 服务的监控 ： 对各个服务去的 访问频率，成功率，相应时间等 做统计和监控，然后做出各种调整策略！ （2）负载：同样业务的服务只有一个 就好比你的服务器只有一个 tomcat，在访问大的情况下 会宕机，服务也存在同样的问题！所以需要负载 和 挂了之后的恢复策略！ |
| 返回顶楼 | |
|
发表时间：2014-02-28
jiq408694711 写道 7454103 写道 1、Hessian等成熟的RPC框架 + Apache + Tomcat负载均衡
我们现在就在使用这样的一个设计！ 很多优点 但缺陷也很明显：（业务大的情况下） 1.0 服务的监控 2.0 服务的负载 这两点得自己去实现 而且还很繁琐！ 这正是我说的那个： （1）服务治理是个大问题； （2）性能也会有问题，单点负载均衡器总会成为瓶颈，而简单地增加复杂均衡器并不是解决方法。 这些是问题，其实主要看 你们业务量 （访问量）的大小 才去选择不同的方案！ 如果 是 100百级别的话 就用这个吧！没什么问题的！我们已经使用了 好几年了！ |
| 返回顶楼 | |
|
发表时间：2014-02-28
jiq408694711 写道 7454103 写道 1、Hessian等成熟的RPC框架 + Apache + Tomcat负载均衡
我们现在就在使用这样的一个设计！ 很多优点 但缺陷也很明显：（业务大的情况下） 1.0 服务的监控 2.0 服务的负载 这两点得自己去实现 而且还很繁琐！ 这正是我说的那个： （1）服务治理是个大问题； （2）性能也会有问题，单点负载均衡器总会成为瓶颈，而简单地增加复杂均衡器并不是解决方法。 =================================================== 现在不讨论Hessian+Apache+Tomcat，为什么不用Hessian + 自己做负载均衡 + 自己做流量监控等服务治理。 先说说我的感觉，我觉得为什么不从选用成熟的RPC框架开始做高性能分布式服务框架，几点原因： （1）Hessain等都是短连接，性能是问题； （2）负载均衡，服务治理等工作不能在Hessian这套壳子外面来做，需要在其内部做，如果在内部做，也就没必要依赖于它们了。 |
| 返回顶楼 | |
|
发表时间：2014-02-28
jiq408694711 写道 jiq408694711 写道 7454103 写道 1、Hessian等成熟的RPC框架 + Apache + Tomcat负载均衡
我们现在就在使用这样的一个设计！ 很多优点 但缺陷也很明显：（业务大的情况下） 1.0 服务的监控 2.0 服务的负载 这两点得自己去实现 而且还很繁琐！ 这正是我说的那个： （1）服务治理是个大问题； （2）性能也会有问题，单点负载均衡器总会成为瓶颈，而简单地增加复杂均衡器并不是解决方法。 =================================================== 现在不讨论Hessian+Apache+Tomcat，为什么不用Hessian + 自己做负载均衡 + 自己做流量监控等服务治理。 先说说我的感觉，我觉得为什么不从选用成熟的RPC框架开始做高性能分布式服务框架，几点原因： （1）Hessain等都是短连接，性能是问题； （2）负载均衡，服务治理等工作不能在Hessian这套壳子外面来做，需要在其内部做，如果在内部做，也就没必要依赖于它们了。 你的感觉很正确！ 但一般情况下 不会自己开发一套的！ 成本 和 周期都不允许！当然用现有成熟的 或者 第三方开源的产品 也是有代价的！ 毕竟各个公司业务 和 程序架构都有区别！本地化 也是有成本的！ 如果你们公司有资本的话 前期可以借鉴下 一些开源/成熟的产品,然后开发出符合你们业务的 服务框架！ |
| 返回顶楼 | |
|
发表时间：2014-02-28
jiq408694711 写道 jiq408694711 写道 jiq408694711 写道 7454103 写道 1、Hessian等成熟的RPC框架 + Apache + Tomcat负载均衡
我们现在就在使用这样的一个设计！ 很多优点 但缺陷也很明显：（业务大的情况下） 1.0 服务的监控 2.0 服务的负载 这两点得自己去实现 而且还很繁琐！ 这正是我说的那个： （1）服务治理是个大问题； （2）性能也会有问题，单点负载均衡器总会成为瓶颈，而简单地增加复杂均衡器并不是解决方法。 =================================================== 现在不讨论Hessian+Apache+Tomcat，为什么不用Hessian + 自己做负载均衡 + 自己做流量监控等服务治理。 先说说我的感觉，我觉得为什么不从选用成熟的RPC框架开始做高性能分布式服务框架，几点原因： （1）Hessain等都是短连接，性能是问题； （2）负载均衡，服务治理等工作不能在Hessian这套壳子外面来做，需要在其内部做，如果在内部做，也就没必要依赖于它们了。 你的感觉很正确！ 但一般情况下 不会自己开发一套的！ 成本 和 周期都不允许！当然用现有成熟的 或者 第三方开源的产品 也是有代价的！ 毕竟各个公司业务 和 程序架构都有区别！本地化 也是有成本的！ 如果你们公司有资本的话 前期可以借鉴下 一些开源/成熟的产品,然后开发出符合你们业务的 服务框架！ 非常感谢你的回答，不过我现在被上面要求要尝试一下“Hessian，ICE等成熟的RPC框架 + 自己做负载均衡 + 自己做流量监控等服务治理。” 先试试吧，感觉这样上下不接。。。 要是系统和访问量不是非常大，就用“Hessian+Apache+Tomcat”就行了，要是太大了非得研究高性能分布式服务框架，自己的RPC框架我觉得是必须的。。。 不管了，没办法，试试吧。 有疑问或者有进展再来讨论。 谢谢你了！ |
| 返回顶楼 | |
|
发表时间：2014-02-28
jiq408694711 写道 Shen.Yiyang 写道 方案1和方案2最大的区别你不是都说了嘛，负载方式不一样，方案1的集中式负载意味着单点，但它的好处在于透明性，客户端不需要知道所有节点的位置。方案2的好处在于没有单点，伸缩性强大，这类方案最初提出来，主要就是为了性能。
至于时间上的考虑，我觉得直接用Dubbo没什么不好，没有必要自己重复去造。 方案1没有任何所谓的透明性的优势吧。 方案2完全可以封装成透明的，我觉得自己开发的分布式服务框架最大的优势除了二次开发之外，关键是可以增加服务治理相关的功能。 至于有没有必要再造。。。呵呵，每个公司有自己的情况，而且Dubbo服务治理不开源，谁知道以后会怎么样。 我说的没错吧？ 封装的透明只能算是开发上的便利，和实质上的透明还是不一样的，通过代理均衡的服务可以开放给外网，软负载明显就不能这么干。当然内部服务的场景是没这种考虑。。 服务治理的实现和RPC本身是不相干的，你用现有的开源框架也可以再开发。 |
| 返回顶楼 | |
|
发表时间：2014-03-02
在Hessian之上实现服务治理和监控，楼主可有好的思路？
|
| 返回顶楼 | |
|
发表时间：2014-03-02
我理解中的高性能服务框架（HSF）的核心主要是两个：1、分布式；2、透明度
分布式，主要是指具体的业务服务可分布管理，即提到的服务治理与监控，这里面涉及到动态注册、心跳检测、服务分类、异步调用等技术，但HSF本身需要集中式管理。 透明度，主要是指业务服务位置透明、RPC协议透明、访问模式（同步/异步）透明等。 因此RPC框架仅仅是实现HSF的必要条件之一，并且绝不是关键的环节。这也是为什么大公司愿意自己开发HSF的核心的原因。 |
| 返回顶楼 | |
