内容简介:APM是什么?APM全称Application Performance Monitor,即应用性能监控(也有翻译成Application Performance Management,应用性能管理的),所有和应用性能相关的指标、管理相关的事情都属于它的范畴。Skywalking就是一个具体的APM软件,也是Apache下面的一个顶级项目,而且是由中国人发起。随着分布式和微服务架构的普及,一个系统所包含的服务、节点越来越多,APM的需求越来越明显。这里就拿一个具体的例子来看APM有什么用处吧。现在我们有如下一
APM介绍
APM是什么?APM全称Application Performance Monitor,即应用性能监控(也有翻译成Application Performance Management,应用性能管理的),所有和应用性能相关的指标、管理相关的事情都属于它的范畴。Skywalking就是一个具体的APM软件,也是Apache下面的一个顶级项目,而且是由中国人发起。随着分布式和微服务架构的普及,一个系统所包含的服务、节点越来越多,APM的需求越来越明显。这里就拿一个具体的例子来看APM有什么用处吧。
现在我们有如下一个基于Spring Cloud的微服务系统:
这个系统是一个非常简化的微服务架构了,它包含了5个服务:
- 网关服务 :使用zuul实现;
- 注册中心 :使用Eureka实现;
- 用户服务 :提供RESTful API的用户服务,使用Spring MVC实现;该服务会调用 产品服务 ;
- 产品服务 :提供RESTful API的产品服务,使用Spring MVC实现,使用了一个H2数据库;
- Web服务 :外部用户通过该服务来访问系统各项服务,这里使用curl命令模拟。
这个系统的代码可以从这里下载: github , 注意使用 skywalking-demo1
分支 。现在呢,这个系统跑起来以后客户反馈了两个问题:
- 系统偶尔出现请求调用失败。
- 请求有时候响应很慢。
现在该怎么定位这2个问题呢?如果没有APM,最直观的方式从调用发起端(Web)一个个往后排查。如果服务少,机器少这个方式还行,但如果有很多服务,每个服务还有多个实例,那可能就有几十个甚至成百上千个服务实例,一个一个排查估计客户没发飙之前运维同学已经离职了。
这个时候,是该让APM上场了。本文介绍Skywalking。
Skywalking介绍
本文目标是先把整个系统运行起来,具体Skywalking的细节,后面文章再讲述。Skywalking架构图如下(图片来自官方):
可以看到主要由四部分组成:
- Agent(也叫Probe) :代理或者探针,集成在被监测的应用中(SDK形式或者动态注入),采集应用的数据发送给后端(OAP)。
- UI :自带的Web页面。
- OAP :后端,接收Agent的数据并进行分析。Agent和OAP通信走的是gRPC,端口号默认为11800;UI和OAP通信走的是HTTP接口,端口号默认为12800。
- Storage :后端存储,OAP处理后的数据存储在这里。生产比较常用的是 MySQL 和ES。
先从官网下载安装包: 下载页面 ,目前最新的版本是8.0.1。下载后解压即可完成安装。
然后在解压后的目录执行 bin/startup.sh
即可启动(Windows下执行 startup.bat
),这样默认启动了两个模块:
- Skywalking UI,默认端口为8080。
- Skywalking OAP,即后端。默认存储使用的是H2数据库,对于测试和体验来说,够用了。
浏览器访问 http://127.0.0.1 :8080/,如果页面正常,说明Skywalking已经部署好了。下面看如何借助Skywalking来定位上面客户反馈的两个问题。
服务集成Skywalking
首先得在服务里面集成Skywalking的Agent。Java的Agent是通过字节码注入实现的。所以启动时在虚拟机参数中配置javaagent即可。下载前面说的代码,然后编辑每个服务启动时的虚拟机参数,如图:
-javaagent:/Users/allan/portable-software/apache-skywalking-apm-bin-8.0.1/agent/skywalking-agent.jar -Dskywalking.agent.service_name=eureka-server
这些配置好以后,按如下顺序依次启动4个服务(不按照这个顺序启动也可以,只是可能会报些错误以及服务发现可能慢一些,但不影响功能):
- eureka-server:监听端口为8761。启动后,如果浏览器能访问
http://127.0.0.1:8761/
,则表示启动成功。 - product-service:监听端口为8082。提供一个RESTful API接口:
/products/{id}
,这个接口内部会有一个数据库访问操作,数据库默认使用的是H2. - user-service:监听端口为8081。提供一个RESTful API接口:
/users/{id}
,这个接口内部会使用RestTemplate调用product-service的/products/{id}
接口。 -
zuul-server:监听端口为8000。默认配置了两个路由:
zuul: routes: user-service: path: /user-service/** serviceId: USER-SERVICE product-service: path: /product-service/** serviceId: product-service
配置的含义是将 /user-service/
开头的请求转发给USER-SERVICE(不区分大小写)服务,转发的时候去掉前面的 /user-service
。比如 /user-service/users/1
转发到USER-SERVICE时会变为 /users/1
。product-service部分配置一样。
都启动后,在浏览器能访问 http://127.0.0.1:8761/
,看下3个服务是否已经在Eureka中注册成功(Eureka自身不注册)。如果成功了,我们使用curl模拟web发送如下请求(这里我用的是HTTPie这个工具,比curl使用简单,且输出自动高亮且格式化了。如果你没有装,直接将下面的http命令替换成curl即可,或者使用postman之类的 工具 都OK):
# curl http://localhost:8000/user-service/users/1 http http://localhost:8000/user-service/users/1 # 上面的命令多执行几次,保证出现过以下两种结果 # 结果1:即客户反映的有调用失败的情况 { "error": "Internal Server Error", "message": "500 : [<Map><timestamp>2020-07-09T09:17:36.024+0000</timestamp><status>500</status><error>Internal Server Error</error><message>something error in product service</message><path>/products/1</path></Map>]", "path": "/users/1", "status": 500, "timestamp": "2020-07-09T09:17:36.065+0000" } # 结果2:结果正常,但明显比较慢。 { "products": [ "audi", "benz", "volvo", "honda" ], "user_id": "1" }
我们发现多次执行请求(curl命令),的确有时会失败(结果1);不失败的时候,一次请求挺慢的。和客户反馈的是一致的。这个时候,打开Skywalking的Web页面( http://127.0.0.1 :8080/)来看看为什么吧(Web上面的详细功能本文就不介绍了,后面文章介绍):
先看trace菜单,也就是调用的链路数据(如果你看不到数据,先点击一下那个Clear,然后选一下时间范围,再点击Search),就能出现链路图了。
先在左侧找一个没有标红的链路,右侧选择“Table”视图,如下:
可以看到,整个请求耗时9057ms,product-service的一个 /products/{id}
接口就占了9029ms,这样我们就知道调用慢到底是哪个服务导致的了。而且可以看到的是,里面的数据库操作并没有占用太多时间。在去检查 /products/{id}
到底做了什么事情,耗费了这么多时间之前,我们再找一个标红的链路看看。
标红的链路表示请求出错了,对应刚才发请求时返回的结果1。我们随便找一个出错的,点击右侧链路中最下面的那个请求(即图中的 /products/{id}
,根据颜色可以看出来这个接口属于product-service),右侧会弹出一个详细内容框,这里有一些基本的元数据信息,最主要的是对于出错的,展示出了调用栈信息:
从调用栈可以看出,错误发生在ProductServiceApplication.java文件的第30行。
至此,我们已经知道了偶尔出错和请求慢的罪魁祸首都是product-service提供的 /products/{id}
接口导致的。然后赶紧看下那里的代码到底在搞什么:
@SpringBootApplication @RestController public class ProductServiceApplication { public static void main(String[] args) { SpringApplication.run(ProductServiceApplication.class, args); } @Autowired ProductRepository productRepo; @GetMapping("/products/{id}") public Object getProductsById(@PathVariable String id) throws Exception { // 产品经理让加的,说方便后面让客户给钱升级版本 int trap = (int) (Math.random() * 10); if (trap % 2 == 0) { throw new Exception("something error in product service"); } Thread.sleep(trap * 1000); productRepo.findByDescriptionLike("%world%"); List<String> productList = new ArrayList<>(8); productRepo.findAll().forEach(product -> productList.add(product.getName())); return productList; } }
第30行代码是 throw new Exception("something error in product service");
。看了代码上下文我们才发现:原来罪魁祸首都是产品经理:让在代码里面加了一个随机的出错,即使不出错,也要sleep。怪不得请求偶尔会出错或者请求比较慢呢。原来都是产品经理的锅,是时候杀个产品经理来祭天了。
至此,可以看到,APM提供的链路分析对于定位请求出错以及耗时方面是非常方便的。当然APM除了链路跟踪这个功能之外,一般还会提供很多其它跟性能相关的数据。比如Skywalking还提供了指标分析(Dashboard)、拓扑图(Topology)、告警(Alarm)、性能剖析(Profile)功能。下面截几张图看看,后面文章专门介绍。
Dashboard的APM页面:
Dashboard的数据库页面:
如果你的图那里没有看到数据的话,去Skywalking安装目录下,修改config/application.yml文件,找到下面的行,将default后面的值改为1(只有超过这个值的 SQL 语句才会被认为是慢SQL),如下图:
slowDBAccessThreshold: ${SW_SLOW_DB_THRESHOLD:default:1,mongodb:100}
然后重启Skywalking,重新发几次请求,再查看这个页面。
拓扑图页面:
可以根据服务调用自动还原应用拓扑图,那个连线会根据请求关系动态流动,截图体现不出来。可以看到,这个拓扑图和前面画的那个架构图是一致的。
告警页面:
如果你之前没有接触过APM,我想看到这些,应该是有被惊艳到的。的确,APM是应用性能监控或管理的大杀器。除了Skywalking,还有一些开源和商用的APM。网上的文章很多,有兴趣的可以自行Google。
下篇文章介绍一下Skywalking的整体架构。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
正当法律程序简史
(美)约翰·V.奥尔特 / 杨明成、陈霜玲 / 商务印书馆 / 2006-8 / 14.00元
本书的主题——正当法律程序,是英美法的核心概念,它使诸如法治、经济自由、个人自治以及免于政府专断行为的侵害等价值观念具体化,因而是法学领域一个永恒的主题,数百年以来一直是法学家、法官及律师关注的重点。本书以极为简洁、精确的语言总结了五百年法律发展的恢弘历史,为人们描述了正当法律程序观念发展演变的清晰轨迹。而沿着这条轨迹,人们可以准确地了解正当法律程序这一重要概念所包含的广泛的问题。 作为一本......一起来看看 《正当法律程序简史》 这本书的介绍吧!