内容简介：分布式系统，服务调用服务，服务再调用服务，一个顶层服务可能会cascade调用几十个甚至几百个底层服务；一旦一个底层服务不稳定，会造成cascading failure；所以服务治理的推动，在中大型网站，是最最核心和关键的一件事情之一；基础架构的服务，重在核心功能和对业务响应的速度；如果你加入一个现有的restful服务为主的公司，面临技术升级，如果全部要改造成为类dubbo的解决方案，需要很大的精力和业务投入；但是如果采用这套框架，那么不需要代码改动/minimum改动，就可以实现比较好的监控+治理的核
分布式系统，服务调用服务，服务再调用服务，一个顶层服务可能会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改动，就可以实现比较好的监控+治理的核心功能；
你会选择什么？
感慨一下；
以上所述就是小编给大家介绍的《restful服务的治理》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 2018年微服务服务治理现状
- 轻松构建微服务之服务治理
- 苏宁微服务治理架构Istio的通信和治理之道
- 酷家乐如何使用 Istio 解决新服务治理系统 (Serverless) 接入已有成熟自研 Java 服务治理体系
- SpringCloud微服务治理
- 服务治理的技术血脉
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
