Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说
从使用的角度讲,eda技术主要包括几个方面的内容?_user centered design,希望能够帮助你!!!。

晚上下班回家，想起白天有同事说到的一个叫EDAS的分布式服务框架，就去其阿里云官网看了User Guide了解下下，通过UG了解下下其基础功能，猜想下其实现。喜欢结合以前相关产品的使用体会，想尽量把里面的功能说的易懂一点。低级的视野来说高级的技术和牛B的产品。还没有用过，充其量是一个UG的读后感。对着UG上涉及的若干个重要内容，其实就是功能，记录下理解。

1. 服务化：

就是把一个大的系统垂直拆分，其实就是按照分成子模块。每个拆分的业务根据业务（可能也要考虑到负载，这个和业务也不矛盾），搞成一个个功能内聚的子系统。即使我们不做微服务，我们自己做一个系统，在系统到一定规模的时候，出于系统间功能划分的考虑，出于开发维护人员划分的考虑，我们也会这么干。至少05年的时候就看到过SOA这种说法，好像IBM当时对应的还有所谓的标准产品。

2 创建应用，

就是创建一个逻辑的应用，为这个应用选择一组ECS，每个ECS上的agent，链接EDAS控制器，这个agent负责的每台机器上会自动初始化Java环境，以及EDAS底层容器环境，可能就是一个tomcat，和用到的其他中间件的驱动吧。

3 部署应用：
就是上传一个war包，则个war包应该会被分发到这个应用绑定的多个ECS上.

4 启动应用：
通过EDAS发指令的ECS上，启动各个ECS上的web服务。并能列出来这个应用里面总共有多少个ECS在运行，每个ECS上的地址，规格（CPU内存啥的）

5 回滚应用：
看上去就是用用户自己提交的一个历史版本的war包去替换现在运行环境的。

6. 应用扩容：
就是给选定的应用里面加几ECS。（ECS应该是在工作台的另外一个地方买的，这里应该只能看到你买的属于一个地区的ECS）

7. 弹性伸缩：
也是根据应用运行情况决定要不要加几个加ECS进来。

8.监控

包括cpu mem这样的load，还有网络读写，磁盘读写这样的的主机的基础监控。还有应用的监控，包括服务提供者的qps，服务消费者的qps，都是http的。

CPU、内存和Load等维度的基础监控指标，还提供了针对HTTP入口、提供HSF服务的调用QPS和消费HSF服务的调用QPS等应用层面的监控指标

作为提供出来一种服务，即所谓的云服务，监控真的很重要。阿里云的产品的监控真的非常详细，指标维度非常多，cpu，内存的，qps这些标准的外，每秒insert行数，insert指令数，update、delete行数、指令数。单个实例的多个指标对比，多个实例的多个指标对比。慢sql日志，慢sql优化建议。真的可以帮你定位问题。一年前用的，现在还是对很多细节功能非常熟悉，真的好用。

9. 实时日志：
列出IP，文件名，catalina，多么熟悉，就是tomcat输出的日志啊。还提供个在线查看的按钮，怎么看都是点对点到连了对应ECS上的agent，去实时看远端的日志文件了。

10. 容器诊断：
能看自己的ali-tomcat的 jvm的堆、栈、加载的类

11. 限流降级：
对一个服务接口，发布出来的一个服务的一个接口方法，限制qps（应该是调用频度上限制），限制线程数（应该是调用并发数上限制）。使用时需要应用的mvn构建中依赖cglib，aop。

12. 容量规划：
对一个接口方法进行压测，对所需的机器数进行预估。其实这个接口方法快不快，除了服务的能力外，一般应该是后端的数据能力。

13，调用链分析：
使用一个叫鹰眼的系统，从用户发起的web请求，请求的服务调用的服务。，每一步的耗时，一个用户请求的调用中的服务调用的路径，和每个步骤的耗时。就像数据库的profile里，能告诉你一个sql的执行中fileter、merge、combine这些操作每个步骤的执行时间。像profile进行sql优化一样，进行服务诊断。可以看到一个请求的整个请求链路，和期望的是否相同，并且定位到最耗时的步骤。对于一个涉及了服务之间互相调用的情况来说，这个调用链分析应该是非常重要。

整体感觉下来，大家都说是一个paas形态的微服务框架。通过UG的介绍，想着之前用阿里云产品时台，UG中有限的截图都能猜到这个东西在用户的工作台上是怎么堆的。阿里云的其他产品一样。工作台就是一堆功能放在那儿、有点干巴巴，没有啥流程。好像就是一堆东西放在那儿，谁用根据自己的需要，根据口袋里的钱多少，根据自己业务需要去选择东西，选好了自己攒起来就可以了。

买ECS，有钱买好的，没钱买差的
买负载均衡SLB，选择你买好的ECS作为后端（SLB的转发的端口，ECS上自己的服务要有服务起来）

买RDS，其实就是mysql实例
买DRDS，把RDS加进来组成一个所谓可以无限水平扩展的超级强大的的分布式数据库集群，可以放一个几乎无限大的逻辑大表，用起来和一个普遍的mysql表一模一样，jdbc的协议，索引，标准sql语法（还会有特有的增强来提高性能）

不是很框架化，适应性也不像那么多开源paas那么好，就像是把自己在用的一堆东西，用一个能用的系统给堆起来。感觉上是非常不高大上（这句话不要被误解哦，其实是本人的观点是褒义的），但是比较好用，比较接地气。就是去解决自己的具体问题去的，想也是，不光 EDAS的企业级分布式应用服务，OTS、OCS、ACE、ADS、ODPS、OpenSearch、SLB这些非常牛的中间件大多也是自己业务需要，瞄着一个非常明确的目标，业务目标、性能目标做好，解决了自己问题，做通用，做独立，拿出来给租户用，收租子。而所谓paas，似乎也就是提供一个平台让用户把这些东西用起来，方便的组装自己的业务，解决自己的问题。因为中间件是经过自己系统上考验的，给用户吹的时候就比较有场景（比如著名的yunxidahui），是在的成功案例就在那儿放着。这个框架，对用开发者友好程度差点大家倒是不太有所谓了。有事需要自己等到ECS上去，执行脚本啥的，感觉封装的并不是那么好。较真讲到底是工作在云计算的那一层都不好说了。反正一年多前，有个阿里云的业务经理推销业务，说他们是没有paas的，只有中间件和Iaas。

很多中间件真的是解决自己问题下了功夫，解决的问题非常明确，性能也都很好。如用过的ODPS，也是从文档上（真正用起来看，各种文档其实也是有点简陋的）看是一个Hadoop的东西，可以根据其sdk自己写mapreduce，但是你能说的也就是他是一个类hadoop的离线分析，很大可能他已经不用hadoop了。

但其这些宣传的很牛的中间件，实际使用中也并不总是那么神奇。DRDS，也是被宣传的最厉害的一个产品，在UG的第一页EDAS架构中就一个大框表示其是多么重要的中间件。文档中宣传他们会在中间件中做多么强大的merge，多么高效的数据裁剪，但是测试中还是很容易测出他们对细微场景的处理。select count(*) 一样很慢，在非分库分表键上进行where、order by、group by的查询页很慢，一样会推荐你慎用。实例扩展也并不能自动的数据重新均衡，只是的加几个rds实例进来，甚至分库分表这样的schema都不能修改，必须要创建一个新的集群来做DTS。

前面提到了yunxidahui，还亲身经历过一次，听了一个负责一个非常牛逼的中间件的领导（google下这个这个中间件的几个字母前三个搜索记录中一定会出现这个哥哥的flower name）上讲使用这个其性能多么好，扩张性多么强，是多么容易构建强大的业务。第二天早上报个问题给他，也会回复你用法不对，现在暂时还不支持云云。

个人认为大家说他的pass好，不是框架多么高级，是其后面自己使用的中间件比较好，比较让人信赖。拿出来给别人用，因为自己真的用过了，估计中间件团队也是被产品团队骂了100回了，提了100回需求了才打磨出来的。pass是一种形态，重要的还是提供的能力，底层资源的能力，中间件的能力。这些能力帮用户解决问题。

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。