转载

restful服务的治理

分布式系统，服务调用服务，服务再调用服务，一个顶层服务可能会cascade调用几十个甚至几百个底层服务；一旦一个底层服务不稳定，会造成cascading failure；所以服务治理的推动，在中大型网站，是最最核心和关键的一件事情之一；

所以，vip为了推动了服务治理，花了极大的精力，搞了OSP(Open Service Platform)，从头自己实现了类Dubbo的服务治理框架，然后把一个一个的核心应用，从原先的java/php 的restful的调用，改成了osp服务（同时做了一部分的应用架构的梳理和优化）；应该说，这个还是投入非常大（近2年的osp框架开发和3年的osp服务化改造接入），当然对于稳定定的贡献大大的；

其实vip早年(2012,2013,2014)，所有服务都是php+少量的java；为了监控服务性能，我们在每个php和java前面都启用了nginx，让nginx来实现connection management 和log写日志，然后通过flume 收集日志，在spark上面计算，计算每个pool, 每个服务器的qps，4xx/5xx error rate和responsetime 的breakdown以及调用关系/量的分析，在前面几年是网站应用性能的主要监控工具；但是这个只能解决监控问题，但是无法解决分布式服务的服务治理问题，一直是一个很大的遗憾；

今天和同事聊到，原先的这套监控体系用mercury替换之后，原先的一部分没有接入OSP服务的，直接采用了nginx+lua来统计当年的性能监控的问题；突然想到，既然nginx+lua实现了性能监控，lua本身有能力来做一定的action，我如果统计了每个jvm/php机器的每个restful call的请求量，请求响应时间，4xx/5xx错误率，加上lua 的action的能力，我其实，可以很简单快速的实现，除了监控的性能数据，还可以针对这个应用服务器，和这个应用服务器上面的每个url请求，根据设定的阈值，来实现快速的前段请求拒绝，后端请求不下发/部分下发等服务治理的管理任务和能力；

然后想起来前段时间打开还没来得及看的近期炒作的service mesh的文章一看，https://liangzl.com/get-article-detail-4046.html， 简直直接就是一个套路！

基础架构的服务，重在核心功能和对业务响应的速度；

如果你加入一个现有的restful服务为主的公司，面临技术升级，如果全部要改造成为类dubbo的解决方案，需要很大的精力和业务投入；但是如果采用这套框架，那么不需要代码改动/minimum改动，就可以实现比较好的监控+治理的核心功能；

你会选择什么？

感慨一下；

原文 http://blog.sina.com.cn/s/blog_53ca4b7d0102z3we.html

正文到此结束