分布式服务框架——分布式服务的组织者综述06/07年以后，随着淘宝用户数量和网站流量的增长，应用系统的数量和复杂程度也急剧增加。诸多前台系统都需要使用一些公共的业务逻辑，这些业务逻辑通常具有共性的东西，比如，获取用户信息或查询宝贝详情等。如果将这些业务逻辑在各个系统内部都实现一遍，则大大增加了开发成本和后期维护成本。于是，像服务框架这类的中间件产品就应运而生。服务框架帮助各个系统将那些相似的业务逻辑抽离出来，单独部署，而前台系统在需要调用这些业务逻辑时，只需要通过服务框架远程调用即可，大大节约了前端系统的开发成本，也提高了系统的可维护性和可扩展性。 2.1、HSF简介HSF是淘宝的分布式服务框架。服务框架从分布式应用层面以及统一的发布/调用方式层面为业务系统提供支持，从而可以让他们很容易地开发分布式应用并提供和使用公用功能模块，而不用考虑分布式领域中的各种细节技术，例如远程通讯、性能损耗、调用的透明化、同步/异步调用方式的实现等等问题。 服务框架的实现有三种角色：服务提供者、服务消费者和注册中心。服务提供者在服务可用的前提下，将地址注册到注册中心。服务消费者启动时，会订阅注册中心的相关服务，获取服务地址，通过一定的负载均衡策略调用服务。由于注册中心这个软负载集群的存在，服务提供者和服务消费者可以任意扩容和下线，注册中心可以实时将提供者地址的变更推送给消费者。 服务治理 服务治理是服务框架的核心功能。所谓服务治理，是指服务的提供方和消费方达成一致的约定，保证服务的高质量。服务治理功能，可以解决将某些特定流量引入某一批机器，以及限制某些非法消费者的恶意访问，和在提供者处理量达到一定程度时，拒绝接受新的请求等功能。 2.2、HSF双11准备与优化在双11中，HSF主要通过精简日志输出、流量限制、解决应用依赖冲突等措施，保证了服务的稳定可靠。
消费者在调用过程中，容易因为网络问题或服务提供方等原因引起调用失败。如果没有足够的日志，有时候排查问题会很困难。因此，服务框架在生产环境使用时，往往将日志级别设置比较低或打印较多日志，记录下足够多的信息。这在平时没有问题，而且在遇到问题时也有足够的信息来排查问题。但是日志打印本身耗费性能，在双11这种高峰调用期间，尽量要减少日志的输出。为了达到灵活控制日志输出的目标，服务框架优化了日志打印，精简了日志输出。
虽然很多应用设置了流量限制等规则，但平时的流量远远低于阈值，只有在双11这种流量高峰，才会起到效果。在双11之前，我们检查了线上所有的限流规则，发现有不少配置错误或者配置不合理的情况，其中有些是由于HSF对于一些默认参数设置不合理造成的。通过性能测试，将不合理的规则和参数进行改正。
由于淘宝业务发展迅速，前端应用需要依赖越来越多的其他系统，这很容易造成应用依赖的冲突。服务框架引入了Pandora容器，对应用进行了依赖的隔离，防止应用和服务框架的依赖相互冲突。 小结HSF已经经受了淘宝各种复杂、高并发的调用场景。今年来，HSF在易用性、服务治理和性能上有了很大的改进，是很稳定的分布式服务框架。作为淘宝中间件团队最早诞生的中间件框架之一，HSF将在未来继续发挥其巨大的作用。
系列文章： 《中间件技术及双十一实践之中间件总体介绍》http://jm-blog./?p=3359 《中间件技术及双十一实践之软负载篇》http://jm-blog./?p=3450 《中间件技术及双十一实践·服务框架篇》http://jm-blog./?p=3462 《中间件技术及双十一实践·EagleEye篇》http://jm-blog./?p=3465 如果觉得内容还行，请分享给更多的人… |
|
|
来自： icecity1306 > 《产品设计》
