EDAS带你快速搞定分布式应用

【EDAS最近更新】

作为一个开发者，你是否经历过这样的咆哮？
这样的场景出现，不是谁的脾气有bug，而是打开方式或许不对。今天我们就通过一个真实案例，来看看分布式开发对消灭吐槽，促进团队和谐的作用。

X公司是一个秉承传统的开发方式的典型，如下图的架构图是一个实际场景中的架构图，按照传统的开发方式，业务模块层按照“高内聚低耦合”的原则划分成不同的模块，所有模块的开发人员都是在一个大工程下进行编码测试，模块之间的业务划分的很清晰。

但理想是丰满的，现实很骨感，按照很“完美”的模块划分后，在一个大的应用工程下进行开发，但随着系统功能越来越强大，软件复杂度急剧增加，开发人员的新旧交替，慢慢的单体应用给开发团队、产品发展等造成的直接弊端，系统维护变得异常艰难。

在这种情况下，估计很多的开发团队估计都会想到用分布式应用来解决。但是，分布式应用就一定是完美的吗？答案当然是否定的。分布式应用也难免存在很多问题，例如：

这些问题其实如果要全部解决，也是个浩大的工程。还好，不完美的世界不需要一个人面对，总有些人在寻找解决方案。比如阿里云中间件产品EDAS，就是为分布式开发的不完美提供了不少解决方案。

快速基于EDAS开发好分布式应用，减少大量开发工作，应用可以是服务提供者，也可以是服务消费者，也可以两者都是。

实际的大型系统中，都有很复杂的业务链路调用，如果将单体应用重构为分布式应用后，没有一套良好的监控体系，在系统出现问题时定位问题将会异常困难。如图是一个实际场景下的链路调用：

EDAS 鹰眼监控系统能够分析分布式系统的每一次系统调用、消息发送和数据库访问，从而精准发现系统的瓶颈和隐患。

当当当当~~

最新重量级功能隆重登场：方法追踪。
让你以火箭般的速度，打通应用诊断的“最后一公里”。EDAS基础版里即可使用~嘘~

EDAS 方法追踪能够帮助用户在应用运行时出现问题，进行快速的问题排查，典型的场景包括：

应用运行时突然发现执行某一个业务逻辑耗时很长，此时希望能够有一种方式定位运行时代码各个部分的耗时，以确定耗时点在什么地方。
应用运行时一切正常，绝大部分情况下，业务运行都非常顺畅，但某一例用户反馈，当传入XXX参数时，业务响应非常缓慢。此时希望能够有一种方式针对特定的方法入参来观察代码执行情况。
一个比较复杂的程序方法，其中业务逻辑较为复杂，在真正运行时，无法确定具体调用了那些逻辑，以及调用时序。此时希望能够有一种方式详细的展现出方法执行的具体逻辑、时序等。

此外，以上的任何一种场景，都希望代码无入侵，可以在应用运行时不停机的情况下，定位问题。

EDAS 方法追踪采用 JVM 字节码增强的技术，对选中的所有方法调用增加必要的耗时与调用序列记录的增强，从而达到观看执行过程中的具体执行序列的目的。

EDAS 单击进程内方法追踪和RPC框架无关，属于 EDAS 基础版功能，提升用户应用诊断能力。方法追踪是对当前分布式调用链路追踪的补充，解决在使用调用链路追踪功能定位到单机某一个服务的问题后，进一步诊断该服务方法本地执行的时序细节、各执行环节的耗时、入参/返回值和异常情况。