EDAS平台使用感受

EDAS 适合中小企业，提供监控，服务部署，持续集成到测试 （云效部分功能）。每样做的监控种类比较多，而且开始不断完善。之后转型duboo框架也非常方便。

大致就是提供了一个管理端界面，可以做一些普通的操作，上传服务，部署，设置一些基本参数 如JVM堆栈大小等等。但是在管理界面配置的参数不够全。还是有一定受限的。

监控方面：提供全链路监控（使用mybatis和redis的一个包（非jedis）的话提供耗时统计）、拓扑图（使用时，页面显示失败，提工单后续没有看到处理结果就1个月过期了）、日志监控（提供日志提取接口，日志关键字监控）、容器监控（服务状态监控，内存，堆栈等监控数据类似jmx）、物理机CPU 内存监控等。

部署：服务打成war包，选择edas服务器上传war包，自动部署加启动，中间部署过程不透明，通过edas的agent（类似k8s）的容器编排技术进行部署。

数据库：jdbc配置采用dns解析的方式，配置文件写入密文串，连接时 由阿里自己的dns动态解析成数据库的ip地址进行连接，从而可以运行中动态切换ip切换。

开发：把原工程的duboo相关依赖去掉后，在maven中加入hsf框架依赖的edas 包即可开始开发，原duboo的provider consumer配置只需变动为按照hsf：provider hsf：consumer进行配置(相比原有的dubbo的配置项,有部分配置无效了,类似注册中心等) 

优:
提供比原型版本更完善的hsf框架与dubbo框架
拥有完善的配置中心,动态配置并发数、连接数、服务降级、服务限流等服务治理参数，服务治理相对成熟
一键安装、工单处理事务、容器化、集成测试
持续的版本优化，最新第三方包与插件的支持
相比直接虚机启动应用，采用容器化管理应用，采用ali-tomcat作为应用服务器
全面但不完善的监控（全链路，应用，基础设施）
hsf与duboo都对业务代码基本无侵入，相互转换（脱离框架）较容易。

劣：
强制依赖阿里云edas环境，pandora、hsf、商用dubbo不开源。
服务托管部署过程不透明，排除问题难度较大，相关网络资料较少且不齐全
试用期间存在若干bug，比较影响体验
竞争对手 开源duboo重新开始维护，立刻支持最新spring4等第三方包
拥有活跃的社区和活跃人员。
管理平台并不成熟，需要开发API管理平台
依赖每台虚机上的EDAS-agent进行服务发布负责 ,EDAS 控制台与用户 ECS 之间的通信，以此来实现对应用的管理,如果agent出现故障,服务状态不可见