【EDAS最近更新】
- 2.13.1 版本：提供对本地方法执行追踪； 支持租户内服务鉴权与授权。
- 2.13.0 版本：Http流量管理功能上线，提供了对应用运行时线程堆栈和内存分布的查看。
- 2.12.3 版本：链路分析功能上线全新视觉界面；调用链支持多维查询。
- 2.12.2 版本：服务监控上线全新视觉界面；PaaS 平台机器接入层架构升级，支持无限水平扩容。
背景：
- 攻城狮：谁又动了我模块接口？谁又改了我模块逻辑？？？
- 运维：有bug！模块之间的调用跟个蜘蛛网一样，我怎么排查！
- 测试：这么复杂的调用逻辑，我的自动化测试用例咋写？！
- 架构师：业务上升了，系统要部署到多台服务器才行，这我怎么拆？！
- 新人入职后：代码太难理解，想shi的心都有了…….
- 老板：为啥大半年过去了需求还没搞定！！！
作为一个开发者，你是否经历过这样的咆哮？
这样的场景出现，不是谁的脾气有bug，而是打开方式或许不对。今天我们就通过一个真实案例，来看看分布式开发对消灭吐槽，促进团队和谐的作用。
单体应用很丰满，现实很骨感
X公司是一个秉承传统的开发方式的典型，如下图的架构图是一个实际场景中的架构图，按照传统的开发方式，业务模块层按照“高内聚低耦合”的原则划分成不同的模块，所有模块的开发人员都是在一个大工程下进行编码测试，模块之间的业务划分的很清晰。
但理想是丰满的，现实很骨感，按照很“完美”的模块划分后，在一个大的应用工程下进行开发进行开发，但随着系统功能越来越强大，，软件复杂度急剧增加，开发人员的新旧交替，慢慢的单体应用给开发团队、产品发展等造成的直接弊端，系统维护变得异常艰难。
一切不完美，都可以坦然面对
在这种情况下，估计很多的开发团队估计都会想到用分布式应用来解决。但是，分布式应用就一定是完美的吗？答案当然是否定的。分布式应用也难免存在很多问题，例如：
- 如何保证服务之间调用链路的稳定性
- 如何保证服务调用安全性
- 遇到应用需要扩容时候该怎么办
- 应用拆分了，都需要单独部署，我能怎么更方便管理应用部署问题
- 服务调用的性能能保证吗
- 毕竟是由本地调用改为了rpc方式，我需要怎样更方便的监控调用链路呢？
- 分布式事务的问题要如何解决呢？
这些问题其实如果要全部解决，也是个浩大的工程。还好，不完美的世界不需要一个人面对，总有些人在寻找解决方案。比如阿里云中间件产品EDAS，就是为分布式开发的不完美提供了不少解决方案。
EDAS能够带来什么？
1、搭建分布式应用系统
快速基于EDAS开发好分布式应用，减少大量开发工作，应用可以是服务提供者，也可以是服务消费者，也可以两者都是。
2、应用生命周期管理
3、链路调用监控
实际的大型系统中，都有很复杂的业务链路调用，如果将单体应用重构为分布式应用后，没有一套良好的监控体系，在系统出现问题时定位问题将会异常困难。如图是一个实际场景下的链路调用：
EDAS 鹰眼监控系统能够分析分布式系统的每一次系统调用、消息发送和数据库访问，从而精准发现系统的瓶颈和隐患。
4. 单机进程内方法追踪
当当当当~~
最新重量级功能隆重登场：方法追踪。
让你以火箭般的速度，打通应用诊断的“最后一公里”。EDAS基础版里即可使用~嘘~
EDAS 方法追踪能够帮助用户在应用运行时出现问题时，进行快速的问题排查，典型的场景包括：
- 应用运行时突然发现执行某一个业务逻辑耗时很长，此时希望能够有一种方式定位运行时代码各个部分的耗时，以确定耗时点在什么地方。
- 应用运行时一切正常，绝大部分情况下，业务运行都非常顺畅，但某一例用户反馈，当传入XXX参数时，业务响应非常缓慢。此时希望能够有一种方式针对特定的方法入参来观察代码执行情况。
- 一个比较复杂的程序方法，其中业务逻辑较为复杂，在真正运行时，无法确定具体调用了那些逻辑，以及调用时序。此时希望能够有一种方式详细的展现出方法执行的具体逻辑、时序等。
此外，以上的任何一种场景，都希望代码无入侵，可以在应用运行时不停机的情况下，定位问题。
EDAS 方法追踪采用 JVM 字节码增强的技术，对选中方法的所有方法调用增加必要的耗时与调用序列记录的增强，从而达到观看执行过程中的具体执行序列的目的。
EDAS 单击进程内方法追踪和RPC框架无关，属于 EDAS 基础版功能，提升用户应用诊断能力。方法追踪是对当前分布式调用链路追踪的补充，解决在使用调用链路追踪功能定位到单机某一个服务的问题后，进一步诊断该服务方法本地执行的时序细节、各执行环节的耗时、入参/返回值和异常情况。
X公司开发案例实战
像开头说到的，当系统到达一定规模后，软件复杂度急剧增加，维护也将变得异常艰难。如何用挽救X公司于水深火热之中？下图是将业务拆分后一部分业务架构：
其中，将资产中心和鉴权中心采用docker部署的方式，docker部署的方式可以支持一台服务器上部署多个应用，这样也有利于节省硬件成本，提高资源利用率。
业务开发
代码工程划分
整体思路是提供一个公共的接口应用，作为公共引入的jar包（这只是其中一种开发模式），其他每个应用一个工程，采用maven工程的模式来开发。本地开发时，如果几个应用工程都在同一个环境下，可以将几个groupId都指向同一个，方便调试。下图是工程划分：
接口应用开发
在接口应用中将需要被不同应用引用的实体以及需要对外暴露的接口都定义好。如图所示
创建好后eclipse工程如截图：
部分代码片段：
引入接口工程
将tradeshop-api工程打成jar包发布到maven仓库，在其他三个工程pom文件引入：
资产中心开发
资产中心要实现的业务是能够被交易中心调用、获取资产信息，所以资产中心需要做的是实现获取资产信息的接口业务，并且用hsf标签对外注册提供服务。例如简单的业务实现代码为：
代码实现后，就需要将服务对外暴露，供服务消费端来调用：
需要注意的是，发布的服务中version和group固定了，那么消费端在调用的时候，这两者的值必须保持统一。
鉴权中心开发
鉴权中心实现的业务是提供对外的接口用来查询鉴权信息，那么也是需要对外暴露一个服务，开发方式跟资产中心类似，可以参考资产中心的开发。
交易中心开发
交易中心需要有两方面的作用，一是对外暴露服务用于查询交易信息，一个是充当消费端，主动去调用其他服务。充当服务端的代码开发模式和前两个应用类似，充当消费端去调用资产中心和鉴权中心的，就可以采用spring bean加载的方式获取到接口service，然后当做本地方法来调用，如核心代码：
将依赖的服务和需要发布的服务配置，注意版本号和分组值，以及接口名不能写错。
用户中心开发
用户中心在本案例中充当业务入口，去调用交易服务，所以用户中心只需要注册消费一个服务即可：
消费代码：
业务验证
参考EDAS官网文档，创建好应用，并成功将应用部署到线上后，可以在EDAS控制台上很方便的进行业务验证，链路跟踪，也就能很方便的定位到平时业务之间链路的瓶颈所在。查看创建及发布应用的文档
应用服务验证
当应用部署成功后，可以在控制上看到提供的服务和调用的服务，也可以在应用控制台上看到业务运行的日志，如截图所示
同样也可以查看到应用中的http服务、hsf服务信息：
服务链路验证
通过链路监控，可以很直观的监控到整个业务调用的状态，及时的定位到问题出现的地方
好了，一套简单的分布式应用系统就开发完成了，so easy！X公司的故事，也不出意外的迎来了happy ending。
相关链接
产品专家建议：各版本特色看这里
0-5个节点推荐：基础版
5-50个节点推荐：高级版
50以上推荐：专业版